Відновлення інформації на основі доказів та сім’ї: забезпечення того, щоб контекст 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, менше за кількість необхідних родин, а також запитання, які не повинні активувати жодного плану.

Способи збою

• Планувальник, який активується занадто широко, оскільки загальний ключовий слово запускає непов’язаний план. Використовуйте комбінації фраз та негативні формулювання.
• Неповний план, у якому знаходяться оголошені родини, проте запитання все одно не може бути відповідь. Відсутнє поняття має бути включене як у план, так і у тести на регресію.
• Зміна назв джерел, яка призводить до тихого припинення збігу за допомогою регулярних виразів. Тести корпусу мають підтверджувати, що заплановані родини відповідають реальним джерелам.

Запити на порятунок надмірно пристосовані до запитань оцінки. Складайте їх навколо концепцій домену та перевіряйте за допомогою парафраз та закритих зразків даних.

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

Занадто багато груп для обмеженого обсягу контексту, що означає, що планувальник повинен визначати пріоритети, об’єднувати сумісні докази або просити уточнень.

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

Наступні покращення

Наступним кроком варто здійснити кілька оновлень. Необхідно зберігати інформацію про сім’ю у метаданих версійних частин замість у назвах файлів. Слід створити таксономію доказів для домену, яка вказує власників та правила авторитетності. Для незвичайних складних запитань потрібно додати структурований планувальник із суворими обмеженнями, а також окремо налаштувати поріг мінімальної релевантності для кожної сім’ї. При виборі можна брати до уваги релевантність, охоплення, Redundancy та обмеження кількості елементів. Відстеження має дозволяти бачити план та рівень охоплення сім’ї. Окрім рівня відтворення інформації, необхідно вимірювати точність планувальника, автоматично перевіряти зміни в корпусі даних та перейменовані джерела, а також порівнювати планувальники на основі правил, класифікаторів та ШІ на закритих даних для тестування. Нарешті, система має відкрито повідомляти про те, що необхідну сім’ю не вдалося знайти.

Мета не у тому, щоб ускладнювати пошук для кожного запиту. Йдеться про те, щоб докладати додаткових зусиль лише тоді, коли запит справді потребує кількох видів доказів. Метод Top-k визначає, які фрагменти є найбільш релевантними, а механізм пошуку за родинами доказів ставить друге запитання: чи містить кінцевий контекст усі види доказів, необхідні для повної відповіді? Показник релевантності визначає, чи є фрагмент корисним, показник авторитетності — чи можна йому довіряти, а показник охоплення — чи може бути відповідь повною. Для практичного використання RAG потрібні всі три показники.