# Почини извлечение, прежде чем винить модель Экспресс-курс о RAG и заземлении. 22 понятия — knowledge cutoff, RAG, grounding, чанкинг, метаданные, эмбеддинги, векторный поиск, hybrid search, reranking, precision и recall, цитаты, честный отказ, faithfulness, golden set, свежесть индекса и другие — у каждого английское название, схема, пример и карточка. Главная мысль: в RAG модель редко проблема — твоё извлечение. В конце — шпаргалка по всем понятиям на одной странице. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~35 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/rag-and-grounding-express --- ## 1. Зачем нужен RAG Модель не знает твоих данных и ничего после своей даты обучения. RAG — это как ты даёшь ей факты, чтобы отвечать по ним, — так что пойми задачу, что он решает, до механики. ### Карта: 22 понятия в семи группах > Карта метро: сначала видишь линии целиком, потом едешь по станциям. Сначала три **основы** — почему памяти модели мало, что такое RAG и зачем нужно заземление. Дальше шесть групп, по одной на главу: **чанкинг**, **эмбеддинги и поиск**, **качество извлечения**, **заземление**, **оценка** и как **строить хорошо**. У каждого понятия дальше одно и то же: **английское название** (запомни его — это термин), образ из жизни, **схема** и **карточка** с полями: _что это_ или _проблема_, _как работает_ или _идея_, _пример_, _подвох_ или _цена_ и _связи_. _Diagram: Основы сверху, ниже — шесть групп, по ним идут главы 2–7._ ### Knowledge Cutoff — память модели заморожена > Блестящий выпускник, что прочёл всю библиотеку годы назад, — но не файлы твоей компании и ничего, напечатанного с его выпуска. LLM знает только то, что было в её обучающих данных, замороженных на дате отсечки — **knowledge cutoff**. Она не знает твоих документов, твоего продукта, записи твоего клиента или вчерашних новостей. Спроси всё равно — и она **ответит из размытой памяти или выдумает что-то правдоподобное.** RAG существует, чтобы починить ровно это: перестань полагаться на то, что модель запомнила, и вручи ей нужные факты в момент вопроса. _Diagram: Всё, что после отсечки или внутри твоей компании, модель не видела никогда._ #### Knowledge Cutoff (дата отсечки знаний) - **Что это:** Модель знает только свои обучающие данные, замороженные на одной дате. - **Пример:** Она не знает твою документацию, запись клиента и вчерашние новости. - **Подвох:** Модель не молчит, когда не знает, — она отвечает из размытой памяти или выдумывает. - **Связи:** Эту дыру закрывает **RAG**: факты приходят в момент вопроса. ### RAG — сначала извлеки, потом отвечай > Экзамен с открытой книгой — вместо того чтобы доверять памяти, ты сначала смотришь нужные страницы, а потом пишешь ответ по тому, что перед тобой. Это паттерн **Retrieval-Augmented Generation (RAG)** — генерация, дополненная извлечением. Три шага: **retrieve** — по вопросу пользователя **достать самые релевантные чанки** твоих документов; **augment** — положить их в контекст; **generate** — попросить модель ответить по ним. Теперь ответ идёт из твоих настоящих данных, а не из воспоминаний модели. Так ассистент отвечает про твою документацию, твои политики, твою базу знаний — точно и актуально. _Diagram: Три шага RAG: извлечь чанки, добавить их в контекст, сгенерировать ответ._ #### Retrieval-Augmented Generation (RAG, генерация с извлечением) - **Проблема:** Модель не знает твоих данных и всего, что после её отсечки. - **Идея:** Найти нужные куски документов и дать модели ответить по ним. - **Пример:** Ассистент поддержки отвечает про политику возврата по свежей статье из базы знаний. - **Цена:** Целая система поиска: чанкинг, индекс, свежесть, оценка. - **Когда брать:** Знаний много, они часто меняются или зависят от пользователя. - **Связи:** Ради **grounding**; держится на **chunking**, **embedding** и **vector search**. ### Grounding — вот настоящий приз > Журналист, что обязан цитировать источник на каждое утверждение, выдумывает куда меньше, чем тот, кто пишет по памяти. Глубокая причина, почему RAG важен, — **заземление (grounding)**: поскольку ответ взят из извлечённого текста, ты можешь требовать цитаты и проверять, что каждое утверждение реально подкреплено источником. Это не стирает галлюцинацию целиком, но режет её и делает то, что проскользнуло, ловимым. Ответ, что ты можешь проследить до документа, — это ответ, которому можно доверять и который можно защитить. _Diagram: У каждого утверждения есть источник. Утверждение без источника сразу видно._ #### Grounding (заземление) - **Что это:** Ответ опирается на извлечённый текст, а не на память модели. - **Как работает:** Каждое утверждение можно проследить до конкретного чанка и проверить. - **Пример:** «Возврат — 14 дней [1]», где [1] — абзац из политики возврата. - **Подвох:** Режет галлюцинации, но не убирает их до нуля. - **Связи:** Делается через **context-only answering**, **citations** и **refusal**; меряется **faithfulness**. ### Retrieval-first — это система поиска с моделью на конце > Научный ассистент хорош ровно настолько, насколько картотека, в которой он ищет, — дай ему отличную библиотеку и плохой индекс, и он всё равно вручит не ту папку. Ментальная модель, что сэкономит тебе месяцы: RAG — это в основном **задача поиска (search problem)**, с языковой моделью на конце, чтобы сформулировать ответ. Модель — лёгкая, в основном решённая часть. Тяжёлая, определяющая качество часть — всё, что решает, _какой текст доходит до модели_, — и это остаток курса. _Diagram: Чанкинг, эмбеддинги, поиск и ранжирование — тяжёлая часть. Модель только формулирует._ > **Вопрос рамки:** «Этот ответ идёт из фактов, что я извлёк и могу процитировать, — или из замороженной, размытой памяти модели?» > Не спрашивай модель, что она знает. Извлеки нужные факты и попроси ответить по ним — заземлённо, актуально и с цитатами. ## 2. Чанкинг Прежде чем извлекать, ты режешь документы на куски. Как ты их режешь, тихо решает качество извлечения — это наименее гламурный шаг и один из самых важных. ### Chunk — единица качества > Справочник полезен, только разрезанный на находимые статьи, — один гигантский неиндексированный свиток или тысяча рваных клочков одинаково бесполезны для поиска. Ты извлекаешь не целые документы, а **чанки (chunks)** — пассажи в несколько сотен слов. Процесс нарезки называется **chunking**. Чанк — это единица, что видит поиск и читает модель, так что его границы важны колоссально. Хорошие чанки самодостаточны и на одну тему. Сделай чанкинг неверно — и никакой хитрый поиск или умная модель этого не спасут. _Diagram: Документ режется на чанки. Поиск видит чанки, модель читает чанки — не документы._ #### Chunk (чанк, кусок документа) - **Что это:** Пассаж в несколько сотен слов — единица поиска и чтения. - **Как работает:** Документы режутся заранее; поиск возвращает чанки, модель отвечает по ним. - **Размер:** Слишком большой хоронит ответ, слишком маленький теряет контекст. Число подбирают измерением. - **Подвох:** Плохой чанкинг не спасёт ни поиск, ни модель. - **Связи:** Режь через **structure-aware chunking**, помечай **metadata**, превращай в **embedding**. ### Chunk Size — слишком большой хоронит ответ, слишком маленький теряет контекст > Вручи кому-то целую главу, чтобы ответить на однострочный вопрос, и он бредёт сквозь шум; вручи одно предложение без окружения, и он не поймёт, что оно значит. Режь слишком **крупно** — и каждый чанк мешает нужный факт с абзацами не относящегося текста: поиск становится размытым, а внимание модели разбавляется. Режь слишком **мелко** — и ты обрубаешь контекст, что делал факт осмысленным. Золотая середина держит одну связную идею с достаточным окружением, чтобы стоять самой по себе. Универсального **размера чанка (chunk size)** нет; он зависит от твоих документов, и ты его настраиваешь измерением. _Diagram: Цветная полоска — нужный факт. Слева он тонет в шуме, справа остался без контекста._ ### Structure-Aware Chunking — режь по смыслу, а не по числу символов > Деление книги подсчётом символов может разрезать предложение — или рецепт — ровно пополам. Деление по главам и разделам держит каждый кусок целым. Наивный подход — **fixed-size chunking** — рубит каждые N символов и разрезает предложения, таблицы и идеи. Лучше резать по **естественной структуре** документа — заголовкам, разделам, абзацам, — чтобы каждый чанк был законченной мыслью. Немного **перекрытия (overlap)** между соседними чанками не даёт факту провалиться в щель между двумя. Уважай форму документа — и извлечение становится легче само собой. _Diagram: Сверху разрезы через каждые N символов. Снизу — по разделам, с небольшим перекрытием на стыках._ #### Structure-Aware Chunking (нарезка по структуре, overlap) - **Проблема:** Нарезка по числу символов режет предложения и таблицы пополам. - **Идея:** Резать по заголовкам, разделам и абзацам, с небольшим перекрытием. - **Пример:** Раздел «Сроки возврата» целиком становится одним чанком. - **Цена:** Нужно разбирать формат документа: Markdown, HTML, PDF. - **Связи:** Улучшает каждый **chunk** и всё ниже по течению. ### Metadata — прикрепляй ярлыки к каждому чанку > Библиотечная карточка держит не только текст — она записывает автора, дату и раздел, чтобы ты мог отфильтровать ровно нужную полку ещё до поиска. Храни каждый чанк с **метаданными (metadata)**: исходный документ, заголовок, дата, раздел, права. Это позволяет **фильтровать** до или вместе с семантическим поиском — только документы этого продукта, только текущие политики, только то, что этому пользователю позволено видеть, — и даёт источник для цитат. Метаданные дёшево хранить, и они превращают плоскую груду текста в то, что можно нацеливать. _Diagram: Метаданные дают две вещи: фильтр до поиска и источник для цитаты._ #### Metadata (метаданные чанка) - **Проблема:** Плоская груда текста: нельзя сузить поиск и нечего цитировать. - **Идея:** Хранить с чанком источник, заголовок, дату, раздел и права. - **Пример:** Искать только в текущих политиках, которые этому пользователю можно видеть. - **Цена:** Почти ничего — несколько полей на чанк. - **Связи:** Даёт фильтр для **vector search** и источник для **citations**. > **Вопрос чанкинга:** «Каждый ли чанк стоит сам по себе как одна связная идея — с достаточным контекстом, чтобы быть понятым, и достаточными метаданными, чтобы быть отфильтрованным и процитированным?» > Ты извлекаешь чанки, а не документы. Режь по смыслу, держи каждый самодостаточным и тегируй — качество чанкинга ограничивает всё ниже по течению. ## 3. Эмбеддинги и векторный поиск Чтобы найти чанки, что совпадают с вопросом, ты ищешь по смыслу, а не по совпадению слов. Эмбеддинги — это трюк, что делает «найди мне похожее на это» возможным. ### Embedding — смысл превращается в координаты > Карта, где у каждой идеи есть место, и вещи, что значат схожее, сидят рядом, — «собака» близко к «щенку», обе далеко от «налоговой декларации». **Эмбеддинг (embedding)** — это список чисел, **вектор**, что представляет смысл куска текста, помещённый в многомерное пространство так, что схожие смыслы оказываются рядом. Ты эмбеддишь каждый чанк один раз и хранишь векторы. Теперь у «смысла» есть координаты, и «найди связанный текст» становится «найди ближайшие точки» — задача, что компьютер решает быстро. _Diagram: Чанк → модель эмбеддингов → вектор. Один раз на каждый чанк, потом в хранилище._ #### Embedding (эмбеддинг, вектор) - **Что это:** Список чисел, который представляет смысл текста. - **Как работает:** Модель эмбеддингов выдаёт координаты; похожий смысл — близкие точки. - **Пример:** «Собака» и «щенок» рядом, обе далеко от «налоговой декларации». - **Связи:** Делает возможным **vector search**; векторы живут в **vector database**. ### Vector Search — поиск по сходству, а не по ключевым словам > Библиотекарь, что находит книги по тому, о чём они, — «похожее на это», — а не только по точному совпадению названия, что ты сказал. В момент вопроса ты эмбеддишь **вопрос** тем же способом, потом ищешь в хранилище чанки, чьи векторы ближе всего к нему. Это **векторный поиск (vector search)**, он же **семантический поиск (semantic search)**: он находит чанк про «политику возврата», даже когда пользователь спросил про «вернуть свои деньги», потому что смыслы сидят рядом. Поиск по ключевым словам это упустил бы; векторный поиск для этого и создан. _Diagram: Вопрос и чанк про возврат не делят ни одного слова — но в пространстве смыслов они рядом._ #### Vector Search (semantic search, семантический поиск) - **Что это:** Поиск чанков, чьи векторы ближе всего к вектору вопроса. - **Как работает:** Вопрос эмбеддится той же моделью, затем ищутся ближайшие точки. - **Пример:** «Вернуть деньги» находит раздел «Политика возврата». - **Подвох:** Промахивается по точным кодам и именам; близко — не всегда полезно. - **Связи:** Работает на **vector database**; дополняется **hybrid search** и **reranking**. ### Vector Database — движок извлечения > Склад, устроенный так, что по любому предмету он мгновенно вручит тебе сотню самых похожих, — не читая каждую полку, а благодаря тому, как он организован. **Векторная база данных (vector database)** хранит твои эмбеддинги и отвечает на запросы «ближайшее к этому» за миллисекунды, даже по миллионам чанков, используя приближённый индекс (**ANN**, approximate nearest neighbour) вместо сканирования всего. Это движок извлечения под RAG. Строить его не надо — но надо знать, что именно там живут твои чанки и насколько быстр и точен его поиск. _Diagram: Векторная база не сканирует всё подряд: приближённый индекс сразу ведёт к ближайшим._ #### Vector Database (векторная база, ANN-индекс) - **Что это:** Хранилище векторов с быстрым поиском ближайших. - **Как работает:** Приближённый индекс (ANN) вместо полного перебора. - **Пример:** Миллионы чанков — и ближайшие к вопросу за миллисекунды. - **Подвох:** Строить не нужно, но нужно знать, насколько быстр и точен поиск. - **Связи:** Хранит **embeddings**; на нём работает **vector search**. ### Similar ≠ Relevant — сходство не то же, что релевантность > Два пассажа могут быть на одну тему и при этом отвечать на разные вопросы — «как отменить» и «почему отменяют» сидят рядом, но только один — то, что спросили. Векторный поиск возвращает то, что **семантически близко (similar)**, что обычно **релевантно (relevant)**, но не всегда. Чанк может быть про нужный предмет и при этом не содержать ответа. Этот разрыв — близко по смыслу против реально полезно — вот почему сырой векторный поиск это сильный первый проход, но не финальное слово, и почему существует следующий раздел. _Diagram: Оба чанка близки к вопросу. Ответ есть только в одном._ #### Similar ≠ Relevant (сходство не равно релевантности) - **Что это:** Близкий по смыслу чанк не обязательно содержит ответ. - **Пример:** «Как отменить» и «почему отменяют» — рядом, но ответ только в первом. - **Подвох:** Сырой векторный поиск принимает близость за полезность. - **Связи:** Лечится **reranking**; меряется **retrieval eval**. > **Вопрос поиска:** «Я совпадаю со смыслом вопроса — или просто надеюсь, что пользователь напечатал те же ключевые слова, что были в моих документах?» > Эмбеддинги дают смыслу координаты; векторный поиск находит чанки по сходству. Это мощно — и «близко по смыслу» это не совсем «отвечает на вопрос». ## 4. Извлечение — это вся игра Вот урок, что чинит большинство сломанных RAG-систем: когда ответы плохи, причина обычно в извлечении. Заведи нужные чанки внутрь — и приличная модель сделает остальное. ### Garbage In, Confident Garbage Out — мусор на входе, уверенный мусор на выходе > Вручи кому-то не тот файл и попроси его суммировать — он даст безупречную сводку совершенно не той вещи, звуча полностью уверенно. RAG-ответ хорош ровно настолько, насколько чанки, что ему дали. Извлеки не те пассажи — и модель **добросовестно ответит из неверного контекста**, со всей своей обычной уверенностью. Баг выглядит как «модель неправа», но настоящий сбой случился выше по течению, в извлечении. Так что когда ответы плохи, **осмотри, что извлеклось, прежде чем трогать промпт или модель.** _Diagram: Ошибка видна в ответе, а родилась в извлечении. Смотри на чанки первым делом._ ### Hybrid Search — сочетай ключевые слова и смысл > Один искатель, что точно знает, что слова значат, и другой, что совпадает по точным именам и кодам, — вместе они ловят то, что каждый по отдельности упустил бы. Векторный поиск понимает смысл, но может промахиваться по точным терминам — кодам продуктов, именам, редкому жаргону. **Поиск по ключевым словам (keyword search)** бьёт по ним, но упускает перефразировки. **Гибридный поиск (hybrid search)** гоняет оба и сливает результаты, прикрывая слепые зоны друг друга. Для большинства реальных корпусов гибрид бьёт любой по отдельности, потому что реальные вопросы мешают понятия с конкретными именами. _Diagram: Два поиска параллельно: один ловит точные коды, другой — перефразировки. Результаты сливаются._ #### Hybrid Search (гибридный поиск, keyword + vector) - **Проблема:** Векторный поиск путает точные коды и имена; поиск по словам не видит перефразировок. - **Идея:** Запустить оба поиска и слить результаты. - **Пример:** «Ошибка SKU-4471 при возврате» — код находит поиск по словам, смысл — векторный. - **Цена:** Два индекса и логика слияния. - **Когда брать:** Почти всегда для реальных корпусов. - **Связи:** Широкий первый проход перед **reranking**. ### Reranking — переранжируй короткий список > Процесс найма: дешёвый первый проход вытягивает пятьдесят правдоподобных резюме, потом внимательный ревьюер читает их вблизи и ранжирует настоящую топ-пятёрку. Поиск первого прохода быстр, но груб. **Реранкер (reranker)** берёт топ, скажем, пятьдесят кандидатов и оценивает каждого против вопроса аккуратнее, выталкивая по-настоящему релевантные чанки наверх. Извлекай широко, потом переранжируй до точных немногих. Эта двухэтапная форма — широкий дешёвый отзыв, потом острое ранжирование — один из самых рычажных апгрейдов посредственной RAG-системы. _Diagram: Этап 1 — быстро набрать 50 кандидатов. Этап 2 — внимательно выбрать лучшие 5._ #### Reranking (переранжирование, two-stage retrieval) - **Проблема:** Первый проход быстр, но груб: нужное может стоять на 30-м месте. - **Идея:** Взять топ-50 и аккуратно оценить каждого кандидата против вопроса. - **Пример:** Из 50 найденных чанков реранкер оставляет 5 самых полезных. - **Цена:** Лишний шаг — немного задержки и денег на каждый вопрос. - **Когда брать:** Когда RAG посредственный — один из самых сильных апгрейдов. - **Связи:** Лечит **similar ≠ relevant**; стоит после **hybrid search**. ### Precision и Recall — точность и полнота тянут друг против друга > Сеть с широкими ячейками ловит только крупную рыбу, но многое пропускает; мелкая сеть ловит всё, включая водоросли. Ты настраиваешь ячею под нужный улов. Извлеки слишком мало чанков — и можешь **упустить тот, что с ответом** (низкая **полнота, recall**); извлеки слишком много — и хоронишь ответ в нерелевантном тексте, что разбавляет модель и стоит токенов (низкая **точность, precision**). Верное число чанков (его часто зовут **k**) балансирует эти двое, и оно специфично для твоих данных и типа вопроса. Ты его не угадываешь — ты его меряешь, а это следующий раздел. _Diagram: Мало чанков — ответ упущен. Много — ответ утонул. Середину находят измерением._ #### Precision & Recall (точность и полнота, top-k) - **Что это:** Recall — нашёлся ли нужный чанк; precision — сколько мусора пришло вместе с ним. - **Как работает:** Больше k — выше полнота, ниже точность, и наоборот. - **Пример:** k = 2 упускает ответ; k = 40 хоронит его и жжёт токены. - **Подвох:** Нужное k не угадать — его меряют на своих данных. - **Связи:** Меряется **retrieval eval**; влияет на **cost & latency**. > **Вопрос извлечения:** «Когда ответ неверен, я реально посмотрел, какие чанки извлеклись, — или предположил, что это модель, и начал крутить промпт?» > Большинство плохих RAG-ответов — это плохое извлечение. Сочетай ключевые слова и семантику, переранжируй короткий список и проверь чанки, прежде чем винить модель. ## 5. Заземление и цитаты Как только нужные чанки в контексте, работа — заставить модель отвечать строго по ним и доказать, что она это сделала. Это и превращает извлечение в ответ, которому можно доверять. ### Context-Only Answering — отвечай только из извлечённого текста > Свидетель, которому велено показывать только то, что он лично видел, — не то, что предполагает, смутно помнит или слышал из вторых рук. Укажи модели отвечать **только из предоставленных чанков** и говорить, что не знает, когда ответа там нет. Это ядро заземления: извлечённый текст — это разрешённый **источник истины (source of truth)**, а собственная память модели снята со стола. Идеально не будет — модель всё ещё может дрейфовать, — но инструкция плюс нужный контекст делают бо́льшую часть работы. _Diagram: Чанки — разрешённый источник. Память модели — нет._ #### Context-Only Answering (отвечать только по контексту) - **Проблема:** Модель смешивает извлечённые факты со своей памятью. - **Идея:** Инструкция: отвечать только из предоставленных чанков, иначе — «не знаю». - **Пример:** «Отвечай только по фрагментам ниже. Если ответа там нет — так и скажи». - **Цена:** Не идеально: модель всё ещё может дрейфовать. - **Связи:** Ядро **grounding**; проверяется **citations** и **faithfulness**. ### Citations — цитаты делают утверждения проверяемыми > Научная статья со сносками позволяет любому читателю проследить утверждение до источника и проверить его — или поймать, где оно не держится. Пусть модель **цитирует, из какого чанка** пришла каждая часть её ответа. **Цитаты (citations)** делают две вещи: позволяют пользователю (и тебе) сверить утверждение с источником, и сам акт заземления каждого высказывания в извлечённом пассаже отбивает у модели охоту уходить от фактов. Ответ с прослеживаемыми источниками можно проаудитировать; ответ без источников — лишь уверенная догадка. _Diagram: Каждое предложение ответа ведёт к своему источнику — его можно открыть и проверить._ #### Citations (цитаты, ссылки на источник) - **Проблема:** Ответ без источников нельзя проверить — это уверенная догадка. - **Идея:** Модель указывает, из какого чанка взято каждое утверждение. - **Пример:** «Возврат — 14 дней [1]», где [1] — refund-policy.md, раздел «Сроки». - **Цена:** Нужны метаданные с источником у каждого чанка. - **Связи:** Опираются на **metadata**; делают **grounding** проверяемым. ### Refusal — научи её говорить «я не знаю» > Эксперт, которому ты доверяешь больше всего, — тот, кто говорит «этого нет в том, что у меня есть», вместо того чтобы уверенно заполнить пробел догадкой. Самый опасный сбой RAG — отвечать всё равно, когда извлечение вернулось пустым или мимо. Так что сделай **отказ (refusal) валидным, ожидаемым выводом**: если чанки не содержат ответа, модель должна так и сказать, а не импровизировать из памяти. Система, что признаёт пробел, куда надёжнее той, что его замазывает, — и она вскрывает, где твоё извлечение нуждается в работе. _Diagram: Обе ветки — правильный выход. Неправильно только одно: выдумать ответ из памяти._ #### Refusal (честное «я не знаю») - **Проблема:** Извлечение вернулось мимо, а модель всё равно отвечает. - **Идея:** «Этого нет в моих источниках» — нормальный, ожидаемый ответ. - **Пример:** Вопрос вне базы знаний → «В документации этого нет». - **Цена:** Пользователь иногда не получает ответа — зато не получает и выдумки. - **Связи:** Часть **grounding**; отказы показывают дыры в извлечении. ### Grounding снижает галлюцинацию — но не кончает её > Ремни безопасности резко снижают смертность, но ты всё равно едешь осторожно. Сильная мера защиты — не повод перестать смотреть на дорогу. Даже с идеальными чанками модель может неверно прочесть, переобобщить или смешать извлечённый факт с собственной памятью. Заземление **режет** **галлюцинацию (hallucination)** и делает её ловимой; оно её не убирает. Так что ты всё равно проверяешь — цитатами, что пользователь может сверить, и эвалами, что меряют верность. Относись к заземлению как к мощному контролю, а не как к гарантии. > **Вопрос заземления:** «Каждое ли утверждение в этом ответе можно проследить до извлечённого чанка — и говорит ли система „я не знаю“, когда фактов там нет?» > Заземление значит, что ответ идёт только из извлечённого текста, с цитатами в доказательство, — и честным «я не знаю», когда фактов там нет. ## 6. Оценка RAG У RAG два этапа, что сбоят по-разному, так что ты меряешь их отдельно. Свали их вместе — и будешь неделями настраивать не ту половину. (Курс об эвалах копает глубже; здесь — RAG-специфичная форма.) ### Два этапа — меряй извлечение и генерацию по отдельности > У ресторана с плохим блюдом два возможных виновника — доставленные ингредиенты или повар. Сначала пробуешь ингредиенты, иначе переучишь не того. RAG-ответ может сбоить, потому что **извлечение (retrieval)** принесло не те чанки, или потому что **генерация (generation)** плохо ответила из верных чанков. Им нужны разные починки, так что меряй их отдельно: вернулись ли нужные чанки? и, при этих чанках, был ли ответ верным и полным? Большинство команд, что «не могут улучшить свой RAG», оценивают только финальный ответ и гадают, какую половину винить. _Diagram: У каждого этапа свой измеритель — и своя починка._ ### Retrieval Eval — вернулись ли нужные чанки? > Прежде чем судить эссе, проверь, что студенту вообще вручили нужные справочные страницы, — если нет, ничто из написанного не могло быть верным. Оценивай извлечение само по себе — это **retrieval eval**: для набора вопросов с известными релевантными документами вернул ли поиск их в топе результатов? Долю таких попаданий часто называют **recall@k**. Это ловит плохой чанкинг, слабый поиск и отсутствие реранкинга напрямую — выше-по-течению причины большинства плохих ответов. **Чини извлечение первым**, потому что никакое улучшение промпта или модели не спасёт ответ, построенный из неверных чанков. _Diagram: Для вопроса известен нужный документ. Попал он в топ-k — тест пройден._ #### Retrieval Eval (оценка извлечения, recall@k) - **Проблема:** По финальному ответу не видно, виноват ли поиск. - **Идея:** Вопросы с известными нужными документами: вернулись ли они в топ-k? - **Пример:** Из 50 реальных вопросов нужный документ в топ-5 у 41. - **Что ловит:** Плохой чанкинг, слабый поиск, отсутствие реранкинга. - **Связи:** Меряет **precision & recall**; чинится до **faithfulness**. ### Faithfulness — был ли ответ верен чанкам? > Фактчекер читает ответ против цитируемых источников и помечает любое предложение, что источники на деле не подкрепляют. Когда извлечение хорошо, оценивай ответ на **верность (faithfulness)**: подкреплено ли каждое утверждение извлечёнными чанками, без выдумок и без противоречий? Также проверь, что он реально использовал извлечённое и ответил на вопрос. Здесь ты ловишь дрейф модели прочь от твёрдого контекста — и это измеримо, часто с другой моделью в роли оценщика (**LLM-as-judge**). _Diagram: Оценщик сверяет каждое предложение с чанками и помечает то, что они не подкрепляют._ #### Faithfulness (верность источникам) - **Что это:** Каждое утверждение ответа подкреплено извлечёнными чанками. - **Как работает:** Оценщик — часто другая модель — сверяет предложения с чанками. - **Пример:** Два предложения подкреплены, третье — нет: оно помечается. - **Подвох:** Верный чанкам ответ всё равно должен отвечать на вопрос. - **Связи:** Меряет **grounding**; имеет смысл после хорошего **retrieval eval**. ### Golden Set — строй эвал из реальных вопросов > Ты тестируешь мост грузовиками, что реально по нему поедут, а не весами, что нашёл удобными. Твой эвал-набор — его часто зовут **golden set** — должен быть **реальными вопросами**, что задают пользователи, включая грязные и вне-области, каждый в паре с чанками, что должны извлечься, и известным хорошим ответом. Гоняй его на каждом изменении, чтобы видеть, реально ли новая стратегия чанкинга или реранкер помогли. Без этого ты настраиваешь RAG по анекдотам — а анекдоты врут. _Diagram: Таблица реальных вопросов с ожидаемыми чанками и ответами — прогоняется на каждом изменении._ #### Golden Set (эталонный набор вопросов) - **Проблема:** Настройка по анекдотам: «вроде стало лучше». - **Идея:** Реальные вопросы + чанки, что должны найтись, + известный хороший ответ. - **Пример:** Грязный вопрос, перефразированный вопрос и вопрос вне области с ожидаемым «не знаю». - **Цена:** Время собрать и поддерживать набор. - **Связи:** Кормит и **retrieval eval**, и **faithfulness**. > **Вопрос эвала:** «Когда ответ неверен, могу ли я сказать, извлечение упустило чанк или модель его запорола, — или я гадаю?» > RAG сбоит в двух местах. Меряй извлечение и генерацию отдельно, чини извлечение первым и строй эвал из реальных вопросов. ## 7. Строить хорошо RAG мощен и к нему часто тянутся зря. Навык — применять его, когда он отрабатывает своё место, держать данные свежими и не платить за машинерию, что более простой подход пропустил бы. ### Paste First — не RAG-ай то, что мог бы просто вставить > Ты не строишь библиотечный каталог для трёх книг на своём столе — ты просто их открываешь. Если нужные факты малы и фиксированы — пара документов, короткая политика, — просто **положи их в промпт.** RAG отрабатывает свою сложность, когда знание слишком велико для контекста, часто меняется или должно фильтроваться по пользователю. Строить конвейер извлечения над тремя страницами — это эквивалент перебора в виде цикла агента ради одного вызова. Тянись к нему, когда данные вынуждают. _Diagram: Мало и стабильно — вставь в промпт. Много, меняется или зависит от пользователя — RAG._ #### Paste First (сначала просто вставь в промпт) - **Проблема:** Конвейер извлечения строят там, где он не нужен. - **Идея:** Малые стабильные факты кладут прямо в промпт. - **Пример:** Короткая политика на две страницы — в промпт, без индекса. - **Когда брать RAG:** Знание не влезает в контекст, часто меняется или фильтруется по пользователю. - **Связи:** Нижняя ступень лестницы; **RAG** — следующая. ### Index Freshness — устаревшие данные это неверные данные > Телефонная книга полезна, только если её переиздают, — номера прошлого десятилетия уверенно и бесполезно неверны. Обещание RAG — актуальные факты, а значит, твой индекс обязан **оставаться актуальным.** Когда исходные документы меняются, чанки и эмбеддинги надо обновить — **переиндексация (reindexing)**, — иначе модель заземлит свои ответы в уверенном, устаревшем тексте. Планируй переиндексацию как часть системы, а не как мысль вдогонку, — свежесть это фича, что надо поддерживать, а не свойство, что получаешь раз. _Diagram: Сверху — документы меняются, индекс пересобирается. Снизу — плана нет, ответы устаревают._ #### Index Freshness (свежесть индекса, reindexing) - **Проблема:** Документы поменялись, а индекс нет — ответы уверенно устарели. - **Идея:** Пере-чанкать и пере-эмбеддить изменённые документы по плану. - **Пример:** Политику обновили — её чанки пересобраны в тот же день. - **Цена:** Конвейер переиндексации, который надо поддерживать. - **Связи:** Держит **grounding** актуальным; трогает **chunk** и **embedding**. ### Cost & Latency — следи за стоимостью и задержкой > Каждый лишний шаг в конвейере — эмбеддинг, поиск, реранк, набивка контекста, генерация — добавляет немного времени и немного денег к каждому вопросу. RAG добавляет этапы, и каждый стоит **задержки (latency)** и токенов. Извлечение большего числа чанков, реранкинг, больший контекст — всё улучшает качество до некоторого предела и поднимает счёт всю дорогу. Так что настраивай на **наименьшее число чанков, что отвечает хорошо**, кэшируй где можешь и помни, что отличный ответ, что слишком медленный или дорогой, — не отличный ответ в проде. _Diagram: Каждый этап добавляет время и деньги — и платит за них каждый вопрос._ #### Cost & Latency (стоимость и задержка) - **Что это:** Каждый этап RAG добавляет время и токены к каждому вопросу. - **Как работает:** Больше чанков, реранк, больший контекст — лучше качество до предела, дороже всегда. - **Пример:** Сократить k с 20 до 5 после реранка — ответ тот же, счёт меньше. - **Подвох:** Отличный, но медленный или дорогой ответ — не отличный в проде. - **Связи:** Тянет против **precision & recall** и **reranking**. ### RAG — одна ступень; модель остаётся компонентом > У хорошей кухни есть кладовая, но кладовая — не повар: это один хорошо организованный вход для того, кто всё ещё должен приготовить блюдо. RAG сидит на лестнице выше обычного промпта и ниже инструментов и агентов: тянись к нему, когда модели нужны твои факты, и держи его за чистым интерфейсом, как любую зависимость. Извлечение кормит модель; оно не заменяет суждение вокруг модели. Та же дисциплина, что везде, — используй простейшую ступень, что работает, и держи модель заменяемой. _Diagram: Обычный промпт → RAG → инструменты и агенты. Поднимайся, только когда задача вынуждает._ ### Как понятия связаны > Две смены одной кухни: ночью заготовка — нарезать и разложить по полкам; днём готовка — найти, выбрать и подать. Всё в курсе — одна цепочка в два этапа. **Офлайн (indexing)**: документы режутся на **чанки** с **метаданными**, превращаются в **эмбеддинги** и ложатся в **векторную базу** — и пересобираются, когда документы меняются (**index freshness**). **В момент вопроса (query time)**: **hybrid search** находит кандидатов, **reranking** оставляет лучших, **precision и recall** решают, сколько их взять. Дальше **grounding**: модель отвечает **только по контексту**, с **цитатами** или честным **отказом**. Сбоку — **paste first**: если фактов мало, вся цепочка не нужна. А **эвалы** — **retrieval eval**, **faithfulness**, **golden set** — меряют каждое звено. _Diagram: Сверху — индексация, ниже — путь вопроса, внизу — эвалы, что меряют всю цепочку._ #### Прежде чем выкатывать RAG-фичу - **Нужен ли RAG вообще** — или факты малы и стабильны достаточно, чтобы вставить в промпт? - **Как чанкятся документы** — по смыслу, самодостаточно, с метаданными и небольшим перекрытием? - **Гибридное ли извлечение и переранжировано**, или сырой векторный поиск, что ты не мерил? - **Отвечает ли модель только из извлечённого текста**, цитирует источники и говорит «я не знаю»? - **Какой эвал** для извлечения, отдельный от генерации? - **Как индекс остаётся свежим**, и сколько запрос стоит во времени и токенах? #### Признаки, что проблема в извлечении - Ответы **уверенно неверны**, а ты ни разу не посмотрел на извлечённые чанки. - **Только сырой векторный поиск** — без запасного по ключевым словам, без реранкинга. - Чанки нарезаны **по числу символов**, разрезая предложения и таблицы. - Ты **крутишь промпт и модель**, чтобы починить то, что на деле промах извлечения. - Индекс не **пересобирали** с тех пор, как исходные документы изменились. #### Признаки, что ты построил хорошо - Чанки **семантичны и самодостаточны**, помечены метаданными для фильтрации и цитат. - Извлечение **гибридное + переранжировано**, настроено на наименьшее число чанков, что отвечает хорошо. - Ответы **заземлены и процитированы**, с честным отказом, когда факты не извлеклись. - Ты меряешь **извлечение и генерацию отдельно** и починил извлечение первым. - У индекса есть **план свежести**, а RAG сидит за интерфейсом, что можно заменить. ## Шпаргалка: все 22 понятия ### Основы - **Knowledge Cutoff** (дата отсечки): Модель знает только обучающие данные до одной даты — не твои документы. - **RAG** (Retrieval-Augmented Generation): Извлечь нужные чанки, положить в контекст, ответить по ним. - **Grounding** (заземление): Ответ опирается на извлечённый текст, и это можно проверить. ### Чанкинг - **Chunk** (чанк): Пассаж в несколько сотен слов — единица поиска; размер подбирают измерением. - **Structure-Aware Chunking** (нарезка по структуре): Резать по заголовкам и абзацам, с небольшим перекрытием. - **Metadata** (метаданные): Источник, дата, раздел, права — для фильтра и цитат. ### Эмбеддинги и поиск - **Embedding** (эмбеддинг): Вектор — координаты смысла текста. - **Vector Search** (семантический поиск): Найти чанки, ближайшие к вопросу по смыслу. - **Vector Database** (векторная база, ANN): Хранит векторы и находит ближайшие за миллисекунды. - **Similar ≠ Relevant** (сходство ≠ релевантность): Близкий по смыслу чанк не обязательно содержит ответ. ### Качество извлечения - **Hybrid Search** (keyword + vector): Поиск по словам и по смыслу вместе, результаты сливаются. - **Reranking** (переранжирование): Широко набрать кандидатов, аккуратно выбрать лучшие немногие. - **Precision & Recall** (точность и полнота): Мало чанков — ответ упущен, много — утонул; k меряют. ### Заземление - **Context-Only Answering** (только по контексту): Отвечать только из извлечённых чанков, память модели — нет. - **Citations** (цитаты): Каждое утверждение ссылается на свой чанк и проверяемо. - **Refusal** («я не знаю»): Нет ответа в чанках — честно сказать, а не выдумывать. ### Оценка - **Retrieval Eval** (recall@k): Вернулись ли нужные чанки в топ-k? Чинить первым. - **Faithfulness** (верность источникам): Каждое утверждение ответа подкреплено чанками. - **Golden Set** (эталонный набор): Реальные вопросы с ожидаемыми чанками и ответами — на каждом изменении. ### Строить хорошо - **Paste First** (сначала вставь в промпт): Мало стабильных фактов — промпт, а не RAG. - **Index Freshness** (свежесть индекса): Документы поменялись — переиндексируй, иначе ответы устарели. - **Cost & Latency** (стоимость и задержка): Каждый этап стоит времени и токенов; бери наименьшее k, что отвечает хорошо. > RAG — это система поиска с моделью на конце. Сделай чанки правильно — и ответ последует; модель редко была проблемой. Конец экспресс-курса · 7 глав · 22 понятия Дальше — практика: построй самый маленький настоящий RAG над горсткой своих документов — режь по структуре, эмбедди, ищи и пусть модель отвечает с цитатами и честным «я не знаю». Потом, прежде чем что-то настраивать, напиши десять реальных вопросов и проверь, что извлекается. Но держи одну мысль выше прочих: когда ответ неверен, смотри сначала на чанки. В RAG модель редко проблема — твоё извлечение да, и это та половина, что ты контролируешь.