Языковая модель знает «интернет вообще», но не знает вашу базу знаний: прайс, регламенты, документацию, историю клиента. Если спросить её напрямую — она уверенно придумает ответ. RAG (retrieval-augmented generation) закрывает этот разрыв: модель отвечает не из памяти, а по найденным в ваших документах фрагментам.
Разберём, как устроен RAG-конвейер, где в нём теряется точность и где он действительно нужен бизнесу, а где — лишняя сложность.
Зачем нужен RAG
У чистой LLM три проблемы для бизнеса: она не знает ваших данных, выдаёт правдоподобные, но неверные ответы (галлюцинации) и не умеет ссылаться на источник. RAG решает всё три сразу — ответ собирается из конкретных фрагментов ваших документов, и к нему можно приложить ссылку на первоисточник.
- Ответы основаны на ваших актуальных документах, а не на «знаниях вообще»
- Каждый ответ можно проверить — видно, из какого документа он собран
- Обновить знания = обновить документы, а не переобучать модель
Как устроен конвейер
RAG состоит из двух контуров. Индексация (один раз и при обновлениях): документы режутся на фрагменты-чанки, каждый превращается в эмбеддинг — вектор смысла — и кладётся в векторную базу. Ответ (на каждый вопрос): вопрос тоже превращается в вектор, по базе ищутся ближайшие чанки, и модель формирует ответ строго на их основе.
В коде это выглядит как два шага: retrieve(query) возвращает top-k релевантных фрагментов, а generate(query, context) просит модель ответить, не выходя за пределы переданного контекста.
Где ломается точность
Качество RAG определяется не моделью, а retrieval-контуром. Если поиск принёс не те фрагменты, даже лучшая модель ответит мимо. Главные рычаги точности:
- Чанкинг. Слишком крупные чанки размывают смысл, слишком мелкие теряют контекст. Режем по смысловым границам, а не по символам.
- Гибридный поиск. Векторный поиск ловит смысл, но промахивается по точным терминам, артикулам и аббревиатурам. Связка с ключевым поиском (BM25) закрывает это.
- Реранкер. Отдельная модель переупорядочивает найденные фрагменты по релевантности перед отправкой в LLM — это заметно поднимает попадание.
В RAG за качество отвечает поиск, а не модель. Сильная LLM на плохом контексте — это уверенный неправильный ответ.
Свежесть и доступы
Два требования, которые отличают демо от продакшна. Свежесть: индекс должен обновляться при изменении документов — иначе агент будет уверенно отвечать по устаревшему регламенту. Доступы: сотрудник не должен через чат увидеть документ, к которому у него нет прав, — фильтрация по правам встраивается прямо в этап поиска.
Где RAG нужен, а где нет
RAG оправдан там, где знание большое, меняется и важна точность: поддержка по продукту, ответы по внутренней базе, помощь менеджеру по прайсу и условиям. Где он избыточен: десяток типовых вопросов FAQ — там проще сценарий, без векторной базы.
Мы внедряем RAG на вашем стеке, с хранением данных в РФ и явными границами: что агент отвечает сам, а что эскалирует человеку. Как это считается в деньгах клиента — в наших кейсах.