Извлечение информации — это фильтрация, а не поиск: ментальная модель для частного RAG.

Enterprise Document Intelligence [Том 1 #7A] – Уточните строки поиска. Фильтруйте line_df и toc_df. Затем короткие привязки, расширяйте контекст.

Делиться

статья — первый этап поиска в серии статей Enterprise Document Intelligence, посвященной построению корпоративной системы RAG из четырех компонентов: синтаксический анализ, анализ задач, поиск и генерация. Поиск — третий компонент, и это первая из трёх его частей, ментальная модель: поиск — это фильтрация, а не поиск; Отфильтруйте line_df и toc_df , выберите небольшое количество, расширите контекст.

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

На работе кто-то хочет узнать, сколько дней отпуска ему положено в этом году. Этот PDF-файл создается с соблюдением требований отдела кадров. Нажимает Ctrl+F. Вводит слово «отпуск». Прокручивается пятнадцать результатов поиска, некоторые в заголовках, некоторые в оглавлении. Он переходит к нужному абзацу, читает правило и получает ответ через 60 секунд.

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

Иногда Ctrl+F ничего не нахожу: в документе это называется «PTO», а не «отпуск». Или текст находится на отсканированной странице, которую Ctrl+F не видит. Эксперт пробует синоним, затем третий. И всё равно ни одного совпадения.

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

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

• Эксперт вводит по одному ключевому слову за раз . Система может обнаружить одновременное появление нескольких символов на одной странице или в одном разделе за один проход.
• Эксперт ничего не видит, когда слова заблокированы в отсканированных изображениях . Блок обработки текста запускается оптическое распознавание символов (OCR)при наличии данных, поэтому текст, связанный с изображениями, становится доступным для поиска, как и любая другая строка.
• Эксперт вручную сканирует оглавление . Система программно объединяет оглавление и контент : выбирает нужный раздел на карте, а затем ограничивает поиск по ключевым словам внутри текста этого раздела.

После того как парсер создаст чистый DataFrame, поиск данных сводится к к задачам фильтрации структурированных таблиц : фильтрация line_df (текст) и toc_df (карта). В этой статье строится эта концептуальная модель. Следующие две статьи касаются механики процесса.

В данной статье мы работаем с одним документом «Внимание — это все, что вам нужно» (Васвани и др., 2017, 15 страниц; лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv). Он содержит чистое собственное оглавление в поэтапном PDF-файле (22 записи, 3 уровня вложенности), и его содержание хорошо знакомо любому инженеру, работающему с RAG: кодировщик, декодер, внимание, запросы, ключи, значения. Это позволяет сосредоточиться на методах поиска, а не на разборе предметно-ориентированного объекта. В данной статье также указано, что документ содержит собственное оглавление; восстановление его исходного текста оставлено для дальнейшей работы.

1. Извлечение данных путем фильтрации по структурированным таблицам.

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

После того, как в результате парсинга получены чистые DataFrames, поиск перестаёт быть резервным определением в классическом смысле. Это задача фильтрации структурированных таблиц . Каждый из обсуждаемых нами методов представляет собой различный способ фильтрации строк line_df (текстовый документ) и toc_df (карта документа). Мысленная модель ближе к SQL-запросу, чем поиск в Google.

Это изменение обеспечивает доступ к методам, которые не обеспечиваются при поиске в режиме свободного текста:

• Вы можно фильтровать по столбцам: только строки в разделе X, только строки, соответствующие обычному выражению, только фрагменты, которые векторное представление близко к запросу, только заголовки, слова, которые пересекаются с ключевыми словами-вопросами. line_df , затем найдите раздел, к которому относится эта строка, в toc_df , а затем присвойте оценку весу в зависимости от того, является ли заголовок раздела также релевантным.
• Легковесную фильтрацию LLM можно применять к простым таблицам (например, toc_df с 50 записями), затем как к большим (например, line_df с 12 000 строками, слишком много токенов для одного вызова) это невозможно.

Блок анализа создает структурированные DataFrame: line_df содержит текстовые критерии с номерами строк, координатами страниц и идентификаторами разделов; toc_df содержит оглавление в виде навигационной иерархии; page_df и image_df для преобразования данных модели. К моменту выполнения операции извлечение документа уже не является свободным текстом.

Часть, содержащая вопрос, а также предварительная обработка. Блок разбора результата преобразует текст пользователя в краткое описание RetrivalQuery (производственное представление ParsedQuestion), которые содержат ключевые слова, фильтры, которые усиливают структурные подсказки и приводят к контексту ответа, должен привлекать механизм привлечения. Механизм извлечения считывает один типизированный объект с каждой стороны: документ в виде таблицы слева, RetrivalQuery справа.

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

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

toc_df — разреженная таблица:одна строка в каждом разделе в оглавлении, обычно от 20 до 100 строк для большинства документов, иногда всего 10. Столбцы включают заголовок раздела, уровень (1, 2, 3…), диапазон страниц, родительский раздел и постоянный section_id . Разреженная, небольшая, крупнозернистая: каждая строка соответствует большому блоку документа, поэтому фильтрация по строкам может быть затратной. Эта карта, показывающая, где может находиться ответ : она указывает, в каком разделе искать, а не то, что в самом разделе написано.

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

Хороший алгоритм поиска использует оба варианта. Он использует toc_df для поиска соответствующего раздела, а затем line_df для поиска точных строк в этом разделе. Две таблицы взаимодействуют между собой объединением section_id .

1.2 Почему ни один метод не является предпочтительным

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

1. «Какой номер полиса?» Иголка в стоге сена. Якорь — это конкретный тег, вероятно, в заголовке. Контекст — страница 1, возможно, 5 строк.
2. «Какова годовая премия?» Поиск по ключевым словам. Ключевым моментом является пункт договора, в котором упоминаются «премии», «основной премии» или «коэффициент покрытия» с указанием суммы. Контекстом является раздел, включающий этот пункт, возможно, от 50 до 200 строк.
3. «Каковы все честно продают?» — вопрос, заданный при размещении объявления. Ключевые моменты — это несколько фрагментов текста, разбросанных по всему документу. Контекст — весь раздел «Обязательства», если он есть, плюс любой другой раздел, независимо. Возможно, от 500 до 2000 строк.
4. «Кратко предложите из содержания раздела о гарантиях». Целенаправленное обобщение. В качестве отправной используется заголовок раздела о гарантиях в toc_df . Контекст – эффективный текст раздела о гарантиях. Возможно, от 200 до 1500 строк.

Конвейер обработки данных, использующий косинусное сходство с параметром top-k=5 (возвращающий 5 фрагментов по оценке) для всех четырех случаев, будет неверным, как минимум, в трех из них. Правильный ответ зависит от того, какую структуру вы фильтруете, по какому столбцу вы фильтруете, по какому якорю вы обнаруживаете и какой контекст вы сообщаете дальше. Остальная часть статьи посвящена разработке этой сетки.

Первый вопрос в списке, «Каков номер полиса?», — это именно то, что в последнее время является эталоном «Иголка в стоге сена» (Камрадт, 2023, github.com/gkamradt/LLMTest_NeedleInAHaystack). Вставьте дословное предложение в подробном контексте, задайте вопрос о нем и посмотрите, как модель его найдет. Модели Frontier показывают почти идеальные результаты. Бенчмарк реален, результат реален.

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

Данный эталонный тест подтверждает корректность одного класса вопросов, а не трех других. Это результаты исследования для отдельной задачи поиска информации, а не решение пропускать поиск информации в производственной среде. Мы выбираем показательный вопрос: «Как сохраняется внимание?». Ответ находится в формульном блоке в разделе 3.2. Затем мы применяем алгоритм косинуса top-k к векторным представлениям страниц. п>

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

Процесс определения соответствия двух этапов. На первом этапе Определяется местонахождение результата: результаты обнаружения ключевых слов и эмбеддинги на основе line_df и toc_df , в конечном итоге алгоритм LLM ранжирует приведенные значения, и в результате получается небольшой набор якорей (раздела, страницы). На втором этапе Определяется размер контекста вокруг каждого якоря: абзац, раздел или окно из N строк, в зависимости от намерения вопроса и поиска области области (уже проанализированных на боковой стороне вопроса). Статья 7B (обнаружение якорей) разрабатывает детекторы для первых этапов, а статья 7C (арбитр LLM) разрабатывает арбитра, который их ранжирует; В разделе 2.4 ниже описан второй этап.

Сотрудник отдела комплаенса, ищущий «ответственность» с помощью Ctrl+F, находит всего один текст, соответствующий запросу. Он никогда не читает только этот текст. Он читает окружающий абзац, часто весь главный раздел. Якорь — одна строка; context — учитывает строки.

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

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

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

• Строка? Найдите слово, встречающееся в этой строке.
• Абзац? Найдите слово, которое можно встретить в любом месте этого абзаца.
• Заголовок раздела? Найдите это слово, если оно встречается в заголовке раздела.
• Основной текст раздела? Найдите это слово, если оно встречается где-либо в тексте раздела.

Одно и то же слово в разных контекстах дает совершенно разные результаты. В длинном документе контекст на уровне заголовка гораздо более избирателен и точен, чем контекст основного текста.

2.2 Контекст: что следует выполнить в связи с сопоставлениями

После того, как была найдена точка, что следует далее по течению для генерации электричество?

• Только совпадающая линия? Редко, обычно слишком узкая.
• Окружающий абзац?
• Весь раздел, к которому относится соответствие?
• Окно из N строк до и после?

Одного совпадения в line_df недостаточно для полезного получения ответа. Это расширение приводит к возникновению совпадений в контексте.

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

Конкретный пример. Пользователь спрашивает: «Какие исключения предусмотрены для возмещения затрат от наводнений?». Ключевое слово «исключение» находится в toc_df на уровне заголовка, в записи «Раздел 5: Конкретные исключения». Этот единственный заголовок не является ответом; это карта . Затем из контекста включения берется весь раздел 5 из line_df , поскольку эффективное исключение операций в тексте.

Якорь был найден в руководстве toc_dfиз 50 строк. Извлечение контекста связано с line_df для получения фактической оценки. Две структуры взаимодействуют, и результат является объединенным продуктом. Каноническая реализация, detect_then_extract , разработанная в 7B (обнаружение якоря) главы с другими комбинациями.

2.3 Типы вопросов и варианты рассмотрения.

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

Извлечение полей:«Какова дата приложения силы?» Закрепите поле в строке, где рядом с «датой подтверждения силы» или «датой начала» находится дата шаблона. Контекст страницы достаточен для подтверждения правильности полей.

Поиск раздела: «Какие исключения?» Привяжите текст к заголовку раздела «Исключения». Контекст – это основной текст раздела, от заголовка к следующему.

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

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

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

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

2.4 От игры к контексту: три расширения стратегии

Метод получения возвращает следующие значения: идентификаторы строк, идентификаторы разделов, идентификаторы фрагментов, получившие балл. Практически никогда они не передаются напрямую в поколение. Сначала их разворачивают.

Почему? Потому что об отдельном якоре, изолированном от контекста, сложно рассуждать. Возьмем, к примеру, этот якорь:

«125 000 евро в год».

Контекста магистральных прав не понимает, что означает размер суммы в 125 000 евро. Вот пояснение в одном аннотации:

«Ежегодная страховая премия формируется следующим образом. Базовая дополнительная премия составляет 125 000 евро в год. Она может быть скорректирована в соответствии с разделом 3.4».

В большинстве случаев удачно три стратегии расширения.

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

Расширение раздела: Для вопросов, требующих перечисления или обобщения, разверните раздел полностью. Используйте toc_df для определения границ.

Расширение окна:Для документов без четких границ абзацев или разделов (стенограммы, длинные тексты) расширяйте окно до N строк до и после абзаца.

Выбор зависит от вопроса (цель, ожидаемая форма ответа) и документа (имеет ли он абзацную структуру? разделы?). Диспетчер выбирает, а команда применяет выбранную погрешность равномерно. Используя один из этих вариантов, студенты-магистры смогут правильно ответить и точно процитировать информацию. (line_df[«line_num»] == line_num) & (line_df[«page_num»] == page_num), «section_id», .iloc[0] sec = toc_df[toc_df[«section_id»] == якорь_section_id].iloc[0] in_section = (line_df[«page_num»] >= sec[«start_page»]) & (line_df[«page_num»] <= sec["end_page"]) return "n".join(line_df[in_section]["text"]) defexpand_window(line_num, page_num, line_df, n=5): page_lines = line_df[line_df["page_num"] == page_num].reset_index(drop=True) i = page_lines.index[page_lines["line_num"] == line_num][0] return "n".join(page_lines.iloc[max(0, i - n) : i + n + 1]["text"])

Запустить оба кода в первой строке текста на странице 4 (там, где находится формула Attention(Q,K,V) ), и вы увидите разницу между двумя областями:

2.5. Если нет оглавления: где заканчивается раздел?

Расширение раздела становится простым, когда toc_df задает диапазон страниц. Начало ответа — это якорь, конец — начальная страница этой записи в оглавлении, никаких размышлений не требуется. Когда в документе нет ни собственного, ни синтезированного оглавления, эта простая граница исчезает. Конец раздела должен определяться самостоятельно содержимым, и это одна из сложных проблем в документах искусственного интеллекта. class=»wp-block-list-item»> Обнаружение заголовков во время синтаксического анализа:Пройдите вперед от якоря, остановитесь на следующей строке, которая выглядит как заголовок (более крупный шрифт, жирный шрифт, обычное выражение для «Раздел X» или «Статья X»). Просто, быстро, но ненадежно в документах, где отсутствуют визуальные обозначения заголовков.

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

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

В более широком понимании: разработка и проектирование корпоративных систем — это разные задачи.Обнаружение концов разделов имеет обширную исследовательскую базу. Большинству частной команды не нужно решать эту проблему; Им нужна система, которая работает с их реальными документами и их реальными инструментами. В этом случае, прежде чем приступить к TextTiling или пользовательскому сегментатору, задайте вопрос: выполните один дополнительный вызов LLM по той же задаче? Сегодняшний ответ обычно положительный. Вывод крупных моделей уже не тот, что был два года назад: цены снизились на порядок, задержка приемлема, и корпоративный конвейер может позволить себе один дополнительный вызов по каждому вопросу в такой задаче, не выходя за рамки бюджета. Компромисс очевиден: тратьте деньги на вывод, а не на пользовательский сегмент сегментации, который вы будете использовать вечно.

Это не универсальное утверждение типа «используйте LLM для всего». Стоимость по-прежнему важности, задержка по-прежнему важности, и небольшое определенное правило превосходит решение на основе LLM, если правило четко соответствует конкретному случаю. Но подход по умолчанию изменился. НИОКР изучает космические технологии и продвигает их вперед; корпоративная инженерия выбирает самый простой инструмент, учитывающий требования, и выпускает его. При поиске этой информации великий соблазн спутать два случая, потому что эта статья выглядит как возможность. Правильным решением обычно является то, что не требует новых исследований и разработок.

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

Извлечение данных — это не поиск, а фильтрация по различным структурированным таблицам ( line_df и toc_df), которые уже были получены в результате анализа. Каждый метод извлечения данных представляет собой разный способ выбора строк из этих двух таблиц.

Якорь и контекст — это разные уровни детализации. Якорь (строка, заголовок): именно его вы оцениваете. Контекст (абзац, раздел): именно его вы передаете для генерации. Эти два уровня детализации являются независимыми проектными решениями; их объединение — самая распространенная ошибка в конвейерной обработке данных.

Два этапа. Этап 1: поиск источника ответа. Этап 2: определение контекста вокруг каждого опорного элемента на основе понятия и области области вопроса (уже проанализированных на боковых вопросах).

После создания ментальной модели следующий алгоритм вопроса — как процедура, якоря: какие детекторы работают с line_df и <код>toc_dfкод>, в каком порядке и когда будет LLM. В статье 7B (обнаружение якорей) описывается этот трехэтапный конвейер (ключевое слово + встраивание параллельно, агрегирование в единицу структуры, один арбитр LLM в конце), с использованием в качестве примера исполняемого кода из статей Transformer. Статья 7C (арбитр LLM) завершает цикл вызова арбитра, решения дерева, выбирает методы для каждого вопроса, путь «не найдено» и унифицированного извлечения контракта JSON, управленческого генерирования.

Эта статья является частью серии материалов по корпоративной аналитике документов. Минимальный конвейер RAG-процесса процесса извлечения данных от начала до конца для реального PDF-файла.

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

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

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

• Сарти и др., RAPTOR: Рекурсивная абстрактная обработка для поиска информации в древовидной фазе, ICLR 2024 (arXiv:2401.18059). Ближайший опубликованный эквивалент концепции «оглавление как средство определения»; RAPTOR кластеризует собственное дерево, в данной статье используется оглавление, уже указанное в документе.
• Антропный, контекстуальный поиск (сентябрь 2024 г.). Согласованный гибридный поиск, основанный на разделении якоря и контекста, представленном в данной статье.

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

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

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

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