Память AI-агента часто начинают строить с RAG, embeddings и vector DB, будто без этого агент немедленно всё забудет. Контрпример с Habr показывает более полезный порядок действий: сначала обычные файлы, затем измерения и лишь потом новая инфраструктура, если файлы действительно перестали справляться.
Это не спор markdown против баз данных. Это спор преждевременной архитектуры с архитектурой, которую продукт уже заслужил нагрузкой.
Что произошло
Автор Habr описал систему из восьми агентов с постоянной памятью. В ней больше 360 markdown-файлов, около 1,4 МБ текста, ни одной векторной базы и ни одного рассчитанного эмбеддинга.
От vector DB он отказался не случайно. По его словам, вопрос о внедрении поднимался трижды, каждый раз рассматривался конкретный кандидат, но решение оставалось прежним: отдельный векторный слой пока не окупается.
Автор утверждает, что точка окупаемости vector store находится примерно около десяти тысяч документов, а не нескольких сотен. До этого порога владелец системы платит за дополнительную инфраструктуру, эмбеддинг-модель и риск рассинхронизации индекса, хотя обычный markdown решает ту же задачу. В статье также заявлена двухслойная схема и семантический поиск без эмбеддингов, но из опубликованного описания нельзя оценить их механику и качество извлечения.
Последняя оговорка важна. Перед нами рабочий контрпример, а не универсальный бенчмарк. Число в десять тысяч документов пока разумнее считать авторским инженерным порогом, который предстоит проверять на своём корпусе.
Почему файлы могут выиграть
Главная ценность подхода не в расширении .md. Markdown здесь убирает целый класс компонентов: не нужно отдельно считать embeddings, поднимать vector DB и следить, совпадает ли индекс с актуальной памятью агента. Сама память остаётся набором читаемых человеком документов.
Для небольшого или персонального агента это сильный размен. Поиск можно улучшать внутри существующей файловой схемы, обновление памяти сводится к изменению исходного документа, а перенос системы не требует отдельно перевозить базу и восстанавливать индекс. Если агент записал ерунду, оператор может открыть файл и увидеть её без специальной панели наблюдаемости. Простота тут не эстетика, а уменьшение числа мест, где система способна тихо разъехаться сама с собой.
Есть и экономический эффект, хотя источник не даёт цифр для его оценки. Пока embeddings не считаются, а отдельное хранилище не обслуживается, у проекта меньше инфраструктурных расходов и инженерных обязанностей. Для команды на ранней стадии это часто важнее теоретически более умного поиска: компонент, который не пришлось внедрять, не ломается и не требует миграции.
Но markdown не становится от этого бесплатной вечной памятью. По мере роста корпуса поиск может начать пропускать нужные фрагменты, задержка может увеличиться, а структура файлов превратиться в ручную онтологию, которую понимает только её автор. Именно здесь vector DB может перестать быть модным ритуалом и стать оправданным инструментом.
Что это меняет для билдера
Не стоит выбирать vector DB в день, когда у агента появился первый файл памяти. Сначала полезнее собрать корпус в простой форме и завести набор контрольных запросов: какие воспоминания агент обязан находить, какие не должен смешивать и сколько времени допустимо тратить на извлечение.
Дальше решение принимается не по размеру презентации провайдера, а по трём показателям: полнота извлечения на контрольном наборе, задержка поиска и время от обновления документа до появления новой информации в ответе агента. Четвёртый показатель организационный: сколько часов уходит на поддержку памяти и исправление ошибок.
Конкретный маркер на будущее: проверяйте эти показатели после каждого заметного роста корпуса. Если файловая схема стабильно пропускает нужные факты, не укладывается в допустимую задержку или требует всё больше ручной разметки, vector DB наконец заработала право появиться в архитектуре. Пока этого не произошло, 363 markdown-файла выглядят не кустарным компромиссом, а дисциплинированным отказом платить за проблему, которой ещё нет.