От регулярных выражений к моделям машинного зрения: какой метод RAG подходит для какой задачи?

Enterprise Document Intelligence [Том 1, № 4] — Диагностика PDF-файлов и вопросов, а также план методов, которые будут рассмотрены в остальных частях серии.

Делиться

Большинство проблем, связанных с техникой RAG, не заслуживают классического руководства. В статье 3 говорилось, что нет ЕДИНОЙ техники RAG. Вам все равно придется выбрать одну. Эта статья — диагностический инструмент, который подскажет вам, какую именно.

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

Реальные проблемы гораздо разнообразнее, чем это показано в руководстве. Несколько реальных случаев.

Три случая на трёх разных крайних полюсах.

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

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

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

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

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

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

Классический подход избыточен для шаблонных документов (подойдут регулярные выражения), некорректен в размерах стенограмм звонков (отсутствует привязка) и не учитывает модальность данных при работе со схемами (требуется визуальное представление). Он охватывает средний диапазон проблем и выпускается так, как будто решает все. Этот средний диапазон реален, и раздел 3.3 его описывает; именно для предотвращения подобных проблем и предназначена эта статья.

Эта статья — диагностический этап. Три шага в правильной последовательности.

1. Определите две оси: проблемы RAG — это не одна проблема. Они располагаются на картине с двумя осями: насколько структурированы ваши документы и насколько контролируемы ваши вопросы. Каждая комбинация требует разного подхода.
2. Определите методы для каждого региона: каждый регион изображения имеет свой собственный набор методов: регулярные выражения, поиск по разделам, гибридный поиск (лексический поиск + сходство встраивания), компьютерное зрение, агрегация SQL. Третья ось (агентное измерение, раздел 2.4) находится поверх них и определяет, какой уровень контроля над LLM предоставляется во время выполнения. Каталог, приведенный далее в статье, сопоставляет каждый регион с его зоной методов.
3. Определите свой собственный случай: где находятся ваши документы на оси сложности? Где находятся ваши вопросы на оси управления? Пересечение указывает на область и на методы, которые ей соответствуют.

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

Прежде чем перейти к техническим деталям, несколько слов. Большинство корпоративных задач RAG (Research Agencies and Questions) решаются в двух формах: извлечение полей из шаблонных документов (случай с регулярными выражениями в начале статьи) или ответы на вопросы в свободной форме по разнородным документам, таким как контракты и отчеты (где остальная часть серии посвящена большей части времени). Стенограммы разговоров — это третья форма, распространенная в сфере обслуживания клиентов, управления персоналом и соблюдения нормативных требований; сарказм — самый сложный вопрос, который они поднимают. Вопросы, касающиеся чисто визуального контента (схемы, презентации) и вопросов, охватывающих корпус данных (Часть IV), встречаются реже. Вы можете столкнуться с одним или двумя из них. Приведенная ниже таблица поможет вам быстро найти нужный случай.

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

1. Две оси: сложность документа и контроль вопросов.

Каждая проблема, с которой мы столкнемся в этой серии, находится где-то на двух осях:

• Сложность документа: насколько избыточна структура ваших документов? Может ли парсер обращаться к полям по положению, по заголовку, или вам нужна модель, которая видит страницу целиком?
• Контроль за формулировкой вопроса: Кто задает вопрос? Инженер, составляющий заранее подготовленный вопрос, или пользователь, свободно вводящий текст в чат, возможно, не имея ни малейшего представления о том, что спросить?

Эти две оси практически независимы. Единственное совпадение: документ с фиксированным шаблоном (Уровень 1, ниже) обычно вынуждает инженера задавать вопросы по шаблону (Уровень A), поскольку пользователь никогда не вводит вопрос. За пределами этого угла любой уровень документа может сочетаться с любым уровнем вопроса.

1.1 Ось документа: от фиксированного шаблона к модели визуального представления

В первом томе рассматриваются только PDF-файлы. Многоформатные документы (Word, Excel, PowerPoint, электронная почта) рассматриваются во втором томе; все, что описано ниже, посвящено отдельным PDF-файлам.

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

Уровень 1: Фиксированный шаблон: Каждый документ имеет одинаковую структуру, одни и те же поля в одном и том же месте, часто созданные одним и тем же программным обеспечением: страховые сертификаты от одного брокера, формы KYC, налоговые декларации, внутренние подтверждения соответствия. Структура настолько предсказуема, что к полям можно обращаться по их координатам на странице. Техника: извлечение на основе регулярных выражений или координат, без модели.

Уровень 2: Семейство шаблонов: Документы следуют узнаваемому шаблону с вариациями (разные поставщики, разное программное обеспечение, разные годы): счета-фактуры от разных поставщиков, договоры аренды от разных арендодателей, трудовые договоры от разных компаний в рамках одной правовой системы. Техника: регулярное выражение для каждого шаблона плюс несколько примеров LLM в качестве запасного варианта, когда шаблон отличается.

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

