Comments 16
Миллениалы придумали MCP для LSP-сервера? В студии такой из коробки есть уже N лет, да и свободные реализации тоже существуют.
У меня было в планах написать именно такой инструмент. Опередили.
Я делаю похожее приложение, но с нормальной семантикой, полным графом и стат анализом. А так же бесконечное undo любых изменений, линтинг, анализ разного рода, граф по документации в связке с кодом, автодокументирование кода. Первые версии на пользователях протестил, понял что нужна максимальная автоматизация установки и использования (установка докера, запуск конфигуратора - оказывается неподёмная задача для обычного пользователя). Через пару недель доведу до нормального вида и поделюсь.
Так вот, у меня на предварительной версии сейчас такие цифры по swift-репо (на ноутбучной RTX5060):
Парсинг 4 393 файла с кодом в 143 101 сущности с 458 201 связями (в 5 раз больше структурных данных чем в CodeGraph/Socrati) – 2,2 сек
Индексация с предобучением и записью в БД – 2.8 сек
Генерация 170 332 вектора ембеддингов – 38 сек. (4 376 emb/s) С учётом всех доп-процессов (prolly, trigram, etc) на все процессы от старта до завершения = 60 сек (инкрементные изменения 50-100мс).
4 минуты на базовые связи - это очень долго. Если запустить CodeGraph/Socrati на проекты типа postgesql, chromium, dawn, aspnet (3M LOC), то оно мне кажется помрёт в конвульсиях…
Всё гораздо сложнее в разработке таких приложений, чем просто взять доступный парсер и векторную бд.
Для IDE семейства IDEA давно существует "pycharm-index" и его близнецы. Решает ту же задачу, но через встроенные инструменты IDE. Найти всех наследников, объявления или использования класса\метода - моментально. Плюс умеет в умное переименование и перемещение, а также забирает результаты диагностики IDE, подхватывая ошибки синтаксиса, дублирование и прочее.
На монорепо в 200к строк TypeScript пробовали разные подходы, сейчас смотрим в сторону статического анализа как раз. Интересно что у CodeGraph нет эмбеддингов, то есть поиск только структурный, по символам и связям. Это хорошо для "кто вызывает эту функцию", но как оно справляется с семантическим поиском типа "где у нас обрабатывается авторизация", когда сам код называется не auth а permission_check или middleware_guard? Это та граница где vector-подход выигрывает, интересно как авторы видят это ограничение.
Такие случаи в CodeGraph/Socrati нормально не обрабатываются. Для корректной работы таких запросов нужен и связанный многогранный граф и семантическое соответствие и дополнительные алгоритмы поиска “часто используется рядом с…” с предразбивкой всего составного в коде на токены и потом прогон по новым найденным дополнительным графам в связке с семантикой и второй круг - совмещение всех графов в один с реранкингом. Если делать это “прямолинейно” на 200к строк, то потребует 30Гб RAM и один запрос будет 10 мин колбасить (слишком много прогонов по всему дереву с перебором). Конкретно когда я решал проблему, то было много “шаманства” на каждом этапе (их примерно десяток в этом запросе), но получилось до 50-100мс сократить.
А что насчёт совмещения подходов? Первый запрос в вектор, а оттуда, найдя конкретные определения/имена - уже расширять контекст через lsp
Я иногда бегаю по репе во времени, вы не знаете, как в этом случае будет вести себя Claude? Можно ли этим инструментом иметь несколько графов?
С подключением.
Не хочу вас разочаровывать, но строить ast дерево все попробовали ещё в 2024 и бросили, так как это не работает.
Если без шуток, AST был лучше банального grep где то во времена chatgpt4.
Для себя когда-то выделял такие пункты обоснования для НЕ развития AST подхода:
1) AST описывает синтаксис, а агенту нужны смысл и намерение - структура вызовов не объясняет, зачем код существует и что сломается при изменении.
2) Гранулярность не совпадает с задачей: уровень выражений слишком мелкий, уровень функций слишком крупный, а смысловой кусок в дерево не ложится.
3) LLM сами хорошо парсят сырой код. Прогон через AST и обратную сериализацию только теряет сигнал (комментарии, форматирование, идиоматику).
4) Релевантный контекст обычно не лежит в соседних узлах - нужна семантическая близость, а не синтаксическая.
5) Важная часть контекста вообще вне кода: коммиты, тикеты, доки, логи, рантайм-поведение, тесты.
6) AST требует валидного кода, тогда как агенты постоянно работают со сломанным и недописанным состоянием.
7) Полезные вещи (резолв символов, типы, поток данных) - не AST, а семантический анализ поверх, и фактически означают написание language server'а.
8) На практике выигрывает гибрид: эмбеддинги для поиска по смыслу + LSP/индексы для точечных запросов + git/доки как отдельные источники + сырой код напрямую в модель с хитрым RAG и пояснением кода за счёт мульт модальности. Но стоит это слишком дорого.
Есть еще codealive.ai
У меня успешно работает на проекте 44.4 MB
Скрытый текст
Крутая идея и схема работы. Я нашел CodeGraph самостоятельно, запустил, проверил и только потом увидел ваш пост. В любом случае Большое Спасибо и Удачи! p.s. Да, вектора пригодятся и особенно для работы со сложными фреймворками, пакетами, библиотеками. Вызовы всех функций будет долго проверять логическим путем. Вообще проект немного напоминаем знаменитый дизассемблер IDA Ильфака Гильфанова. С ним идут мощным базы данных всех системных вызовов всех ОС и компиляторов. Скорее всего нечто подобное скоро должно появиться и с CodeGraph.
я всё прочитал
Ллм, а не ты, ровно как и статью написала слоп машина
CodeGraph: граф кода для Claude Code вместо grep по файлам. Разбираю архитектуру и проверяю бенчмарки