Комментарии 8
Пустой, только что созданный репозиторий без мр...
Как в DSP решается конфликт актуальности между графом структур данных и реальным кодом при быстрых/массовых изменениях (много PR в день, рефакторинг модуля)? Насколько сильно отстаёт «долговременная память» и кто/как принудительно синхронизирует?
Семантический поиск по графу + LLM-инференс для ранжирования — это быстро и дёшево? Каков типичный latency и стоимость одного осмысленного запроса по большому репозиторию (10k–100k файлов) при использовании DSP?
Версионируемость графа структур выглядит красиво на бумаге, но как обрабатываются merge-конфликты в самом графе при слиянии веток, особенно если разные ветки по-разному переименовывали/рефакторили одни и те же сущности?
Кажется grepai решает проблему быстрее одним запросом в мсп получает либо нужный метод, либо текст, либо дерево вызовов. Правда настраивается сложнее: нужно локально поднять небольшую модель, проиндексировать проект, подключить и главное заставить через хуки Claude Code пользоваться именно семантическим поиском вместо базовых Glob/Grep утилит.
Исходный проект: https://github.com/yoanbernabeu/grepai
Плагин под ClaudeCode где решена проблема выбора инструмента через хуки и автоматизированная установка: https://github.com/kochetkov-ma/claude-brewcode
Привет, спасибо за интересный подход! А вы не пробовали работать с библиотекой https://github.com/ruvnet/ruvector ? Там используется интересный подход, позволяющий строить локальный RAG и GNN, который дообучает веса в зависимости от запросов к сущности (насколько я правильно понял). Было бы здоров использовать это совместно с вашим подходом описания (де факто) спеки репозитория для ускорения поиска по ней и экономии контекстного окна

Data Structure Protocol (DSP): как дать LLM-агентам «долговременную память» о большом репозитории