Membina Satu Graf Pengetahuan Merentasi 46 Repositori

Saya Ryan, CTO di airCloset.

Saya menghabiskan masa selama tiga bulan membina code-graph. Ia merupakan satu graf pengetahuan tunggal yang menyatukan 46 repositori merentasi pelbagai perkhidmatan.

Ramai orang berfikir anda boleh menyerahkan semua kod anda kepada AI dan bertanya soalan. Ini gagal atas dua sebab:

  • Tetingkap konteks (Context windows): Anda tidak boleh memuatkan kod bertahun-tahun daripada 46 repos ke dalam satu prom.
  • Halusinasi: AI melakukan kesilapan apabila ia cuba membuat inferens tentang hubungan. Ia terlepas sambungan yang ada.

Untuk menyelesaikan masalah ini, saya menggunakan analisis statik untuk membina sumber kebenaran (source of truth).

Cabaran: Merentasi Sempadan

Kod asas (codebase) yang besar adalah berserabut. Satu API mungkin dipanggil oleh lima repositori yang berbeza. Satu jadual pangkalan data mungkin digunakan oleh tiga perkhidmatan yang berbeza.

Jika anda hanya melihat satu repositori, anda akan terlepas gambaran penuh. Ini berbahaya. Jika anda mengubah kod dan tidak melihat radius impak (blast radius) yang sebenar, anda akan merosakkan sistem.

Pendekatan saya menggunakan tree-sitter untuk menghuraikan (parse) kod kepada pokok sintaks (syntax trees). Namun, tree-sitter sahaja tidak dapat melihat merentasi sempadan repositori.

Saya membina nod sempadan (boundary nodes) untuk menyelesaikan masalah ini.

Cara ia berfungsi:

  • Kami mengekstrak hubungan dalam satu repo menggunakan tree-sitter.
  • Kami menggunakan TypeScript Compiler API untuk menyelesaikan jenis (types) dan pemboleh ubah (variables).
  • Kami menggunakan Gemini untuk mengendalikan kes dinamik yang terlepas oleh alatan lain.

Daripada meminta AI untuk meneka, kami memberikannya fakta. Kami memberitahunya: "API ini juga dipanggil daripada Repo X." Ini menghalang halusinasi.

Bahagian yang Sukar: Zoo Rangka Kerja (Framework Zoo)

Pertempuran sebenar adalah untuk mengekstrak sempadan ini. Setiap rangka kerja (framework) menulis sempadan dengan cara yang berbeza.

Satu pasukan menggunakan dekorator NestJS. Pasukan lain menggunakan laluan (routes) Express. Pasukan lain pula menggunakan jQuery mentah. Setiap satu mencipta struktur yang berbeza dalam kod.

Untuk menjayakannya, kami perlu membina penghurai (parsers) tersuai untuk:

  • NestJS dan TypeORM
  • Express dan Fastify
  • AngularJS dan Redux
  • Pelbagai skema alias-laluan (path-alias schemes)

Kami perlu menyasarkan ketepatan 99%. Jika kadar sambungan kami hanya 90%, AI akan terlepas 10% sambungan. Dalam sistem pengeluaran (production system), 10% itulah tempat pepijat (bugs) bersembunyi.

Kami kini menjalankan semakan harian. Jika kadar sambungan kami jatuh lebih daripada 5%, kami akan menerima amaran. Ini dapat mengesan apabila corak kod baharu merosakkan penghurai kami.

Had Semasa

Graf ini tidak sempurna.

  • Carian adalah sukar. Anda sering perlu mengetahui nama fungsi untuk memulakan carian anda.
  • Letupan nod (Node explosion). Mengikuti satu laluan boleh menarik masuk beribu-ribu fungsi pembantu (helper functions) yang kecil dan tidak berguna.
  • Penyelenggaraan. Setiap kali rangka kerja baharu memasuki stack kami, kami mesti menulis penghurai baharu.

Ini adalah Bahagian 1. Dalam Bahagian 2, saya akan membincangkan lapisan graf-produk-perkhidmatan (service-product-graph atau SPG) yang saya bina untuk menutup jurang ini.

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

Komuniti pembelajaran pilihan: https://t.me/GyaanSetuAi