Производственный RAG-конвейер для PDF-файлов: реляционный анализ, поиск оглавлений, типизированные ответы.

Enterprise Document Intelligence [Том 1 #9A] – Та же статья, тот же вопрос, что и в статье 1. Один улучшенный контракт для каждого блока: анализ документа, анализ вопроса, поиск, генерация

Делиться

Эта статья дает третью часть серии статей «Интеллектуальное управление документами на предприятии», в которой задачи создания корпоративной системы RAG из четырех компонентов: анализ документов, анализ вопросов, поиск и генерирование.

Это первая из двух частей модернизированного конвейера: в этой части модернизируется каждый блок, по одному контракту за раз, по тому же самому документу и с той же темой, что и в статье 1 (минимальный RAG). Вторая часть, объединение четырех блоков RAG в один конвейер, протестированный на одних документах (ссылка Председателя позже), объединяет их в один вызов и запускает его на нескольких дополнительных документах.

📓 Запускаемые сопутствующие блокноты доступны на GitHub : doc-intel/notebooks-vol1.

Сто строк кода Python связывают одновременно четыре функции: анализ PDF-файла, анализ результатов, получение нескольких страниц, обращение к моделям.

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

• Теперь при разборе документа возвращается не просто line_df , реляционный набор данных, включающее оглавление, метаданные уровни страниц и типизированное parsing_summary , содержащий тип документа, язык и краткое описание его содержания в одном abzace.
• Анализ вопросов преобразует зашумленный пользовательский ввод в структурированное краткое изложение, в котором ключевые слова корректируются с учетом собственного словарного корпуса, форма ответа Определена на основании возникновения (одно значение, список, таблица).
• Система поиска читает оглавление так, как это сделал эксперт: дает все оглавление небольшому специалисту с магистерской степенью, который выбирает разделы по семантической релевантности, а затем выбирает их со страницами, содержит ключевые слова. который конвейер обрабатывает, чтобы решить, следует ли отправить ответ или выбрать еще один проход.

Основной документ — это опубликованная на arXiv 15-страничная статья под названием «Внимание — это всё, что вам нужно». Вопрос «Какие существуют варианты позиционного кодирования?» содержит две опечатки, так что блоку анализа вопросов есть чем заняться. Результат — это то, что нужно корпоративному пользователю: напечатанный ответ с дословными цитатами, обоснованными к неизменным строкам и полный журнальный аудит по вопросам цитирования.

1. Где происходит разрыв базового уровня RAG

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

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

• Анализ документа : документ преобразуется в плоский список. Статья 1 (минимальный RAG) преобразовала PDF-файл в одну строку простого списка, достаточный для подсчета ключевых слов, но не более того. Страницы, разделы, таблицы, вся структура, на которой мог бы основываться код следующего блока, выбрасываются на первом этапе.
• Анализ вопросов: вопросы, которые задают пользователи, редко бывают корректными. В вопросе «Какие есть варианты для позиционного кодирования?» две опечатки. Базовый экстрактор ключевых слов не увидел слово «позиционный», он увидел «позиционный», поэтому поиск пропускает именно ту страницу, где находится ответ.
• Поиск информации : базовый никогда не определяет определение. В документе Внимание присутствует четкое встроенное оглавление, именованные разделы с номерами страниц, на трех уровнях вложенности. Наиболее сильное определение сигнала поиска во всем документе теряется.
• Генерация: ответ возвращается в виде необработанной строки. В вопросе со списком вариантов ответ запрашивается по одному вопросу для каждого собеседника, согласно каждому его утверждению. Свободная форма причины заставляет вызывающую сторону повторно проанализировать ответ, чтобы найти пункты; типизированная схема с диапазоном подтверждений для каждого пункта границы этого шага.

Четыре блока ниже используют эти четыре слабых места. Тот же документ, тот же вопрос, настоящие звонки на экзаменах LLM. В результате получается напечатанный список с дословными цитатами, диапазонами строк и полной цепочкой решений, которые привели к его созданию.В результате обновления сохранилась та же самая структура из четырех блоков, что и в статье 1 (минимальный RAG). Изменился контракт для каждого блока: что потребляет каждый блок, что он производит и как потребляет следующий блок. На диаграмме ниже представлен контракт: каждый блок, переменные в данных выходного дня, и какой нижестоящий полный блок потребляет каждый из них (включая побочный канал parsing_summary, ведущий как к анализу, так и к формированию вопросов). Затем в разделах, посвященных каждому блоку, подробно описан осмотр каждого блока.

Каждый из четырех блоков улучшен в отделении, который стоит прочитать, чтобы ознакомиться с полным текстом контракта:

• Анализ документов : статья 5A (читать в PDF-файле) и статья 5B (реляционная модель данных).
• Разбор вопросов : статья 6A (тезис), статья 6B (извлечение) и статья 6C (отправка).
• Поиск : Статья 7A (поиск как фильтрация), Статья 7B (обнаружение якоря) и Статья 7C (арбитр LLM).
• Генерация : контракт ответа, сборка запроса и проверка (статьи 8A–8C, ссылки будут добавлены позже).

2.1 Анализ документов: небольшой набор реляционных данных

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

Входные данные: pdf_path , PDF-файл на диске. Выходные данные: line_df , page_df , toc_df , parsing_summary .

На выходе получается один ряд на единицу продукции:

• line_df : одна строка на каждой видимой форме ( page_num , line_num , text , ограничивающая рамка). Единица цитирования.
• page_df : одна строка на странице ( page_num , text ). Грубая поверхность поверхности.
• toc_df : одна строка в разделе ( title, <код>уровенькод> , <код>начальная_страницакод> ). Карта самого документа.
• parsing_summary : метаданные уровни документа (тип документа, язык, количество страниц, макет). Дополнительный канал для доступа к блокам LLM.

В 1 (минимальный RAG) PDF-файл был преобразован в один DataFrame под названием line_df , по одной строке в видимой форме текста статьи. Этого достаточно для поиска ключевых слов, но недостаточно для чего-либо еще. В статье 5 (анализ документа) анализ переосмыслен как построение небольшого реляционного набора: line_df Остается, page_df ключевые строки на странице с их текстом, а toc_df содержит исходное оглавление документ.п>

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

Номера page_num и line_numв каждой строке преобразуют ответ в цитату. Если отобразить строки на той же странице, откуда они были взяты, то они будут Google буквально: распознаваемая строка представляет собой отдельный блок, а ее line_num находится в промежутке между строками.

Агрегирование строк поичностран дает page_df — естественную единицу страницы, которая содержит текст всей страницы и контекст на уровне страницы:

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

Три таблицы одинаковы, формы контракта, одинаковые числовые первичные ключи. Блоки обработки данных считывают необходимые данные без повторного анализа PDF-файла; Функция извлечения (раздел 2.3) сканирует совпадение ключевых слов и считывает toc_df для привязки к нужному разделу, а затем определяет размер контекста вокруг него (весь раздел или строковое окно) с той степенью детализации, которая формируется в вопросе. page_df — это количество резко на уровне страницы, toc_df card, line_df атомарные строки, из которых вырезаны якорь и окно. <код>parse_pdf фактически получает больше данных в том же словаре (области изображения, внутренние ссылки, именованные объекты) плюс parsing_summary , независимо метаданные на уровне документа (тип документа, язык, количество страниц, макет, типичные поля, краткое описание); этот раздел посвящен трем таблицам, которые считывают функцию извлечения, parsing_summary возвращает во второй части как побочный канал , который применяет блоки в обработке данных LLM.

2.2 Анализ вопросы: от шума к краткому содержанию

Анализ результата преобразует исходный текст пользователя в выбранный текст, на основе которого выполняются два блока. п>

Входные данные: исходный question , concept_keywords_df эксперта и parsing_summary для контекста документа. Выходные данные: ParsedQuestion последовательно intent , keywords , краткое описание RetrivalQuery и GenerationBrief .

Что получается в итоге:

• keywords : исправлены опечатки и подобраны термины из общего содержания в рамках одного конкурса на получение степени магистра права, а затем расширены с использованием лексики эксперта.
• intent : форма ответа, в котором содержится вопрос (фактическая, перечислительная, сравнительная).
• RetrivalQuery : используется краткий запрос ( main_query , rewrites , anchor_keywords , section_hint , layout_hint ).
• GenerationBrief: генерация может воздействовать только на те поля, которые ей доступны (вопрос, форма ответа, разрешение неоднозначности).

Статья 1 (минимальный RAG) вызвала get_keywords_from_question для конкретного вопроса и получила ответ <код>исправленный_вопроскод>плюс короткий список ключевых слов для одного вызова LLM. Этот единственный вызов выполняет две задачи одновременно: исправляет поверхностные опечатки и извлекает ключевые слова из оценки. Исправленные ключевые слова проводятся непосредственно из анализа, без дополнительных проверок орфографии. Если ключевое слово действительно отсутствует в документе, то восстановление представляет собой обратный цикл поиска (статья 13, процесс конвейера), который повторно ищет использование терминов, фактически включение в документ, а не слепой поиск ближайшего корпуса токена. Исправленные ключевые слова добираются терминами из экспертного файла concept_keywords_df , которые также можно было бы использовать для специалистов в данной области. Что касается позиционного кодирования, то в дополнение включены два конкретных метода: синусоидальный и обученный, поэтому поиск соответствует им, даже если в вопросе они не упоминались.

Статья 6 (анализ вопросов) отвечает на оба уровня в полном блоке parse_question . Результатом является типизированный Pydantic-объект ParsedQuestion последовательно intentuser, извлеченные keywords , подзаголовок RetrivalQuery , который обрабатывает поиск ( main_query , rewrites , anchor_keywords , section_hint , layout_hint ), и structural_hints для размещения страниц/листов/слайдов, если они оказывается в вопросе. Определение вопросов также определяет, какой объем информации следует сохранить вокруг якоря: весь раздел, если он соответствует ему, или строки окна для точного факта, чтобы найти информацию, а не только, где искать. Статья 7А (поиск как фильтрация) подробно описывает эту двухуровневую модель якоря/контекста. Раздел 1.2 статьи 6 (анализ вопросов) описывает шаблон двухпроизводных кратких изложений: один и тот же ParsedQuestionвыдает одно краткое изложение для поиска и GenerationBrief для генерации, каждый из которых содержит только те поля, причем каждая сторона может объединить его потребитель.

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

Главный вопрос, вызывающий много шума, — это тот самый самый вопрос, который бы задал расстроенный пользователь:

Один звонок уже исправил опечатки: слова «optoins» и «posiitional» сохраняются как четкие, содержательные ключевые слова, без дополнительные проверки орфографии. Теперь дополните их словарь эксперта — таблица concept_keywords_df, которая сопоставляет каждую тему с терминами, которые также использовались практикующими специалистами:

 { "original_question": "Каковы варианты позиционного кодирования?", "keywords": ["позиционное кодирование"], "expanded_keywords": ["позиционное кодирование", "синусоидальное", "обученное"] }

За один проход произошло две вещи. Ключевые слова вернулись исправленными: posiitional и optoins были опечатками, и вызов parse_question исправил их, одновременно извлеченную именную фразу и отбрасывая вводные слова, такие как опции. Если ключевое слово по-прежнему отсутствовало в документе, цикл обратной связи завершения (статья 13, рабочий процесс конвейера) управлял его, а не слепо нажимал на ближайший токен корпуса.

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

Подробный код для разбора вопросов можно найти в трех статьях, посвященных разработке этого блока:

• Статья 6А (тезис): проанализируйте вопрос перед поиском — это недостающий шаг в большинстве алгоритмов RAG.
• Статья 6B (извлечение): пять полей, которые анализируются из любых запросов (ключевые слова, область охвата, форма, декомпозиция, уточнение).
• Статья 6C (диспетчеризация): определяет алгоритм обработки аспектов (стратегия обработки фрагментов, модели уровня, фрагменты, журнал аудита).

2.3 Извлечение данных: структурированные таблицы

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

Входные данные: Краткое описание RetrivalQuery (полученное в результате анализа вопросов), а также line_df и toc_df (полученные в результате анализа документа). Выходные данные: RetrivalResult : сохраненные страницы и filtered_line_df , данные для формирования раздела или строки окна.

Как это работает, в два этапа:

• Anchor : количество совпадений по ключевым словам подсчитывается для каждого раздела оглавления, затем последовательно LLM TOC анализирует структуру и выбирает раздел, который отвечает на вопрос.
• Контекст : размер окна соответствует якорю, исходя из вопросов детализации (весь раздел для списка, окно в виде строк для конкретных фактов).
• filtered_line_df : будут считываться только строки, строка из которых будет сохраняться page_num и line_numдля цитирования.

В 1 (минимальный RAG) использовался один метод поиска — сопоставление ключевых слов с page_df — и сохранялись три страницы с наиболее вероятными совпадениями статьи. В статье 7 (поиск) поиск переосмысливается как фильтр для избранного реляционного набора, созданного в разделе 2.1: сужение области поиска кандидатов с помощью структурированных таблиц перед оценкой ключевых слов. Метод ключевых слов по-прежнему используется, но toc_df дает второй сигнал. Естественный способ его использования — нерассмотрение подстрок в заголовках. Автор документа уже сгруппировал строки в разделы и написал заголовок для каждого. Небольшой вызов LLM может прочитать все оглавление, определить, какой раздел отвечает за вопрос, и вернуть свои варианты с однострочным обоснованием.

Поиск работает в двух этапах (статья 7А, поиск как фильтрация). Сначала он обнаружил якорь : количество совпадений ключевых слов, подсчитанное для каждого раздела оглавления, сообщает маршрутизатору, какие разделы содержат термины вопроса; reason_on_toc читает оглавление плюс эти подсчеты и выбирает раздел. Затем он определяет размер контекста вокруг этого якоря, после детализации, который включает в себя вопрос (раздел 2.2): весь раздел для вопросов типа списка или раздела, или строковое окно вокруг совпадения для точного факта. Разделение естественно является единым контекстом; page_df — это грубая поверхность неровности, line_dfатомарные линии, из которых вырезается окно.

Здесь, чтобы руководствоваться принципами инкрементальности, описанными в статье 1 (минимальный RAG), в этой статье для получения двух детекторов и объединяются их страницы; производственный гибрид вместо этого производит их по разделам (статья 7 (извлечение), арбитр, работающий по принципу «раздел в первую очередь», описанный выше). Сначала запускается метод ключевых слов (дешевый, без LLM, детерминированный). Затем запускается маршрутизатор TOC с LLM на том же toc_df . Объединение их страниц генерируется.

В статье 7B (обнаружение якоря) подробно описан порядок LLM TOC (запрос, вывод Pydantic, почему он преувеличил рассмотрение подстрок в отдельных документах). Статья 7C (арбитр LLM) завершает картину, ранжируя каждую страницу-кандидат от каждого детектора по одному вызову. Мы используем здесь автономный reason_on_toc, потому что он сам по себе достаточно эффективен: переход от парламентской подстрок к парламентской подстрок — это наиболее эффективные результаты изменения, которые могут привести к использованию команды, используемой процедуры, описанной в статье 1 (минимальный RAG), в процессе определения.

В 7 (поиск информации) представлен унифицированный диспетчер retrieve_context(question, line_df, *, метод, top_k, ...) → RetrivalResult , который направляет запросы к ключевым словам/встраиваниям/оглавлению/единичным запросам по одной сигнатуре и восстановлению типизированной статьи <код>Получение результатакод>вместо двух кортежей. Здесь мы использовали необработанные retrive_pages и reason_on_toc , чтобы эта статья разработала поверхность статьи 1 (минимальный RAG); в рабочем коде возникает retrive_context или общий вспомогательный метод dispatch_page_retrival .

Полезная проверка перед темой, как доверять этой таблице. Первый столбец с совпадающими строками сканирует быстро, по одной строке за раз. Это работает для ключевых слов, состоящих из одного слова. Ключевое слово, состоящее из нескольких слов, например, «позиционное кодирование», может быть разбито при переносе строки в PDF-файле, при этом «позиционное» находится в конце одной строки, а «кодирование» — в следующем начале. каждая отдельная строка не содержит ни одной из этих фраз. Построчное сканирование ничего не даст результата, даже если ключевое слово находится прямо на странице. src=»https://contributor.insightmediagroup.io/wp-content/uploads/2026/07/image-54-1024×435.png» alt=»» class=»wp-image-672193″/>

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

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

Маршрутизатор TOC LLM заполняет другой пробел, указанный выше. То же самое toc_df , что и при разборе, но LLM считывает его корпус и выводит, какой раздел отвечает на вопрос, возвращая идентификаторы выбранных разделов плюс однострочное обоснование. Сама функция короткая (форматировать каждый символ TOC, вставить его в подсказку с вариантами, выполнить синтаксический анализ введенного SectionSelection ); в статье 7B (обнаружение якоря) она показала полностью.

Проведите проверку по шумному вопросу, сопоставив его с 22 статьями из оглавления работы:

Один вызов LLM, всё оглавление внутри запроса, типизированный список section_idsпредложение обоснования. используемый в этой статье механизм парламентия подстрок обнаружил ошибку позиционного кодирования 3.5 по этому конкретному вопросу, поскольку кодировка находится в заголовке. Он бы пропустил все вопросы, сформулированные иначе, чем автором. «Что произойдет, если мы выйдем раньше?» против контракта, раздел которого называется «Завершение»: подстрока ноль, LLM один. Стоимость — небольшой вызов LLM (несколько тысяч токенов для кодового оглавления, несколько сотен миллисекунд), и он кэшируется навсегда для индивидуальных входных данных.

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

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

• Статья 7А (поиск как фильтрация): ментальная модель, поиск — это фильтрация, а не поиск.
• Статья 7B (обнаружение якоря): физические детекторы (ключевые слова, эмбеддинги, сигналы TOC), которые находят якорь.
• Статья 7C (арбитр LLM): в конце каждого решения LLM оценивается каждая страница кандидата, при этом обосновании этого основания.

2.4 Поколение: ответ в печатном виде

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

Входные данные: GenerationBrief (форма вопроса и ответа, полученная в результате анализа вопросов), filtered_line_df (полученный в результате поиска) и схема ответа. Выходные данные: типизированный AnswerWithEvidence или ListAnswer , если вопрос требует списка.

Что получается в итоге:

• ответ : соответствует вопросу, одна строка для одного факта, одна запись для каждого элемента в списке.
• evidence_spans: строка строки плюс дословная цитата для каждого элемента, проверяемая по filtered_line_df .
• Сигналы качества: confidence , предостережения и флаг context_structured, который устанавливает LLM, когда полученный текст больше не читается по порядку.

В статье 1 (минимальный RAG) AnswerWithEvidence возвращает один ответ: str , один непрерывный фрагмент данных, несколько цитат. Доработка для вопроса с одним ответом («Такой набор данных был использован?»). При рассмотрении вопроса задаются <сильные>вариантысильные> , во множественном числе. Базовая схема позволяет перечислять их внутри строк, но в вызывающей части нет удобного процесса перебрать элементы или присвоить каждый вариант одной цитаты.

В статье 8 приведена схема в соответствии с формой ожидаемого ответа. Когда парсер вопросов помечает expected_answer_shape = "listing" (статья 12 (листинг) подробно описывает это), генерационный блок возвращает ListAnswer с одной записью для каждого элемента, метод, из которого содержит свой фрагмент подтверждающих данных и свою дословную цитату.

Главное — это форма: один AnswerItem на каждый вариант ответа (его text , диапазон начальной/конечной строки и дословная quote ), заключенный в ListAnswer , который также содержит флаги качества ответа ( answer_found , complete_answer_found , context_structured , confidence , предостережения). Статья 8 (генерация) полностью разрабатывает схему.

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

 { "items": [ { "text": "Синусоидальные позиционные кодировки (синусоидальные и косинусоидальные функции разных частот).", "start_page_num": 6, "start_line_num": 33, "end_page_num": 6, "end_line_num": 37, "quote": "мы используем синусоидальные и косинусоидальные функции разных частот" }, { "text": "Изученные позиционные embeddings.", "start_page_num": 6, "start_line_num": 39, "end_page_num": 6, "end_line_num": 41, "quote": "мы также экспериментировали с использованием изученных позиционных вложений" } ], "answer_found": true, "complete_answer_found": true, "context_completeness": 1.0, "context_structured": true, «уверенность»: 0,98, «предостережения»: [] }

Четыре индикатора отображают профиль доверия к ответу. complete_answer_found означает, что ответ касается всех вариантов ответа, упомянутых в документе, или только их подмножества. context_completeness показывает, что действительно хорошо получены строки, соответствующие вопросу, независимо от того, это сам ответ. <код>контекстная структуракод>переключается на false, когда LLM не может соответствовать порядку чтения, что является каноническим сигналом ошибки OCR. Маршрут ниже по потоку считывает их: уверенность + полнота + высокая структурированность = отправка ответа; Разблокировать полнота или неструктурированный контекст = попытка получения или возврат к более глубокому анализу (путь, разработанный повторный в 10).

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

 { "clean context": { "answer_found": true, "complete_answer_found": true, "context_completeness": 1.0, "context_structured": true, "confidence": 1.0, "n_items": 2, "caveats": [] }, "перемешанный контекст (те же строки, случайный порядок)": { "answer_found": true, "complete_answer_found": true, "context_completeness": 1.0, "context_structured": true, "confidence": 0,95, "n_items": 2, «предостережения»: [] } }

В процессе производства среды измененный контекст получается из другого источника, мощность df.sample . Это могут быть PDF-файлы с двухколоночной разметкой, которые анализатор читает по столбцам, а не по строкам, отсканированные документы, распознанные с помощью OCR-моделей, которые потеряли разметку, а также экспортированные из документов Word, в которых были таблицы повреждены из-за скрытых привязок. Конвейер не может это исправить самостоятельно, но схема сообщения сообщает о вызывающей стороне, что что-то пошло не так, и в этом случае запускается код данного участка.

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

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

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

Теперь эти четыре кирпича общаются посредством подписанных контрактов:

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

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

Это помогает понять, где находится этот проход на более длинном пути. Те же четыре кирпича остались сохранившимися; меняется с одной ступени на другую, то есть, где находится управление. Эта статья — второй шаг: pdf_qa, один более насыщенный проход, который уже выдает поля обратной связи (уверенность в поиске, отсутствующие ключевые слова), но пока ничего с ними не делает. Статья 13 превращает этот проход в pdf_qa_flow , составной элемент Тома 1, который обрабатывает шаблоны вопросов и повторно запускает проход в ограниченном цикле, воздействуя именно на эти поля. pdf_chat Тома 2 добавили многоцелевую запись перед собой. Только последняя ступень обучения циклу управления самой LLM.

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

Эта часть обновляет четыре блока (из статей 5-8) по одному контракту за раз, используя документ «Внимание — это все, что вам нужно». Вторая часть решает их с начала до конца и запускает собранный конвейер на нескольких документах. Шаблон responses.parse(text_format=Schema)на границах разбора и генерации вопросов используются структурированные выходные данные OpenAI (август 2024 г.). Наиболее близкое к этому готовое к использованию описание конвейера — это Contextual Retrival от Anthropic (сентябрь 2024 г.). Путь обновления агента на поверхности тех же четырех блоков — это следующая работа; отслеживание возникновения каждого блока обеспечивает возможность аудита выбора агента.

Ранее в сериях:

• Документальная разведка: введение в серии. Что представляет собой серия, кирпичик за кирпичиком, и в таком порядке.

Что работает, а что ломается

• Базовая модель Enterprise РЭГ: из PDF-файла до выделенного ответа. Четырехэтапный конвейер от начала до конца: PDF-файл на входе, выделенный ответ на выходе.
• Вставки — это не магия: выгодные варианты в поиске RAG. Где сходство эмдингов приводит (пользование синонимами, опечатки, перефразирование), где оно выгодно дает сбой (неизвестные термины, отрицательное равнозначие, релевантность термина и ответа) и как его все используют. затраты. Что включает кросс-кодировщик по сравнению со встраиванием на основе двух кодировщиков (измеренные показатели) и когда оправдана задержка.

Анализ документов

• Помимо функции extract_text: два слоя PDF-файла, определяющие качество RAG. Анализ первой половины блока: характер документа, сигналы и резюме.
• Прекратите вернуться в простой текст из PDF-файлов: RAG нуждается в реляционных таблицах. Анализ второй половины блока: реляционные таблицы, которые читают каждый последующий блок.
  • Если PyMuPDF не видит таблицу: анализ PDF-файлов для RAG с помощью Azure Layout. Те же таблицы из Azure Layout: ячейки ячеек, OCR, ролики абзацев.
  • Анализ PDF-файлов для RAG локально с помощью Docling: расширенные таблицы, без загрузки в облако. Те же таблицы, вычисленные локально с помощью Docling: ячейки TableFormer, не покидает машину.
  • Программное обеспечение для обработки изображений также является парсером PDF-файлов: оно ничего не считывает диаграммы и схемы для анализа данных. Обработчик изображений: изображения преобразуются в текст, доступный для поиска.
  • Анализ отсканированных PDF-файлов для RAG с помощью EasyOCR: бесплатное распознавание текста Позволяет получить слова, а не документ.
  • Как сделать так, чтобы изображения в PDF-файлах можно было искать по RAG (Research, Goodreads, Acquisition, Reading, Get… Get
  • Восстановление оглавления, которое не было включено в PDF-файл, чтобы RAG мог обработать его по разделам. Перестройка toc_df, если PDF-файл печатает оглавление, но не включает структуру документа.

разбор вопросов

• Вопросы RAG также необходимы в синтаксическом анализе: необходимо преобразовать форму пользователя в краткое описание для поиска и формирования. Основная идея синтаксического анализа вопросов: почему строка пользователя требуется в том же анализе, что и документ, и как она разделяет краткое описание для поиска и краткое описание для генерации. Пять столбцов семейства, которые анализатор считывает непосредственно из запроса пользователя вместе с кодом, сопровождающим каждого из них.
• Обработка проанализированного вопроса RAG: стратегия обработки фрагментов, уровень модели, активация, аудит. Решения, принятые парсером на основе пользовательской строки с использованием профиля документа: обработка, активация, полная схема, журнал аудита (pipeline_trace.json) и обходы корпуса брокера. Одно целенаправленное уточнение, когда вопрос слишком расплывчатый, и значение по умолчанию, проявленное на основе объяснения.

Извлечение

• Поиск — это фильтрация, а не поиск: ментальная модель для частного RAG. Поиск переосмыслен как фильтрация по line_df и toc_df: якоря малы, контекст велик.
• Обнаружение якорей для RAG: внешние детекторы, затем один вызов LLM в конце. Параллельные детекторы якорей: ключевое слово всегда, встраивание параллельно, один вызов LLM в конце.
• Предоставление возможности основного права выбрать правильную страницу RAG: шаблон арбитра в конце поиска. Арбитр из числа магистров прав: кандидаты ранжируются с указанием причины, одна из которых выводится в формате JSON.
  • Структура для проектирования контекста: четыре типизированных элемента, объединение в основе каждого ответа RAG. Проектирование контекста с заданной структурой: четыре типизированных элемента (фиксированная системная подсказка, извлеченные строки, блок контекста документа, оболочка PromptContext), которые заменяют один вызов RAG LLM для одного документа.

Поколение

• Результат формирования RAG представляет собой типизированный контракт: цитаты, типизированные значения и самопроверки (ссылка будет представлена ​​позже). Схема объяснения как контракт: типизированные значения, элементы с рядом доказательств, поля самооценки и полноты сигналов, которые конвейер высчитывает. Диспетчер: фиксированное базовое приглашение плюс правила, необходимые для каждого вопроса, схема, выбранная из реестра и полная трассировка, сохраняемая для каждого вызова.
• Проверка ответа RAG до того, как его увидит пользователь: фрагменты кода, кавычки и цикл обратной связи (ссылка будет позже). Валидатор после генерации (фрагменты кода, дословные кавычки, форматы), отсутствие ответа как первого и циклов обратной связи, замыкающих конвейеров.

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

• Антропный контекстный поиск (инженерная статья, сентябрь 2024 г.). Наиболее близко к описанному в данной статье описанию «минимального, но условного для использования в производственной среде» излучения; оно основано на гибридном поиске + переранжировании и выполнении обновления, наблюдающее содержание текста, описанное в этой статье.
• OpenAI, структурированные данные выходного дня. Шаблон responses.parse(text_format=Schema)Эффективность на границе между анализом и генерацией задач.
• Васвани и др., Внимание — это все, что вам нужно, NeurIPS 2017 (arXiv:1706.03762). Статья, на которой работает каждый кирпичик. Лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv.
• NIST, NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, февраль 2024 г. (DOI 10.6028/NIST.CSWP.29). Документ, подтверждающий соответствие, на котором проводится испытание собранного конвейера во второй части. Работа правительства США, общественное положение в США, см. заявление NIST об авторских правах.
• Льюис и др., Генерация расширения поиска задач обработки естественного языка, требующих интенсивного использования знаний, NeurIPS 2020 (arXiv:2005.11401). Сама статья RAG представляет собой тест для сборного конвейера во второй части. Лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv.
• Всемирный банк, Обзор товарных рынков, выпуск за апрель 2024 года. Стресс-тест вырожденного ТОС (пустые закладки) во второй части. CC BY 3.0 IGO, как указано на странице страницы OKR за апрель 2024 года.

Исполняемые фрагменты кодов вызовов сервисов OpenAI, регулируемые условия использования OpenAI.

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

• Яо и др., ReAct: Синергизация рассуждений и действий в языковых моделях, ICLR 2023 (arXiv:2210.03629). Основополагающая статья агентского РАГ. Контекст – универсальный выбор инструментов во время выполнения. Дальнейшим занятием является развитие этого направления, где четыре модернизированных блока становятся проверенным набором инструментов агента. Можно обновить с использованием длинного контекста вместо RAG: пройти синтаксический анализ, пройти поиск, загрузку всего документа. Эмпирические данные о том, где это работает, а где нет.

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

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