Odzyskiwanie informacji z rodziny dowodów: zapewnienie, by kontekst RAG obejmował każdą część pytania

Pięć istotnych fragmentów może nadal pozostawić system RAG bez tego, czego potrzebuje całe pytanie. Paradoks znika, gdy okazuje się, że pytanie wymaga dowodów kilku różnych rodzajów. Wyobraźmy sobie kogoś, kto pyta, jak ustawienia aplikacji, tajne dane oraz uprawnienia przyznane zadań powinny być traktowane jako jedna konfiguracja. System wyszukiwania może zwrócić pięć doskonałych fragmentów na temat konfiguracji. Wszystkie są istotne, ale kontekst jest niekompletny, jeśli nie mówi nic o danych uwierzytelniających ani uprawnieniach.

To jest wrodzona słabość zwykłego metodu wyszukiwania top-k: ranking fragmentów pojedynczo nie informuje o tym, czy wszystkie niezbędne do odpowiedzi koncepcje są obecne.

Istotność to nie kompletność

Konwencjonalna ścieżka przetwarzania sortuje fragmenty i zachowuje pierwsze k z nich. Jest to w porządku, gdy jeden typ dowodów rozstrzyga kwestię, ale niewystarczające, gdy wymagana jest porównywalność, synteza lub kilka źródeł prawdy. Załóżmy, że pięć najlepszych fragmentów dotyczy tajemnic, ale odpowiedź wymaga również informacji o tożsamości ServiceAccount oraz uprawnień RBAC. Taki ranking jest sensowny na poziomie lokalnym, ale niekompletny w skali ogólnej.

Zwiększenie wartości top_k może pomóc, ale nie gwarantuje efektu. Większy kontekst może przynieść duplikaty, szumy, opóźnienia i dodatkowe koszty, bez żadnych gwarancji, że brakujący element się pojawi; ponadto, jeśli jedna grupa źródeł dominuje wśród kandydatów, może sama zajmować pierwsze 20 pozycji. W takim przypadku konieczna jest ograniczenie dotyczące zakresu objęcia.

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

Pobieranie rodzin dowodów dodaje tę ograniczającą zasadę, zachowując przy tym standardowe rankingi powiązań.

Co stanowi rodzinę

Rodzina dowodów to zbiór źródeł lub fragmentów tekstu, które mogą spełnić jedno z wymagań w danym pytaniu. Nie musi ona odpowiadać jednemu plikowi, etykiecie tematu, klastrum embeddingów, strategii wyszukiwania ani fragmentowi tekstu. Wyobraźmy sobie pytanie dotyczące bezpiecznego używania aplikacji: jego rodziny mogą to być routowanie Ingress, odkrywanie usług oraz zachowanie gotowości. Kilka dokumentów może należeć do rodziny „Usługi”, a jeden dokument może znajdować się w więcej niż jednej rodzinie, jeśli jego metadane i treść na to pozwalają.

Przygotuj dowody przed ostatecznym wyborem

Dla rozpoznanych struktur złożonych pytań projekt wykorzystuje deterministyczny planer dowodów. Koncepcyjnie jego wynikiem jest zbiór par (source_pattern, rescue_query), po jednej dla każdej rodziny potrzebnej w pytaniu:

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

Zakres jest celowo skromny, daleki od otwartego, autonomicznego planowania. Pytania o znaczeniu uzyskują przewidywalne zasady obsługi, natomiast wszystko inne jest przetwarzane za pomocą standardowych metod wyszukiwania. Kluczową cechą jest możliwość inspekcji: plan można przeanalizować i przetestować, dzięki czemu zespół, który odkryje brakującą rodzinę, może zlokalizować przyczynę w detekcji pytań, klasyfikacji źródeł, wyszukiwaniu kandydatów, ponownym sortowaniu, filtrowaniu lub końcowym skracaniu.

Rozpoznawanie przynależności

W tym studium przypadku przynależność do rodziny określana jest poprzez dopasowanie wyrażenia regularnego do nazwy źródła fragmentu tekstu:

pattern.search(str(chunk.source))

To jest deterministyczny kontrakt źródłowy, a nie klasterowanie semantyczne. Otrzymujesz dzięki temu precyzję i możliwość audytu: dokument pasuje do deklarowanej rodziny albo nie. Kosztem jest konieczność utrzymania, ponieważ zmienione nazwy plików oraz nowe kolekcje wymagają aktualizacji ich mapowania. Platforma wielokrotnego użytku powinna preferować wyraźne metadane nad wzorcami nazw plików:

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

