RAG и база знаний — термины простыми словами

RAG — это самый практичный способ сделать ассистента, который отвечает по вашим документам и меньше “додумывает”. Вместо того чтобы надеяться на память модели, система находит релевантные куски в вашей базе знаний и подкладывает их в контекст перед ответом. Так ответы становятся точнее, а риски галлюцинаций — ниже. Ниже — основные термины RAG, которые помогут понимать, как это работает и где чаще всего ломается.

RAG (Retrieval-Augmented Generation)

RAG — это подход, где генерация ответа подкрепляется поиском по вашим источникам: документам, регламентам, базе знаний, FAQ. Сначала система ищет релевантные фрагменты, затем передаёт их модели как контекст, и только после этого модель формулирует ответ. Это сильно снижает “уверенные выдумки”, потому что модель опирается на конкретные источники. В бизнесе RAG обычно быстрее и безопаснее, чем дообучение: вы обновили документы — и ответы обновились.

• Зачем в бизнесе: ассистент отвечает по вашим правилам и документам, а не “по общим знаниям”.
• Пример: бот поддержки отвечает по политике возвратов, вытаскивая нужный пункт из регламента.
• Частая ошибка: думать, что RAG = “просто загрузить PDF” и всё будет идеально без настройки поиска.

Retrieval / Поиск (извлечение)

Retrieval — этап, где система находит релевантные куски информации в базе знаний. Поиск может быть разным: по словам, по смыслу, гибридный, с фильтрами по разделам и датам. От retrieval зависит половина качества: если нашли не то, модель ответит красиво, но неправильно. Поэтому retrieval — это не “внутри модели”, а отдельный инженерный компонент, который нужно измерять и улучшать.

• Зачем в бизнесе: находить правильные источники быстрее, чем человек листает документы.
• Пример: по запросу “как вернуть товар” система находит раздел “Возвраты” и конкретный пункт условий.
• Частая ошибка: использовать поиск “как получится” без тестов на реальных вопросах.

База знаний (Knowledge Base)

База знаний — это ваши источники правды: регламенты, инструкции, FAQ, карточки товаров, документы, ответы поддержки, внутренние правила. Главное требование к базе знаний — актуальность и единый порядок: иначе ассистент будет отвечать по старым версиям или по противоречивым кускам. В RAG база знаний должна быть “для машины”: структурированной, без мусора, с понятными заголовками и датами. Чем лучше база, тем дешевле и точнее RAG.

• Зачем в бизнесе: быстро масштабировать поддержку и внутренние ответы, не теряя качество.
• Пример: корпоративный помощник отвечает сотрудникам по инструкциям и регламентам.
• Частая ошибка: держать знания в хаотичных файлах “как у всех на диске” и ждать точного поиска.

Источник (Source)

Источник — это конкретный документ или страница, откуда берётся фрагмент для ответа. В бизнесе важно знать “откуда взялось”: это повышает доверие и позволяет быстро исправлять ошибки. Если ассистент всегда показывает источник, вы можете обновить документ и сразу улучшить ответы. Без источников RAG превращается в “поверьте мне на слово”, а это плохая стратегия для поддержки и регламентов.

• Зачем в бизнесе: прозрачность, доверие, быстрые правки и контроль.
• Пример: в ответе указано: “Регламент возвратов, пункт 3.2”.
• Частая ошибка: не хранить связь ответа с источником — невозможно понять, где исправлять.

Индексация (Indexing)

Индексация — это подготовка базы знаний для быстрого поиска: документы режутся на части, превращаются в представление для поиска и сохраняются в индекс. Индексация нужна, чтобы retrieval работал быстро и стабильно. В реальных проектах индексация — это не разовое действие: документы меняются, значит индекс нужно обновлять. Если индекс устарел, ассистент будет отвечать по “вчерашним правилам”.

• Зачем в бизнесе: быстрый поиск и актуальные ответы по свежим документам.
• Пример: обновили прайс — переиндексация — ответы по ценам стали актуальными.
• Частая ошибка: забыть про обновление индекса и получать устаревшие ответы.

Chunk / Чанк (фрагмент)

Чанк — это кусок текста, на который вы режете документы для поиска. Слишком маленькие чанки теряют смысл (нет контекста), слишком большие — ухудшают точность поиска и раздувают токены. Хороший чанк обычно совпадает с логическими блоками: пункт, подраздел, ответ FAQ. Чанки — это одна из главных ручек качества RAG, поэтому их обычно подбирают тестами.

• Зачем в бизнесе: чтобы поиск находил конкретный ответ, а не “где-то рядом”.
• Пример: разделить регламент на пункты и подпункты, а не на случайные 1000 символов.
• Частая ошибка: резать документ “по длине”, игнорируя структуру и заголовки.

Chunking / Разбиение на чанки

