Модель обучена на общих данных из интернета и ничего не знает про вашу компанию: ни базы знаний, ни документации, ни свежих новостей после её обучения. Спросишь про внутренний регламент — она либо признается, что не знает, либо выдумает правдоподобный ответ. RAG решает эту проблему: он находит нужные куски ваших данных и подмешивает их в запрос, чтобы модель отвечала по фактам, а не по памяти.
Почему нельзя просто «загрузить всё»
Первая наивная мысль — вставить в промпт весь корпус документов. Не выйдет: окно контекста конечно, туда не влезут гигабайты, а лишний текст ещё и путает модель и дорого стоит. Значит, на каждый вопрос нужно класть в контекст только релевантные куски. Задача сводится к поиску: как из большого корпуса быстро достать именно то, что относится к вопросу?
Эмбеддинги: текст как вектор смысла
Обычный поиск по ключевым словам плохо справляется: пользователь спрашивает «как вернуть товар», а в документе написано «оформление возврата покупки» — слова разные, смысл один. Здесь помогают эмбеддинги.
Эмбеддинг — это превращение текста в вектор (длинный список чисел), который кодирует его смысл. Ключевое свойство: тексты, близкие по смыслу, получают близкие векторы, даже если слова разные. «Вернуть товар» и «оформление возврата» окажутся рядом в этом пространстве смыслов, а «рецепт борща» — далеко.
Семантический поиск
Раз смысл стал вектором, поиск похожего становится геометрией. Все куски документов заранее переводят в эмбеддинги и складывают. Приходит вопрос — его тоже переводят в вектор и ищут ближайшие векторы кусков. Это и есть семантический поиск: находим не по совпадению слов, а по близости смысла. Хранят эти векторы и ищут ближайшие в векторной базе данных — о ней отдельная статья.
Как собирается RAG
RAG (retrieval-augmented generation — «генерация, дополненная поиском») складывает всё вместе в два этапа.
Подготовка (заранее): документы режут на куски (чанки) разумного размера, каждый кусок переводят в эмбеддинг и складывают в векторную базу. Это индексация базы знаний.
Ответ (на каждый вопрос):
- вопрос пользователя переводят в эмбеддинг;
- семантическим поиском достают несколько самых релевантных кусков;
- эти куски подмешивают в промпт вместе с вопросом и инструкцией «отвечай только по этим фрагментам»;
- модель формулирует ответ, опираясь на факты, а не на память.
Результат — ответы по вашим актуальным данным, со ссылками на источники, и заметно меньше выдумок: модели дали факты и попросили не выходить за их пределы.
Грабли, о которых надо знать
- качество кусков решает всё. Плохо порезали документы (слишком крупно или мелко) — поиск достаёт нерелевантное, и ответ портится. Чанкинг — не мелочь.
- RAG не отменяет проверку. Даже с фактами в контексте модель может исказить их при пересказе; ответ всё равно проверяют, а источники показывают пользователю.
- свежесть индекса. Данные меняются — индекс надо обновлять, иначе модель отвечает по устаревшим кускам.
Где это применяется
RAG — самый частый способ построить полезную LLM-фичу на своих данных: чат по документации и базе знаний, поддержка, отвечающая по регламентам, поиск по внутренним данным «человеческим языком», ассистент по кодовой базе. Почти любая фича «спроси мою систему на естественном языке» под капотом — это RAG.
Коротко
- Модель не знает ваших данных; RAG находит релевантные куски и кладёт их в промпт, чтобы она отвечала по фактам.
- Эмбеддинг превращает текст в вектор смысла: близкие по смыслу тексты — близкие векторы, даже при разных словах.
- Семантический поиск достаёт нужные куски по близости векторов, а не по совпадению слов; хранят их в векторной базе.
- RAG = заранее проиндексировать корпус (чанки → эмбеддинги), а на вопрос — найти релевантное и подмешать в промпт. Это резко снижает выдумки.
- Грабли: качество чанкинга, обновление индекса и всё та же проверка ответа.
Дальше — векторные базы данных: где и как хранят эмбеддинги и ищут ближайшие векторы на масштабе.