Membangun Satu Knowledge Graph di Seluruh 46 Repositori

Saya Ryan, CTO di airCloset.

Saya menghabiskan tiga bulan untuk membangun code-graph. Ini adalah sebuah knowledge graph tunggal yang menyatukan 46 repositori di berbagai layanan.

Banyak orang berpikir Anda bisa memberikan semua kode Anda ke AI dan mengajukan pertanyaan. Hal ini gagal karena dua alasan:

  • Context windows: Anda tidak bisa memasukkan kode selama bertahun-tahun dari 46 repositori ke dalam satu prompt.
  • Halusinasi: AI membuat kesalahan saat mencoba menyimpulkan hubungan. AI melewatkan koneksi-koneksi yang ada.

Untuk mengatasi hal ini, saya menggunakan analisis statis untuk membangun sebuah sumber kebenaran (source of truth).

Tantangan: Melintasi Batasan

Basis kode yang besar itu berantakan. Satu API mungkin dipanggil oleh lima repositori yang berbeda. Satu tabel database mungkin digunakan oleh tiga layanan yang berbeda.

Jika Anda hanya melihat satu repositori, Anda akan kehilangan gambaran utuhnya. Ini berbahaya. Jika Anda mengubah kode dan tidak melihat blast radius yang sebenarnya, Anda akan merusak sistem.

Pendekatan saya menggunakan tree-sitter untuk mengurai kode menjadi syntax trees. Namun, tree-sitter saja tidak dapat melihat melintasi batasan repositori.

Saya membangun boundary nodes untuk mengatasi hal ini.

Cara kerjanya:

  • Kami mengekstrak hubungan di dalam sebuah repo menggunakan tree-sitter.
  • Kami menggunakan TypeScript Compiler API untuk menyelesaikan tipe dan variabel.
  • Kami menggunakan Gemini untuk menangani kasus dinamis yang terlewatkan oleh alat-alat lain.

Alih-alih meminta AI untuk menebak, kami memberinya fakta. Kami memberitahunya: "API ini juga dipanggil dari Repo X." Ini mencegah halusinasi.

Bagian Sulit: Kerumitan Berbagai Framework

Pertarungan sebenarnya adalah mengekstrak batasan-batasan ini. Setiap framework menulis batasan dengan cara yang berbeda.

Satu tim menggunakan dekorator NestJS. Tim lain menggunakan rute Express. Tim lainnya menggunakan jQuery mentah. Masing-masing menciptakan struktur yang berbeda dalam kode.

Agar ini berhasil, kami harus membangun parser khusus untuk:

  • NestJS dan TypeORM
  • Express dan Fastify
  • AngularJS dan Redux
  • Berbagai skema path-alias

Kami harus menargetkan akurasi 99%. Jika tingkat koneksi kami hanya 90%, AI akan melewatkan 10% koneksi. Dalam sistem produksi, 10% itulah tempat bug bersembunyi.

Kami sekarang menjalankan pemeriksaan harian. Jika tingkat koneksi kami turun lebih dari 5%, kami akan menerima peringatan. Ini berguna untuk mendeteksi saat pola kode baru merusak parser kami.

Batasan Saat Ini

Graph ini tidak sempurna.

  • Pencarian sulit dilakukan. Anda sering kali perlu mengetahui nama fungsi untuk memulai pencarian.
  • Ledakan node (node explosion). Mengikuti sebuah jalur dapat menarik ribuan fungsi pembantu (helper functions) kecil yang tidak berguna.
  • Pemeliharaan. Setiap kali framework baru masuk ke dalam stack kami, kami harus menulis parser baru.

Ini adalah Bagian 1. Di Bagian 2, saya akan membahas lapisan service-product-graph (SPG) yang saya bangun untuk memperbaiki celah-celah ini.

Source: https://dev.to/ryantsuji/building-one-knowledge-graph-across-46-repositories-with-static-analysis-part-1-egm

Optional learning community: https://t.me/GyaanSetuAi