Chunking — процесс разбиения документов на чанки с учётом структуры, заголовков и логики. В идеале chunking сохраняет смысловой блок целиком и добавляет минимальные “склейки” для контекста. Хороший chunking снижает ошибки, потому что модель получает цельный фрагмент, а не кусок из середины абзаца. В бизнесе chunking особенно важен для регламентов, договоров и инструкций, где одна фраза без соседнего пункта может означать противоположное.

• Зачем в бизнесе: повысить точность RAG и снизить риск неверных трактовок.
• Пример: пункт “исключения” всегда попадает в тот же чанк, что и правило.
• Частая ошибка: разрывать важные условия на разные чанки и терять контекст.

Overlap / Перекрытие чанков

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

• Зачем в бизнесе: меньше случаев, когда ассистент “не видит” ключевую фразу.
• Пример: конец пункта повторяется в начале следующего чанка на 1–2 предложения.
• Частая ошибка: делать слишком большой overlap и получать много одинаковых фрагментов.

Embeddings / Эмбеддинги

Эмбеддинги — это числовое представление смысла текста (вектор), с помощью которого система может искать “по смыслу”, а не по точным словам. Благодаря эмбеддингам запрос “вернуть товар” может найти текст “оформление возврата” даже без совпадения слов. Это основа семантического поиска в RAG. В бизнесе эмбеддинги дают большой прирост качества для живого языка клиентов, где формулировки постоянно разные.

• Зачем в бизнесе: находить релевантные ответы, даже если пользователь формулирует по-другому.
• Пример: “как отменить заказ” → находится “аннулирование заявки” в регламенте.
• Частая ошибка: считать, что эмбеддинги решают всё — без хороших чанков и фильтров качество всё равно будет плавать.

Вектор (Vector)

Вектор — это массив чисел, который представляет текст, документ или запрос в пространстве смыслов. Вектора сравнивают между собой, чтобы понять, “похоже ли по смыслу”. В RAG вектор есть у запроса и у каждого чанка; поиск выбирает ближайшие вектора. Для бизнеса смысл простой: так ассистент находит похожее по смыслу, а не только по словам.

• Зачем в бизнесе: семантический поиск по реальным формулировкам клиентов.
• Пример: разные фразы клиентов попадают в один “смысловой кластер” и находят один и тот же пункт.
• Частая ошибка: не контролировать качество поиска и думать, что “вектора сами разберутся”.

Vector Database / Векторная база данных

Векторная база данных — хранилище, которое умеет быстро искать ближайшие вектора (то есть похожие по смыслу чанки). Она хранит эмбеддинги и метаданные: источник, раздел, дата, язык, доступы. В бизнесе векторная база — это часть инфраструктуры RAG, которая отвечает за скорость и качество извлечения. Важно правильно настроить метаданные, иначе поиск будет находить “похоже”, но из неправильного раздела или устаревшую версию.

• Зачем в бизнесе: быстрый смысловой поиск по базе знаний.
• Пример: фильтр “только актуальная версия регламента 2026” + поиск по смыслу.
• Частая ошибка: хранить всё без метаданных и потом получать “правильный смысл, но не тот документ”.

Metadata / Метаданные

Метаданные — это служебные поля для чанка: источник, раздел, дата, тип документа, язык, права доступа, версия. Метаданные позволяют фильтровать поиск и делать его точнее: “только политика возвратов”, “только прайсы”, “только русские документы”. Без метаданных поиск становится слишком общим и чаще ошибается. Для бизнеса метаданные — это способ заставить RAG отвечать по правильному документу и правильной версии.

• Зачем в бизнесе: точнее ответы, меньше конфликтов и меньше устаревшей информации.
• Пример: не показывать внутренние документы внешнему клиенту по правам доступа.
• Частая ошибка: не вести версии и даты — ассистент отвечает по старому.

Top-K / Количество извлекаемых фрагментов

Top-K — это сколько чанков система берёт из поиска и передаёт модели в контекст. Если K слишком маленький, можно не захватить нужный пункт; если слишком большой — вы раздуваете контекст, добавляете шум и повышаете стоимость. В бизнесе K подбирают тестами: важно, чтобы модель получала ровно столько источников, сколько нужно. Часто лучше 3–6 сильных фрагментов, чем 20 “почти похожих”.

• Зачем в бизнесе: баланс точности, скорости и стоимости.
• Пример: для FAQ достаточно K=3, для сложного регламента — больше.
• Частая ошибка: ставить большой K “на всякий случай” и ухудшать качество из-за шума.

Релевантность (Relevance)

Релевантность — это насколько найденный фрагмент действительно отвечает на вопрос пользователя. В RAG можно ошибиться не “в модели”, а на этапе релевантности: поиск нашёл близкое по словам, но не по смыслу. Поэтому релевантность нужно измерять на реальных вопросах и дорабатывать retrieval. Для бизнеса релевантность — это меньше неправильных ответов и меньше ручных вмешательств.

• Зачем в бизнесе: точные ответы и меньше “не по теме”.
• Пример: вопрос про возврат денег не должен приводить к фрагменту про обмен товара.
• Частая ошибка: не собирать тестовый набор вопросов и не проверять релевантность системно.

