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

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

Это встроенная слабость простого метода поиска top-k: ранжирование фрагментов по одному не позволяет определить, присутствуют ли в ответе все необходимые концепции.

Релевантность — это не полнота

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

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

Useful context = relevance + required-family coverage + trusted provenance - noise

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

Что считается семьей

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

Планируйте доказательства перед окончательным выбором

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

def evidence_plan(question: str):
    # Returns list of (family_pattern, rescue_query) tuples
    # for recognized composite question shapes
    if asks_about_workload_identity(question):
        return [
            (SECRET_SOURCE_PATTERN,      "Kubernetes Secret credentials Pod"),
            (SERVICE_ACCOUNT_PATTERN,    "Pod ServiceAccount workload identity"),
            (RBAC_SOURCE_PATTERN,        "RBAC least privilege RoleBinding"),
        ]
    return []  # unknown shapes continue through normal retrieval

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

Определение принадлежности

В примере исследования принадлежность к семье определяется путем сопоставления регулярного выражения с именем источника фрагмента:

pattern.search(str(chunk.source))

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

{
  "source": "security-policy.pdf",
  "document_id": "doc-123",
  "chunk_index": 17,
  "evidence_family": "access-control",
  "authority_tier": "official",
  "version": "2026-07"
}

Участие тогда сводится к поиску: chunk.metadata[“evidence_family”] == required_family.

Восстановление отсутствующих семей

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

for family_pattern, rescue_query in plan:
    matches = [c for c in candidates if family_pattern.search(c.source)]

    if len(matches) < desired_candidate_count:
        # Targeted rescue — bounded, not an open retry loop
        rescued = sparse_search(rescue_query, top_k=wide_limit)
        candidates.extend(
            c for c in rescued if family_pattern.search(c.source)
        )

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

Переупорядочивание выбирает варианты, а не семьи

Этап планирования определяет, какие семьи должны быть учтены, а этап переупорядочивания — какие из доступных вариантов наилучшим образом отвечают на поставленный вопрос. Эти этапы дополняют друг друга. Алгоритм переупорядочивания проекта объединяет взвешенную сумму различных факторов:

0.4 × normalized cross-encoder score
+ 0.3 × normalized retrieval score
+ 0.3 × lexical overlap
+ conditional exact-token bonus

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

selected = []

# Step 1: reserve best chunk per required family
for family in required_families:
    best_match = first_ranked_match(family, ranked_chunks)
    if best_match:
        selected.append(best_match)

# Step 2: fill remaining slots by global rank
selected.extend(c for c in ranked_chunks if c not in selected)

final_chunks = selected[:top_k]  # constrained top-k, not an alternative to ranking

Почему фрагменты из одного источника могут нуждаться в сохранении вместе

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

Авторитетность против релевантности

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

Relevance:  Does this passage discuss the question?
Authority:  Is this an approved source of truth?
Coverage:   Which required evidence obligation does it satisfy?

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

Корректирующий RAG без потери охвата

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

Retrieve broadly
→ shape and rerank candidates
→ reserve family coverage
→ grade evidence (CRAG)
→ restore validated required families
→ build context

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

Оценка охвата

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

Evidence-family recall = covered required families / total required families

# Example: Secret + RBAC covered, ServiceAccount missing
Evidence-family recall = 2/3 = 0.67

# This failure is invisible to standard chunk-relevance metrics

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

Возможные сценарии сбоев

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

Запросы на спасение слишком точно соответствуют вопросам оценки. Формулируйте их с учётом концепций домена и проверяйте с помощью парафразов и засекреченных примеров.

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

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

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

Следующие улучшения

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

Цель не в том, чтобы усложнять поиск ответов на каждый запрос. Необходимо прилагать дополнительные усилия только тогда, когда вопрос действительно требует нескольких видов доказательств. Метод Top-k определяет, какие фрагменты текста наиболее релевантны, а механизм поиска по семействам доказательств задает второй вопрос: содержит ли итоговый контекст все виды доказательств, необходимые для полного ответа? Параметр релевантности показывает, полезен ли фрагмент, параметр авторитетности — стоит ли ему доверять, а параметр полноты — может ли ответ считаться полным. Для практического использования RAG требуются все три этих фактора.