Уровень 4: Неструктурированные / ОКР: Отсканированные PDF-файлы, фотографии бумаг, электронные письма, заметки в свободной форме: текст присутствует, но макет искажен или отсутствует. Техника: ОКР с оценкой достоверности, затем гибридный поиск (лексический + векторные представления) по зашумленному тексту.

Уровень 5: Визуально насыщенные: Документы, где смысл заключен в визуальных элементах: схемы, плотные таблицы данных, встроенные в виде изображений, презентации с диаграммами, инженерные чертежи. Анализ чистого текста теряет ответ. Техника: визуально приемлемая модель на изображении страницы, часто в сочетании с RAG на текстовой стороне.

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

1.2 Ось вопросов: от фиксированной подсказки к многоходовому чат-боту

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

Уровень А: Шаблон, разработанный инженером: Вопрос является параметром системы: «Извлеките дату вступления в силу», «Какой номер полиса?». Инженер написал подсказку, откалибровал ее, протестировал на тысяче документов. Пользователь, если таковой имеется, даже не задает вопросов. Техника: извлечение полей, структурированный вывод, не требуется этап анализа вопросов.

Уровень B: Пользователь заполняет ячейки: Вопрос представляет собой шаблон с заданными пользователем значениями: «Покажите мне пункт о {теме} в этом договоре». Пользователь выбирает тему из списка или вводит тег. Форма запроса фиксирована, изменяется только одна ячейка. Техника: поиск по разделам, поиск по известной таксономии.

Уровень C: Бесплатный пользовательский запрос, одноразовый: пользователь вводит все, что хочет, система отвечает за один раз: «Почему этот контракт отличается от прошлогоднего?». Это классическая схема «чат с документом», где система должна проанализировать вопрос, решить, что нужно получить, и дать ответ. Техника: RAG с одним документом и анализом вопроса.

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

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

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

Шкала вопросов — это отдельный вопрос, а не уровень на этой оси. Вопрос «Сколько PDF-файлов в вашем корпусе, и являются ли они однородными или неоднородными?» — это вопрос, касающийся данных, который рассматривается в разделе 3.2 диагностического обследования и разрабатывается в части IV (статьи 14-17). Включение его в ось вопросов размывает две разные вещи, поэтому он не рассматривается отдельно.

1.3 От конкретного случая к технической зоне

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

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

Средняя полоса (строки 2-4, столбцы CD) — это поиск по одному документу. Пример использования, демонстрируемый в каждой демонстрации поставщика, — это общение с PDF-файлом. Это реально, это сложно, и большая часть серии посвящена именно этому. Разбиение документа на блоки для поиска, поиск (выбор нужных блоков), переранжирование (точная проверка списка) и оценка (знание того, что это работает) — всё это важно, когда документ неоднороден и вопрос остаётся открытым.

Нижний ряд (строка 5, все столбцы) — это территория визуализации. Диаграммы, схемы, сложные таблицы. Текстовый парсер теряет ответ, независимо от того, насколько искусно осуществляется поиск. Модели визуализации подходят именно сюда, и только сюда. В статье 10 обсуждается, когда этап визуализации оправдывает свои затраты, а когда нет.

Задания, относящиеся к корпусу большого размера, находятся вне сетки , поскольку сетка представляет собой один PDF-файл за раз. Когда вопрос касается множества PDF-файлов одновременно («найти все контракты поставщиков с ограничением ответственности ниже одного миллиона»), диагностические пути ведут к Части IV (статьи 14-17): классификация при загрузке, структурированные поля, SQL для структурированных данных, RAG для оставшихся неструктурированных вопросов.

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

2. Методы, применяемые в каждом конкретном случае, и то, что не является методом.

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

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

Семейство RAG для работы с одним документом — вот о чём рассказывают части II и III этой серии. Анализ с учётом структуры (статья 5), анализ и калибровка вопросов (статья 6), поиск как выбор области действия (статья 7), генерация как управляемое выполнение (статья 8), гибридный поиск и маршрутизация TOC (статья 9), адаптивный анализ, включая визуальное представление (статья 10), перекрестные ссылки (статья 11), составление списков и синтез (статья 12), составные конвейеры с петлями обратной связи (статья 13). Каждый из этих методов вы будете использовать в центральной части сетки.

Семейство задач, рассматриваемых в контексте корпусной модели, представлено в Части IV. Речь идёт о проблеме создания корпуса (статья 14), подготовке корпуса для выполнения запросов из папки с PDF-файлами (статья 15), онтологии корпуса (статья 16), выполнении запросов с использованием SQL-фильтра в первую очередь и последующего извлечения данных (статья 17). Эти задачи возникают при переходе от одного PDF-файла к корпусу из PDF-файлов.