Członkostwo sprowadza się wtedy do prostego sprawdzenia: chunk.metadata[„evidence_family“] == required_family.

Ratowanie brakujących rodzin

Po pierwszym etapie pobierania danych, proces liczy odpowiadające kandydaty dla każdej planowanej rodziny. Jeśli dana rodzina ma mniej elementów niż wymagane, uruchamiana jest celowana, rozproszona wyszukiwanka z zapytaniem służącym do jej uratowania:

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)
        )

Proces ratunkowy odbywa się wyłącznie w przypadku zaginionych rodzin, przy użyciu precyzyjnego zapytania powiązanego z umową rodziny, i przynosi kilka kandydatów, aby system ponownego rankowania mógł wybrać najlepszy z nich zamiast zadowolić się pierwszą dostępną opcją.

Ponowne rankowanie wybiera fragmenty, a nie rodziny

Planowanie decyduje, które rodziny muszą być uwzględnione, natomiast ponowne rankowanie określa, które dostępne fragmenty najlepiej odpowiadają na pytanie. Obie te funkcje są wzajemnie uzupełniające. System ponownego rankowania projektu łączy ważone sygnały:

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

Po ustaleniu rankingu kandydatów, selekcja uwzględniająca potrzeby rodziny rezerwuje najwyżej sklasyfikowane kandydaty odpowiadające wymaganiom każdej rodziny, a następnie wypełnia pozostałe miejsca według ogólnego rankingu:

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

Dlaczego fragmenty z jednego źródła mogą musieć pozostać razem

Wczesna wersja selekcji uwzględniającej kontekst rodzinny popełniła błąd, usuwając duplikaty na podstawie nazwy pliku. Wyobraźmy sobie dokument NetworkPolicy zawierający oddzielne części dotyczące zachowania domyślnego odrzucenia, zasad przychodzących i wychodzących ruchów, które są potrzebne do odpowiedzi na jedno złożone pytanie. Jeśli selekcja pozwala tylko jeden fragment na nazwę pliku, dwie niezbędne części znikają. Odpowiednia polityka usuwania duplikatów zależy od wymogów dotyczących dostarczanych informacji: powinna eliminować redundancję bez utraty kompletności danych, a jedno źródło może uzasadnione dostarczyć kilka uzupełniających się fragmentów, o ile każdy z nich spełnia inny wymóg.

Autoritatność versus istotność

Hałaśliwy artykuł badawczy może semantycznie przypominać pytanie z praktyki produkcyjnej, a ogólny przewodnik dotyczący paneli sterowania może zawierać wiele terminów z zapytań. Żadne z nich nie powinno zastępować zatwierdzonego podręcznika operacyjnego, który bezpośrednio odpowiada na to pytanie. Trzy rodzaje sygnałów powinny pozostać odrębne:

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

Jeden wynik nie powinien w sposób pasywny zastępować wszystkich trzech. Metadane autorytatywne muszą przetrwać procesy pobierania, wyszukiwania, fuzji, ponownego rankowania, przechowywania w pamięci cache oraz serializacji przez API, a nie tylko pozostać w bazie danych wektorowej.

Korygujący RAG bez utraty zakresu

Korygujący RAG ocenia pobrane fragmenty i może spróbować ponownie, gdy dowody wydają się słabe. Poprawia precyzję, ale może kolidować z planowaniem dowodów – wąski fragment, który sam w sobie wydaje się tylko częściowo istotny, może okazać się kluczowy dla syntezy wielu dokumentów. Jeśli CRAG go odrzuci, niezbędna grupa informacji znika z odpowiedzi. Aby temu zapobiec, implementacja traktuje zweryfikowany plan jako zasadę domeny: po filtrowaniu przez CRAG przeprowadza nowe, szerokie wyszukiwanie dla każdej zaplanowanej grupy i wybiera najsilniejszy, autorytatywny fragment. Kolejność ma znaczenie:

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

