Есть одна странная вещь в разработке.

Пока задача в работе, вокруг неё много живого контекста. Что хотели сделать. Почему выбрали именно такое решение. Что обсуждали в комментариях. Какие были ограничения. Что поменялось в коде. Где приняли компромисс.

А потом задача закрывается.

Код остаётся. Контекст исчезает.

Через несколько месяцев кто-то открывает этот участок кода и пытается понять, что здесь вообще происходило. Иногда этот кто-то - ты сам.

Начинается мини-расследование. Нужно найти задачу, открыть Merge Request, перечитать комментарии, вспомнить, где лежали требования, посмотреть diff и попытаться отделить осознанные решения от случайных следов прошлых итераций.

Я решил начать свой путь в RAG именно с этой проблемы.

Не с векторных баз. Не с embeddings. Не с красивых схем с агентами.

А с более практичного вопроса: как сделать так, чтобы после задачи оставался не только код, но и понятное описание того, что было реализовано, почему и на основании каких источников?

Сейчас я собираю небольшой MVP, который берёт Merge Request, изменения в коде, задачу, документацию и обсуждения, а потом формирует описание реализации.

Для меня важно, чтобы это был не просто красивый текст от модели.

Важно видеть, откуда взялась информация. Что подтверждается кодом. Что подтверждается обсуждением. Где есть уверенность. Где данных не хватает. Что лучше проверить человеку.

По сути, идея в том, чтобы превращать рабочий контекст в аккуратный слой знаний.

Такой, к которому можно вернуться через месяц, через полгода или перед следующим похожим изменением.

И вот здесь RAG становится намного более прикладной историей.

Не “давайте подключим модель ко всем документам и будем задавать вопросы”.

А “давайте перестанем терять знания, которые команда уже однажды создала в процессе работы”.

Мне кажется, хороший RAG начинается не с embeddings.

Он начинается с дисциплины вокруг источников, контекста и доверия к тому, что сгенерировано.