Контекстная инженерия для RAG: четыре типизированных входных параметра, согласование на основе каждого ответа.

Enterprise Document Intelligence [Vol.1 #7bis] – Тоби Лютке и Андрей Карпати дали название этой публикации в 2025 году. Для одного документа в каждом блоке последовательно выбраны фрагменты, которые снимаются по одному вызову LLM. Корпус, диалоги и инструменты расширения – это дальнейшая работа.

Делиться

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

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

К тому моменту, когда будут собраны четыре блока RAG из одного документа, сборка завершена. Парсинг составляет реляционные таблицы. Парсинг предложений создает типизированный ParsedQuestion. Извлечение производит отфильтрованное подмножество строк, а также отчет о том, как оно их выбрало. Генерация представляет ответ Pydantic с указанием источников. Все это сводится к одному вызову LLM с фиксированной системной подсказкой и пользовательским контентом, собранным из исходных элементов.

Теперь у этого конвейера есть название. В июне 2025 года Тоби Лютке написал в Твиттере, что «проектирование подсказок» — это неправильная формулировка, и предложил вместо этого «проектирование контекста»: «искусство предоставления всего контекста для того, чтобы задача была правдоподобно разрешима с помощью LLM». Андрей Карпати спустя неделю продержался, назвав это «тонким искусством и наукой заполнить контекстное окно именно той информацией, которая необходима для следующего шага». Через несколько месяцев этот термин появился на обложке книги издательства O'Reilly и был структурирован в таксономической компании LangChain.

Следующий метод обработки RAG с одним документом через эту призму. Каждый блок имеет адаптивные типизированные фрагменты; на этапе сборки они встраиваются в вызов LLM; системная подсказка остается неизменной для кэширования. Название процесса не меняет архитектуры. Оно меняет то, как его называет, когда аудитор спрашивает, как работает система, и сообщает читателю, что архитектура — это та, к которой пришли промышленные предприятия в 2025 году. означала две дополнительные вещи: изменение формулировки одной подсказки для достижения наилучшего поведения и написание примеров кода, чтобы модель знала, как выглядит хороший результат. Обе вещи имеют узкую направленность. Они касаются одного блока текста, отправленного в один вызов.

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

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

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

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

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

2. Каждый кирпичный проход типизированный контекст.

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

Парсинг выдает реляционные таблицы и синтез одного словаря. line_df содержит одну строку на договор с ограничивающими рамками. page_df содержит по одной строке на странице с типом и указанием столбцов. toc_df содержит записи оглавления с начальной страницей и глубиной. image_df содержит встроенные изображения с phash и метаданными. parsing_summary — это синтез на уровне документа: doc_type , n_pages , типичные_поля , summary , плюс поля механики. В блоке поиска используются таблицы по строкам. Блок анализа вопросов использует семантическое подмножество parsing_summary через DocContext .

Анализ вопросов выдаёт объект ParsedQuestion . Его поля не являются произвольными. <код>ключевые словакод> — это краткий список именных фраз для поиска контента. intent — это метка из постоянного буквенного перечисления, которая управляет отправкой формирования при генерации. structural_hints.pages_hint содержит закрепленные страницы, когда пользователь сказал «на странице 3». answer_shape содержит ожидаемую выходную форму (текст, часть, дата, список, таблица, адрес) для поиска формы генерации. Каждое поле обрабатывается острым блоком обработки. Ни одно из них не применяется в LLM в виде необработанных строк. В этот ряд входят три статьи, из которых следует прочитать по разным причинам:

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

Функция извлечения данных выдает отфильтрованный DataFrame и словарный аудит. filtered_line_df — это подмножество <код>line_df который видит генерацию блока. anchor_pages — это идентификаторы страниц, которые были сохранены, и причина их сохранения. retrival_audit содержит информацию о методе, который победил (ключевое слово, оглавление, арбитр LLM), обосновании оглавления LLM (если применимо) и выбранных разделах. Отфильтрованный DataFrame — это то, что читает LLM. Аудит — это то, что читает аудитор. Три статьи составляют этот блок, в порядке их выполнения:

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

Generation — это потребитель, а не источник. Он принимает вопрос, отфильтрованные строки, PromptContext и схему ответа. Он представляет LLM. Он возвращает ответ, типизированный с помощью Pydantic. Пунктирная рамка в блоке Генерация указывает на эту роль.

Фиолетовая зона «PROMPT ASSEMBLY» справа — это место, где происходит контекстное проектирование в коде. Мы реализуем его с помощью трех примитивов:

• Агрегатор PromptContext(BaseModel) с одним полем для каждого источника контекста: doc_context , Future corpus_context , Future project_context .
• На уровне модуляции для каждого блока, вызывающего LLM, создается фиксированный MODULE_SYSTEM_PROMPT .
• MODULE_USER_TEMPLATE с именованными заполнителями, которые создаются кирпичом с помощью str.format(...) .

Статья 1 (минимальный RAG из четырех блоков) представлена ​​блоками как поток. Статья 6А (тезис о разборе вопросов) сделала разборщик вопросов типизированным. Статья 8А (генерация типизированного контракта) Создание типизированной схемы генерации. В этой статье те же четыре блока анализируют точки зрения «какой контекст вносит каждый из них, как они определяют вызов LLM, не загрязняя друг друга». Тот же код, другой подход.

3. Четыре выбранных фрагмента одного документа.

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

3.1 Исправленная системная подсказка

Первая часть — это системное сообщение. Описание роликов, правил, примеров. Оно не меняется при каждом вызове. В этой серии оно записывается как константа Python на уровне модуляции, а затем повторяется в виде аргумента kwarg со значением по умолчанию, чтобы вызывающая сторона могла переопределить его для каждого домена без создания дочернего процесса:

 PARSE_QUESTION_SYSTEM_PROMPT = ("Вы извлекаете фразы-существительные из вопроса пользователя..." ) def parse_question(question, *, system_prompt: str = PARSE_QUESTION_SYSTEM_PROMPT, user_template: str = PARSE_QUESTION_USER_TEMPLATE, context: PromptContext | None = None): ...

Два рабочих следствия. Запрос кэшируетсяпоставщиком LLM, поскольку он не меняется между вызовами одной и той же модели. Кэшированный ввод обходится примерно в десять раз дешевле, чем ввод новых данных у поставщиков, публикующих тарифы. И требуется запрос аудит , поскольку он находится в стабильном символе Python, который аудитор может использовать для поиска, проверки способа и сравнения между релизами.

3.2 Полученные строки, отфильтрованные диспетчером.

Вторая часть — это строки, которые фактически читают LLM. Диспетчер обрабатывает ParsedQuestion.keywords и structural_hints , выбирает метод (ключевое слово, оглавление, арбитр LLM) и возвращает отфильтрованный кадр плюс аудит. Пользовательский контент получает отфильтрованный кадр; аудит хранилища на диске, чтобы оператор мог проверить его позже:

 извлечено, filtered_line_df, аудит = диспетчеризация_страницы_ретривал( вопрос, line_df, page_df, toc_df=toc_df, ключевые слова=ключевые слова, top_k=5, use_toc=True, )

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

3.3 Блок контекста документа, компактный JSON

Третий компонент — это синтез на уровне документа: тип документа, количество страниц, типичные поля, краткое описание. Этот фактор необходим в виде компактного JSON-объекта, чтобы LLM мог определить границы неоднозначных формулировок в соответствии с характером документа. В этой серии метод реализован в каждом классе Pydantic, в обычном контексте. DocContext.as_prompt_json() создает самый маленький JSON-объект, который по-прежнему содержит имена четырех полей; значения null и пустые значения выбрасываются:

 class DocContext(BaseModel): doc_type: str | Нет = Нет n_pages: int | Нет = Нет типичные_поля: список[str] = [] сводка: str | None = None def as_prompt_json(self) -> str: payload = {k: v for k, v in self.model_dump().items(), если v не равен None и v != []} return json.dumps(payload, separators=(",", ":"))

При включении резюме с doc_type="resume" , n_pages=1В соответствии с уникальными типичными полями, полезная нагрузка составляет менее 200 символов. В известном документе, где каждое поле имеет значение null или пустое, полезная нагрузка представляет собой объект пустой {} , блок полностью отключается из пользовательского контента. Та же схема применяется к зарезервированным слотам corpus-context и project-context, когда указанные статьи активируют их.

3.4 Агрегатор PromptContext , который выбирает три вышеупомянутых компонент.

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

 class PromptContext(BaseModel): doc_context: DocContext | Нет = Нет # corpus_context: CorpusContext | Нет = Нет # зарезервировано # project_context: ProjectContext | None = None # зарезервировано

Каждый LLM-блок принимает один необязательный context: PromptContext . Вспомогательная функция render_context_block(context)обрабатывает каждое ненулевое поле, отображает его компактный JSON и выдает один помеченный блок для каждого слоя. Добавление нового слоя означает раскомментирование одного поля, добавление двух строк во вспомогательную функцию, и каждый блок автоматически выбирает новый слой. Подпись остается стабильной во всех релизах.

4. Какие изменения продолжаются на практике?

Изменение названия практики меняет три аспекта ее работы, даже при неизменном коде.

Аудит. Если ответ неверный, вопрос уже не в том, «что было сказано в подсказке». Вопрос в том, «что отобразилось в контекстном окне для этого вызова». Серия сохраняет вывод каждого блока на диск: parsing/ , questions//parsed_question.json , <код>извлечение/<хеш>/retrived_pages.parquetкод> , <код>поиск/<хэш>/retrival_audit.json . Аудитор восстанавливает контекстную информацию из этих файлов. Тогда возникает вопрос: был ли doc_context неверным, были выбраны неправильные страницы, менялась ли системная подсказка между версиями, был ли шаблон пользователя конфиденциальим. Для каждой из этих проблем существует свой способ решения.

Стоимость. Два рычага суммируются. Системный запрос фиксирован для всех вызовов в одной и той же модели, поэтому он оплачивается по тарифу кэшированного ввода. Пользовательский контент увеличивается с помощью as_prompt_jsonи выбран путем извлечения, поэтому переменная часть невелика. В корпусе из 100 документов, содержащих по 10 вопросов в каждом, основная стоимость — это переменная часть, умноженная на 1000 вызовов. Название практики не меняет математику, но составляет бюджет для каждого вызова понятным: строка в контекстной структуре содержит генератор, на который можно указать. одно поле, еще два зарезервированы для слоев контекста корпуса и контекста проекта, которые были добавлены в более поздних частях серии. Когда они появились, эта статья не требовала переработки. Подпись остается. Тело render_context_block увеличивается на одну ветвь. Каждый блок, который уже принимает context: PromptContext | None получает новый подконтекст бесплатно. Такой подход окупается, вызывает отсрочку поломок между релизами.

5. Выход за рамки темы, с указаниями.

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

• Контекстный корпус. Когда для ответа требуется изучить множество документов, LLM необходимо учитывать, какие документы находятся в поиске области и статьи, которые у них есть. вообще. Это будет реализовано в будущем CorpusContext Pydantic, который будет получать данные от агрегатора на основе значений parsing_summary для каждого документа. <код>PromptContextкод>место для этого параметра зарезервировано, чтобы подписи блоков не менялись. В более поздней статье будет описан процесс построения и подключения потребителей.
• История переписки. Многоэтапный чат содержит пары вопросов/ответов, которые магистр права должен определить, прежде чем приступить к новому вопросу. Это состояние проблемы (где хранится история, когда она суммируется, когда удаляется) в дополнении к проблемному контексту. В более поздней статье этой серии она превращается в первый элемент.
• Вызовы инструменты.В цикле агентов по поиску инструментов, выходные данные инструментов и промежуточное состояние рассматриваются в контекстном окне. Проблемы выбора/сжатия/изоляции здесь обостряются, поскольку контекстное окно быстро заполняется за ходы. В более поздней статье этой серии проектирование контекста агентами как отдельная тема.

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

Один и тот же якорь, четыре собеседника рядом. Якорь — одна строка. Абзац — ±5 строк на той же странице. Раздел использует оглавление для расширения до основного раздела текста. <сильная>Страницасильная>заполняет всю страницу. Компромисс в статье (стоимость против точности) становится ползунком, который вы можете запустить в первом PDF-файле, не отрываясь от текста. об инженерии контекста, который дает название дисциплине, уже отработанной на уровне отдельных документов. Анализ выдает реляционные таблицы и синтез на уровне документа. При анализе вопроса выдается типизированный ParsedQuestion , поля которого управляют элементом на каждом последующем уровне. Извлечение выдает отфильтрованный набор строк плюс аудит. Генерация обрабатывает собранную полезную платформу через фиксированную системную подсказку, шаблонный пользовательский контент и агрегатор PromptContextс одним типизированным слотом на каждом вышестоящем уровне.

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

• Уолден Ян, «Не создавайте многоагентные системы», Cognition, 12 июня 2025 г. Самая ранняя работа, в которой дается название этой дисциплины. Утверждение Яна о том, что «контекстная инженерия — это, по сути, задача номер один для инженеров, создателей агентов ИИ», — эту фразу, которую позже цитирует Лэнс Мартин, предусматривающая пред таксономию четыре стратегии.
• Тоби Лютке, X, 18 июня 2025 г. Твит, оглавленный «Название: Мне больше нравится термин „контекстное проектирование“, чем „проектирование подсказок“. Он лучше описывает основные навыки: искусство предоставления всего контекста, чтобы задача была правдоподобно решена для магистра прав». Статья о таксономии. Также переиздана в блоге LangChain под именем команды LangChain.
• Андрей Карпати, X, 25 июня 2025 г. Рекомендация: «+1 за „контекстное проектирование“ вместо „проектирование подсказок“. Люди ассоциируют подсказки с краткими описаниями задач, которые вы бы давали студентам магистратуры в повседневной работе. В каждом профессиональном приложении для студентов магистратуры контекстное проектирование — это тонкое искусство и наука, сжатое контекстное окно именно той информации, которая необходима для следующего шага». Параллельная таксономия: шесть отдельных тактик (RAG, Загрузка инструментов, Карантин контекста, Удаление контекста, Суммирование контекста, Выгрузка контекста) для обеспечения работоспособности контекстного окна.

Таксономии, расположенные рядом.

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

Чем продлить курс лечения.

• Эдди Османи, «Контекстная инженерия: применение инженерных преобразований к подсказкам, часть 1», O'Reilly Radar, 11 августа 2025 г. Переосмысление инженерных возражений, немного позднее, чем обсуждение X: «Инженерная идея подсказок завершилась в грамотной формулировке вопроса; контекстная инженерия — в построении целостной информационной среды, чтобы ИИ мог надежно решить проблему».
• Майк контролирует, «Контекстная инженерия с помощью DSPy», книга издательства O'Reilly. Книга представляет собой подробное изложение материала, основанное на модели DSPy, ориентированной на сигнатуру.
• Руководство по оперативному проектированию, руководство по контекстному проектированию. Формализованное учебное пособие с примерами решения задач.

Контрапункты.

• Weaviate, электронная книга по контекстной инженерии (23 стр., декабрь 2025 г.). Представление поставщика: шесть компонентов (агенты, расширение запросов, поиск, методы подсказок, память, инструменты). Позиция серии в отношении этого ребрендинга, где переименование соответствует линейке продуктов, а не практике, переходу в критическую публикацию.
• Блог Roadie, почему смешение RAG и контекстной инженерии обходится вам дорого в продакшене. Противоположная точка зрения: разделение RAG и контекстной инженерии, рассмотрение извлечения информации лишь как один из многих аспектов.

В данной статье упоминаются примитивные серии.

• Агрегатор PromptContext и проекция DocContext : src/docintel/core/schemas/ .
• вспомогательная функция render_context_block : src/docintel/core/prompts.py .
• Системные подсказки на уровне модулей и пользовательские шаблоны: каждый модуль, вызывающий LLM, в каталоге src/docintel/ , по соглашению. Ранее в этой серии:
• Усиление экспертного мнения: философия построения системы управления репутацией предприятия. Серии манифестов: четыре основных элемента (анализ, анализ вопросов, поиск, генерация) цели масштабировать экспертное определение, а не заменять его.

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

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

Часть II: Четыре кирпича

Анализ документып>

• Помимо функции 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 должна учитывать любые вопросы из пяти полей: ключевые слова, область применения, структура, декомпозиция, пояснение. Пять семейств столбцов, которые анализатор обрабатывает непосредственно из запроса пользователя вместе с кодом, сопровождающим каждого из них.
• Один проанализированный вопрос RAG, четыре решения: стратегия обработки фрагментов, модели уровней, фрагменты, журнал аудита. Решения, которые принимают парсер на основе строки пользователя, с помощью профиля документа: диспетчеризация, активация, полная схема, журнал аудита (pipeline_trace.json) и обход корпуса брокера.
  • Когда пользователи RAG задают расплывчатые вопросы: уточните один раз, а затем запомните значение по умолчанию. Если слишком вопрос расплывчатый, достаточно одного уточнения, значение по умолчанию будет заимствовано из ответа.

Из

• Поиск — это фильтрация, а не поиск: ментальная модель для частного RAG. Поиск переосмыслен как фильтрация по line_df и toc_df: якоря малы, контекст велик.
• Поиск под якорей для RAG: одновременно введите слова, эмбеди и сигналы TOC. Параллельные детекторы якорей: ключевое слово всегда, встраивание рядом, один вызов LLM в конце.
• Магистр прав в качестве арбитра при поиске RAG: выбор подходящего кандидата с обоснованием. Арбитр-магистр права: кандидаты ранжированы с обоснованием, одно из них выводится в формате JSON.

Кежан Ши Посмотреть все Кежан Ши

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