Если ваша проблема находится в верхнем левом углу сетки, вы можете прекратить чтение серии после статьи 5 (анализ текста) и перейти к статье 15 (подготовка корпуса, пригодного для запросов). Если ваша проблема находится в средней части, вам понадобятся части II и III. Если ваша проблема касается корпуса, вам понадобится часть IV, которая дополнит базовый материал. Карта покажет, какая именно.

2.1 Выберите самый простой и эффективный метод.

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

• Стоимость: при обработке двух миллионов документов в год использование регулярных выражений на виртуальной машине — это погрешность округления; стоимость обучения на магистра права (LLM) за документ составляет шестьдесят тысяч евро.
• Задержка: микросекунды против секунд, разница между ощущением «мгновенно» и ощущением «ожидания».
• Надежность: Регулярное выражение либо совпадает, либо нет, и инженер может прочитать правило; LLM выдает ответы, которые иногда содержат незначительные ошибки, а причины сбоев сложнее обнаружить, что исключает возможность его использования для аудита.

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

2.2 Длинный контекст — не выход

Раз в несколько месяцев кто-то объявляет, что «RAG мертв», потому что контекстные окна стали больше. Аргумент: выложите весь документ в подсказку и позвольте модели самой разобраться.

Это работает для одного документа и одного пользователя. В рабочей среде это не работает по четырем причинам:

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

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

2.3. Сложные приемы обычно представляют собой замаскированную работу с ключевыми словами.

Методы, продаваемые как «продвинутые», часто оказываются работой с ключевыми словами в другой форме, и зачастую в неправильной. HyDE (Hypothetical Document Embeddings, Gao et al., 2022) — самый яркий пример. Протокол требует от студента, изучающего язык программирования, написать гипотетический документ, который бы отвечал на запрос, а затем выполняет поиск по векторному представлению этого гипотетического документа. Суть в том, что гипотетический документ содержит лексику, используемую в реальном ответе, расширяя косинусное поле.

В сопроводительном блокноте это проверяется на примере статьи об механизме внимания: задается вопрос, почему используется многоголовочный механизм внимания, HyDE генерирует соответствующий фрагмент текста, а затем сравнивается с фактическим словарем раздела 3.2.2. Два списка совпадают ровно по одной фразе — заголовку раздела. HyDE использует словарь из учебника по машинному обучению ( semantic relationships , contextual dependencies , parallel processing , attention patterns ); в статье же используется операциональный словарь ( attention layers , encoder-decoder attention , different positions , linear transformations ).

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

2.4 Предоставление возможности магистратуре выбрать кейс

Каждая комбинация уровня документа и уровня вопроса представляет собой элементарный случай с одним соответствующим методом. В первом томе инженер выбирает случай на этапе компиляции и внедряет метод. Диспетчер (статья 13) кодирует знания команды о маршрутизации на Python; LLM анализирует выходные данные внутри фиксированных циклов; каждый блок поддается аудиту. Этого достаточно для подавляющего большинства корпоративных RAG.

Естественным продолжением является ситуация, когда LLM сам выбирает сценарий во время выполнения, анализируя вопрос, классифицируя его по типу сценария и выбирая применяемый метод. Это то, что в индустрии 2026 года называется агентным RAG . Том 3 (Агентные блоки) строит этот слой выбора во время выполнения поверх блоков, созданных Томом 1. Сдвиг касается того, кто принимает решение и когда, а не самих блоков: агентные стеки по-прежнему используют те же примитивы анализа, поиска и генерации, которые Том 1 проверяет и тестирует.

3. Найдите свой случай на практике.

3.1. Разместите систему вокруг существующего эксперта.

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

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

Задача системы ясна: усилить влияние эксперта , а не заменить его. Кодифицировать его лексику, его способы уточнения фраз, его эвристические методы, применяемые из года в год. Пусть конвейер обрабатывает объем информации; пусть эксперт остается источником истины.

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

Формулировка вопроса редко является свойством самих документов или вопросов. Это выбор, который делает команда. Большинство команд перенимают его у чат-ботов для потребителей, даже не замечая этого. Сначала нужно расположить систему вокруг уже имеющегося эксперта. Затем прочитать описание кейса в сетке, на которую указывает ответ.

3.2 Диагностические вопросы

Прежде чем писать код, проработайте эти вопросы. Вслух, перед доской, в присутствии экспертов в данной области.

