RAG для малого бизнеса: когда он нужен и когда это лишнее

Расшифровка без терминов

RAG это аббревиатура. Retrieval Augmented Generation. Если по-русски, агент перед тем как ответить, сначала ищет релевантные документы в твоей базе, а потом формулирует ответ опираясь на них.

Зачем это нужно. LLM сам по себе знает то что было в интернете до даты обучения. Он не знает твой прайс, твои договоры, твои политики возвратов, твою документацию на продукт. Если ты спросишь агента сколько стоит твой курс, он выдумает цифру или признается что не знает.

RAG решает это. Ты даёшь агенту доступ к твоим документам. Агент перед ответом ищет в них нужный кусок и отвечает основываясь на нём.

Когда это реально нужно

У тебя большая база знаний. Инструкции по продуктам, типовые вопросы, юридические документы, прайсы с сотнями позиций. Всё это не влезет в один промпт. Нужен механизм который умеет находить правильный кусок под каждый вопрос. Это RAG.

У тебя частые обновления. Прайс меняется, появляются новые товары, меняются условия. Если это зашито в промпт, его надо постоянно переписывать. Если это в базе, достаточно обновить документ, агент сразу начнёт использовать свежую версию.

У тебя вопросы требуют точности. Юридические консультации, медицинская информация, финансовые расчёты. Здесь нельзя позволить модели выдумывать. RAG заставляет её опираться на реальные документы и снижает риск галлюцинаций.

Когда RAG это излишество

У тебя пять типовых вопросов и пять типовых ответов. Их проще зашить в промпт и не городить векторную базу.

У тебя сценарий где агент не отвечает по знаниям, а выполняет действия. Например, создаёт задачи в CRM, отправляет письма, ищет в базе заказов. Это не RAG, это function calling.

У тебя пилот на две недели. Собирать RAG под пилот значит потратить время на инфраструктуру которая может не дожить до продакшена. Начни с простого промпта с документами внутри, если заработает, потом сделаешь RAG.

Как я это делаю в K + AI Studio

Технически у меня типовой стек. Документы клиента разбиваю на чанки по 500-800 токенов с перекрытием. Эмбеддинги через мультиязычную модель которая хорошо работает с русским. Храню в Qdrant локально. При каждом запросе ищу 5-7 самых релевантных фрагментов и кладу их в промпт.

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

Типичные ошибки

Первая: взять стандартную эмбеддинг-модель без тестов. Для английского текста работает что угодно. Для русского качество сильно варьируется. Я всегда прогоняю тест: 20 реальных вопросов клиента, смотрю какие чанки находит каждая модель, выбираю лучшую.

Вторая: не обновлять базу. Клиент загружает документы один раз, через полгода прайс поменялся, агент отвечает устаревшее. Я делаю автоматическое обновление либо учу клиента запускать ресинхронизацию.

Третья: забывать про фильтры. Если у клиента разные продукты, одна база для всех это каша. Я делаю фильтрацию по метаданным: категория продукта, язык, тип документа. Это драматически улучшает качество поиска.

Что делать тебе

Если у тебя уже работает агент без RAG и он отвечает нормально, не трогай. Не надо добавлять сложность ради сложности.

Если у тебя есть реальная проблема "агент не знает наших документов", тогда RAG это правильный инструмент и он окупится.

Хочешь понять нужен ли RAG в твоём случае, напиши в t.me/kulmashev, опиши ситуацию, я скажу честно стоит или нет.