AI / LLM
RAG architecture: тест с множественным выбором
Суть Синтез по всему юниту RAG в формате выбора — chunking, стоимость embedding, retrieval по схеме wide-then-narrow, lost-in-the-middle и режим уверенной галлюцинации.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих сквозь весь pipeline. Ни один не про заучивание определения — каждый это решение, которое вы принимаете, пока RAG-система молча выдаёт уверенные и неверные ответы в продакшене.
Цель
Убедитесь, что вы связываете chunking, стоимость embedding, двухстадийный retrieval, сборку контекста и режим отказа, обусловленный retrieval, в единый диагноз — тот синтез, к которому вёл весь юнит.
Викторина
Completed
Бот поддержки уверенно сообщает конкретную, но неверную цифру оттока за Q3; ответ месяц проходил ревью незамеченным. Где чаще всего лежит причина и почему она невидима?
Heads-up Генератор может рассуждать только о чанках, которые ему отдал retrieval. Нужный чанк вообще не попал в prompt, поэтому более крупная модель просто галлюцинирует глаже на тех же отсутствующих данных.
Heads-up Промах означает, что чанк с ответом вообще не был извлечён; размер окна не может включить текст, который retrieval не вернул.
Heads-up Определяющий сбой RAG это не падение — он выдаёт правдоподобный ответ без ошибки, именно поэтому он неделями переживает ревью.
Викторина
Completed
В документе политика указывает правило, а исключение к нему стоит абзацем ниже. Запросы про исключение возвращают полуправду. Какое изменение chunking — правильный первый шаг?
Heads-up Мелкие чанки дают точный embedding, но ещё сильнее дробят сквозные правила — вы разрежете правило и исключение по ещё большему числу границ, усугубив полуправду.
Heads-up Более широкая сеть может помочь recall, но не чинит факт, который разрезал chunking; она заваливает контекст шумом и провоцирует lost-in-the-middle, а проблема стыка остаётся.
Heads-up Точность embedding не при чём — текст с ответом физически разрезан надвое на этапе индексации. Никакая модель embedding не восстановит факт, который не целостен ни в одном чанке.
Викторина
Completed
p99 поиска по индексу слишком велик на 3072 измерениях, а стоимость хранения растёт. Какой senior-компромисс до смены инфраструктуры?
Heads-up Обученные по Matryoshka embeddings явно усекаемы — можно отбросить измерения, сохранив большую часть точности, и снизить и хранение, и latency поиска без лишнего железа.
Heads-up Полный перебор убирает миллисекундное ускорение ANN; на масштабе в миллионы он делает latency куда хуже. Рычаг здесь — размер вектора, а не отказ от ANN-индекса.
Heads-up ANN-поиск сравнивает запрос с индексом независимо от k; уменьшение k урезает число возвращаемых кандидатов, а не стоимость поиска на запрос, которую задаёт размерность.
Викторина
Completed
Почему «retrieve широко (k=20–50), затем rerank узко до 3–8 через cross-encoder» лучше одиночного embedding top-3?
Heads-up Cross-encoder медленный на элемент именно потому, что совместно кодирует запрос и чанк — поэтому его запускают только на шорт-листе со стадии один, а не на всём корпусе.
Heads-up Top-3 без rerank хрупок: один промах ANN или разрез по границе — и ответа нет в prompt. Двухстадийная схема разводит recall (стадия 1) и precision (стадия 2).
Heads-up Наоборот — он сужает 20–50 кандидатов до 3–8, что режет токены, стоимость и lost-in-the-middle, повышая precision.
Викторина
Completed
У вас окно на 128k токенов, поэтому вы запихиваете все 40 извлечённых чанков в порядке retrieval и ставите решающий примерно в середину. Что предсказывает литература?
Heads-up Эмпирически внимание U-образное: эффект lost-in-the-middle сохраняется даже в long-context моделях, так что позиция внутри окна важна.
Heads-up Наоборот: середина — наименее внимаемая зона. Делайте rerank, оставляйте мало и ставьте сильнейшие доказательства в самое начало или конец.
Heads-up Большее окно не заменяет reranking; набивка нерелевантными чанками всё равно хоронит решающий в малозаметной середине и жжёт токены.
Викторина
Completed
RAG-бот, работавший на прошлой неделе, теперь возвращает политику прошлого квартала без изменений кода и без ошибок. Самая вероятная причина и структурное исправление?
Heads-up Замороженный генератор не перевернул бы прежде верный ответ в конкретное старое значение — этот паттерн про индекс, отдающий устаревшие embeddings, а не про смену модели.
Heads-up Embedding запроса не менялся; устарели проиндексированные embeddings документов относительно обновлённого источника. Исправление — переиндексация корпуса, а не переэмбеддинг запросов.
Heads-up Если новую политику не переиндексировали, никакое k её не извлечёт — её нет в индексе. Недостающее звено — свежесть, а не ширина.
Итог
Сквозная линия юнита — единый диагноз: продакшен-RAG падает на retrieval, а не на генерации. Chunking задаёт потолок (размер под смысловую единицу ответа, overlap для выживания стыков); размерность embedding — реальный рычаг стоимости, который можно усекать; разрыв recall-vs-precision решается схемой retrieve-wide-then-rerank-narrow; порядок контекста должен обходить lost-in-the-middle, ставя лучшие доказательства по краям; а устаревший или отравленный индекс превращает тихий промах в уверенный неверный ответ — от чего защищают gate по score, свежесть и инструкция отвечать только из контекста или говорить «я не знаю».