Reranking / Переранжирование

Reranking — это этап, когда система повторно сортирует найденные чанки, чтобы наверх попало самое полезное. Поиск по эмбеддингам даёт кандидатов, но не всегда лучший порядок; reranking улучшает качество выдачи. В бизнесе reranking часто даёт заметный прирост: меньше “почти подходящих” фрагментов и больше точных. Особенно полезно для длинных регламентов и похожих разделов.

• Зачем в бизнесе: повысить точность и снизить шум в контексте.
• Пример: из 10 кандидатов выбрать 4 самых релевантных и упорядочить их.
• Частая ошибка: пропускать reranking и компенсировать это большим Top-K (дорого и шумно).

Hybrid Search / Гибридный поиск

Гибридный поиск сочетает поиск по смыслу (эмбеддинги) и поиск по словам (keyword). Это полезно, когда запрос содержит точные термины, артикулы, номера пунктов, модели товара — там семантика может “плыть”. Гибридный подход обычно устойчивее: он находит и “похожее по смыслу”, и “точное совпадение”. В бизнесе это особенно важно для каталогов, прайсов, юридических формулировок и техдокументации.

• Зачем в бизнесе: меньше промахов на точных запросах и на “человеческих” формулировках.
• Пример: “пункт 3.2 возврат” → keyword + смысловой поиск по разделу возвратов.
• Частая ошибка: использовать только семантику и терять точные совпадения (номера, артикулы).

Grounding / “Приземление” ответа на источники

Grounding — это практика, когда ответ модели должен опираться на предоставленные источники, а не на фантазию. В RAG grounding означает: “отвечай только на основе найденных фрагментов; если не хватает — уточни или скажи, что данных нет”. Это ключ к снижению галлюцинаций и повышению доверия. В бизнесе grounding особенно важен для поддержки, правил, цен и любых обещаний.

• Зачем в бизнесе: меньше выдумок, больше точных и проверяемых ответов.
• Пример: “В регламенте указано… (источник: документ X, пункт Y)”.
• Частая ошибка: дать источники, но не требовать опоры на них — модель всё равно будет додумывать.

Citations / Ссылки на источники в ответе

Citations — это когда ассистент показывает, на какие документы и фрагменты он опирался. Это повышает доверие и упрощает контроль: видно, откуда взята информация. Внутри компании citations помогают быстрее обновлять базу знаний: нашли ошибку — поправили источник. Для клиентов citations полезны как “подтверждение”, что ответ не из воздуха.

• Зачем в бизнесе: прозрачность, доверие, быстрые исправления.
• Пример: “Источник: Политика возвратов, раздел 2, пункт 2.4”.
• Частая ошибка: скрывать источники — пользователи не верят, а команда не может дебажить.

Freshness / Актуальность

Актуальность — это гарантия, что ассистент отвечает по свежим правилам и последним версиям документов. В RAG актуальность достигается обновлением индекса, версиями документов и фильтрами по датам. Без контроля актуальности ассистент начинает жить “в прошлом” — особенно в ценах, условиях, регламентах. В бизнесе актуальность — это не косметика, а снижение конфликтов и ошибок.

• Зачем в бизнесе: не отвечать по устаревшим условиям и не создавать претензии.
• Пример: “только документы версии 2026-02” участвуют в поиске.
• Частая ошибка: не переиндексировать базу и не вести версии документов.

Контекстная сборка для RAG (Context Packing)

Контекстная сборка — это как вы кладёте найденные фрагменты в запрос к модели: порядок, заголовки, отделение источников, краткие выжимки. Даже хорошие чанки можно “убить” плохой сборкой: смешали всё в кашу, и модель выбрала не то. В бизнесе правильная сборка делает ответы стабильнее и снижает риск, что модель возьмёт неправильный пункт. Сборку обычно стандартизируют: одинаковый формат для всех запросов.

• Зачем в бизнесе: предсказуемость ответа и меньше ошибок из-за путаницы источников.
• Пример: “Источник 1 (заголовок, дата) → цитата → источник 2 → цитата → инструкция ответа”.
• Частая ошибка: вставлять фрагменты без заголовков и контекста, а потом удивляться неверной интерпретации.

No Answer / “Нет ответа в базе”

No answer — это корректное поведение системы, когда в найденных источниках нет информации для ответа. В RAG это лучше, чем выдумка: ассистент должен уточнить вопрос, попросить документ или передать человеку. Для бизнеса это критично: лучше честное “нужны данные”, чем уверенный неправильный ответ. Правило “no answer” обычно задают в системных инструкциях и проверках.

• Зачем в бизнесе: снижать риск ошибок и претензий, особенно в правилах и ценах.
• Пример: “В базе знаний нет пункта про это. Уточните…, или я передам специалисту.”
• Частая ошибка: заставлять ассистента отвечать всегда, даже когда данных нет.