Enterprise Advanced RAG · Artykuł 5 z 5
Praktyczny przewodnik po Enterprise Advanced RAG · Artykuł 5 z 5: umowy, weryfikacje oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.
To przewodnictwo pokazuje, jak odbudować ścieżkę od surowców do działającego systemu dla: . Skupiamy się na krokach realizowalnych w praktyce, wyraźnych sprawdzeniach oraz kodzie, który można bez problemu dodać do repozytorium, nie musząc zgadywać jego przeznaczenia. W fazie przeglądu należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić dany krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu systemu. Należy udokumentować zarówno prawidłowy przebieg procesu, jak i ścieżkę naprawczą. Próby ponownych działań, kontrole ludzkie oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
Poza Top-K: Wyodrębnianie rodzin dowodów dla kompletnych odpowiedzi RAG
Gdy pracujesz nad etapem Beyond Top-K Evidence-Family Retrieval, najpierw zapisz specyfikację: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolij małe, testowalne jednostki nad rozbudowane skrypty. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Zmierz stopień odzyskiwania informacji na ustalonej grupie pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe możliwości wyszukiwania.
Top-K Relevance Nie Jest Pełnością Dowodów
Gdy przechodzisz przez etap „Top-K Relevance Is Not”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć możliwość cichego, częściowego ukończenia zadania. Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolejkę z zadań oraz jak cofnąć ostatnie zadanie.
Useful context = relevance + required-family coverage + trusted provenance - noise
Czym jest rodzina dowodów?
Podczas prace nad etapem „Co to jest dowód”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z wersji demonstracyjnej do środowisk współdzielonych. Napisz krótki przewodnik: jak rotować klucze, jak opróżniać kolej z zadań, jak cofnąć ostatni proces pobierania danych. Podczas prace nad etapem „Co to jest dowód”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
Planowanie dowodów następuje przed ostatecznym wyborem
Najlepiej funkcjonuje etap planowania dowodów, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zanim rozszerzysz zakres pracy, zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia działań. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Zdefiniuj wersje zależności i zapisz hash obrazu, który został użyty do uruchomienia demonstracji. Powtarzalność jest ważniejsza od lokalnej wiedzy zespołu.
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
Jak rozpoznaje się przynależność do rodziny
Etap „Jak funkcjonuje członkostwo w rodzinie How” działa najlepiej, gdy traktuje się go jako mierzalną powierzchnię do analizy. Zapisz jeden idealny przykład działania, jeden przypadek niepowodzenia oraz notatkę dotyczącą cofnięcia działań, zanim rozszerzysz zakres badania. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć przypadki częściowego ukończenia bez informacji. Ustal wersje zależności i zapisz hash obrazu użytego do przeprowadzenia demonstracji. Reprodukowalność jest ważniejsza od lokalnej wiedzy eksperckiej.
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"
}
Brakujące rodziny uruchamia celowane działania ratunkowe
Faza The Missing Families Trigger Targeted funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zapisuj czasy wykonywania operacji oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Zaznacz wersje zależności i zapisz digest obrazu, który uruchomił demonstrację. Reprodukowalność jest ważniejsza od lokalnej wiedzy zespołu. Faza The Missing Families Trigger Targeted funkcjonuje najlepiej, gdy traktowana jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny przepis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres pracy. Zdokumentuj zarówno optymalną ścieżkę działania, jak i ścieżkę naprawczą. Próby ponownego wykonania, kontrolne punkty ludzkie oraz obsługa wiadomości błędowych stanowią część produktu, a nie elementy dodawane później.
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)
)
Reranking wybiera najlepszy fragment, a nie całą rodzinę
Aby w fazie Reranking Chooses the Best móc zmienić kod, należy najpierw zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Należy preferować małe, łatwe do przetestowania jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, powinno to wskazywać na konkretną odpowiedzialność, a nie na skomplikowaną strukturę procesów. Gdy budżet na to pozwala, należy dodać test dymny, który sprawdza kluczową ścieżkę w CI przy użyciu fixtur, a nie rzeczywistych, płatnych API.
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
Dlaczego fragmenty o tym samym źródle czasami muszą funkcjonować razem
Aby w fazie „Dlaczego czasami używa się tych samych fragmentów źródłowych”, określić należy dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed modyfikacją kodu. Operatorzy powinni móc ponownie uruchomić ten krok na podstawie znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij poszczególne elementy, zdefiniuj kryteria sukcesu i odrzuć przypadkowe, częściowe ukończenie zadania. Dodaj test sprawdzający kluczową ścieżkę w procesie CI, wykorzystując przy tym specjalne narzędzia, a nie rzeczywiste, płatne API, o ile pozwala na to budżet.
Autoritet i istotność to różne wskaźniki
W fazie Authority and Relevance Are należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zapisuj czas trwania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Gdy budżet na to pozwala, dodaj test dymny, który sprawdza kluczową ścieżkę w procesie CI przy użyciu fixitów, a nie rzeczywistych, płatnych API. W fazie Authority and Relevance Are należy zdefiniować dane wejściowe, osobę odpowiedzialną za dany krok oraz kryteria zakończenia przed zmianą kodu. Operatorzy powinni móc ponownie uruchomić ten krok od znanego punktu kontrolnego, bez konieczności zgadywania ukrytego stanu. Zdokumentuj zarówno ścieżkę pomyślną, jak i ścieżkę naprawczą. Próby ponownych działań, mechanizmy ludzkiej kontroli oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
Relevance: Does this passage discuss the question?
Authority: Is this an approved source of truth?
Coverage: Which required evidence obligation does it satisfy?
CRAG Should Correct Retrieval Without Breaking Coverage
Podczas pracy nad etapem CRAG Should Correct Retrieval najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok się nie powiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany proces. Zmierz stopień przywoływania informacji na ustalonej serii pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe możliwości wyszukiwania informacji.
Retrieve broadly
→ shape and rerank candidates
→ reserve family coverage
→ grade evidence (CRAG)
→ restore validated required families
→ build context
A General Architecture for Other RAG Projects
Gdy pracujesz nad Ogólną architekturą dla danej fazy, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj tę fazę jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć przypadkowe, częściowe ukończenie zadań. Zmierz stopień przywoływalności na ustalonej serii pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe możliwości wyszukiwania.
Pełny pipeline rodziny dowodów
Gdy przechodzisz przez etap The Full Evidence-Family Pipeline, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Obok wyników funkcjonalnych zapisz czas wykonywania oraz koszt tokena lub zapytania. Wczesna widoczność kosztów zapobiega nieoczekiwanym rachunkom, gdy ścieżka przechodzi z środowiska demonstracyjnego do wspólnych środowisk. Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolejkę oraz jak cofnąć ostatnie zaimportowanie.
Ten wzorzec jest stosowany w różnych domenach
Gdy przechodzisz przez etap The Pattern Transfers Across, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Przechowuj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności czytania całej struktury. Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolejkę oraz jak cofnąć ostatnie zadanie.
Ocena musi mierzyć stopień pokrycia rodziny
Gdy przechodzisz przez etap „Evaluation Must Measure Family”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponowne, kontrolne punkty ludzkie oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później w celu udoskonalenia. Zmierz stopień odzyskiwania informacji na ustalonej grupie pytań przed dostosowywaniem promptów. Częste zmiany promptów rzadko naprawiają słabe mechanizmy wyszukiwania.
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
Możliwe rodzaje awarii
Gdy przechodzisz przez etap identyfikacji możliwych błędów, najpierw zapisz specyfikację umowy: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego awarii. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, błąd powinien wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Napisz krótki przewodnik: jak rotować klucze, jak opróżnić kolejkę z zadań, jak cofnąć ostatnie zadanie.
Czego należy poprawić dalej
Gdy przechodzisz przez etap „Co chcesz poprawić”, najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nadaj nazwy poszczególnym elementom, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadania. Traktuj efekty jako synchronizację z otaczającym światem, a nie jako zamiennik wartości wyliczanych podczas renderowania.
Ostateczny wniosek
Podczas prace na etapie Final Takeaway najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z środowiska demonstracyjnego do współdzielonych środowisk. Napisz krótki przewodnik: jak rotować klucze, jak opróżniać kolejkę z zadań, jak cofnąć ostatni proces pobierania danych. Podczas prace na etapie Final Takeaway najpierw zapisz umowę: wymagane dane wejściowe, sygnał sukcesu oraz to, co dzieje się w przypadku częściowego niepowodzenia. Taka lista kontrolna zapewnia uczciwość późniejszych zmian w kodzie. Zdokumentuj zarówno ścieżkę prawidłowego działania, jak i ścieżkę naprawczą. Próby ponownych działań, kontrolne punkty ludzkie oraz obsługa wiadomości błędnych stanowią część produktu, a nie elementy dodawane później.
Linki do projektu
Etap Projekt Links funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres projektu. Wolno preferować małe, testowalne jednostki zamiast rozbudowanych skryptów. Gdy jakiś krok zawiedzie, awaria powinna wskazywać na konkretną odpowiedzialność, a nie na skomplikowany łańcuch operacji. Ustal wersje zależności i zapisz hash obrazu, który służył do uruchomienia demonstracji. Powtarzalność jest ważniejsza od lokalnej wiedzy zespołu.
Lista kontrolna operacyjna
Etap Listy kontrolnej operacyjnej funkcjonuje najlepiej, gdy traktowany jest jako mierzalna powierzchnia do analizy. Zapisz jeden idealny zapis działania, jeden przypadek awarii oraz notatkę dotyczącą cofnięcia zmian, zanim rozszerzysz zakres projektu.
Zachowaj konfigurację poza kodem aplikacji. Pliki środowiskowe, magazyny tajnych danych oraz flagi funkcjonalne powinny znajdować się w jednym miejscu, które operatorzy mogą sprawdzić bez konieczności analizy całej struktury.
Zapisz wersje zależne od Pin i zarejestruj hash obrazu, który uruchomił demonstrację. Reprodukowalność jest lepsza od wiedzy opartej na doświadczeniach zespołu.
Zapisz czasy wykonywania oraz koszt tokenów lub zapytań obok wyników funkcjonalnych. Wczesna widoczność kosztów zapobiega niespodziewanym rachunkom, gdy proces przechodzi z demonstracji do środowisk współdzielonych.
Napisz krótki przewodnik: jak rotować klucze, jak opróżniać kolejki zadań, jak cofnąć ostatni proces importu.
Traktuj ten etap jako umowę pomiędzy danymi wejściowymi a zweryfikowanymi wynikami. Nazwij wszystkie pliki, zdefiniuj kryteria sukcesu i odrzuć ciche, częściowe ukończenie zadań.
Zanim przejdziesz do wyższych wersji stacku, zamroź wersje, stwórz „złoty zapis” dla kluczowych ścieżek oraz potwierdź kroki cofania. Środowiska współdzielone wymagają ograniczeń szybkości, weryfikacji przynależności oraz jasnego odpowiedzialnego za rotację sekretów. Wolisz nudną niezawodność od pomysłowych, jednorazowych demonstracji.
Uwagi dotyczące partii 22eaeeb42c59: unikaj przechowywania kluczy dostawcy w repozytorium, ustaw ograniczenie liczby tokenów na sesję oraz przechowuj transkrypcje obok plików testowych, aby późniejsze zmiany modeli pozostały porównywalne.
Literatura pokrewna
- Praktyczne notatki: Ponad prostymi agentami – inżynieria DeepAgents dla przedsiębiorstw — Szczegółowy przewodnik po Praktycznych notatkach: Ponad prostymi agentami – inżynieria DeepAgents dla przedsiębiorstw: umowy, sprawdzenia oraz miejsca na kod do wstawienia dla zespołów wdrażających ten wzorzec.