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

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

Делить

Эта статья является блоком поиска в серии статей «Enterprise Document Intelligence», которая строит корпоративную систему RAG из четырех блоков: синтаксический анализ, анализ вопросов, поиск и генерация. Это вторая из трёх частей блока. Предыдущая часть, статья 7А (поиск как фильтрация), задала ментальную модель; Этот же механизм строится: параллельные детекторы якорей, ключевое слово всегда, векторные представления параллельно и один вызов LLM в конце.

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

60~p class=»wp-block-paragraph»>Пользователь вводит запрос «Как распределяется внимание?» в статье о Трансформере. Шесть страниц-кандидатов соответствуют attention ». На правой странице упоминаются softmax , query , key и d_k вместе, и она находится в разделе, который в оглавлении называется «Маштабированное скалярное». произведение внимания». Два инструмента поиска — ключевое слово и встраивание — оба находят набор кандидатов. Ни один из них по отдельности не может определить, какая страница действительно отвечает за вопрос. На третьем этапе необходимо изучить всех кандидатов рядом, указав раздел, в котором они находятся, и выбрать правильный вариант, обоснование выбора которого будет понятно аудитору даже спустя несколько месяцев.

Представленный ниже трехэтапный конвейер на основе трех соединений:

• Ключевые слова обрабатываются постоянно. Обнаружение ключевых слов бесплатно. Нет ни одного сценария, в котором вам не понадобился бы этот сигнал. Он обрабатывает как line_df , так и toc_df с первых миллисекунд.
• Внедрение осуществляется параллельно и осуществляется параллельно. необязательными. Когда учитывается несоответствие словарного запаса или вопрос носит концептуальный характер, эмбеддинги выявляют то, что пропущено ключевое слово. При использовании предварительно вычисленных индексов время выполнения запроса составляет микросекунды. Пропустите их, если сигнал ключевого слова уже чист.
• Один заключительный этап LLM. Нет промежуточных этапов «анализа содержания» LLM. На третьем этапе арбитр видит содержание, совпадения по ключевым словам, совпадения по эмбеддингам и структурную привязку каждого кандидата в рамках одного запроса. Он неявно анализирует содержание как часть процесса ранжирования.

В этой статье детекторы детекторов для каждой таблицы (раздел 2 о toc_df , раздел 3 о line_df ), а затем — по обеим таблицам (раздел 4). Сам вызов арбитра, деревянных решений и выходной JSON находится в статье 7C (арбитр LLM и выходной JSON-файл для извлечения данных).

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

1. Конвейер нашел статью якорей

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

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

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

• Эксперт по правовым вопросам (LLM) проводит анализ содержания документа (TOC) неявно.При ответе на вопрос «Что произойдет, если мы выйдем из проекта досрочно?», если в оглавлении документа есть разделы «Прекращение действия» и «Штрафы» (но нет раздела «Выход»), эксперт LLM выбирает обоих партнеров на этапе ранжирования. Других этапов анализа TOC на более ранних стадиях процесса нет; Эта работа выполняется в рамках его сложных решений.
• LLM разрешает неочевидные совпадения в заголовках. Если вопрос касается «премий», но соответствующий раздел заглавлен «Краткое ключевое изложение договора», ни одно слово не будет соответствовать заголовку. LLM, совпадение ключевых слов в тексте и структурная связь с этим разделом, все равно его результат.

Остальная часть статьи посвящена методам обнаружения (раздел 2 посвящен toc_df , раздел 3 — line_df , раздел 4 — взаимодействие двух таблиц). В статье 7C (арбитр LLM) описан окончательный результат: единственный вызов, который преобразует агрегированные кандидаты в ранжированный ответ. class=»wp-block-paragraph»>Для проверки содержимого использовалось два детектора: совпадение по ключевым словам (всегда, бесплатно) и совпадение по эмбеддингам (опционально, параллельно). Оба алгоритма основаны исключительно на результатах оценки, на данном этапе LLM не используется. Когнитивная работа (выбор правильных разделов из вопросов типа «что случится раньше, если мы выйдем?», когда соответствующий раздел оглавлен «Завершение») происходит позже, при вызове арбитра. Арбитр видит содержание и совпадение по ключевым словам/эмбеддингам в рамках одного вызова LLM.

