Когда ИИ должен перестать доверять собственным знаниям? — Триггер извлечения

Вопрос

Когда ИИ должен перестать полагаться на то, что он уже знает, и получить внешнюю информацию перед ответом?

Этот вопрос кажется простым, но он находится в центре одного из самых важных проектных решений в современных системах ИИ.

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

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

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

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

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

Что это на самом деле означает

У LLM есть два принципиально разных способа получения информации.

Первый — это знания модели. Это информация, представленная в обученных параметрах модели. Во время выполнения не требуется ни запрос к базе данных, ни веб-поиск, ни поиск по документам.

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

RAG соединяет эти два мира. Но сам RAG не отвечает на вопрос, когда это соединение должно быть активировано. Именно для этого предназначен Триггер выборки.

Question
   ↓
Model Knowledge
   ↓
Is internal knowledge sufficient?
   ↓
Retrieval Trigger
   ↓
External Retrieval, if required
   ↓
Evidence
   ↓
Reasoning
   ↓
Answer Validity Boundary
   ↓
Answer

Таким образом, Триггер выборки находится перед выборкой. Граница допустимости ответа находится позже.

Первый спрашивает: нужны ли мне внешние доказательства?

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

Это связанные решения, но это не одно и то же решение.

Простейший пример

Рассмотрим три вопроса.

Первый вопрос основан на весьма стабильном факте.

User
↓
"What is the capital of France?"

Model knowledge
↓
Paris

Fresh external evidence required?
↓
No

Answer
↓
Paris

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

Теперь рассмотрим вопрос, ответ на который постоянно меняется.

User
↓
"What is the current NVIDIA stock price?"

Model knowledge
↓
Potentially outdated

Current information required?
↓
Yes

RETRIEVAL TRIGGER
↓
Market data / search / API
↓
Answer

Модель может знать очень много о NVIDIA. Это не означает, что она знает цену сейчас.

Третий пример ещё важнее.

User
↓
"Does this new scientific paper prove that X causes Y?"

Model knowledge
↓
Can reason about causality,
statistics and scientific methodology.

But:
the actual evidence is not available internally.

RETRIEVAL TRIGGER
↓
Retrieve the paper
↓
Inspect methodology
↓
Inspect results
↓
Compare claim with evidence
↓
Answer Validity Boundary
↓
Answer

Способность модели к рассуждению может быть вполне полезной. Отсутствующий компонент — это доказательства.

Это различие является фундаментальным.

Где пример перестаёт работать

Приведённые выше примеры представляют решение как бинарное: извлекать или не извлекать.

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

Само извлечение также может внести некорректный контекст в остальном разумный ответ.

Именно поэтому поиск информации не следует рассматривать как автоматический синоним истины.

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

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

Adaptive-RAG аналогично выбирает между отсутствием поиска, одношаговым поиском и более сложными стратегиями поиска в зависимости от сложности вопроса.

Таким образом, важный вопрос не в том: есть ли в этой системе RAG?

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

Прямой ответ

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

В практических системах триггер поиска может возникать из нескольких условий:

Need for current information
        OR
Need for exact source-specific information
        OR
Need for evidence or provenance
        OR
Need for private/user-specific information
        OR
Insufficient knowledge coverage
        OR
Conflicting evidence
        OR
High consequence of factual error

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

Почему это так

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

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

Это различие создаёт неизбежную системную проблему.

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

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

Именно в этой точке триггер поиска становится полезным.

Контекст

Традиционный RAG часто выглядит так:

Question
↓
Retrieve documents
↓
Add documents to context
↓
Generate answer

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

Более продвинутые подходы вводят адаптивный шаг:

Question
↓
Evaluate information requirement
↓
        ┌───────────────┐
        │               │
   no retrieval      retrieval
        │               │
        ↓               ↓
 model knowledge    external evidence
        │               │
        └───────┬───────┘
                ↓
              answer

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

Self-RAG аналогично вводит механизмы, позволяющие извлечению, генерации и критике взаимодействовать, вместо того чтобы рассматривать извлечение как безусловный этап предварительной обработки.

Adaptive-RAG подходит к той же более широкой проблеме с точки зрения сложности запроса: разные вопросы могут требовать разных стратегий извлечения.

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

Допущения

Фреймворк Retrieval Trigger предполагает, что система имеет доступ как минимум к одному внешнему источнику информации, когда требуется извлечение.

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

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

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

Таким образом, оптимальная система не максимизирует извлечение. Она максимизирует целесообразное извлечение.

Переменные

Практический Retrieval Trigger может учитывать пять основных переменных.

Актуальность

Насколько вероятно, что требуемая информация изменилась? Столица Франции обладает очень низкой волатильностью. Цена акции обладает чрезвычайно высокой волатильностью.

Специфичность

Требует ли вопрос информации из конкретного источника, документа, организации, аккаунта или набора данных? Если пользователь спрашивает, что написано в конкретном договоре, общие знания модели не имеют значения. Договор необходимо извлечь.

Требование доказательств

Нужно ли ответу происхождение? Модель может знать, что утверждение общепринято, но всё равно нуждаться в источнике, когда задача требует проверки.

Покрытие знаний

Вероятно ли, что предмет adequately представлен во внутренних знаниях модели? Редкая, проприетарная, узколокальная или недавно опубликованная информация создаёт более сильное давление в пользу извлечения.

Последствия ошибки

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

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

