Comments 7
Спасибо, интересная статья.
Если есть возможность, выложите пожалуйста скил, как вы настроили (включили) такую память. Я пока с этим не сталкивался.
И ещё классно было бы добавить ссылку на гитхаб с такими файлами и оглавлением как у вас. Это позволит более наглядно понять, как работает память в вашем случае и, может быть, сделать у себя также. Если там есть чувствительные данные, можно будет их обезличить перед этим)
Спасибо! Отдельного скила-плагина тут нет, это скорее протокол: обычная папка с md-файлами, один всегда подгружаемый индекс (MEMORY.md) и короткая инструкция в конфиге проекта, которая велит модели читать индекс на старте и дописывать новый факт отдельным файлом. Само “включение” - буквально пара правил в CLAUDE.md, никакой механики поверх модели. Собрал обезличенный пример с оглавлением, форматом файлов и самим блоком-протоколом, плюс промпт, чтобы агент развернул это у себя сам: https://github.com/mngerasimenko/keepware-llm-lab
Поддерживаю. Образ "мышления" модели человеческий. Предполагаю, ее поиск по оглавлению в один-два уровня будет качественней, чем RAG. Скажем, так - это разные инструменты. В большинстве случаев человек откроет доки по оглавлению, а не ищет по всей базе документов сходу.
И еще мне не понятно стремление использовать RAG в кодовой базе. Проводились какие-то тесты его эффективности?
RAG - это поиск по вектору "смысла". Для обычных текстов эта штука может быть эффективна. Где-то, наверное, вообще незаменима, в какой-нибудь юридической базе документов. Но код - это жестко детерменированный синтаксис. Там не нужен "смысл", он очень хорошо грепается регулярками. А для совсем большой кодовой базы есть другие индексы, заточенные на регулярки. Или заточенные прямо на синтаксис конкретного языка. Зачем тут вектора "смысла"? Тем более, они по чанкам, а "смысл" порезанного кода, это вообще нечто странное...
Возможно, я не прав, это все исключительно рассуждения без практики. Интересно было бы почитать о каких-либо реальных тестированиях на эту тему.
Согласен по коду - синтаксис детерминирован, grep и индекс по символам/AST бьют точнее, чем вектор “смысла” по нарезанным чанкам. Формального A/B “RAG против грепа” я честно не гонял: выбор тут не из бенчмарка, а иуме для другого з практики - на моих объемах оглавление плюс grep стабильно находят нужное без отдельной инфраструктуры и без риска, что чанк порвет смысл.
Доброго времени!) Спасибо за разбор! Отказ от векторных БД в пользу zero-infra на малых масштабах - отличный подход. Вопрос по архитектуре: как вы решаете коллизии, когда на один description претендуют сразу 2–3 смежных Markdown-файла (например, общее правило и специфическое под проект)? Не начинает ли харнесс в этот момент галлюцинировать или дропать тела из-за лимитов контекста?
Спасибо, хороший вопрос. Автоматического разрешения коллизий тут нет: description - не уникальный ключ, а короткая подсказка в оглавлении. Модель читает оглавление и сама решает, какой файл открыть; если тема на стыке общего и частного, обычно открывает оба и сводит их - частное уточняет общее, “победителя” механизм не выбирает. Чтобы такие пересечения не плодились, при записи держим правило “одно понятие - один файл” и перед созданием нового проверяем, нет ли уже подходящего. Это ручная аккуратность, а не авто-магия, и это, пожалуй, главная цена подхода против векторной базы, которая ранжирует за тебя. Про контекст можно не волноваться: на старте грузится только оглавление, тела подтягиваются по запросу - открыть два-три смежных файла это маленькое точечное чтение, а не заливка всего в контекст, ничего не дропается. Когда оглавление разрастается, его делят на несколько частей по темам.
Память агента без вектор-БД: 363 markdown-файла вместо эмбеддингов