Russian
Работая с клиентами мы часто сталкиваемся с вопросом: «Объясни по-человечески, что такое RAG и как его собрать, чтобы работало в бизнесе?». Мы решили дать простое объяснение, чтобы было понятно каждому.
Если по пути останутся белые пятна, то дайте знать в комментариях. Обновим материал, развернем спорные места и добавим практики из реальных внедрений.
Retrieval-Augmented Generation — это способ заставить большую языковую модель отвечать не «из головы», а на основе актуальных фактов. Суть проста, мы к вопросу пользователя добавляем найденные извне сведения (из базы знаний, файлов, веб-источников) и уже весь этот комплект отдаём LLM. В результате модель опирается на контекст и даёт точный, проверяемый ответ.
Если например мы спросим: «какой средний рост у императорского пингвина?» то, сначала нужен источник правды — энциклопедия, экспертные сайты и.т.п. — а уже затем этот фрагмент подкладывается к вопросу. Модель не угадывает — она читает.
Плохая идея — постоянно дообучать модель на FAQ, который меняется каждую неделю. Дорого и ненадёжно. Гораздо лучше, по вопросу находить релевантные статьи и прикладывать их кусочки к запросу. Модель формирует ответ, опираясь на актуальные разделы базы знаний.
Именно это и описывает название: retrieval (поиск фактов) → augmentation (добавление к запросу) → generation (формирование ответа с учётом найденного).
- Режем документы на чанки — небольшие фрагменты по 100–1000 слов.
- Кодируем чанки в векторы (эмбеддинги) — получаем числовое представление смысла.
- Складываем в векторное хранилище — чтобы быстро искать ближайшие по смыслу фрагменты.
- Находим топ-N подходящих чанков к конкретному вопросу (обычно по косинусной близости).
- Собираем подсказку для LLM: системная инструкция + вопрос пользователя + найденные куски.
- Получаем ответ, где модель опирается не на память, а на предоставленные факты.
На бумаге выглядит элементарно. На практике — почти всегда первая версия работает «не так». Дальше начинается тот самый тюнинг.
Но, дьявол кроется в деталях. Давайте посмотрим на размер и перекрытие чанков:
Комбинированный поиск, ведь один векторный поиск — не серебряная пуля. Для терминов и формулировок помогут BM25/TF-IDF. Частая схема — hybrid retrieval: объединяем результаты «по смыслу» и «по словам» с весами, найденными на ваших данных.
Расширение запроса (query expansion) Перефразируйте вопрос 3–5 способами (автоматически) и ищите по всем вариантам. Так повышаете шанс достать нужный контент, даже если оригинальная формулировка была «не как в документации».
Сжатие (summarization) и переупаковка Если найденного слишком много и в контекст всё не лезет — делайте выжимку по каждой группе похожих фрагментов и отдавайте модельке уже «архив знаний», а не простыню текста.
Режим RAG для модели Системной подсказкой (а на зрелом этапе — лёгким дообучением) объясните формат: вопрос тут, факты тут, отвечай только на основании фактов; если их мало — скажи об этом. Это снижает «галлюцинации» и дисциплинирует ответы.
- Подготовьте корпус: PDF/HTML/Markdown → чистый текст.
- Разрежьте на чанки с перекрытием (например, 300–600 слов, overlap 50–100 слов).
- Постройте эмбеддинги и положите во векторное хранилище.
- Реализуйте гибридный ретривер: вектора + BM25/TF-IDF, задайте веса.
- Соберите промпт: инструкция → вопрос → топ-k чанков.
- Добавьте логирование: какой вопрос, какие чанки, какой ответ. Без трассировки RAG не улучшается.
Чтобы понять, что модель стала лучше отвечать, нужен набор реальных вопросов. Как правило их пишет бизнес — те, кто действительно будет пользоваться ассистентом. Желательно несколько ответов на один вопрос, написанные людьми. Если запуск срочный, можно сначала сгенерировать эталоны моделью-ассистентом на небольших документах, а потом вручную подправить. Смешайте несколько (ROUGE/BERT-подобные) в одну агрегированную. Главное — подобрать веса по вашей предметной области.
Сохраните пары «вопрос → эталонные чанки» и меряйте MRR. В 8 случаях из 10 качество финального ответа ломается именно на этапе поиска, а не генерации.
Ждем ваши вопросы и замечания!
Работая с клиентами мы часто сталкиваемся с вопросом: «Объясни по-человечески, что такое RAG и как его собрать, чтобы работало в бизнесе?». Мы решили дать простое объяснение, чтобы было понятно каждому.
Если по пути останутся белые пятна, то дайте знать в комментариях. Обновим материал, развернем спорные места и добавим практики из реальных внедрений.
Retrieval-Augmented Generation — это способ заставить большую языковую модель отвечать не «из головы», а на основе актуальных фактов. Суть проста, мы к вопросу пользователя добавляем найденные извне сведения (из базы знаний, файлов, веб-источников) и уже весь этот комплект отдаём LLM. В результате модель опирается на контекст и даёт точный, проверяемый ответ.
Если например мы спросим: «какой средний рост у императорского пингвина?» то, сначала нужен источник правды — энциклопедия, экспертные сайты и.т.п. — а уже затем этот фрагмент подкладывается к вопросу. Модель не угадывает — она читает.
Плохая идея — постоянно дообучать модель на FAQ, который меняется каждую неделю. Дорого и ненадёжно. Гораздо лучше, по вопросу находить релевантные статьи и прикладывать их кусочки к запросу. Модель формирует ответ, опираясь на актуальные разделы базы знаний.
Именно это и описывает название: retrieval (поиск фактов) → augmentation (добавление к запросу) → generation (формирование ответа с учётом найденного).
- Режем документы на чанки — небольшие фрагменты по 100–1000 слов.
- Кодируем чанки в векторы (эмбеддинги) — получаем числовое представление смысла.
- Складываем в векторное хранилище — чтобы быстро искать ближайшие по смыслу фрагменты.
- Находим топ-N подходящих чанков к конкретному вопросу (обычно по косинусной близости).
- Собираем подсказку для LLM: системная инструкция + вопрос пользователя + найденные куски.
- Получаем ответ, где модель опирается не на память, а на предоставленные факты.
На бумаге выглядит элементарно. На практике — почти всегда первая версия работает «не так». Дальше начинается тот самый тюнинг.
Но, дьявол кроется в деталях. Давайте посмотрим на размер и перекрытие чанков:
Комбинированный поиск, ведь один векторный поиск — не серебряная пуля. Для терминов и формулировок помогут BM25/TF-IDF. Частая схема — hybrid retrieval: объединяем результаты «по смыслу» и «по словам» с весами, найденными на ваших данных.
Расширение запроса (query expansion) Перефразируйте вопрос 3–5 способами (автоматически) и ищите по всем вариантам. Так повышаете шанс достать нужный контент, даже если оригинальная формулировка была «не как в документации».
Сжатие (summarization) и переупаковка Если найденного слишком много и в контекст всё не лезет — делайте выжимку по каждой группе похожих фрагментов и отдавайте модельке уже «архив знаний», а не простыню текста.
Режим RAG для модели Системной подсказкой (а на зрелом этапе — лёгким дообучением) объясните формат: вопрос тут, факты тут, отвечай только на основании фактов; если их мало — скажи об этом. Это снижает «галлюцинации» и дисциплинирует ответы.
- Подготовьте корпус: PDF/HTML/Markdown → чистый текст.
- Разрежьте на чанки с перекрытием (например, 300–600 слов, overlap 50–100 слов).
- Постройте эмбеддинги и положите во векторное хранилище.
- Реализуйте гибридный ретривер: вектора + BM25/TF-IDF, задайте веса.
- Соберите промпт: инструкция → вопрос → топ-k чанков.
- Добавьте логирование: какой вопрос, какие чанки, какой ответ. Без трассировки RAG не улучшается.
Чтобы понять, что модель стала лучше отвечать, нужен набор реальных вопросов. Как правило их пишет бизнес — те, кто действительно будет пользоваться ассистентом. Желательно несколько ответов на один вопрос, написанные людьми. Если запуск срочный, можно сначала сгенерировать эталоны моделью-ассистентом на небольших документах, а потом вручную подправить. Смешайте несколько (ROUGE/BERT-подобные) в одну агрегированную. Главное — подобрать веса по вашей предметной области.
Сохраните пары «вопрос → эталонные чанки» и меряйте MRR. В 8 случаях из 10 качество финального ответа ломается именно на этапе поиска, а не генерации.
Ждем ваши вопросы и замечания!
Другие публикации автора
Share
Share