Ниже показано, как в последовательном показана отдельная функция reason_on_toc : она изолирует конкретное действие арбитра при анализе TOC. В производственной среде вы можете либо запустить ее отдельный вызов (дополнительные затраты LLM, полезно для отладки), либо включить ее в работу арбитра (всего один вызов LLM, постоянный вариант по умолчанию). class=»wp-block-paragraph»> Файл toc_df достаточно мало, чтобы передать его руководителю в LLM. Арбитр (разработанный в статье 7C, арбитр LLM) использует это преимущество: он читает все оглавления и выводит выводы о том, какие разделы обеспечиваются по заданному вопросу. Автономная функция reason_on_toc, приведенная ниже, изолирует ту же логику в виде отдельного вызова, что полезно, когда вы хотите проверить или отладить этап вывода выводов из оглавления самостоятельно.

Почему это важно. Магистр прав понимает семантику, но, что более важно, он понимает последствия. Вопрос «Что произойдет, если мы расторгнем договор досрочно?» не имеет общего с термином «Расторжение договора», но магистр права определяет, что расторжение договора предполагает именно это. Вопрос «Как страховщик поступает в случае наводнения?» не имеет общего с термином «Процедура рассмотрения претензий», но магистр права определяет, что обработка затрат — это процесс рассмотрения претензий. Вопрос «Есть ли плата за изменение страхового покрытия?» может соответствовать как «Изменению страхового покрытия», так и «Графике сборов», и магистр права выбирает обоих сторон, обосновывая свой выбор. Тонкий пример из практики: вопрос о «премиях» содержится в разделе «Краткое изложение договора». Ключевого слова нет, но магистр права, последние строки текста, в которых упоминаются суммы премий, относящиеся к этому разделу, все равно вы берете его.

