Чем заменить векторную базу для памяти AI-агента: Git + Markdown

Когда AI-агент должен помнить контекст диалога, первое, что приходит в голову — поднять векторную базу данных. Красиво, современно, но часто избыточно. Один архитектор пошёл другим путём: использовал Git для управления историей и Markdown для хранения. Никаких новых сервисов, никаких затрат — и всё прозрачно.

Почему векторные базы тут вообще ни при чём

Векторные БД решают задачу семантического поиска по большим массивам текста. А память агента в типичном сценарии — это несколько последних диалогов, которые можно просто прочитать. Для такого объёма эмбеддинги, индексы и кластеры — как болид «Формулы-1» для поездки в соседний магазин. Быстро, но дорого и неудобно парковаться.

Проблема даже не в деньгах. Сама инфраструктура превращается в отдельный источник багов: то соединение отвалилось, то миграция схемы сломалась. А ещё такой стек сложно отлаживать — попробуй объясни коллеге, почему агент «забыл» что-то, если всё лежит в векторном индексе.

Идея: Git для памяти, Markdown для формата

Вместо новой базы данных автор использует то, что уже есть у каждого разработчика. Git даёт версионирование, а Markdown — читаемый текст.

• Git как ядро. История разговора становится коммитами. Можно посмотреть diff между версиями, откатить неудачное «мышление» агента, вернуться к прежнему состоянию — всё как с обычным кодом.
• Markdown как хранилище. LLM отлично парсит разметку, а человек может открыть файл и увидеть, что именно агент запомнил. Никаких бинарных форматов и загадочных таблиц.
• Ноль затрат и портативность. Модуль подключается к внутренним инструментам без расходов на обслуживание базы. Переносится куда угодно.

Сравнение: векторная БД против Git + Markdown

Как это выглядит на практике

Берёшь Git-репозиторий, заводишь папку с Markdown-файлами. Каждый диалог — отдельный файл. Каждое новое сообщение или важная мысль — коммит. Агент при обращении к памяти просто читает нужные файлы, а не делает запрос с эмбеддингами.

Что даёт такой подход в работе:

• видно, когда агент «подумал неправильно» — достаточно посмотреть diff;
• можно откатиться к состоянию до неудачного разговора;
• легко чистить память — удалил файл, и всё;
• никаких зависимостей, всё работает даже на самой дешёвой виртуалке.

Когда так делать не стоит

Если у агента память на тысячи документов, нужен семантический поиск по смыслу или ты строишь RAG на огромной базе знаний — без векторной БД не обойтись. Git и Markdown не умеют «находить похожее» в большом корпусе.
Но для хранения контекста разговора, истории диалогов и внутреннего состояния агента — это идеальный вариант. Честно, банальный вариант, который почему-то многие пропускают.

Почему это не «игрушка», а рабочий подход

Главный аргумент не в том, что векторы плохие. А в том, что для мелкой задачи не нужна тяжёлая артиллерия. Git и Markdown — это не экзотика, а стандартные инструменты. Их не надо отдельно разворачивать, они не сломаются в пятницу вечером, и их сможет поддерживать любой разработчик.

Поэтому, когда в следующий раз захочешь добавить агенту «память», сначала спроси себя: тебе нужна база данных или просто файл с историей? Иногда Git — уже всё, что нужно.