RAG — это не машинное обучение, и инструментарий машинного обучения решает не ту проблему.

Enterprise Document Intelligence [Том 1 #3] – Почему набор инструментов машинного обучения (перебор гиперпараметров, разделение на обучающую и тестовую выборки, фреймворки для обеспечения объяснимости) решает не ту задачу, и что использовать вместо него

Делиться

Команда разработчиков посвятила шесть месяцев доработке своего конвейера RAG.

• Они провели пять опросов компании Optuna.
• Они добавили собственный инструмент для переранжирования.
• Они доработали модель встраивания на основе собственных данных.

Точность выполнения заданий оставалась неизменной. Пилоты продолжали жаловаться на одни и те же неправильные ответы. Спустя шесть месяцев выяснилось, что ошибка заключалась в парсере.

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

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

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

Позиция «RAG — это не машинное обучение» — это один из элементов первого тома «Интеллектуального управления документами в корпоративной среде», в котором шаг за шагом строится корпоративная система RAG. Четыре основных элемента (анализ, анализ вопросов, поиск, генерация) — это набор инженерных инструментов, на которые указывает эта статья.

1. Две разные проблемы

Машинное обучение решает задачи, где истинный ответ неизвестен и должен быть предсказан. Уйдет ли этот клиент? Какова вероятность того, что эта транзакция является мошеннической? Это изображение кошки? Вы не знаете ответа заранее. Именно поэтому вы обучаете модель. Модель учится на размеченных примерах, обобщает результаты на новые входные данные и выдает предсказание. Производительность измеряется в совокупности, по тысячам тестовых случаев, поскольку отдельные предсказания могут быть неверными, в то время как модель в целом остается полезной.

RAG решает другую проблему. Ответ на вопрос «какова дата вступления в силу этого контракта?» либо есть, он написан на первой странице документа, либо его нигде нет. Предсказывать нечего. Система либо находит ответ в документе и точно его сообщает, либо выдает ошибку и должна об этом сообщить. Эффективность на уровне вопроса является бинарной (получил ответ или нет), даже если измерять совокупные показатели по множеству вопросов.

Эти различия являются конкретными:

• В машинном обучении «модель ошиблась в 8% случаев» — это особенность системы. Вы создаете избыточность, проводите последующие проверки, проводите проверку человеком в пограничных случаях. В RAG «система дала неправильный ответ в 8% случаев» — это ошибка. У каждого из этих 8% есть конкретная причина: был получен неправильный фрагмент текста, был получен правильный фрагмент, но модель плохо его перефразировала, ответа не было в корпусе, и система его придумала. Это не статистический шум, который нужно оптимизировать в среднем. Это отдельные, исправимые ошибки.
• В машинном обучении обычно невозможно определить, почему модель допустила ошибку в конкретном случае. Именно поэтому объяснимость — это область исследований. В RAG это всегда можно определить. В журналах поиска фиксируется, какие фрагменты текста были возвращены. Генератор видел именно эти фрагменты. Если ответ неверен, вы проходите цепочку в обратном направлении и находите разорванное звено. Ничего скрытого нет.
• В машинном обучении модель улучшается за счет обучения на большем объеме данных. В RAG система улучшается за счет более качественного индексирования, более тщательного анализа, более точного поиска и более четких подсказок. Ничто из этого не является обучением. Это инженерия.

Эта разница влияет на то, какие инструменты вы используете, когда что-то ломается.

Описанные в статье 2 случаи точно попадают в эту категорию: отрицание, точные идентификаторы, внутренние акронимы, ослабление сигнала в длинном контексте, тематическая близость, превосходящая фактический ответ. Ни один из этих случаев не меняется при смене моделей встраивания или изменении размеров фрагментов. Это не ошибки, которые модель может исправить самостоятельно, потому что нет помеченного сигнала, указывающего «это правильная строка», на которой модель должна обучаться. Решение носит структурный характер (анализ вопросов, ключевые слова экспертов, поиск, учитывающий структуру документа), а в следующих разделах рассматриваются три рефлекса машинного обучения, которые вместо этого выбирают неправильный инструмент.

2. Три аргумента, которые не применимы.

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

2.1 Аргумент гиперпараметра

Наиболее распространенная схема выглядит примерно так: размер фрагмента, перекрытие, топ-k, порог сходства. Это гиперпараметры, и их следует оптимизировать так же, как и модели машинного обучения, используя такие инструменты, как Optuna или Ray Tune. Проведите сканирование, постройте кривые и выберите наилучшую конфигурацию.

В этих настройках top_k — это количество фрагментов, которые сохраняет поисковая система, а similarity_threshold — это минимальный косинусный балл, которого должен достичь фрагмент, чтобы соответствовать критериям. Приведенный ниже код объявляет все четыре параметра как числа для оптимизации:

 # What teams typically write (and why it's the wrong activity) import optuna def objective(trial): chunk_size = trial.suggest_int("chunk_size", 100, 2000) chunk_overlap = trial.suggest_int("chunk_overlap", 0, 200) top_k = trial.suggest_int("top_k", 1, 20) threshold = trial.suggest_float("threshold", 0.5, 0.95) accuracy = run_rag_pipeline_and_score( chunk_size, chunk_overlap, top_k, threshold ) return accuracy study = optuna.create_study(direction="maximize") study.optimize(objective, n_trials=200) # two weeks of compute later...

В этом есть доля правды. Эти переменные действительно влияют на качество поиска, и их стоит настраивать. Проблема начинается со слова «гиперпараметр», которое вводит метафору со скрытыми предположениями.

В машинном обучении гиперпараметр управляет процессом обучения модели: скоростью обучения, силой регуляризации, количеством слоев. Сама модель изменяется в процессе обучения; гиперпараметр формирует эти изменения. В алгоритме RAG обучение отсутствует. Размер блока не определяет процесс обучения. Он определяет, как функция разделяет текст, каждый раз одинаково, независимо от того, какие данные были ей переданы ранее.

То, что выглядит как гиперпараметр, на самом деле является параметром конфигурации, подобным тем, которые вы выбираете при настройке поисковой системы. Для его качественной настройки необходимы не статистические методы оптимизации, а понимание структуры ваших документов и формулировки ваших вопросов. Размер блока в 512 токенов может прекрасно работать в объёмных научных статьях и катастрофически плохо — в страховых договорах, где один пункт занимает 800 токенов, и его разделение пополам приводит к потере условного предложения, придающего пункту смысл. Ни один поиск по сетке вам этого не покажет. Вам нужно прочитать свои документы.

Вот почему команды, которые используют поиск по сетке для выбора размера блока данных, часто находят «наилучшее» значение, которое показывает лишь незначительно лучшие результаты на тестовом наборе и идентичные результаты на производственных данных. Оптимальное значение на тестовом наборе данных оказалось артефактом тестового набора, а не подлинным улучшением базовой системы. Они оптимизировали число, а не решили проблему.

Распространенная ошибка: команда в течение двух недель запускает Optuna для параметров chunk_size, top_k и similarity_threshold, в итоге получая chunk_size=487, не понимая, почему. Честный ответ на вопрос «почему 487?» — «потому что так сказала Optuna». Этот ответ не выдерживает реальной проверки в производственной среде и не применим к случаям изменения распределения документов. Размер фрагмента в 500, выбранный потому, что это примерно размер абзаца в этом корпусе, более оправдан, чем размер 487, выбранный потому, что в результате проверки было получено именно такое значение.

Правильная задача — не настройка цифр. Важно определить структурный способ разбивки текста на части. По разделам? По абзацам? По содержанию? По типу вопросов, с разными способами разбивки для коротких запросов и длинных предложений? Ответ дается путем анализа документов и вопросов, а не с помощью оптимизационных кривых.

Есть более веская причина, по которой размер блока данных не поддается оптимизации: по своей сути, ни один размер блока не может охватить все вопросы. Возьмем два вопроса по одному и тому же страховому договору:

• «Какова дата вступления в силу?» Ответ можно найти в одной строке, где-нибудь на первой странице. Требуется фрагмент текста, достаточно небольшой, чтобы точно указать его в одной строке.
• «Какие пункты полиса исключены из его действия?» Ответ может занять одну или три страницы, в зависимости от того, как страховщик его сформулировал. Страховщику нужен достаточно большой фрагмент, чтобы охватить весь раздел.

Не существует числа, которое удовлетворяло бы обоим условиям. Блок размером в 200 токенов разбивает раздел исключений на бессвязные фрагменты. Блок размером в 2000 токенов скрывает дату вступления в силу в окружающем шуме.

Таким образом, попытка найти «оптимальный размер блока» не является проблемой настройки. Сама концепция неверна: ни одно число не может охватить распределение вопросов, ответы на которые имеют разную длину.

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

Но в этом нет необходимости. Вы можете записать правило. Посмотрите на вопрос, и вы поймете, спрашивается ли в нем дата, раздел или сравнение. То же самое может сделать эксперт в данной области. То же самое могут сделать десять строк кода на Python с условиями, написанными от руки, для ключевых слов. Более глубокая причина, по которой RAG не является машинным обучением, заключается в том, что для большинства решений внутри системы вы уже знаете ответ , или кто-то из вашей команды знает. Машинное обучение — это инструмент для решения проблем, где никто не знает ответа заранее.

Правильный подход заключается в том, чтобы перестать искать информацию одного размера и начать направлять различные типы вопросов к различным стратегиям поиска:

 # What to do instead: route by question type def chunk_for_question(question: str, line_df, toc_df): intent = classify_intent(question) if intent == "point_lookup": # "what is the effective date?" return chunk_by_line(line_df) elif intent == "section_retrieval": # "what are the exclusions?" return chunk_by_toc_section(line_df, toc_df) elif intent == "comparison": # "compare clauses A and B" return chunk_by_full_section(line_df, toc_df)

Два приведенных выше блока кода представляют собой всю аргументацию этого раздела. Первый запускает Optuna на четырех числах в течение двух недель и выдает значение, которое никто не может обосновать. Второй принимает одно структурное решение для каждого типа вопросов и создает систему, поведение которой может объяснить любой.

В последующих статьях рассматривается вопрос классификации намерений (статья 6, о понимании вопросов) и реализация различных методов и уровней детализации поиска (статья 7, о поиске). Суть здесь в том, что речь идёт не о настройке, а о маршрутизации.

2.2 Аргумент набора данных для оценки

Следующий важный аспект машинного обучения — метод оценки. Логика такова: RAG, как и любая система машинного обучения, нуждается в соответствующем наборе данных для оценки: вопросы, сопоставленные с ожидаемыми ответами, разделенные на обучающую и тестовую выборки, с оценкой точности и полноты. Такие фреймворки, как RAGAS, сделали это еще более привлекательным, предлагая метрики для достоверности, релевантности ответов и контекстной релевантности, которые выглядят вполне подходящими для машинного обучения.

Оценка полезна. Вопрос не в том, следует ли проводить оценку, а в том, что означают эти метрики. В машинном обучении оценка показывает, удалось ли модели обобщить данные, полученные на обучающей выборке, на ранее не встречавшиеся примеры. Разделение на обучающую и тестовую выборки существует для того, чтобы выявить переобучение: модель, которая запомнила обучающий набор данных, а не выработала переносимый шаблон.

В RAG нет ничего, что нужно обобщать. Переобучение (когда модель запоминает обучающие примеры, а не изучает закономерность, которая переносится на новые данные) здесь невозможно: система не меняется между запросами. Извлекатель вычисляет одни и те же косинусные расстояния каждый раз. Генератор следует одному и тому же шаблону запроса. Модель не подстраивается под данные.

В рамках оценки RAG используются три показателя, все из которых касаются охвата и качества, а не статистического обобщения:

• Содержит ли мой корпус ответ? Если нет, система не сможет его найти. Это вопрос о содержании, а не вопрос о модели.
• Находит ли мой поисковик нужный фрагмент? Если ответ есть в корпусе, но поисковик его пропустил, система дает сбой. Это поисковый вопрос.
• Сохраняет ли мой генератор точность в отношении полученного результата? Если получен правильный фрагмент, но модель перефразировала его неправильно или выдала дополнительные данные, система дает сбой. Это вопрос дисциплины генерации.

Каждый из этих показателей указывает на конкретное решение. Смешивание их под общим оценочным баллом «точности» приводит к потере информации. 75% точности по показателю «в корпусе отсутствует 25% документированных тем» требует иных действий, чем 75% точности по показателю «система поиска пропускает нужный фрагмент в 25% случаев». В первом случае требуется загрузить больше документов. Во втором — исправить работу системы поиска. Общий показатель, рассматривающий их одинаково, скрывает диагностическую информацию.

Это также объясняет, почему команды, использующие фреймворки в стиле RAGAS, иногда показывают отличные результаты на тестовом наборе, а затем наблюдают сбой системы в продакшене. Тестовый набор охватывал темы, по которым в корпусе были ответы, и система их случайно нашла. В продакшене есть вопросы, ответы на которые вообще отсутствуют в корпусе, и система либо выдает ошибку, либо не сообщает «ответ не найден». Высокий показатель на тестовом наборе объясняется тем, что тестовый набор был удобным для использования. Система не сломана. Сломалась оценка.

Для оценки необходимого объема информации, с разбивкой по типам вопросов, потребуется около десяти строк:

 # Retrieval recall, per question, per intent def evaluate_retrieval(reference_set, retrieve_fn): rows = [] for ref in reference_set: retrieved_lines = retrieve_fn(ref.question) recall = len(set(retrieved_lines) & set(ref.expected_lines)) / len(ref.expected_lines) rows.append({ "question": ref.question, "intent": ref.intent, "recall": recall, "hit": recall > 0, }) return pd.DataFrame(rows) # Always break down by question type, never just an aggregate df.groupby("intent")["hit"].mean() # point_lookup 0.92 # section_retrieval 0.41 <-- this is the real problem # comparison 0.55

Единичная совокупная точность в 63% скрыла бы катастрофу на этапе поиска разделов. Разбивка по намерениям выявляет её мгновенно. Под полнотой здесь понимается: находил ли поиск нужный фрагмент текста по вопросам, ответ на которые есть в корпусе? Группировка по намерениям (поиск по точкам, поиск разделов и т. д.) показывает, какие типы вопросов вызывают сбой, и, следовательно, какую часть конвейера необходимо исправить.

RAG имеет две оценочные поверхности, имеющие совершенно разную форму.

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

Поверхность генерации отличается. После того, как нужный фрагмент найден, возникает вопрос: выдала ли модель точный ответ в правильном формате, с корректными ссылками и чистым сообщением «не найдено», когда фрагмент не содержал ответа? Часть этого вы оцениваете самостоятельно, но большая часть уже оценивается поставщиками LLM-решений. OpenAI, Anthropic и Mistral тратят огромные ресурсы на тестирование того, соответствуют ли их модели JSON-схемам, отказываются ли от изобретательства и соблюдают ли инструкции подсказок. Именно по этим параметрам они улучшают свои модели. Как разработчик RAG, вы не обучаете генератор, а используете его. Если модель плохо справляется с возвратом структурированного JSON или не соответствует своим входным данным, вы заметите это в течение часа после интеграции. Это не метрика, которую нужно настраивать; это проверка на адекватность, которая либо очевидна, либо приемлема.

На практике это означает следующее: большую часть времени, затрачиваемого на оценку, следует посвятить поиску (это специфично для конкретного корпуса и может быть выполнено только вами), а не генерации (это в основном проблема поставщика, и очевидные недостатки проявляются быстро). Команды, которые тратят недели на создание сложных наборов инструментов для оценки генерации, обычно откладывают более сложную работу по поиску, которая могла бы улучшить результат.

Далее: в разделе «Оценка вашей системы» (в последующих статьях серии) рассказывается о том, как создать эталонный набор данных для вашего конкретного корпуса, о четырех важных метриках и о том, почему метрики, отражающие тип вопроса, необходимы, а агрегированные метрики вводят в заблуждение.

2.3 Аргумент объяснимости

Машинное обучение имеет собственный набор инструментов для обеспечения объяснимости. Значения SHAP используются для сопоставления прогнозов с признаками. LIME — для локальных аппроксимаций сложных моделей. Визуализация внимания используется для трансформеров. Когда люди начинают задавать вопросы об объяснимости RAG («почему система дала этот ответ?»), они, естественно, обращаются к этим инструментам. Они хотят оценить релевантность поиска, взвесить вклад документов, визуализировать, какие токены повлияли на результат.

Ирония заключается в том, что RAG по своей конструкции более понятен, чем большинство моделей машинного обучения. Нет необходимости в SHAP. Нет никакой непрозрачности, которую нужно было бы раскрыть. Система извлекла эти конкретные фрагменты из этих конкретных источников, и ответ был построен на их основе. Это и есть объяснение. Оно документальное, а не статистическое.

Это указывает на более глубокую асимметрию между машинным обучением и RAG. В машинном обучении человек обладает интуицией, но не может количественно оценить ситуацию. Спросите, кто выжил на «Титанике», и люди ответят: богатство, возраст, класс: ни один ответ не окажется неверным, ни один — точным. У модели нет таких сомнений: постройте дерево решений, и корневым разделителем будет пол, следующим — точный возрастной порог, который никто бы не угадал, затем — класс. Каждое разделение — это число, которое невозможно было бы получить одной лишь интуицией. Модель существует для того, чтобы зафиксировать эти числа.

В случае с текстовыми данными ситуация меняется на противоположную. Пользователь может прочитать исходный текст. Юрист, просматривающий договор, видит условия, исключения, даты. Специалист по соблюдению нормативных требований читает политику и понимает, нарушает ли какое-либо поведение ее положения. Текст не скрывает своего смысла, и эксперт уже свободно владеет чтением.

Есть исключения: сарказм и ирония — классические примеры, где современные программы обучения лингвистике иногда улавливают то, что не замечает внимательный читатель. Но в корпоративной среде пользователь является экспертом в данной области.

Модель предназначена не для объяснения текста. Она предназначена для чтения в масштабе всего корпуса, и одной ссылки достаточно, чтобы эксперт мог проверить любой ответ за считанные секунды.

Когда пользователь спрашивает: «Почему именно этот ответ?», правильный ответ — это не тепловая карта весов внимания или оценка атрибуции признаков. Правильный ответ: «Я просмотрел страницы 12, 47 и 89 этого контракта. Вот точный текст, который я использовал. Ответ вытекает из этого текста». Если пользователь не согласен с ответом, он может сам прочитать источник и оценить ситуацию. Ему не нужна система объяснения. Ему нужна ссылка.

Это уже было продемонстрировано в пятидесятистрочном конвейере из статьи 1. В задании модели требовалось вернуть номера начальной и конечной строк (с указанием страниц) вместе с ответом в структурированном формате JSON; затем аннотатор выделял именно эти строки в PDF-файле. Никакого SHAP, никакого LIME, никакой визуализации внимания, никакой специализированной платформы для мониторинга. «Объяснение» было побочным продуктом формулировки задания. Цитата является частью ответа, а не дополнительным слоем анализа.

След — это объяснение. Для его прочтения не требуется никакой интерпретации, достаточно просто прочитать.

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

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

3. Что меняется, когда вы правильно видите RAG?

Как только вы перестаёте рассматривать RAG как машинное обучение, меняются две вещи. Инструменты, метрики и люди в повседневной работе перестраиваются вокруг поиска, а не обучения. И более глубокий вопрос (где находится интеллект) перемещается от модели к команде. Оба вопроса исходят из одной и той же концепции.

3.1 Инструменты, показатели, люди

Изменятся три конкретных вещи.

Инструменты меняются: вам не нужен PyTorch, обучающий кластер или фреймворки для оптимизации гиперпараметров самой системы. Вам нужен хороший парсер, гибкий механизм получения данных, тщательная разработка подсказок и структурированное логирование всего происходящего. Компоненты машинного обучения (модель встраивания, LLM) вы используете как сервисы. Это стандартные входные данные, а не то, что вы создаете или обучаете.

Метрики меняются: совокупная точность уступает место метрикам для каждого режима отказа: полнота поиска (нашли ли мы нужный фрагмент?), точность ответа (придерживалась ли модель ответа?), точность извлечения (при извлечении структурированных данных совпадали ли значения?), частота отсутствия ответа (если ответа нет в корпусе, указали ли мы это четко?). Каждая метрика измеряет что-то конкретное, каждая соответствует определенной части конвейера, которую можно исправить.

Люди меняются: команда, состоящая исключительно из специалистов по машинному обучению и пытающаяся выпустить систему RAG, часто упускает из виду то, что обеспечивает её работоспособность, и то, что приводит к сбоям. Наиболее важными навыками являются разработка программного обеспечения (система имеет множество движущихся частей, которые должны корректно взаимодействовать), экспертные знания в предметной области (кто-то должен знать, как выглядит хороший ответ на вопрос в предметной области) и интуиция в области поиска информации (кто-то должен мыслить как разработчик поисковых систем, а не как тренер моделей). Экспертные знания в области машинного обучения полезны, но это не доминирующий навык. Команда исследователей в области машинного обучения без эксперта в предметной области создаст идеально настроенную систему, которая не достигнет своей цели. Команда с одним инженером, разбирающимся в машинном обучении, двумя инженерами-программистами и одним экспертом в предметной области, как правило, превзойдёт её по результатам.

3.2 Где находится разведка

Изменения в составе людей указывают на более глубокий вопрос: где же находится интеллект системы?

В системе машинного обучения интеллект находится в модели. Модель хранит закономерности. Команда предоставляет ей обучающие данные и настраивает функцию потерь. В системе RAG интеллект находится в команде. Юрист знает, какие пункты следует изучить в первую очередь. Страховщик знает, что означает «франшиза» и на какой странице обычно она находится. Специалист по соблюдению нормативных требований знает, какое регулирование применяется к какому продукту. Ничто из этого не находится внутри модели встраивания. Ничто из этого не является результатом перебора гиперпараметров. Это уже есть в головах людей, которые читали эти документы годами.

Посмотрите, как андеррайтер открывает новый полис. Она читает его не последовательно. Сначала она переходит к разделу исключений, потому что прочитала уже пятьсот таких полисов и знает, что именно там обычно кроется ловушка. Она проверяет таблицу выплат, франшизы и предельные суммы. Она проверяет пункт о территориальном распределении. Через три минуты у нее уже более ясное представление о договоре, чем у любой модели, построенной на основе тысячи таких договоров. Именно эту привычку система должна усиливать.

3.3. Усиление экспертного потенциала, шаг за шагом.

Задача корпоративной системы RAG — расширить возможности использования этих знаний в масштабе предприятия, а не заменить их. Как именно это будет выглядеть, зависит от конкретного компонента.

Сначала выполняется синтаксический анализ . Если парсер преобразует PDF-файл контракта в зашифрованный текст, никакие последующие действия не помогут его восстановить. Если документ содержит рабочее оглавление, парсер должен извлечь его без ошибок, поскольку именно на оглавление эксперт полагается для навигации. Когда в документе вообще нет оглавления (сканированные факсы, презентации, экспортированные в PDF, старые машинописные документы), его восстановление становится самостоятельной задачей, зачастую более полезной, чем любые попытки его восстановления.

Понимание вопросов помогает команде преодолеть разрыв между тем, как пользователь формулирует вопрос, и тем, как документ содержит ответ. Пользователь пилотного проекта вводит «чайник», в контракте — «небольшой электроприбор». Сотрудник отдела соответствия вводит «нарушение безопасности данных», в политике — «несанкционированное разглашение личной информации». Эксперт знает это соответствие. Анализатор вопросов преобразует это соответствие в справочную таблицу: переводы между языками, варианты написания, формы множественного числа, внутренние аббревиатуры. Ничто из этого не усваивается из данных, это диктуется экспертом и записывается.

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

Функция генерации выполняет две вещи, которые эксперт в противном случае сделал бы вручную: указывает точный отрывок, подтверждающий ответ, и форматирует исходное значение в удобный для использования формат. Строка 3455434 на странице превращается в €3,455,434 в ответе. 20260516 становится May 16, 2026 . Тридцать дней с даты убытка остаются без изменений, с указанием ссылки на соответствующий пункт, чтобы эксперт мог проверить это одним щелчком мыши.

В статьях 5, 6, 7 и 8 последовательно разрабатывается каждый компонент: парсер, извлекающий структуру оглавления, экспертный словарь, сопоставляющий лексику, средство поиска с учетом оглавления, генератор текстовых ответов. Принцип всегда один и тот же: взять часть экспертных знаний человека и перенести повторяющуюся часть в машину.

Именно поэтому в серии статей так осторожно относятся к автономным агентам. По умолчанию предпочтение отдается поиску по ключевым словам, а не использованию сходства встраивания. Настройка алгоритма переранжирования рассматривается как крайняя мера. Каждый из этих вариантов по умолчанию предполагает отсутствие эксперта, к которому можно обратиться. В корпоративной среде эксперт всегда доступен. Система должна прислушиваться к нему.

Если вы работаете в условиях отсутствия экспертов, с неограниченным количеством вопросов и очень разнообразными документами, эта серия статей не станет для вас лучшим руководством. В таких ситуациях лучше подойдут универсальные системы поиска информации и автономные агенты.

4. Две части, два режима отказа.

Удобнее всего представить RAG как поисковую систему, плюс магистр права, который пишет ответ . Две части, каждая со своей четкой задачей, каждая со своим способом решения проблем.

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

Программа LLM берет отрывок текста и вопрос и выдает ответ на естественном языке со ссылкой на источник. Программа LLM не находит ответ. Это уже сделала поисковая система. Программа LLM пишет ответ, основываясь на отрывке текста, который ей был предоставлен. Она больше похожа на переводчика или писца, чем на оракула.

Возвращаясь к четырем кирпичикам из статьи 1: синтаксический анализ, понимание вопросов и поиск вместе составляют поисковую систему; генерация — это LLM. Представление о кирпичиках — это операционное представление (один блок кода на каждый кирпичик); двухкомпонентное представление — это ментальная модель, которую вы храните в голове, когда что-то идет не так.

Две части дают сбой по-разному, и диагностика начинается на стыке между ними. Проанализируйте неудачный запрос: находились ли полученные фрагменты перед моделью и содержали ли они ответ?

Если ответа не было в найденных фрагментах , виновником является поисковая система, а решение проблемы находится на более высоком уровне. Была ли правильная страница повреждена парсером (ошибки OCR, многословные термины, разделенные на строки, двухколоночное чередование)? Пропустил ли парсер вопроса синоним, который экспертный словарь должен был расширить? Вывел ли механизм поиска нужную страницу из top_k или сломался из-за пунктуации, требующей регулярного выражения? Или же соответствующий документ просто отсутствует в корпусе? Четыре совершенно разных решения, все на более высоком уровне. «Настройка механизма поиска» бессмысленна, пока вы не определите, какое именно решение не работает. Те же четыре компонента, которые усиливают эксперта при работе (раздел 3.3), здесь ломаются по-своему, каждый со своей подробной статьей (статьи 5, 6, 7).

Если ответ был найден в исходных фрагментах, но ответ неверен , то виновником является LLM, а исправление находится на более позднем этапе. Типичные ситуации: модель перефразировала и потеряла условие, вернула исходное значение 3455434 , потому что схема оставила ответ в свободной форме, указала неверные номера строк, придумала значение, которого нет в фрагменте, или выдала ответ, когда должна была быть надпись «не найдено». Пять ошибок генерации, пять разных исправлений, все на уровне запроса, схемы или постпроверки (статья 8). Ни одна из них не улучшается при настройке механизма извлечения.

Вот как выглядит эта диагностика на практике. Пользователь спрашивает: «Сколько головок использует базовый трансформер?» (ответ: 8, страница 5 статьи «Внимание — это все, что вам нужно», Васвани и др., 2017; неисключительная лицензия на распространение arXiv, указанная на странице аннотации arXiv). Система сообщает «16». Проследите за ходом процесса.

В результате поиска были получены страницы 4, 7, 8. Ни на одной из них нет конфигурации базовой модели: на странице 8 описывается большая модель (которая действительно использует 16 головок), а на страницах 4 и 7 описывается структура энкодера. Генератор считал не те страницы и вернул найденный там номер. Ошибка связана с поиском, а не с генерацией.

Почему поиск не распознал страницу 5? Ключевые слова были ['heads', 'base', 'model'] . На странице 7 слово "heads" встречается шесть раз; на странице 5 — два раза. Поиск по ключевым словам оценил страницу 7 выше, потому что он использовал частоту встречаемости терминов, не проверяя, встречаются ли слова base , model " и heads в одной строке. Пять строк кода на Python в поиске по ключевым словам исправляют это.

Чего не произошло: никто ничего не доработал. Никто не провел проверку. Никто не добавил инструмент для переранжирования. Диагностика заняла пять минут; исправление заняло полдня.

Именно это разделение делает RAG работоспособным на практике. Каждая ошибка имеет свою конкретную часть, которую нужно исправить. Нет цикла обучения, где извлечение и генерация переплетаются. Это независимые компоненты, чисто структурированные, каждый из которых может быть заменен самостоятельно. Производственные системы много выигрывают от этого свойства: можно менять модели эмбеддинга, менять LLM, менять парсеры — и все это без переобучения чего-либо.

Весь конвейер — это конфигурация, а не модель.

Когда что-то идёт не так, вы меняете конфигурацию: метод получения данных, подсказку, схему, правило проверки. Вы не переобучаете систему. Вы изменяете файл Python, выпускаете исправление, измеряете метрику для каждого типа вопросов в затронутой категории и подтверждаете исправление. Цикл итераций: часы, а не недели.

Как только вы поймете, что RAG — это конфигурация для сборки, а не поведение, которому нужно научиться, остальные решения в этой серии станут очевидными.

5. Шесть месяцев на решение неправильной проблемы.

Команде в среднем предприятии дается шесть месяцев на разработку системы RAG для нескольких тысяч внутренних документов. Они начинают с создания оценочного набора данных из 500 вопросов, разделив его в соотношении 70/30 на обучающую и тестовую выборки. Они настраивают Optuna для проверки размера фрагментов, перекрытия, топ-k и порога сходства. Первая проверка занимает неделю вычислений, дает «оптимальную» конфигурацию, и команда запускает ее для внутреннего тестирования.

Пользователи пилотного проекта сразу же начали жаловаться. Система отвечает бегло, но в половине случаев ошибается на вопросы, которые оценщики явно знают: вопросы о конкретных пунктах, конкретных датах, конкретных числовых ограничениях. В ответ команда расширяет набор данных для оценки, проводит еще один анализ, дорабатывает модель встраивания на синтетических парах «вопрос-документ» и добавляет инструмент переранжирования. Проходит еще три месяца. Точность в работе системы не меняется.

Проблема заключалась в том, что парсер обрабатывал отсканированные страницы с поврежденными слоями OCR как обычный текст. Около 30% корпуса были фактически нечитаемы, но набор данных для оценки, использованный командой, как раз и был взят из читаемых 70%. Никакая оптимизация размера фрагментов, тонкая настройка встраивания или интеграция переранжировщика не могли это исправить: треть документов выдавала некорректный результат. Двухдневная проверка каждой страницы (работа, описанная в статье 5, посвященной парсингу) позволила бы выявить это в первый же день.

Команда провела шесть месяцев в режиме машинного обучения (прорабатывала гиперпараметры, расширяла наборы данных для оценки, дорабатывала модели), когда проблема заключалась в изменении парсера.

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

6. Заключение

RAG выглядит как машинное обучение. Сходство поверхностное. Ответ либо есть в документе, либо его нет. Нет статистического обобщения, нет кривой обучения, нет разделения на обучающую и тестовую выборки, которое соответствовало бы реальным сбоям. Правильная концепция — это сборка поисковой системы: поисковая система плюс LLM, две части, которые можно исправить независимо, при этом совокупная точность заменяется метриками для каждого режима отказа.

Цена сохранения подхода, основанного на машинном обучении, не интеллектуальна. Это шесть месяцев кропотливой работы над неправильной проблемой. Статья 4 превращает правильный подход в работающую диагностику: проблемы RAG располагаются на сетке сложности документа по контролю вопросов, и каждая ячейка требует разного стека.

Статья 4 — это одна из отправных точек для первого тома Enterprise Document Intelligence, в котором пошагово выстраивается корпоративная система RAG, охватывающая синтаксический анализ, анализ вопросов, поиск и генерацию: каждый шаг обрабатывается с помощью инженерного инструментария, а не инструментария машинного обучения.

7. Источники и дополнительная литература

В статье RAG помещается в 50-летнюю традицию информационного поиска (Manning, Raghavan, Schütze, Introduction to Information Retrieval, 2008), а не в традицию машинного обучения. Эмпирическое утверждение о том, что BM25 часто превосходит плотные алгоритмы поиска вне распределения, взято из работы Thakur et al. (BEIR, NeurIPS 2021). Формулировка по режимам отказов совпадает с подходом Barnett et al. (Seven Failure Points, 2024). Честное признание заключается в том, что алгоритм переранжирования представляет собой тонкий обучаемый слой, где применяется методология машинного обучения. В статье для объяснения объяснимости используется цитирование как объяснение : ответ RAG содержит ссылки на свои источники, поэтому инструменты объяснимости, заложенные в бюджет проектов машинного обучения, становятся ненужными.

В том же направлении, что и в статье:

• Маннинг, Рагхаван, Шютце, Введение в информационный поиск (Кембридж, 2008). В статью помещается РАГ в контекст 50-летней традиции информационного поиска.
• Такур и др., бенчмарк BEIR, NeurIPS 2021 (arXiv:2104.08663). Плотные ретриверы, настроенные на MS MARCO, часто проигрывают BM25 вне распределения. Эмпирическое подтверждение эффективности IR, а не фрейминга ML.
• Барнетт и др., Семь точек отказа при проектировании системы RAG, 2024 (arXiv:2401.05856). Практикующая таксономия мест, где система RAG дает сбой. В том же направлении, что и подход, основанный на отдельных режимах отказа.
• Камрадт, «Иголка в стоге сена» (2023). Канонический эталон для поиска информации в длинном контексте. Только для исследований: проверяет один дословный факт в длинном контексте, а не агрегирующие вопросы, которые задают корпоративные пользователи. Обсуждается в статье 1 и разработано в статье 7.

Другой ракурс, другой контекст:

• Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation, EACL 2024 (arXiv:2309.15217). В статье рассматривается RAG с использованием агрегированных метрик машинного обучения (точность, релевантность ответа, точность/полнота контекста) на эталонных наборах данных. Контекст – исследовательские эталоны; в статье рассматривается частота отказов в зависимости от режима работы на фиксированном корпоративном корпусе.
• Саад-Фалкон и др., ARES: Автоматизированная система оценки систем генерации с дополненной реальностью, NAACL 2024 (arXiv:2311.09476). Система оценки RAG в стиле машинного обучения с синтетическим разделением на обучающую, тестовую и тестовую выборки. Контекст аналогичен RAGAS; в статье утверждается, что парадигма разделения на обучающую и тестовую выборки не подходит для корпоративных систем RAG, где ответ либо есть в документе, либо его нет.
• Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 (arXiv:2005.11401). Статья, давшая название RAG, и та, в которой обучались ретривер и генератор совместно. Полезная ссылка на пограничный случай: оригинальная статья о RAG была статьей по машинному обучению, хотя инженерный шаблон, унаследовавший название, таковым не является.

Анджела Ши. Все материалы от Анджелы Ши.

Источник: towardsdatascience.com