Память агента без вектор-БД: 363 markdown-файла вместо эмбеддингов

[LyuMih]

Спасибо, интересная статья.

Если есть возможность, выложите пожалуйста скил, как вы настроили (включили) такую память. Я пока с этим не сталкивался.

И ещё классно было бы добавить ссылку на гитхаб с такими файлами и оглавлением как у вас. Это позволит более наглядно понять, как работает память в вашем случае и, может быть, сделать у себя также. Если там есть чувствительные данные, можно будет их обезличить перед этим)

[kuza2000]

Поддерживаю. Образ "мышления" модели человеческий. Предполагаю, ее поиск по оглавлению в один-два уровня будет качественней, чем RAG. Скажем, так - это разные инструменты. В большинстве случаев человек откроет доки по оглавлению, а не ищет по всей базе документов сходу.

И еще мне не понятно стремление использовать RAG в кодовой базе. Проводились какие-то тесты его эффективности?

RAG - это поиск по вектору "смысла". Для обычных текстов эта штука может быть эффективна. Где-то, наверное, вообще незаменима, в какой-нибудь юридической базе документов. Но код - это жестко детерменированный синтаксис. Там не нужен "смысл", он очень хорошо грепается регулярками. А для совсем большой кодовой базы есть другие индексы, заточенные на регулярки. Или заточенные прямо на синтаксис конкретного языка. Зачем тут вектора "смысла"? Тем более, они по чанкам, а "смысл" порезанного кода, это вообще нечто странное...

Возможно, я не прав, это все исключительно рассуждения без практики. Интересно было бы почитать о каких-либо реальных тестированиях на эту тему.

[gotham_engineer]

Доброго времени!) Спасибо за разбор! Отказ от векторных БД в пользу zero-infra на малых масштабах - отличный подход. Вопрос по архитектуре: как вы решаете коллизии, когда на один description претендуют сразу 2–3 смежных Markdown-файла (например, общее правило и специфическое под проект)? Не начинает ли харнесс в этот момент галлюцинировать или дропать тела из-за лимитов контекста?