О документах: насколько они похожи в разных частях корпуса? Исходный текст или распознанный текст (OCR)? Сколько у вас PDF-файлов, и являются ли они однородными или неоднородными? (Здесь в диагностику вступают вопросы, касающиеся масштаба корпуса — они относятся к Части IV). Статическое или ежедневное поступление? Какое место они занимают на оси документов?

О вопросах: Кто их формулирует? Инженер на этапе проектирования или пользователь во время выполнения? Система является одноразовой или может запросить уточнение? Ответ всегда содержится в одном документе или распределен по нескольким? Что означает отсутствие ответа: приемлемо или неприемлемо? Где они находятся на оси вопросов?

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

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

3.3 Типичные сценарии использования энергосети предприятиями

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

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

Извлечение полей из различных вариантов шаблонов. Представьте себе счета-фактуры от сотен поставщиков, договоры аренды от разных арендодателей, трудовые договоры от разных компаний в рамках одной правовой системы: каждый документ соответствует одному из нескольких узнаваемых шаблонов. Пример: документ 2-го уровня, вопрос A или B. Стек алгоритмов: регулярное выражение для каждого распознанного шаблона, плюс краткое извлечение LLM, если документ не соответствует ничему в реестре. Классификация перед извлечением.

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

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

Вне рамок — территория корпуса: «Найдите все контракты с поставщиками, в которых лимит ответственности ниже одного миллиона», охватывающие сотни или тысячи контрактов. Единая сетка PDF-файлов перестает быть подходящей основой; вопрос направлен на корпус, а не на один документ. Стек: извлечение полей при загрузке, структурированные поля, хранящиеся в базе данных, SQL на структурированной стороне, RAG только в качестве резервного варианта для оставшихся неструктурированных вопросов. Статьи 14-17 (Часть IV) развивают эту тему.

Вне рамок системы — отсутствие структуры, на которую можно было бы опереться: роман, классификация намерений, обнаружение сарказма. Документ не имеет структуры, словарный запас не содержит характерных терминов, а вопрос требует понимания тона или намерений, а не поиска отрывка. Stack: LLM, который сканирует весь текст абзац за абзацем, решая, что следует отметить. Это не проблема RAG в смысле первого тома; раздел 2.4 намекает на то, где место подобному принятию решений во время выполнения (третий том).

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

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

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

Следующая статья открывает вторую часть, рассматривая первый кирпичик: анализ документов. Все, что было потеряно на этом этапе, невозможно восстановить позже, как бы искусно ни проводилось восстановление.

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

Двухосевая сетка представляет собой карту, показывающую, где каждый подход находится в контексте сложности документа и управления вопросами в одном PDF-файле. Утверждение о том, что длинный контекст не заменяет поиск информации, на котором основана сетка, подкреплено работами Лю и др. (Lost in the Middle, TACL 2024) и Ли и др. (long-context benchmark, 2024). Строка с описанием визуального восприятия соответствует работе Фейссе и др. (ColPali, 2024). Демонстрация HyDE использует технику Гао и др. (HyDE, 2022). Расширение агентного подхода, упомянутое в разделе 2.4 (выбор случая LLM во время выполнения), — это направление, которое развивается в третьем томе на основе построенных здесь элементов.

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

• Лю и др., «Затерянные посередине: как языковые модели используют длинные контексты», TACL 2024 (arXiv:2307.03172). Модели систематически упускают информацию в середине входных данных. Это подтверждает утверждение, что длинный контекст не является выходом из ситуации.
• Ли и др., Могут ли языковые модели с длинным контекстом заменить поиск информации, RAG, SQL и многое другое?, 2024 (arXiv:2406.13121). Конкретные данные о том, где длинный контекст заменяет поиск информации, а где нарушается.
• Фейсс и др., ColPali: Эффективный поиск документов с использованием моделей визуального языка, 2024 (arXiv:2407.01449). Поиск визуального языка непосредственно на изображении страницы. Привязывает визуальную строку сетки.
• Гао и др., Точный поиск с нулевым количеством примеров без меток релевантности (HyDE), 2022 (arXiv:2212.10496). Методика встраивания гипотетических документов, протестированная в разделе 2.3.

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

• Яо и др., ReAct: Синергия рассуждений и действий в языковых моделях, ICLR 2023 (arXiv:2210.03629). Основополагающая работа в рамках направления LLM-picks-tools-at-runtime. Том 3 развивает эту идею на основе элементов, заложенных в Томе 1.
• Шик и др., Toolformer: Языковые модели могут научиться использовать инструменты, NeurIPS 2023 (arXiv:2302.04761). Направление исследования аналогично ReAct.
• Гао и др., Генерация с расширенным поиском для больших языковых моделей: обзор, 2024 (arXiv:2312.10997). Обзор RAG; рассматривает RAG как одну парадигму с общими проблемами (качество извлекающего объекта, точность генератора).

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

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