Building One Knowledge Graph Across 46 Repositories

Я Райан, CTO в airCloset.

Я потратил три месяца на создание code-graph. Это единый граф знаний, который объединяет 46 репозиториев в различных сервисах.

Многие думают, что можно просто отдать весь свой код ИИ и задавать вопросы. Это не работает по двум причинам:

  • Контекстные окна: Вы не сможете уместить годы кода из 46 репозиториев в один промпт.
  • Галлюцинации: ИИ совершает ошибки, когда пытается вывести взаимосвязи. Он упускает соединения.

Чтобы решить эту проблему, я использовал статический анализ для создания единого источника истины (source of truth).

The Challenge: Crossing Boundaries

Большая кодовая база хаотична. Один API может вызываться пятью разными репозиториями. Одна таблица базы данных может использоваться тремя разными сервисами.

Если смотреть только на один репозиторий, вы упускаете общую картину. Это опасно. Если вы измените код и не увидите реальный радиус поражения (blast radius), вы сломаете систему.

Мой подход использует tree-sitter для парсинга кода в синтаксические деревья. Но один лишь tree-sitter не может видеть связи за пределами репозиториев.

Чтобы решить эту проблему, я создал граничные узлы (boundary nodes).

How it works:

  • Мы извлекаем связи внутри репозитория с помощью tree-sitter.
  • Мы используем TypeScript Compiler API для разрешения типов и переменных.
  • Мы используем Gemini для обработки динамических случаев, которые пропускают инструменты.

Вместо того чтобы просить ИИ угадывать, мы даем ему факты. Мы говорим ему: «Этот API также вызывается из Repo X». Это предотвращает галлюцинации.

The Hard Part: The Framework Zoo

Настоящая битва развернулась при извлечении этих границ. Каждый фреймворк описывает границы по-своему.

Одна команда использует декораторы NestJS. Другая — маршруты Express. Третья — чистый jQuery. Каждый из них создает свою структуру в коде.

Чтобы это заработало, нам пришлось создать кастомные парсеры для:

  • NestJS и TypeORM
  • Express и Fastify
  • AngularJS и Redux
  • Различных схем псевдонимов путей (path-alias schemes)

Нам нужно было стремиться к точности 99%. Если уровень связей составляет всего 90%, ИИ упускает 10% соединений. В рабочей системе (production) именно в этих 10% прячутся баги.

Теперь мы проводим ежедневную проверку. Если уровень связей падает более чем на 5%, мы получаем оповещение. Это позволяет вовремя заметить, когда новые паттерны кода ломают наши парсеры.

Current Limitations

Граф не идеален.

  • Поиск затруднен. Часто нужно знать название функции, чтобы начать поиск.
  • Взрыв узлов. Переход по пути может подтянуть тысячи крошечных, бесполезных вспомогательных функций.
  • Поддержка. Каждый раз, когда в наш стек входит новый фреймворк, нам приходится писать новый парсер.

Это часть 1. В части 2 я расскажу об уровне графа «сервис-продукт» (service-product-graph, SPG), который я создал, чтобы устранить эти пробелы.

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