Немного про RAG

Кратко о том, что такое RAG (Retrieval-Augmented Generation).

Поскольку у LLM нет долговременной памяти, а размер контекста не позволяет поместить туда все нужные документы, придумали следующее: из запроса пользователя с помощью ряда ухищрений (например: "Вот запрос, предположи, как может выглядеть ответ на него" - да-да, именно так, это называется HyDE) и других приёмов формируют запрос в БД (да ещё и, как правило, в векторную или, прости господи, графовую).

Получают список документов, по большей части имеющих слабое отношение к запросу, сортируют их, фильтруют (всё той же LLM) и добавляют в контекст. После этого LLM мудро смотрит на доставленный ей мусор и выдаёт на выходе бред. Garbage in, garbage out.

Беда не в качестве поиска. Беда в том, что это фиксированный пайплайн: один прогон, одна выдача, никакой обратной связи. Что нашлось, с тем и живём.

На маленькой и чистой базе так работает что угодно, поэтому демо заказчику получается хорошее. Главное потом, после внедрения, вовремя удрать за горизонт.

В общем-то, идея просто использовать grep не сказать чтобы оригинальна, но её часто понимают неправильно. Нужен не просто grep, а агентский цикл, в котором есть и чёткий поиск по точной строке, и нечёткий по шаблону. Если у вас терабайт документов, грепать их так себе идея: берите Elastic, ts_vector или даже векторные эмбеддинги, если у вас картинки)

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

Примерно так мы и ищем в гугле: меняем подход в зависимости от того, что нашли, а не вводим ключевое слово и тыкаем в первую ссылку. Заметьте, под этим лежит очень недешёвый индекс. Цикл нужен поверх хорошего поиска, а не вместо него.

Обычно возражают: агентский цикл дорого и долго. Соглашусь, и добавлю третье: ещё и ненадёжно, слабая модель его просто не вытянет. Это архитектура для сильных моделей, а не способ на них сэкономить.

Но альтернатива - быстро, дёшево и дерьмово.