Модель встраивания определения позволяет определить «досрочный выход ≈ завершение» путем сходства, но она не может определить «досрочный выход, заключающий штрафы». Это рассуждение, а не сходство.

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

 classsectionSelection(BaseModel):section_ids: list[str] рассуждение: str def Reason_on_toc(question: str, toc_df: pd.DataFrame) ->РазделSelection: """Передайте полное содержание в LLM, спросите, какие разделы актуальны, с обоснованием. В приглашении используются маркеры [id=N], поэтому LLM возвращает наш внутренний раздел_id, а не ведущий номер заголовка (например, "5.2"), который не будет соответствовать line_df. """ toc_text = "\n".join( f"[id={row.section_id}] {row.title} (level {row.level}, стр. {row.start_page}-{row.end_page})" for row в toc_df.itertuples() ) Prompt = ( "Учитывая этот вопрос и оглавление документа, " "определите, какие разделы, скорее всего, содержат ответ. " "Учитывайте последствия и связанные концепции, а не просто перекрытие ключевых слов.\n\n" "ВАЖНО: верните значение внутри скобок [id=...] -- просто целое число, " "например, \"9\", а не \"id=9\" и не \"5.2\".\n\n" f"Question: {question}\n\nОглавление:\n{toc_text}" ) return client.responses.parse( model=model_chat, input=prompt, text_format=SectionSelection, .output_parsed # A Вопрос читателя о статье. select = Reason_on_toc( "Как Transformer обрабатывает дальние зависимости между словами?", toc_df, ) print("Выбранные разделы:",select.section_ids) print("Reasoning:",selection.reasoning)

В статье о Transformer, LLM select разделы ['4', '11']для ответа на вопрос «Как Трансформатор обрабатывает дальние расстояния в зависимости от слов?». Его дословное обоснование: «Вопрос о том, как Трансформатор обрабатывает дальние зависимости между словами, лучше всего найти в разделах, посвященных механизму внимания (раздел 4) и обоснованию использования самовнимания (раздел 11). Механизм внимания является ключевым для управления дальними зависимостями, а раздел 11, вероятно, дает представление о его необходимости и эффективности». Метод, основанный на ключевом слове, вернулся в список разделов, не объяснив причину. LLM же, указывая причину прямо в тексте, предоставляет вам возможность аудита бесплатно.

2.2 Сопоставление ключевых слов в заголовке (детектор по умолчанию)

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

Когда этого достаточно: Когда лексика вопроса однозначна и напрямую соответствует лексике документа. «Что говорится в разделе о гарантиях?»: заголовок «Гарантия» соответствует. Арбитр видит одно однозначное совпадение и подтверждает его.

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

 def match_titles(toc_df: pd.DataFrame, ключевые слова: list[str]) -> pd.DataFrame: """Вернуть строки toc_df, заголовок которых содержит любое из ключевых слов (без учета регистра)."""keys_lower = [kw.lower() для kw в ключевых словах] маска = toc_df["title"].str.lower().apply(лямбда t: Any(kw in t для kw в ключевых словах_lower) ) return toc_df[mask] # Естественный поиск "внимания" — соответствует пяти разделам (один родительский элемент) + четыре подраздела). match_titles(toc_df, ["attention"])

Проверка оглавления статей с использованием ключевого слова attention :

2.3 Сопоставление встраивания (дополнительный логический сигнал)

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

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

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

 def embed_match_titles(query: str, toc_df_with_embeddings: pd.DataFrame, top_k: int = 3): """Найти заголовки, наиболее близкие к запросу по косинусному сходству.""" query_vec = get_embedding(query, client=client) забил = [] для строки в toc_df_with_embeddings.itertuples(): title_vec = np.array(row.embedding) sim = float(np.dot(query_vec, title_vec)/(np.linalg.norm(query_vec) * np.linalg.norm(title_vec))) Оценка.append((row.section_id, row.title, sim)) return sorted(scored, key=lambda x: -x[2])[:top_k] # Вставьте каждый заголовок и ранг по сходству в расплывчатый запрос читателя. toc_df_emb = toc_df.copy() toc_df_emb["embedding"] = toc_df_emb["title"].apply(lambda t: get_embedding(t, client=client)) embed_match_titles("где они объясняют внимание к себе?", toc_df_emb, top_k=3)

Ранжирование по запросу «где они объяснили самовнимание?» относительно заголовков разделов статей:

2.4 Резюме

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

3. Фильтрация по line_df

В line_df находится сам текст ответа. Вы не можете себе позволить обработать десятки тысяч строк с помощью LLM, но работа LLM по пониманию содержания не отсутствует: она локализована в блоке синтаксического анализа вопроса. Два метода действуют непосредственно с line_df : объединение ключевых слов (с использованием расширенного словаря из анализируемого вопроса) и определение сходства встраивания.

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

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

• Прямое извлечение текст из высказываний пользователя ( premium ).
• Расширение LLM для синонимов и вариантов ( prime , котизация ).
• Экспертные словарныестатьи с регулярными выражениями и разрешение неоднозначностей ( premium около € ).

Здесь представлен вклад LLM в фильтрацию контента. Расширенные ключевые слова и шаблоны экспертного словаря, полученные в результате анализа вопросов с помощью LLM. Поэтому фильтровать ключевые слова в line_df гораздо умнее, чем наивный лексический поиск; он дает понимание вопросов словаря LLM в виде предварительно вычисленного сигнала, а не в виде вызова LLM для каждого запроса.Строка, содержащая ключевые слова из двух семантических групп (тема и термин, имеющие значения формы), с гораздо большей вероятностью будет иметь ответом, чем строка, содержащая только одно из них. Слово «премиум» само по себе соответствует заголовку раздела, определениям и пояснительному тексту. Слово «premium» рядом с числом, расположенным рядом с «€», соответствует строке с кратким изложением, в которой указана длина. Основная группа — это словарь, описывающий внимание; вторичная группа — это «любимая строка, которая выглядит как формула» (математические токены: softmax , query , key , d_k ). Строки, попадающие в ОБЕ группы, почти наверняка являются определениями формулы, не ограничивающимися их текстом.

def co_occurrence_score(text: str, Primary: list[str], Secondary: list[str]) -> int: """Оценивает строку по количеству ключевых слов из каждой семантической группы, которую она содержит. Возвращает 0, если какая-либо из групп отсутствует - речь идет о совместном появлении, а не о частоте. """ p_hits = sum(1 для kw в первичном, если re.search(kw, text, re.IGNORECASE)) s_hits = sum(1 для kw во вторичном if re.search(kw, text, re.IGNORECASE)) if p_hits == 0 или s_hits == 0: return 0 return p_hits + s_hits # Вопрос: "Как на самом деле вычисляется внимание?" Primary = [r"\battention\b"] Secondary = [r"\bsoftmax\b", r"\bquery(ies)?\b", r"\bkey(s)?\b", r"\bd_?k\b"] Оценка = line_df.assign(score=line_df["text"].apply(лямбда t: co_occurrence_score(t, первичный, вторичный)) top = забил[забил["оценка"] >0].sort_values("score", возрастающий=False).head(8) top[["page_num", "line_num", "section_id", "score", "text"]]

Выполните поиск по вопросу «Как происходит механизм внимания?», обращая внимание на основную группу и токены формулы ( softmax , query , key , d_k ) в качестве составляющих группы:

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

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

Помимо каталога регулярных выражений, лексикон формируется на основе экспертного словаря, составленного во время анализа запроса. Результат работы один раз: эксперт пересчитывает сущности и их варианты ( "Франция": ["Франция", "FR", "FRA", "République française", "Hexagone"] ). Затем поисковая система выполняет недорогой поиск по каждой строке.

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

3.2 BM25 и TF-IDF

Более продвинутый вариант использует TF-IDF или BM25. BM25 (Best Match 25) — это классическая формула, оценивающая ключевые слова, которая взвешивает термины по их информационному содержанию и нормализует данные по длине документа: распространенные термины, такие как «the», несут мало информации, а редкие термины, такие как «L131-1», обладают высокой дискриминационной характеристикой. В сообществе RAG BM25 часто выглядит как разреженное дополнение к плотным вставкам, рецепт «гибридного поиска». проиллюстрированная на примере трех доменов.

Пример 1, Курорт:«Какова годовая страховая премия?» На странице А приведена сводная строка: «Годовая страховая премия: 125 000 долларов США» (одна «премия»). На странице находится пояснительный раздел из шести абзацев, посвященный понятию страховой премии (десять «премий», без указания суммы). Ответ — страница А; BM25 отдает предпочтительную страницу В.

Пример 2, документация по программному обеспечению: «Каков лимит запроса для конечной точки поиска?» На странице приведена справочная строка « /search : 100 запросов/минуту» (одна «скорость», один «лимит»). На странице B находится руководство по концепции ограничения скорости запроса (двенадцать «скорость», девять «лимит»). Ответ находится на странице А; BM25 отдает предпочтительную страницу B.

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

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

Что работает вместо этого:

• Функция повышения коэффициента совместной встречи стимулирует строки, в которых присутствуют несколько семантических групп (тема плюс группа результатов). На странице A в каждой теме темы указывается значение; на странице B присутствует только тема.
• Шаблоны с высокой ценностью определения строк, содержащих вычислительную форму ответа, независимо от того, является ли эта форма синтаксическим шаблоном (регулярное выражение для суммы выявляет Пример 1, обычное выражение для числовых результатов — Пример 2, обычное выражение для длительности — пример 3) или поиск товаров (в лексиконе указаны строки, содержащие «Франция», «FR» или «Французская Республика»).
• Использование экспертной оценки по словарю Позволяет специалистам в данной области помечать такие понятия, как «премиум», «ограничение скорости», «период уведомлений», как концепции, требующие высоких оценок, которые получают баллы только в результатах с шаблоном, дающим высокую оценку.

Эти три сигнала представляют собой явные бизнес-знания , а не статистические эвристики. Формула IDF в BM25 не кодирует ни одну из них, независимо от объема данных корпуса. Корпоративный корпус также слишком узок для того, чтобы IDF могла хорошо его реализовать: отдельный контракт или однородная коллекция не обладает междокументной вариативностью, для использования которой и был создан BM25.

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

3.3 Сопоставление встраивания фрагмента

Стандартный метод векторного поиска: разбить line_df на фрагментах по 200–500 токенов, встроить каждый один фрагмент раз при включении, встроить запрос при извлечении, вернуть фрагменты с наибольшим косинусным сходством.

Когда оно побеждает.

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

Три основных принципа, которые следует учитывать при выборе этого метода.

1. Несколько запросов, а не один:корпорировать переадресацию вопросов анализа.
2. Максимальное сходство между вариантами перезаписи, а не среднее значение. Фрагмент, хорошо оснащенный однотипным вариантом перезаписи, превосходит фрагмент, который посредственно соответствует всем операторам перезаписи.
3. Это один сигнал, а не вся обработка данных. Используйте его в сочетании с ключевыми словами содержания и методами оглавления (раздел). 4).ли>ол>

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

   3.4 Косинусный анализ на уровне строк для объяснений (и переранжирования) результатов определения на уровне страниц.

   Постоянная претензия к извлечению эмбеддингов на уровне страниц заключается в оценке непрозрачности. Когда retrive_pages_by_similarity возвращает страницу 9 с косинусом 0,7843 и страницу 6 с косинусом 0,7728, невозможно определить, какие строки на каждой странице определяются по критериям, и, следовательно, невозможно обосновать рейтинг перед аудитором. Эта претензия аналогична той, что была выдвинута в отношении минимального конвейера RAG в той же статье и по тому же вопросу.

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

   

   

   На карте карты сразу же создаются переменные вещи.

   Во-первых, постр анализочный показ, который содержит страницу и где на странице расположен сигнал.На странице 9 лидерство по показателю косинуса, в строках таблицы 3 наблюдается разброс оранжевых знаков: строки, сравнивающие «синусоидальное позиционное кодирование» с «изученными позиционными эмбеддингами» — связанный контент, но не раздел, определяющий позиционное кодирование. На странице 6, занимающей третье место по показателю косинуса, наблюдается плотное скопление темно-красных точек в заголовке раздела «Позиционное кодирование» и последующих за ними уравнений. Верхняя строка на странице получает оценку 0,8902, что выше, чем любая строка на странице 9.

   Во-вторых, ранжирование на уровне страниц — плохой агрегатор. На странице 6 находится раздел, соответственно на вопрос, но страница в среднем содержит 53 строки (кодирование плюса). окружающий контент), и среднее значение снижается из-за остальных страниц. На странице 9 распространенность более широкая, поэтому ее среднее значение остается выше, даже несмотря на то, что пиковое значение ниже. Замена оценки страницы с mean(line_sims) на max(line_sims)(одна строка кода) меняет порядок ранжирования и занимает страницу 6 на первом месте в этом вопросе.

   В-третьих, построчный просмотр восстанавливает контекстную структуру/якорную ссылку из статьи 7A (извлечение как фильтрация). каждая верхняя строка является якорем (фактической). фразой, получившей высокий балл, которая может проверить читателя); страница — это контекст, который подаёт дальше для генерации. В этом же шаблоне detect_then_extract , но вместо ключевого слова используется встраивание.

   В-четвертых, и это неудивительно, если читать сами верхние строки: строки с ключевыми буквами на этих страницах — это те, которые составляют основное содержание Позиционное кодирование или позиционное встраивание.На странице 6 три лучших строки — это сам заголовок раздела («Позиционное кодирование») и две строки основного текста, в которых упоминается термин («как встраивания, так что их можно суммировать», «где поз — позиции, а и — размерность»). На странице 9 две наиболее сильные строки — это строки (E) в таблице 3, в которых упоминается вариант («синусоидальное позиционное кодирование с изученными позиционными встраиваниями», «которое позиционное встраивание вместо синусоидов»). Встраивание здесь не выявляет какого-то глубокого семантического свойства. Он находит буквальное ключевое слово, а остальные слова в каждой строке смещают отсчет на несколько процентных пунктов вокруг базового уровня ключевого слова. Когда в вопросе содержится очевидный ключевой термин, встраивание на уровне строки приводит к группированию с ключевым словом с независимыми шагами. Простой фильтр str.contains("positional")для line_df показаны те же самые верхние строки в микросекундах, без моделей встраивания в цикле.

   Форма оценки оценок дает второй, полезный сигнал: на странице 6 пять прямых линий плавно снижаются (0,890, 0,866, 0,843, 0,802, 0,798), образуя плотное плато, сигнализирует о том, что «в этом разделе обсуждается бурная тема»; на странице 9 результатов показывает два выброса (0,826, 0,823), а затем падение на пять пунктов до 0,771, что указывает на то, что «на странице тема упоминается медленно». Плотность границ, превосходящих пороговое значение, является не только максимальным значением, отличающим определяющий раздел от мимолетных упоминаний.

   Чего это не дает оценки: встраивания по-прежнему не могут вам сказать, это найденная строка тем определений, которые вы хотели, или мимолетным упоминанием в сравнительной таблице. Просмотр на уровне строки позволяет проверить ранжирование, но не делает его точным. Для точности, когда в вопросе содержится критический сигнальный элемент (позиционное кодирование, ограничение ответственности, дата предъявления в силе), методы ключевых слов и регулярных выражений из раздела 3 показывают указанные инструменты. Совпадение по ключевому слову «позиционное кодирование» конкретно сформулировано бы на странице 6 и странице 9, без каких-либо этапов встраивания. Косинусный анализ на уровне строк — это наложение аудита, которое делает конвейер встраивания на уровне страниц обоснованным, когда встраивания происходят методом изначально, и статья 7C (арбитр LLM) определяет, когда это так, а когда нет.

   4. Объединение двух таблиц

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

   4.1 Обоснование с последовательным обсуждением (альтернативной программой LLM)

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

   Когда это оправдывает дополнительный звонок:в контракте на 100 страниц 50 разделов; эксперт выбирает 2-3 за один звонок; затем поиск ключевых слов обрабатывает несколько сотен строк вместо всех 15 000. Компромисс по сравнению с моделью с одним экспертом: вы платите за два звонка эксперта вместо одного, но поиск ключевых слов на втором этапе происходит по гораздо меньшему пулу, что важно, когда пул огромен (например, 500-страничный нормативный документ). Для документов минимального экономического уровня (от 10 до 100 страниц) достаточно моделей с одним экспертом; Эксперт одновременно видит все оглавление и совпадения по ключевым словам и выполняет анализ разделов в рамках одного звонка.

   

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

    def Reason_then_match(question: str, Primary_kw: list[str], Secondary_kw: list[str], line_df: pd.DataFrame, toc_df: pd.DataFrame, top_n: int = 5): """Этап 1: LLM выбирает разделы из toc_df. Этап 2: оценка ключевых слов в этих разделах. Этап 2 фильтрует по диапазону страниц (не по разделу_id), чтобы они были вложенными все подразделы, совместно использующие страницы со своим родителем, - line_df.section_id сворачивается, когда страница содержит несколько разделов, но объединение диапазона страниц восстанавливает все внутри выбранной области. {selection.reasoning[:200]}") соответствующие_страницы = set() для sid в релевантных_идах: rows = toc_df[toc_df["section_id"] == sid] для _, sec в rows.iterrows(): соответствующие_страницы.обновление(диапазон(int(sec["start_page"]), int(sec["end_page"]) + 1)) кандидатов = line_df[line_df["page_num"].isin(relevant_pages)].copy() кандидаты["оценка"] = кандидаты["текст"].apply(лямбда t: co_occurrence_score(t, Primary_kw, Secondary_kw) ) top = кандидаты[кандидаты["оценка"] >0].sort_values("score", возрастающий=False).head(top_n) return top # Вопрос читателя: где настоящая формула? Не проза о внимании. result = Reason_then_match( "Где они определяют фактическую формулу для масштабированного внимания скалярного произведения?", Primary_kw=primary, Secondary_kw=вторичный, line_df=line_df, toc_df=toc_df, ) result[["page_num", "line_num", "section_id", "score", "text"]]

   Запустите программу, ответив на вопрос: «Где они определили фактическую формулу для масштабированного скалярного искусства внимания?», сопоставив выбранные на первом этапе разделы и строки с показателями баллами на первых этапах:

   

   4.2 Сопоставление с учетом весовых коэффициентов по секциям

   Строка, соответствующая ключевому слову и расположенная в разделе, заголовок которой также соответствует, с гораздо большей вероятностью появится ответом, чем строка, соответствующая ключевому слову в несвязанном разделе. Это альтернатива с нулевым LLM, когда вам нужна недорогая предварительная оценка с учетом разделов перед вызовом арбитра. Оба сигнала (совпадение заголовка и совпадение значений) являются чистыми операциями с ключевыми словами. Качество ниже, чем у полного шаблона арбитража в сложных случаях, но достаточно в большинстве простых случаев, и вы можете использовать его в качестве предварительного фильтра, когда пул кандидатов слишком велик, чтобы отправить его на LLM за один раз.defsection_weighted_match(question: str, line_df: pd.DataFrame, toc_df: pd.DataFrame, Primary_kw: list[str], Secondary_kw: list[str], boost: float = 1.5): «»»Оценка строк по совпадению ключевых слов, повышается, когда заголовок раздела строки также совпадает.»»» title_keywords = [w for w in вопрос.lower().split() если len(w) >3] соответствующие_section_ids = set(match_titles(toc_df, title_keywords)[«section_id»]) набрали = [] для строки в line_df.itertuples(): line_score = co_occurrence_score(row.text, Primary_kw, Secondary_kw), если line_score == 0: продолжитьsection_boost = повысить, если row.section_id в соответствующие_section_ids еще 1.0 Assessment.append((row.line_num, row.page_num, row.section_id, line_score *section_boost, row.text)) return pd.DataFrame(scored, columns=[«line_num», «page_num», «section_id», «score», «text»]).sort_values(«score», возрастающий=False).head(8)section_weighted_match( «Как на самом деле вычисляется внимание в этой статье?», line_df, toc_df, Primary_kw=primary, Secondary_kw=вторичный, )

   Применяйте тот же вопрос, требующий поиска, с определением в 1,5 раза, если строки заголовка раздела также совпадают:

   

   4.3 Гибридное встраивание

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

    def Hybrid_embedding(question: str, page_df: pd.DataFrame, line_df: pd.DataFrame, toc_df: pd.DataFrame, top_k: int = 5, boost: float = 1.3): """Встраивайте страницы поиска, увеличивайте те, в разделах, заголовок которых соответствует словарю вопросов.""" title_keywords = [w для w в вопросе.lower().split() if лен(ш) >3] соответствующие_section_ids = set(match_titles(toc_df, title_keywords)["section_id"]) page_to_section = (line_df.dropna(subset=["section_id"]) .groupby("page_num")["section_id"] .agg(lambda s: s.value_counts().index[0]) .to_dict() ) получено, _ = restart_pages_by_similarity(page_df, line_df, вопрос, top_k=top_k * 2, клиент=клиент) забил = получено.copy() забил["section_id"] = забил["page_num"].map(page_to_section) забил["boosted_sim"] = забил.apply(лямбда r: r["similarity"] * (boost if r["section_id"] в соответствующем_section_ids else 1.0), axis=1, ) return Assessment.sort_values("boosted_sim", возрастающий=False).head(top_k)[["page_num", "section_id", "similarity", "boosted_sim", "text"]] Hybrid_embedding("Как на самом деле рассчитывается внимание в этой статье?", page_df, line_df, toc_df, top_k=5)

   Проведите эксперимент с тем же вопросом на привлечение внимания, применив метод заголовка раздела к косинусному показателю встраивания:

   

   4.4 Почему выигрыши выигрывают

   Отдельные детекторы пропускают слишком много информации:

   • Поиск по ключевым словам в заголовке не основания, если заголовки не содержат элементов, основанных на идеях.
   • Ошибка объединения Ключевые слова в происходящем содержимом, когда одно и то же слово встречается во многих разделах, и только одно из них является релевантным. изолировать.

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

   LLM может определить, что строки с высокой последовательностью встречаемости «премия за услуги составляет 200 евро» менее значимы, чем строки с более низкими показателями «l'assurance comprend une prime annuelle de 4 500» €», поскольку вопрос касался основной премии.

   Если отбросить маркетинговую терминологию («агентский RAG»), то суть сводится к следующему: использовать небольшой звонок LLM для принятия решений того, как определенные методы выполнили свою работу. Мы разрабатываем комбинированную логику в последующем интегрированном конвейере.

   Несколько слов в кросс-кодировщиках для переранжирования результатов поиска(Cohere Rerank, bge-reranker, monoT5 и обширное семейство переоценивает лучших кандидатов с помощью обученной модели релевантности). Суть статей этой серии заключается в том, что переранжировщики представляют собой серьезные проблемы слабого поиска на исходном этапе, а не этапом по умолчанию для строгого поиска. Когда исходный этап уже включает в себя экспертные ключевые слова, рассуждения о содержании, фильтры метаданных и выбор структурной области (работа, о которой идет речь в этой статье), правильный фрагмент уже находится в верхней части списка, и кросс-кодировщик дает небольшой прирост при некоторых затратах на задержку и вывод. Когда исходный этап представляет собой общее косинусное сходство в недифференцированном векторном хранилище, переранжировщик восстанавливает большой разрыв. Но, по сути, архитектурным подходом является радикальное исходное состояние, чтобы разрыва вообще не произошло. В этой серии статей переранжирование метода как компенсация тонкого конвейера обработки данных, полезного в сценариях с экономичной допустимой задержкой, и когда вычислительные ресурсы обходятся дешево и их сложно улучшить, а не как стандартная процедура. Несколько общедоступных бенчмарков (BEIR, mTEB) показывают выигрыш от переранжирования в дополнении к векторному поиску; в гибридном поиске, который уже включает фильтры BM25 и метаданные, незначительный выигрыш гораздо меньше. Это и есть редакционная позиция.

   Четыре метода, сравниваемые параллельно: один и тот же вопрос, четыре ретривера. Наблюдаем, как каждый из методов оказывается неэффективным, побеждает комбинация методов.

   

   Обнаружение-затем-из:конвенционная комбинация «привязка к заголовку оглавления, извлечение из основного раздела текста». Привязкой является строка toc_df, найденная по ключевому слову в заголовке; Контекстом является полный текст этого раздела, извлеченный из line_df . Именно на эту функцию ссылалась статья 7A при описании двухуровневого структурирования текста.

    def define_then_extract(toc_df: pd.DataFrame, line_df: pd.DataFrame, ключевые слова: list[str]): """Привязка к заголовкам toc_df, затем извлеките тело раздела по диапазону страниц из line_df.""" matched = match_titles(toc_df, ключевые слова), если matched.empty: return None, Nonesection = matched.iloc[0] body = line_df[ (line_df["page_num"] >= раздел["start_page"]) & (line_df["page_num"] <= раздел["end_page"]) ] return раздел, тело # Пользователь спрашивает: «Где они описывают обучение?» — привязка — это один короткий заголовок, контекст — все тело раздела обучения. раздел, тело = обнаружение_then_extract(toc_df, line_df, ["Обучение"]) print("=== ANCHOR (toc_df, область действия: заголовок, несколько слов) ===") print(f" matched:section_id={section['section_id']} title='{section['title']}'") print(f" диапазон страниц: от {section['start_page']} до {section['end_page']}") print() print(f"=== ЭКСТРАКЦИЯ КОНТЕКСТА (line_df, область действия: полное тело раздела, {len(body)} строк) ===") for _, ln в body.head(8).iterrows(): print(f" p{ln['page_num']:>2} l{ln['line_num']:>3}: {ln['text'][:90]}")

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

   

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

   Обнаружение якоря происходит на трех уровнях, с одним вызовом LLM в конец.

   • Этап 1. Обнаружение (параллельное). Обнаружение ключевых слов в line_df и <код>toc_dfкод>прогресс происходит постоянно (это бесплатно и требует аудита). Встраивание векторов рейтинга параллельно в качестве дополнительного сигнала, полезного для выявления несоответствий в словаре и решениях концептуальных вопросов.
   • Этап 2. Агрегирование. Результаты группируются в структурную единицу (раздел). toc_df , если доступен, в потерянном случае — страница или фрагмент).
   • Этап 3. Один вызов LLM. Арбитр видит оглавление, совпадение по ключевым словам, совпадение по эмбеддингам и структурным вложениям — всё в одном вызове. Он выполняет рассуждение по главлению и выносит окончательный рейтинг одновременно.

   Состав три шаблона (сначала обоснование, затем парламентие, объединение с учетом разделов, гибридное встраивание) создает перекрестное взаимодействие line_df и toc_df до того, как арбитр увидит кандидата, что определит его работу с или документами.

   Что именно делает LLM в конце с фантастическими кандидатами, что он получает и как это становится обоснованным JSON для генерации — это предмет статьи 7C (арбитр LLM и выходной JSON-файл для извлечения): структурированное краткое описание, математическое арбитражное решение, ролик для каждого кандидата ( <код>первичныйкод>/<код>поддержкакод>/<код>тангенциальныйкод>/<код>отбрасываемыйкод> ) с обоснованием, журнал аудита, диспетчер, который выбирает, какие детекторы запускать для каждого случая, путь «не найдено» и единый контракт RetrivalResult.

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

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

   • Робертсон и Сарагоса, Вероятная структура релевантности: BM25 и за ее пределами, FnT IR 2009. Каноническая ссылка на BM25; В статье утверждается, что BM25 измеряет закономерности, когда для поиска информации в бизнесе требуется совместное явление, основанное на этом. Эмпирическое подтверждение статьи о том, что BM25 является надежным базовым признаком, который запас плотных моделей не всегда превосходит.
   • Карпухин и др., Плотный поиск фрагментов текста для ответов на вопросы в открытой предметной области (ДНР), EMNLP 2020 (arXiv:2004.04906). Плотный поиск как стандартный подход в производстве; полезный контраст с подходом, используемым в данной статье при работе с корпоративными корпусами, где, в свою очередь, использовались ключевые слова.

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

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

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

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

   Похожие записи

   • Дизайн-система Kite: путь от «порядка» к «воздушному змею»
   • Американские военные использовали искусственный интеллект Grok Илона Маска для бомбардировки Ирана
   • Я вырос на Red Alert 2. Открыл его заново спустя годы — и впервые поверил, что AI делает игры