Из чего собран RAG: эмбеддинги, поиск, нарезка
🤔 Зачем это читать
Подрядчик подключил тебе AI-ассистента к базе знаний компании — мануалы, регламенты, ответы поддержки. На демо красота: спросил — получил точный ответ со ссылкой на документ. Запустили на сотрудниках. И тут начинается: на половину вопросов ассистент отвечает уверенно, но мимо. Спрашиваешь подрядчика «почему?», а в ответ — «это RAG, там эмбеддинги и векторный поиск, сложная технология, надо дотюнивать». Звучит как заклинание. Ты киваешь и платишь за «дотюнивание», не понимая, что чинят.
Знакомо? Или другой вариант: ты сам слышал слово «RAG» на конференции, понял, что это «AI, который отвечает по твоим документам», и на этом всё. Магия. А раз магия — значит, либо работает, либо нет, и повлиять ты ни на что не можешь.
А правда в том, что RAG (от англ. retrieval-augmented generation — поиск нужных фактов в базе перед ответом) — это не магия, а понятный конвейер из трёх шагов. И каждый шаг можно сделать хорошо или испортить. Когда ассистент отвечает невпопад, дело почти никогда не в «слабой модели» — дело в том, что один из трёх шагов настроили криво. Не понимаешь шаги — не можешь ни спросить, что чинят, ни проверить, починили ли.
После этой темы ты сможешь назвать три части RAG своими словами и понимать, какой шаг за что отвечает. Не чтобы самому это строить — а чтобы перестать видеть в нём чёрный ящик и начать задавать вопросы, на которые подрядчику придётся отвечать по делу.
Задержись на 10 секунд. Вспомни какой-нибудь толстый документ со своей работы — регламент, инструкцию, договор на сорок страниц. Если бы тебе нужно было быстро находить в нём ответ на конкретный вопрос, ты бы стал перечитывать его целиком каждый раз? Или как-то разложил бы по полочкам? Держи эту мысль: ровно с неё начинается первый шаг RAG.
🍲 Сначала — один маленький пример, без терминов
Прежде чем называть шаги умными словами, давай разберём один живой случай — медленно, за руку. Дальше всё станет на свои места.
Представь нашу кухню (напомню: повар — это языковая модель, а ты — владелец ресторана). У повара есть огромная картотека — мы её завели в прошлом модуле, когда говорили про длинную память (6.2 — Короткая и длинная память). Это умная картотека по смыслу (vector DB): она находит карточки не по точному слову, а по смыслу запроса.
К повару подходит официант с заказом гостя: «хочу прозрачный навар из птицы». Повар идёт к картотеке. В картотеке нет ни одной карточки со словами «прозрачный навар из птицы». Но есть карточка «куриный бульон». Слова совсем другие — ни одно не совпало. А смысл — тот же самый. И картотека выдаёт повару именно эту карточку. Повар кладёт её на стол и готовит ответ, опираясь на неё, а не на «то, что когда-то слышал».
Вот это всё — нахождение нужной карточки по смыслу и подкладывание её повару — и есть RAG в миниатюре. А теперь разложим, из чего этот фокус собран. Тут три шага, и они идут именно в таком порядке.
🔪 Шаг первый — нарезка (chunking): режем документы на карточки
Откуда вообще в картотеке взялись карточки? Кто-то их туда положил — заранее, до всех вопросов. И вот первое неочевидное решение: в картотеку кладут не целые документы, а куски.
Представь: у тебя есть толстенный талмуд — полное руководство ресторана на триста страниц. Можно ли запихнуть его в картотеку одной карточкой «вот вам вся книга»? Технически да. Но толку ноль: гость спросил про один соус, а ты суёшь повару всю книгу — ищи сам. Поэтому книгу режут на куски-карточки: один рецепт — одна карточка, один регламент — одна, один пункт договора — одна. Это и называется нарезка (chunking) — деление документов на куски-карточки.
И тут — первая точка, где всё может сломаться. Резать надо по смыслу, а не как попало. Разрежешь рецепт ровно посередине — и на одной карточке окажется «возьмите две луковицы», а на другой, оторванной, «...и тушите сорок минут». По отдельности обе карточки бесполезны: непонятно, что тушить и куда класть лук. Плохо нарезал — и сколько потом ни ищи, цельного ответа в картотеке просто нет, он разорван между двумя обрывками.
Запомни этот образ. Карточки вместо талмуда. Не «вся книга разом», а аккуратные куски по одному смыслу на каждом. От того, насколько ровно нарезали, напрямую зависит, найдётся ли потом цельный ответ. Это незаметная работа, которую делают один раз заранее, — и именно на ней чаще всего и спотыкаются.
🏷️ Шаг второй — эмбеддинг (embedding): подписываем полки по смыслу
Карточки нарезали. Теперь их надо разложить так, чтобы потом искать по смыслу, а не по точным словам. Как это вообще возможно — найти «куриный бульон» по запросу «прозрачный навар из птицы», если ни одно слово не совпало?
Вот фокус. Каждой карточке дают «числовой отпечаток смысла» — это и есть эмбеддинг (embedding). Представь, что вместо алфавитного порядка ты подписываешь полки в картотеке по смыслу: всё про супы — в одном углу, всё про десерты — в другом, всё про аллергии — на третьей полке. И раскладываешь так, что близкие по смыслу карточки лежат физически рядом, а далёкие — далеко друг от друга.
«Куриный бульон» и «прозрачный навар из птицы» по смыслу — почти одно и то же, значит, их отпечатки оказываются рядышком на одной полке. А «шоколадный фондан» — в другом конце комнаты. Машина не понимает слов, как мы, — но она умеет считать, насколько близко лежат два отпечатка. Близко лежат — значит, про одно и то же. Вот и весь секрет «поиска по смыслу»: не сравнение букв, а сравнение «отпечатков смысла» — насколько они рядом.
Зачем тебе, владельцу, это знать? Чтобы понимать: «ищет по смыслу» — не волшебство, а вот эта раскладка по смысловым полкам. И качество отпечатков тоже бывает разным — на плохо подписанных полках близкое по смыслу разъезжается по разным углам, и поиск промахивается.
🔎 Шаг третий — поиск (retrieval): достаём близкие карточки и кладём повару на стол
Два шага выше — это подготовка, её делают заранее: нарезали, разложили по смысловым полкам. Теперь приходит живой запрос гостя — и начинается то, что происходит в момент ответа.
Запрос «прозрачный навар из птицы» тоже превращают в такой же «отпечаток смысла». Дальше — простая геометрия: ищем в картотеке карточки, чей отпечаток лежит ближе всего к отпечатку запроса. Это и есть поиск (retrieval), а раз он идёт по смыслу, а не по словам, — его называют поиск по смыслу (semantic search). Нашлась карточка «куриный бульон» — она лежит ближе всех.
И финальный ход, ради которого всё затевалось: найденную карточку подмешивают в промпт — кладут повару на стол вместе с вопросом гостя. Теперь повар отвечает не «по памяти» (и не привирает, как сделал бы без карточки — про это была тема 2.5 — Галлюцинации), а опираясь на конкретный кусок твоего документа. Это называется заземление (grounding) — привязка ответа к источнику. А раз ответ привязан к конкретной карточке, к нему можно приложить ссылки на источники (citations): «вот откуда я это взял, страница такая-то».
Вот и всё. Никакой магии — конвейер: нарезали → подписали по смыслу → нашли нужное и подложили повару. Чтобы образ конвейера стал совсем осязаемым, посмотри на ту же логику построчно — на человеческом языке, без настоящего кода.
# --- заранее, один раз: готовим картотеку ---
карточки = нарезать(руководство_ресторана) # шаг 1: талмуд → куски по смыслу
для каждой карточки: отпечаток = снять_отпечаток_смысла(карточка) # шаг 2: эмбеддинг
картотека.разложить_по_смыслу(карточки, отпечатки)
# --- в момент каждого вопроса ---
запрос = "прозрачный навар из птицы"
нашлись = картотека.найти_ближайшие_по_смыслу(запрос) # шаг 3: поиск → «куриный бульон»
на_столе = нашлись + запрос # подмешали карточку в промпт (заземление)
ответ = повар.приготовить(на_столе)
# → ответ опирается на твой документ, и к нему можно дать ссылку на источник
⚠️ Где этот конвейер ломается
Теперь главное для тебя как владельца. Раз это конвейер из трёх шагов — значит, у него три места, где можно напортачить. И почти всегда виноват не «слабый повар» (модель), а один из этих трёх шагов.
- Сломали нарезку. Порезали документы криво — ответ оказался разорван между двумя обрывками карточек. Цельного куска в картотеке нет, и достать его неоткуда.
- Сломали раскладку по смыслу. Отпечатки плохие — близкие по смыслу карточки разъехались по разным полкам. Нужная лежит на месте, но поиск её не находит, потому что она «не рядом».
- Сломали поиск. Достали не те карточки или не достали нужную — повару на стол легло не то. Он добросовестно ответит по тому, что дали, — и ответ будет уверенным и мимо.
Заметь закономерность: на любом из трёх шагов сбой выглядит одинаково — уверенный, гладкий, но неправильный ответ. Снаружи не отличишь, какой именно шаг подвёл. Поэтому, когда подрядчик говорит «ассистент врёт, надо дотюнивать модель», правильный встречный вопрос — «а на каком шаге конвейера теряется ответ: нарезка, раскладка или поиск?». Это совсем другой разговор, чем «давайте купим модель помощнее».
Прежде чем трогать тренажёр — проверь себя на одной фразе. Скажи вслух своими словами, что делает каждый из трёх шагов: нарезка, эмбеддинг, поиск. Какой из них происходит заранее, а какой — в момент вопроса? Не подсматривай. Подержи свой ответ в голове: сейчас в тренажёре дам тебе живые симптомы «ассистент ответил мимо» — и по каждому надо будет угадать, какой именно шаг подвёл. Сразу станет видно, где образ уже сложился, а где ещё плывёт.
🎮 Какой шаг сломался?
Узнавать заученную формулировку легко — а вот разобрать живой симптом сложнее и полезнее. Ниже шесть ситуаций: ассистент отвечает не так, как надо. По каждой реши своими словами, на каком шаге конвейера сбой — нарезка, эмбеддинг (раскладка по смыслу) или поиск. Жми кнопку — сразу увидишь разбор. Это не экзамен, а способ проверить, понимаешь ли ты, какой шаг за что отвечает.
📖 Ключевые понятия
- RAG (retrieval-augmented generation)
- Поиск нужных фактов в базе перед ответом. Не магия, а конвейер из трёх шагов: нарезка → эмбеддинг → поиск. Повар отвечает не «по памяти», а опираясь на найденную карточку из твоих документов.
- Нарезка (chunking)
- Первый шаг: деление документов на куски-карточки. В картотеку кладут не талмуд целиком, а отдельные куски по одному смыслу на каждый. Криво нарезал — ответ разорван между обрывками.
- Эмбеддинг (embedding)
- Второй шаг: «числовой отпечаток смысла» карточки. Близкие по смыслу карточки получают близкие отпечатки и ложатся на смысловые полки рядом. Это и позволяет искать по смыслу, а не по словам.
- Поиск (retrieval) и поиск по смыслу (semantic search)
- Третий шаг, в момент вопроса: находят карточки, чей отпечаток ближе всего к отпечатку запроса. Раз ищет по смыслу, а не по точным словам — это поиск по смыслу. «Прозрачный навар из птицы» → «куриный бульон».
- Векторная база / умная картотека по смыслу (vector DB)
- Хранилище карточек, разложенных по смысловым полкам. Та самая умная картотека из темы про длинную память — здесь видно, что у неё внутри.
- Заземление (grounding) и ссылки на источники (citations)
- Заземление — привязка ответа к источнику: найденную карточку подмешивают в промпт, и повар опирается на неё. Раз ответ привязан к куску документа, к нему можно приложить ссылку на источник — «вот откуда взято».
🛡️ Частые заблуждения
«RAG — это сложная магия, владельцу в ней всё равно не разобраться»
RAG — конвейер из трёх понятных шагов: нарезали документы на карточки, подписали полки по смыслу, нашли нужную карточку по запросу. Разобраться, что делает каждый шаг, можно за один разговор. А кто разобрался — тот видит, где конкретно ломается ответ.
«Поиск по смыслу ищет совпадение слов — значит, надо просто писать точные ключевые слова»
Наоборот. Он ищет по смыслу, через отпечатки: «прозрачный навар из птицы» найдёт «куриный бульон» без единого общего слова. Совпадение по словам — это как раз обычный, не умный поиск. В этом и сила, и слабость: иногда находит «по смыслу» лишнее.
«Если ассистент по нашим документам отвечает мимо — значит, модель слабая, нужна помощнее»
Почти всегда дело не в поваре, а в конвейере: криво нарезали, плохо разложили по смыслу или достали не ту карточку. RAG вообще не переучивает повара — он просто кладёт ему на стол нужную карточку. Повар добросовестно отвечает по тому, что ему дали. Сначала чини конвейер, а уже потом думай про «модель помощнее».
🧠 AI-чутьё (AI Judgment)
Качество нарезки и поиска решает качество ответа: мусор на входе — правдоподобный мусор на выходе
Главная мысль на вынос: качество ответа RAG определяется не «умом» повара, а качеством трёх шагов конвейера до него. Повар готовит ровно из того, что ему положили на стол. Положили нужную карточку — будет точный ответ со ссылкой на источник. Положили обрывок, не ту карточку или ничего — повар всё равно ответит, гладко и уверенно. Это и есть правило «мусор на входе — правдоподобный мусор на выходе» (по-английски — garbage in, plausible garbage out). Опасность именно в слове «правдоподобный»: плохой ответ выглядит ровно как хороший.
Отсюда рабочая привычка владельца. Когда покупаешь или заказываешь «AI по нашим документам», не спрашивай только «какая там модель». Спрашивай про конвейер: «Как вы режете наши документы на куски — и не рвутся ли смыслы пополам? Как проверяете, что поиск достаёт нужные карточки, а не похожие-но-не-те? Даёте ли ссылку на источник под каждым ответом?». Если в ответ — только про «мощную модель» и «эмбеддинги последнего поколения», а про нарезку и проверку поиска мнутся, — это красный флаг.
И держи в голове ещё одну вещь, к которой мы скоро вернёмся отдельно. Даже идеально собранный конвейер беззащитен, если в саму картотеку попал мусор: устаревший регламент, противоречивые документы, чужие данные. Картотека настолько хороша, насколько чисты полки, с которых она кормит повара. Про то, как именно «грязный склад» отравляет ответы и что с этим делать, — тема 7.4 — Грязные данные + агент = катастрофа.
🎯 Практика
Одно задание на пять минут — чтобы три шага перестали быть теорией и легли на твою реальную базу знаний.
- Возьми любой набор документов со своей работы, который ты бы хотел «скормить» AI-ассистенту: база ответов поддержки, регламенты, инструкции, договоры.
- Представь шаг нарезки: на какие куски-карточки это естественно режется? Один пункт регламента — карточка? Один ответ FAQ — карточка? Найди место, где наивная нарезка «по страницам» разорвала бы смысл пополам (например, таблицу или длинную пошаговую инструкцию).
- Представь шаг поиска: задай к этим документам один реальный вопрос так, как спросил бы живой сотрудник, — не теми словами, что написаны в документе. Это и проверяет поиск по смыслу. Если для верного ответа карточек надо собрать несколько и из разных мест — отметь это: такие вопросы конвейеру даются тяжелее всего.
- Выпиши три вопроса подрядчику из раздела про чутьё (про нарезку, про проверку поиска, про ссылки на источники). Это твоя готовая повестка на разговор до подписания, а не после.