Zaawansowany projekt może wykorzystywać kilka poziomów planowania, wybranych w zależności od stopnia zrozumienia struktury pytania. Reguły deterministyczne nadają się do sytuacji o wysokim ryzyku lub regulowanych przypadków, gdzie ważna jest pełna audytowalność, natomiast bardziej elastyczne poziomy obejmują szersze dziedziny oraz nowe, złożone pytania, zawsze weryfikowane względem kontrolowanej taksonomii. Ten model jest również przenoszalny. Asystent finansowy, który pyta, czy transfer jest dozwolony i jaką zatwierdzenie wymaga, nie może zrekompensować braku danych konta pięcioma dobrze sformułowanymi zasadami, a planowanie rodziny sprawia, że te obowiązki stają się jawne.

Mierzenie zakresu

Sama istotność fragmentów nie może potwierdzić skuteczności systemu wyszukiwania uwzględniającego aspekty rodzinne. Prosta metryka odzyskiwania informacji o rodzinie ujawnia tę luki:

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

Zestawy testowe powinny obejmować uratowanie brakującej rodziny, przetrwanie poprzez ponowne sortowanie i za pomocą CRAG, ważne alternatywne źródła, uzupełniające fragmenty z jednego dokumentu, filtrowanie według autorytetów, wartość top-k niższą od liczby wymaganych rodzin oraz pytania, które nie powinny uruchamiać żadnego planu.

Sposoby awarii

• Planer, który uruchamia się zbyt szeroko, ponieważ ogólna fraza kluczowa aktywuje niespokrewniony plan. Należy używać kombinacji fraz oraz przypadków negatywnych.
• Niekompletny plan, w którym odzyskuje się deklarowane rodziny, ale pytanie nadal nie może zostać odpowiedziane. Brakujący element powinien znaleźć się zarówno w planie, jak i w testach regresji.
• Zmiany nazw źródeł, które powodują ciche zatrzymanie dopasowywania przez regular expressions. Testy kontraktu korpusu powinny potwierdzić, że planowane rodziny odnoszą się do rzeczywistych źródeł.

Zapytania ratunkowe są zbyt dopasowane do pytań oceniających. Należy je formułować wokół koncepcji z danej dziedziny i sprawdzać za pomocą parafraz oraz utajnionych próbek.

Zarezerwowania chroniące słabe dowody. Należy znaleźć kilka kandydatów na każdą grupę i ponownie je posortować przed zarezerwowaniem, nadal stosując weryfikacje autorytetu i minimalnej istotności.

Zbyt wiele grup w ramach dostępnego budżetu kontekstowego, co oznacza, że planista musi ustalać priorytety, łączyć kompatybilne dowody lub prosić o wyjaśnienia.

Model, który ignoruje część dowodów. Pełne pozyskanie informacji nie gwarantuje pełnej syntezy, dlatego prompty i weryfikacje wierności powinny odzwierciedlać plan.

Kolejne ulepszenia

Następnie warto przeprowadzić kilka ulepszeń. Umieść identyfikator rodziny w metadanych wersjonowanych fragmentów zamiast w nazwach plików. Stwórz taksonomię dowodów domenowych, która określa właścicieli oraz zasady autorytetu. W przypadku nietypowych pytań złożonych dodaj ustrukturyzowany planer z ścisłymi ograniczeniami i dostosuj minimalny próg istotności osobno dla każdej rodziny. Wybór może uwzględniać jednocześnie istotność, zakres, redundancję oraz budżet tokenów. Śledzenie powinno ujawniać plan oraz zakres obejmowany przez daną rodzinę. Oprócz zdolności przywoływania, zmierz precyzję planera, automatycznie sprawdzaj odchylenia w korpusie oraz zmienione źródła, a także porównuj planery oparte na regułach, klasyfikatorach i modelach LLM na zamkniętych próbkach. Wreszcie system powinien jasno informować, gdy nie uda się znaleźć wymaganej rodziny.

Celem nie jest komplikowanie procesu wyszukiwania dla każdego zapytania. Należy włożyć dodatkowe wysiłki tylko wtedy, gdy pytanie rzeczywiście wymaga kilku rodzajów dowodów. Metoda Top-k wybiera te fragmenty, które wydają się najbardziej istotne, natomiast metoda Evidence-Family dodaje drugie pytanie: czy ostateczny kontekst zawiera wszystkie rodzaje dowodów niezbędne do udzielenia kompletnej odpowiedzi? Relevancja określa, czy dany fragment jest przydatny, autorytet – czy można mu ufać, a zakres – czy odpowiedź może być kompletna. W praktyce RAG wymaga wszystkich trzech tych elementów.