Диагностический / решающий метод

Очень простой триггер извлечения может быть реализован без машинного обучения.

def should_retrieve(
    time_sensitive=False,
    source_specific=False,
    evidence_required=False,
    private_context=False,
    knowledge_uncertain=False,
    conflicting_information=False
):
    return any([
        time_sensitive,
        source_specific,
        evidence_required,
        private_context,
        knowledge_uncertain,
        conflicting_information,
    ])

Для стабильного фактического вопроса:

should_retrieve()
# False

Для текущей цены акции:

should_retrieve(
    time_sensitive=True
)
# True

Для научного утверждения:

should_retrieve(
    source_specific=True,
    evidence_required=True
)
# True

Продакшн-системы могут принимать это решение гораздо более изощрённо. Классификатор может предсказывать необходимость извлечения. Модель может генерировать специальные управляющие токены. Маршрутизатор может классифицировать сложность запроса. Извлечение также может запускаться повторно во время генерации.

Реализация может меняться. Архитектурный вопрос остаётся тем же:

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

Доказательства

Концепция, предлагаемая здесь, согласуется с несколькими направлениями исследований в области извлечения.

Оригинальная архитектура RAG продемонстрировала полезность объединения параметрических знаний модели с внешними непараметрическими знаниями, особенно для задач, требующих знаний.

FLARE явно исследует активное извлечение во время генерации, включая извлечение, вызванное низкой уверенностью в предстоящем контенте.

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

Adaptive-RAG динамически выбирает между различными стратегиями в зависимости от сложности вопроса, включая ситуации, когда извлечение не требуется.

Термин «Триггер извлечения» используется здесь как системная абстракция над этим более широким семейством решений.

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

Реальные примеры

Рассмотрим ассистента поддержки, подключённого к документации компании.

"How do I reset my password?"

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

"What permissions does my account currently have?"

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

"Why was my production deployment rejected yesterday?"

Модель может понимать системы развертывания и объяснять распространенные причины. Но вопрос касается конкретного события. Требуются журналы, вывод CI/CD или записи об инцидентах.

Та же логика работает для веб-поиска.

"What is RAG?"

Общее объяснение может не требовать извлечения.

"What did the authors of Self-RAG specifically conclude about unnecessary retrieval?"

Теперь требуются доказательства из конкретного источника.

"What is the latest research on adaptive retrieval?"

Это также вводит требование актуальности. Основная тема не изменилась. Информационное требование изменилось.

Распространенные заблуждения и режимы отказа

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

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

Успешное извлечение означает, что ответ проверен. Извлечение предоставляет только возможные доказательства. Доказательства все еще должны быть релевантными, достаточно авторитетными и правильно интерпретированными.

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

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

Граничные случаи

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

"Who founded NVIDIA, and what is its market capitalization today?"

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

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

Ещё один пограничный случай — расхождение между источниками. Предположим, поиск возвращает три документа с несовместимыми утверждениями.

Триггер поиска уже сработал успешно: система распознала, что требуются внешние доказательства. Но задача ещё не выполнена.

Теперь система столкнулась с проблемой оценки доказательств. Именно здесь становится важной граница достоверности ответа.

Система может получить информацию и всё ещё не располагать достаточными доказательствами для сильного вывода.

Retrieval Trigger
≠
permission to answer

Триггер получает доказательства. Граница достоверности определяет, достаточны ли эти доказательства.

Ограничения

Триггер поиска — это концептуальная основа, а не универсальный алгоритм.

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

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

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

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

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

Что могло бы изменить этот ответ?

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

Модели также могут всё чаще объединять поиск, базы данных, инструменты и структурированные знания, не раскрывая разработчику приложения отдельного этапа RAG.

Эти изменения могут изменить способ реализации триггера. Они не обязательно устраняют лежащее в основе решение.

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

Реализация может исчезнуть из виду. Архитектурный вопрос остаётся.

Заключение

RAG начинается слишком поздно, чтобы объяснить всю проблему.

Прежде чем может произойти извлечение, система ИИ должна определить, необходимо ли извлечение. Это решение и есть Триггер извлечения.

Stable known fact
→ answer from model knowledge

Current fact
→ retrieve

Source-specific or evidence-dependent claim
→ retrieve and verify

Но более широкое следствие важнее. Надёжному ИИ нужен не просто доступ к знаниям. Ему нужен метод определения того, когда его текущих знаний недостаточно.

Model Knowledge
        ↓
Retrieval Trigger
        ↓
Runtime Knowledge / RAG
        ↓
Evidence
        ↓
Reasoning
        ↓
Answer Validity Boundary
        ↓
Answer

Триггер извлечения определяет, когда система должна искать доказательства. Граница достоверности ответа определяет, достаточны ли эти доказательства.

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

Первоисточники

Patrick Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020). Основополагающая работа по RAG, описывающая сочетание параметрической памяти модели с внешней непараметрической памятью.

Zhengbao Jiang et al., Active Retrieval Augmented Generation (2023). Представляет FLARE и активное извлечение во время генерации, включая извлечение на основе предсказанного контента с низкой уверенностью.

Akari Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (2023). Исследует адаптивное извлечение по требованию и саморефлексию вместо безусловного фиксированного извлечения.

Soyeong Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024). Динамически выбирает между отсутствием извлечения, одношаговым извлечением и более сложными стратегиями извлечения в зависимости от поступающего вопроса.