RAG нужен, когда системе требуется найти релевантные фрагменты документов и передать их LLM для подготовки ответа. Для многих enterprise-задач генерация не нужна: код можно проверить точным совпадением, опечатку исправить нормализатором, категорию выбрать классификатором, а значение найти в справочнике.
Выбор метода должен зависеть от типа вопроса и структуры данных, а не от популярности RAG. Чем формальнее задача, тем больше преимуществ у детерминированного правила: ниже задержка, проще аудит, понятнее причина ошибки и легче контроль изменений. LLM и RAG стоит оставлять для случаев, где требуется смысловое понимание, работа с несколькими фрагментами или связный текстовый ответ.
Практичный стек для документов обычно выглядит как каскад: OCR и извлечение, нормализация, точные проверки, словари, классификация или embeddings, затем LLM либо RAG для сложных случаев. Такой подход позволяет направлять дорогие компоненты только на те запросы, которые не закрываются простыми методами.
Почему RAG не должен быть ответом на любую задачу с документами
Какие задачи действительно решает RAG
RAG объединяет два этапа. Сначала retrieval-компонент ищет в индексе фрагменты, связанные с запросом. Затем generation-компонент передает найденный контекст языковой модели, которая формирует ответ.
Такая схема подходит для вопросов вроде «какие условия расторжения договора описаны в документе?» или «сравните требования двух разделов политики». В этих случаях нужно найти подходящие места, связать информацию и выразить результат в свободной форме.
RAG не заменяет OCR, очистку текста, классификатор, справочник или табличный парсер. Если PDF содержит плохо распознанную таблицу, retrieval получит поврежденный текст. Если пользователь просит определить код из фиксированного списка, генерация добавляет неопределенность там, где достаточно проверки значения. Если нужно извлечь сумму и дату, ответ LLM придется дополнительно проверять по схеме и исходному документу.
У RAG есть собственные точки отказа: парсинг может разрушить структуру, обработка запроса может не распознать термин, поиск может не поднять нужный фрагмент, а модель может сформулировать правдоподобный ответ с ошибкой. Практический разбор таких сбоев есть в статье о четырех этапах RAG-пайплайна.
Где RAG оказывается избыточным
Генеративный контур часто не нужен в четырех группах задач:
- проверка точного идентификатора, номера договора, артикула, кода или статуса;
- отнесение обращения к одной категории из заранее заданного списка;
- поиск устойчивого термина, реквизита или шаблонной фразы;
- сопоставление пользовательского текста с небольшим контролируемым справочником.
Например, строку «Договор № AB-2048» разумно искать через нормализованное сравнение или регулярное выражение. Запрос «не могу войти в личный кабинет» можно направить в категорию «авторизация» с помощью словарных признаков и классификатора. Система, которая вызывает LLM для каждой такой операции, получает более сложную отладку и дополнительные точки отказа.
Простые методы не универсальны. Они ломаются на новых формулировках, неполных словарях, смешанных намерениях и поврежденном OCR-тексте. Поэтому для них нужен fallback: низкоуверенный результат отправляется на следующий уровень каскада или ручную проверку.
RAG или классический NLP enterprise: как выбирать по типу задачи
Когда достаточно детерминированного правила
Правило подходит, если признак формален и его можно описать заранее. Это регулярное выражение для номера документа, проверка даты, поиск кода, контроль обязательного поля, сопоставление статуса или проверка допустимого значения.
Перед сравнением строки обычно приводят к единому виду: меняют регистр, убирают лишние пробелы, унифицируют дефисы и формат дат. Для идентификаторов полезно разделять визуальное представление и каноническое значение. Например, «AB-2048», «ab 2048» и «AB2048» могут считаться одним кодом, если такое правило подтверждено форматом конкретного справочника.
Правила нужно хранить в репозитории или версионируемом хранилище. Для каждого изменения пригодятся дата, автор, область действия и набор регрессионных примеров. Исключения лучше описывать явно: слишком агрессивное правило способно принять похожий код за нужный и испортить юридически значимое поле.
Когда нужен семантический, а не буквальный поиск
Словарный поиск теряет качество, когда пользователь перефразирует запрос и не использует устойчивые ключевые слова. «Сбой входа в аккаунт», «не получается авторизоваться» и «система не принимает пароль» могут описывать одну тему, хотя набор слов различается.
Embeddings переводят запрос и эталонные описания в векторы. Затем система сравнивает их близость и выбирает наиболее подходящий кандидат. Это промежуточный уровень между лексическими правилами и LLM: модель понимает сходство формулировок, но не генерирует свободный ответ.
Для embeddings нужны индекс, доменная модель или проверенная универсальная модель, порог сходства и тестовый набор. Один высокий балл еще не доказывает правильность: два класса могут быть семантически близкими, а короткий запрос может не содержать достаточно признаков. Для пограничных случаев следует сохранять несколько кандидатов и отправлять их на проверку.
Перед выбором технологии ответьте на четыре вопроса:
- Нужен точный результат или смысловая близость?
- Есть ли эталонный справочник или фиксированный набор классов?
- Насколько стабилен формат входных данных?
- Требуется выбрать значение или сгенерировать новый текст?
Ответы задают маршрут. Сначала проверяются формальные признаки, затем словари и классификация, после них embeddings, а LLM и RAG подключаются при недостаточной уверенности или для сложного объяснения.
NLP-методы вместо RAG: от точного совпадения до LLM
Точное совпадение для кодов, терминов и реквизитов
Точное совпадение дает самый предсказуемый результат. Оно подходит для кодов продуктов, номеров заявок, ИНН, артикулов, статусов, названий полей и терминов, которые записываются по утвержденному шаблону.
Базовый pipeline включает очистку строки, приведение регистра, замену допустимых разделителей и сравнение с каноническим значением. Синонимы и варианты написания нужно хранить отдельно от основного значения. Тогда аудит может показать, почему пользовательская строка связалась с конкретной записью.
Риски появляются при различиях в пробелах, дефисах, раскладке клавиатуры, похожих символах и форматах записи. Сравнение «О» и «0», «I» и «1» допустимо только в полях, где такой конфликт заранее изучен. Для свободного текста подобные замены могут изменить смысл.
Нормализация опечаток и OCR-шума
OCR часто путает похожие символы, теряет пробелы, дублирует знаки и разрушает границы слов. Часть ошибок исправляется дешевым предварительным слоем:
- удаление повторяющихся пробелов и лишних символов;
- приведение регистра и раскладки к единому виду;
- восстановление пробелов в известных шаблонах;
- обработка типовых подмен букв и цифр в конкретных полях;
- поиск устойчивых реквизитов регулярными выражениями.
Безопасность правила зависит от области применения. Замена символов внутри номера счета может быть оправдана при строгой проверке длины и контрольной суммы. Та же замена в абзаце договора способна изменить юридический смысл.
Исходный OCR-текст нужно сохранять рядом с нормализованной версией. Для каждой коррекции полезно фиксировать правило и позицию изменения. Если слово повреждено в свободном тексте и уверенности нет, лучше передать небольшой фрагмент embeddings или LLM, сохранив оригинал для аудита.
Словарный поиск и лексические признаки
Доменный словарь связывает каноническую категорию с синонимами, словоформами, аббревиатурами и устойчивыми фразами. Для классификации обращений можно задать признаки «пароль», «вход», «код подтверждения», «учетная запись» и связать их с категорией авторизации.
Словарный слой полезно строить с весами. Редкий точный термин получает больший вес, общий глагол вроде «не работает» почти не влияет на результат. Для конфликтующих признаков задаются приоритеты: специфичная фраза должна перевешивать общий маркер.
Морфологические формы можно сводить к леммам или хранить явно, если словарь небольшой. Аббревиатуры и внутренние названия лучше поддерживать отдельными алиасами. При изменении продуктовой линейки словарь обновляют вместе с датами действия записей и примерами.
Ограничение метода очевидно: неизвестная формулировка не попадет в словарь. Поэтому словарь стоит сочетать с классификатором или embeddings, а низкую уверенность направлять на следующий уровень.
Embeddings для смыслового сопоставления
Embeddings подходят, когда нужно сравнить пользовательский запрос с описаниями классов, товаров, услуг или фрагментов справочника. Вместо поиска одинаковых слов система оценивает близость смысловых представлений.
Для enterprise-документов эталонные записи должны быть содержательными. Описание «доступ к системе» хуже различает классы, чем «восстановление пароля сотрудника» или «блокировка учетной записи после неверных попыток». Качество зависит от исходного текста, домена модели, языка, длины запроса и выбранного порога.
Систему нужно проверять на реальных перефразированиях, коротких запросах, отрицаниях и близких категориях. Нельзя считать любое совпадение выше порога правильным: порог выбирают по цене ложных и пропущенных совпадений.
LLM и RAG для нерегулярных вопросов
LLM оправдана, когда структура запроса заранее неизвестна, требуется извлечь сложное условие, обобщить несколько фрагментов или подготовить объяснение. RAG добавляет поиск контекста, если нужные сведения находятся в большом корпусе документов.
Пример задачи: «Сравните ограничения для подрядчиков в трех версиях политики и укажите, какие пункты изменились». Здесь нужно найти несколько мест, сопоставить условия и сформировать связный ответ. Простое совпадение или embeddings могут помочь найти кандидатов, но не закрывают весь анализ.
LLM требует контроля галлюцинаций, строгой схемы результата и проверки обязательных полей. RAG дополнительно зависит от качества парсинга, нарезки, индекса и retrieval. Для перекрестных ссылок полезен отдельный контур разрешения ссылок, описанный в статье о дополнении ответов содержимым связанных разделов.
Классификация обращений: почему генерация ответа часто не нужна
Каскад для фиксированного набора категорий
Если у службы поддержки есть утвержденный список категорий, задача сводится к выбору класса. Генерировать ответ на первом этапе не требуется.
- Очистить текст, привести регистр и обработать типовые OCR-ошибки.
- Проверить явные маркеры и словарные фразы.
- Для остальных обращений запустить классификатор или embeddings.
- Сравнить результат с порогом уверенности.
- Передать неуверенные, смешанные и неизвестные случаи на дополнительную проверку.
Категории удобно организовать иерархически. Сначала определяется крупная тема, например «доступ», «платежи» или «доставка», затем дочерний класс. Для обращения «не могу войти и не вижу начисление» можно разрешить несколько меток или выбрать основной класс по заранее заданному приоритету.
Где классификатор перестает справляться
Качество снижается, когда появляются новые продукты, короткие сообщения, редкие классы и обращения с несколькими намерениями. Фраза «счет списали, но заказ не отображается» может относиться к платежу, заказу или сразу к двум процессам.
Без размеченного набора нельзя надежно выбрать порог уверенности. В него должны входить обычные, сложные и пограничные обращения, включая неизвестные темы. Для низкоуверенных результатов нужен fallback, а не принудительное назначение ближайшей категории.
RAG можно подключить после классификации, чтобы найти инструкцию для оператора или объяснить признаки решения. Смешивать маршрутизацию и генерацию в одном вызове не обязательно.
Сопоставление свободного текста со справочником
Как устроить приоритеты совпадений
Справочник должен хранить каноническое значение, код, алиасы, даты действия и дополнительные признаки. Пользовательский текст проходит каскад сопоставления:
- канонический код;
- точное нормализованное название;
- словарный синоним или алиас;
- лексическое и нечеткое сравнение;
- семантическое сравнение через embeddings.
Такой порядок защищает точные идентификаторы от менее надежного семантического кандидата. Если два значения близки, система должна вернуть оба варианта, причину выбора и запросить ручную проверку. Автоматическое решение полезно только при понятном запасе уверенности между первым и вторым кандидатом.
Как обновлять справочник без переобучения всей системы
Контролируемый справочник можно менять независимо от классификатора и embeddings. Для каждой записи храните версию, алиасы, дату начала и окончания действия, владельца изменения и историю связанных документов.
При появлении нового продукта достаточно добавить каноническое значение и варианты написания. После этого запускаются тесты на старых примерах, чтобы новый алиас не начал перехватывать запросы соседней категории.
Качество зависит от полноты справочных данных. Даже сильная embedding-модель не найдет корректный кандидат, если нужной записи нет или ее описание слишком общее. Справочник должен быть источником истины, а индекс и векторные представления, его производными.
Чтение таблиц и документов с фиксированной структурой
Сначала схема и валидация, затем языковая модель
Финансовые, кадровые и операционные таблицы лучше извлекать специализированным табличным или документным парсером. Результат нужно приводить к схеме с типами полей, обязательными значениями и правилами связности строк.
Минимальный набор проверок включает количество колонок, типы дат и чисел, единицы измерения, допустимые значения, наличие обязательных полей и соответствие итогов исходным строкам. Если документ содержит сумму, ее нельзя считать достоверной только потому, что LLM вернула число в правильном формате.
Отправка всей таблицы в RAG усложняет контроль чисел, пропусков и связей между строками. Для регулярной структуры надежнее получить данные по схеме, проверить их программно и сохранить ссылку на исходную область документа.
Когда таблица становится задачей понимания
Простой парсер может не справиться с многоуровневыми заголовками, объединенными ячейками, сносками и связью таблицы с поясняющим абзацем. Например, значение «5» может означать проценты, месяцы или количество сотрудников в зависимости от заголовка и примечания.
В таких случаях LLM можно применить точечно: определить структуру заголовков, связать сноску с колонкой или классифицировать нестандартный блок. RAG нужен, если для интерпретации приходится искать определения в других разделах документа. Остальные строки по-прежнему следует извлекать и проверять обычным pipeline.
Обработка OCR-шума: дешевый слой перед любым поиском
Какие ошибки исправляются правилами
Качество retrieval и классификации часто ограничивает текст на входе. До индексации и поиска полезно нормализовать регистр, пробелы, повторяющиеся символы и типовые подмены букв в известных полях.
Для реквизитов можно искать устойчивые шаблоны: номер договора, дату, индекс, код товара или телефон. Каждое правило должно иметь область действия. Замена похожих символов допустима в поле с известной маской, но опасна в произвольном абзаце.
Нормализованный текст хранится вместе с оригиналом. Лог должен показывать, какие символы изменились, какое правило сработало и почему результат прошел валидацию. Это особенно важно для договоров, счетов и других юридически значимых документов.
Когда OCR-ошибка требует более сложной модели
Embeddings или LLM нужны, когда повреждено слово в свободном тексте, нарушена сложная верстка или OCR не сообщил уверенность. Обрабатывать следует проблемный фрагмент, а не весь корпус. Исходное написание сохраняется рядом с исправленной гипотезой.
Агрессивная коррекция опасна: она может превратить номер, имя или условие договора в другое значение. Система должна уметь вернуть статус «требуется проверка», а не скрывать неопределенность под гладким исправлением.
Как собрать каскадный стек для enterprise-документов
Пример маршрутизации по типу запроса
Базовая архитектура состоит из последовательных уровней:
- ingestion и OCR с сохранением координат и исходного текста;
- нормализация пробелов, регистра, раскладки и известных искажений;
- правила, регулярные выражения и точные совпадения;
- словарный поиск и лексические признаки;
- классификатор или embeddings для неочевидных совпадений;
- LLM или RAG для составных вопросов и генерации объяснения.
Маршрутизация определяется задачей. Код идет в exact match. Предсказуемая опечатка проходит через normalizer. Значение из справочника ищется по алиасам и лексическим признакам. Перефразированный запрос направляется в embeddings. Составное объяснение по нескольким разделам передается LLM или RAG.
Пайплайн можно разделить по типу документа. Счета требуют строгой схемы и арифметической проверки, обращения, классификатора и контроля неизвестных тем, договоры, поиска условий и ссылок между разделами. Один универсальный маршрут обычно проигрывает специализированным правилам.
Что хранить для отладки и аудита
Для каждого результата фиксируйте:
- исходный текст и нормализованную версию;
- тип документа и область поиска;
- сработавшее правило или словарь;
- найденный кандидат и альтернативы;
- оценку и порог сходства;
- версию справочника, модели и промпта;
- итоговый маршрут и причину fallback;
- ссылку на страницу, строку таблицы или координаты фрагмента.
Такие данные позволяют отделить ошибку OCR от ошибки классификатора, retrieval от генерации. Без журнала команда видит только неверный финальный ответ и не понимает, какой компонент нужно исправлять.
Как проверить, что замена RAG действительно оправдана
Какие ошибки важнее средней точности
Средняя точность не описывает цену ошибок. В справочнике ложное сопоставление может быть опаснее пропуска, а для маршрутизации обращения неверная категория может привести к нарушению SLA. Для критичных полей нужны строгий порог, обязательная валидация и ручная проверка сомнительных случаев.
Отдельно измеряйте:
- ложные совпадения;
- пропущенные документы и значения;
- неверные категории;
- долю запросов, ушедших в fallback;
- долю ручной обработки;
- задержку и стоимость инференса;
- стабильность результата при повторном запуске;
- сложность сопровождения правил, словарей и индексов.
Для генеративного слоя добавляются полнота ответа, наличие подтверждающего фрагмента и число неподтвержденных утверждений. Сравнивать нужно одинаковые наборы документов и одинаковые классы запросов.
Пилот: от простого baseline к сложному компоненту
Начните с набора реальных примеров: типичных, сложных, пограничных и заведомо неизвестных. Разметьте правильную категорию, каноническое значение, извлеченные поля и допустимый fallback.
Первый baseline строится на правилах, нормализации и словарях. Если сохраняется заметный класс ошибок из-за перефразирований, добавьте embeddings. LLM или RAG подключайте к остаточным случаям, где требуется понять несколько условий, разрешить ссылки или составить объяснение.
Каждый новый уровень должен проходить тот же тестовый набор. Сравнивайте точность, полноту, латентность, стоимость обработки и долю ручной работы. Если сложный компонент не уменьшает значимый класс ошибок, его присутствие в pipeline не оправдано.
Итог: RAG остается инструментом, а не архитектурной религией
Точное совпадение подходит для кодов, терминов и реквизитов. Нормализация устраняет предсказуемый OCR- и пользовательский шум. Словари закрывают контролируемую доменную терминологию. Классификатор выбирает категорию из фиксированного набора. Embeddings помогают при смысловом сопоставлении и перефразированиях. LLM и RAG нужны для сложного понимания, поиска по корпусу и генерации связного ответа.
Для enterprise-документов разумный выбор выглядит как каскад: сначала дешевый и объяснимый уровень, затем более гибкий компонент при недостаточной уверенности. Такой pipeline легче тестировать, сопровождать и адаптировать к новым справочникам, продуктам и типам документов.
Перед подключением RAG проверьте, что задача действительно требует retrieval и генерации. Если ответом должен стать код, класс, значение из справочника или проверенный набор полей, начните с NLP-компонента, схемы и валидации. Сложный инструмент оправдан там, где он закрывает конкретный остаточный риск, а не просто присутствует в архитектуре.