Enterprise RAG Challenge 3: wnioski z publicznych zgłoszeń

Viacheslav Dubrov

2026-01-11 · Zaktualizowano 2026-07-15 · 9 min · Agenci AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Enterprise RAG Challenge 3 (ERC3) polegało na tym, by agenci realizowali zadania biznesowe za pośrednictwem symulowanego firmowego API. Zamrożona tabela wyników jest wyjątkowo użyteczna, ponieważ wielu uczestników opublikowało więcej niż sam wynik: architekturę, zestaw modeli, koszty i informacje o błędach.

Przeanalizowałem te publiczne opisy, aby odpowiedzieć na węższe pytanie: jakie decyzje projektowe powtarzały się w najlepszych zgłoszeniach i które z nich są użyteczne poza tym benchmarkiem?

Na końcu powinieneś potrafić przekształcić te obserwacje w hipotezy projektowe dla własnych trace’ów agentów, a następnie przetestować je na swoim zestawie zadań i przy uwzględnieniu kosztów błędów.

Czym jest Enterprise RAG Challenge?

Enterprise RAG Challenge 3 to zakrojony na dużą skalę, crowdsourcingowy projekt badawczy, który sprawdza, jak autonomiczni agenci AI radzą sobie ze złożonymi zadaniami biznesowymi. W przeciwieństwie do statycznych benchmarków ERC3 działa na bazie Agentic Enterprise Simulation (AGES) — symulacji zdarzeń dyskretnych, która udostępnia realistyczne API przedsiębiorstwa.

Co sprawdza benchmark

W ramach AGES agenci pracują w fikcyjnej firmie obejmującej:

• Profile pracowników z określonymi umiejętnościami i działami
• Projekty z przypisanymi zespołami i relacjami z klientami
• Firmową wiki z regułami biznesowymi i hierarchiami uprawnień
• Ewidencję czasu pracy i operacje finansowe

Każde zadanie uruchamia odizolowaną symulację. Wiki firmy jest współdzielona, ale dane operacyjne różnią się między zadaniami, więc agent nie może rozwiązać całego zestawu przez zapamiętanie jednego stanu firmy.

Wyniki należy traktować jako migawkę

ERC3 udostępnia obecnie zarówno zamrożoną tabelę wyników konkursu, jak i publiczny benchmark, w którym po zakończeniu wydarzenia nadal pojawiały się kolejne uruchomienia. Te strony odpowiadają na różne pytania. Poniższe wartości opisują tabelę wyników konkursu w momencie jego zakończenia, a nie późniejsze sesje z najlepszymi rezultatami:

Na stronie aktywnego benchmarku mogą pojawiać się wyższe wyniki, ponieważ uwzględnia ona późniejsze uruchomienia. Dlatego zamrożona tabela wyników jest właściwym źródłem informacji o tym, co wygrało konkurs.

Rodzaje zadań

Zadania obejmują kilka obszarów umiejętności:

• Rozumowanie wieloetapowe, na przykład dopasowywanie umiejętności pracowników do przydziałów projektowych.
• Walidację uprawnień, na przykład blokowanie nieautoryzowanych zmian wynagrodzeń lub dostępu do danych.
• Niejednoznaczne zapytania, w tym prośby wielojęzyczne i parafrazy.
• Ścisłą zgodność formatu wyjściowego, w tym obowiązkowe linki do encji w odpowiedziach.

Co faktycznie wynika ze zgłoszeń

Publiczne opisy nie pozwalają na prosty werdykt w rodzaju „multi-agent wygrywa z single-agent”. Zgłoszenie z czwartego miejsca w konkursie było wprost prostą architekturą single-agent. Opisy potwierdzają jednak cztery węższe obserwacje:

1. Dekompzycja była użyteczna, gdy izolowała znaną granicę błędu. Zespoły rozdzielały sprawdzanie uprawnień, walidację kroków, wykonywanie kodu lub formatowanie odpowiedzi, a nie arbitralne „role agentów”.
2. Walidacja przesuwała się bliżej nieodwracalnych działań. Kilka systemów sprawdzało uprawnienia przed wykonaniem, analizowało poszczególne kroki lub zabezpieczało końcową odpowiedź.
3. Iteracja oparta na trace’ach miała znaczenie. Zwycięzca przekształcał nieudane uruchomienia w poprawki promptu za pomocą automatycznej pętli; inne zespoły również opisywały konkretne poprawki narzędzi i promptów.
4. Polityka kontekstu była decyzją architektoniczną. Zespoły testowały distillation, preloadowanie, retrieval i kompresję historii. Ich własne raporty różnią się w kwestii tego, czy kompresja pomaga, więc nie istnieje uniwersalna recepta.

Pięć pouczających podejść

Nie jest to pięć najlepszych podejść uporządkowanych według rankingu. Wybrałem je, ponieważ ich publiczne opisy pokazują pięć różnych sposobów budowania systemu: automatyczną rewizję promptu, etapy specjalistyczne, walidację każdego kroku, zabezpieczenia odpowiedzi oraz izolację plan-and-execute. Gdy interpretuję, dlaczego dane rozwiązanie mogło pomóc, zaznaczam, że jest to interpretacja, a nie ustalenie wynikające z tabeli liderów.

1. Ewolucyjne projektowanie promptów (zespół VZS9FL / @aostrikov)

Podejście z najwyższym wynikiem automatyzowało projektowanie promptu w pętli samodoskonalenia.

Zamiast ręcznie dostrajać produkcyjny prompt, zespół zbudował pętlę złożoną z trzech agentów, która przekształcała nieudane trace’y w propozycje zmian.

Pipeline trzech agentów:

Produkcyjny prompt był 80. automatycznie wygenerowaną wersją. Zespół opisuje tę pętlę jako proces analizowania nieudanych zadań, proponowania przyczyn i decydowania, które sugestie należy uwzględnić. Tabela wyników potwierdza końcowy rezultat i liczbę iteracji. Nie pozwala natomiast oddzielić wpływu automatyzacji od wpływu modeli, narzędzi i zgromadzonych informacji zwrotnych z benchmarku.

Stack: claude-opus-4.5 z Anthropic Python SDK i natywnym Tool Use.

2. Sekwencyjny pipeline multi-agent (zespół Lcnxuy / @andrey_aiweapps)

W tym zgłoszeniu zbudowano sekwencyjny workflow, w którym wyspecjalizowane komponenty odpowiadały za kontrole bezpieczeństwa, ekstrakcję kontekstu, wykonanie oraz formatowanie linków do encji.

Udokumentowane komponenty:

1. Security Gate Agent: kontrola przed wykonaniem, która przed uruchomieniem głównej pętli weryfikuje uprawnienia względem reguł wiki.
2. Context Extraction Agent: wyodrębnia kluczowe reguły z obszernych promptów i preloaduje dane użytkowników, projektów oraz klientów.
3. Execution Agent: planowanie w stylu ReAct z 5 wewnętrznymi fazami (tożsamość → wykrywanie zagrożeń → zbieranie informacji → walidacja dostępu → wykonanie).
4. LinkGeneratorAgent: osadzony w narzędziu odpowiedzi, analizuje kontekst i dodaje wymagane linki do encji.

LinkGeneratorAgent jest najbardziej uniwersalnym elementem tego rozwiązania. Umieszczenie go w narzędziu odpowiedzi sprawia, że wymaganie benchmarku — obowiązkowe linki do encji — staje się właściwością interfejsu, a nie kolejną instrukcją, o której model wykonawczy może zapomnieć.

Stack: atomic-agents oraz instructor frameworks z modelami gpt-5.1-codex-max, gpt-4.1 i claude-sonnet-4.5.

3. Rozumowanie sterowane schematem z walidacją kroków (zespół NLN7Dw / Ilia Ris)

Zespół połączył SGR z szybką inferencją i walidatorem uruchamianym dla każdego proponowanego kroku. Taka konstrukcja ułatwia wprowadzanie poprawek: odrzucasz błędny krok, zanim stanie się wywołaniem narzędzia, a następnie prosisz główny przepływ o jego przerobienie na podstawie komentarzy walidatora.

Kluczowe komponenty:

Zespół informował o uruchamianiu gpt-oss-120b na Cerebras z przepustowością do około 3000 tokenów na sekundę. Połączenie walidacji z inferencją o wysokiej przepustowości mogło ograniczyć koszt opóźnienia. Publiczny wynik nie pozwala oddzielić tego wpływu.

Stack: gpt-oss-120b na Cerebras oraz dostosowana implementacja SGR NextStep.

4. System wzbogacania i zabezpieczeń (zespół J8Gvbi / @mishka)

W tym zgłoszeniu do bazowego systemu SGR dodano nieblokujące podpowiedzi i wielopoziomowy system zabezpieczeń. Po otrzymaniu odpowiedzi API enrichery analizowały je i dodawały do późniejszego kontekstu wskazówki operacyjne.

Ponad 20 enricherów analizowało odpowiedzi API i wstrzykiwało wskazówki kontekstowe:

RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."

Trzystopniowy system zabezpieczeń:

Hybrydowa RAG dla wiki: Trzy strumienie wyszukiwania (regex, semantyczny i słów kluczowych) obsługiwały różne typy zapytań względem firmowej wiki.

Stack: qwen/qwen3-235b-a22b-2507 na frameworku SGR LangChain.

5. REPL plan-and-execute (zespół key_concept_parallel)

Ta architektura wyraźnie oddzielała planowanie od wykonania i wykorzystywała pętlę generującą kod. Pojawiła się w szerszej tabeli Ultimate, a nie w pierwszej piątce zamrożonego rankingu konkursowego. Jej publiczny opis jest jednak użyteczny, ponieważ pokazuje inną formę dekompozycji: izolację według fazy wykonania, a nie według roli biznesowej.

Różne modele obsługiwały różne zadania: jeden planował, drugi pisał kod w Pythonie, a osobny model decyzyjny wybierał dalsze działanie po każdym kroku.

Konfiguracja z wieloma modelami:

REPL kończenia kroków:

1. Planner tworzy krok wysokiego poziomu.
2. Model code-gen pracuje w świeżym kontekście modelu i pisze skrypt w Pythonie dla tego kroku.
3. Skrypt jest wykonywany w REPL przypisanym do zadania, którego zmienne zachowują się między krokami.
4. Model decyzyjny analizuje wynik i wybiera: kontynuować, przerwać albo przeplanować.

Ścieżka przeplanowania to pomysł, który można ponownie wykorzystać. Gdy krok kończy się częściowym błędem, model decyzyjny może zachować wykonaną pracę i przepisać tylko pozostałą część planu.

Wzorce powtarzające się w zgłoszeniach

Implementacje się różniły, ale w publicznych opisach regularnie pojawiały się te same problemy inżynieryjne.

Zarządzanie kontekstem było jawne

Żaden zespół nie mógł przekazać modelowi wszystkich reguł, rekordów i wcześniejszych kroków bez podjęcia decyzji dotyczącej polityki. Najciekawsza różnica dotyczyła miejsca, w którym poszczególne systemy filtrowały informacje.

Kompromis: NLN7Dw kompresował starsze tury, podczas gdy f1Uixf informował, że kompresja historii pogorszyła wyniki jego eksperymentów, więc zachował pełną rozmowę. Kompresję należy traktować jako decyzję opartą na pomiarach, a nie ustawienie domyślne.

Guardrails rozmieszczono przy różnych granicach błędów

Kilka zespołów umieszczało kontrole przed główną pętlą, w jej trakcie lub po jej zakończeniu. Mechanizmy te ograniczały różne rodzaje ryzyka i nie należy sprowadzać ich do jednego ogólnego „agenta krytyka”.

Wrappery narzędzi

Kilka zespołów zbudowało warstwy abstrakcji nad surowym API:

• Auto-pagination: wrappery przechodzą przez wszystkie strony i zwracają kompletny zbiór danych.
• Fuzzy normalization: „Willingness to travel” jest tłumaczone na pole API will_travel.
• Specialized reasoning tools: narzędzia think, plan i critic do kontrolowanego rozumowania.

Tryby błędów i zgłoszone przez zespoły poprawki strukturalne

W opisach wielokrotnie pojawiają się błędy na granicach API i polityk. Najbardziej uniwersalne poprawki przenosiły wymaganie do kodu albo do dedykowanego kroku walidacji:

Praktyczna kolejność wdrażania

ERC3 dotyczy jednej symulowanej firmy, a nie ogólnego badania ablacyjnego agentów. Traktuj go jako źródło hipotez projektowych, a następnie testuj te hipotezy na własnych trace’ach. Sensowna kolejność wdrażania wygląda następująco:

1. Najpierw zapewnij deterministyczną poprawność API. Dodaj automatyczną paginację endpointów listujących, normalizuj niejednoznaczne pola, waliduj schematy i generuj wymagane linki wewnątrz narzędzia odpowiedzi.
2. Dodaj kontrole przy rzeczywistych granicach ryzyka. Weryfikuj tożsamość i uprawnienia przed mutacją; waliduj krok przed wykonaniem tylko wtedy, gdy dodatkowe wywołanie modelu wychwytuje błędy warte swojego kosztu.
3. Zapisz politykę kontekstu. Zdecyduj, co jest preloadowane, wyszukiwane, kompresowane lub zachowywane bez zmian. Mierz tę politykę według wycinków zadań, a nie wyłącznie liczbą tokenów.
4. Przekształcaj nieudane trace’y w przypadki regresyjne. Klasyfikuj błąd, zmieniaj jeden mechanizm i ponownie uruchamiaj dotknięty nim wycinek. Automatyzuj rewizję promptu dopiero wtedy, gdy ta pętla działa niezawodnie.
5. Stosuj dekompozycję, gdy wyraźniej określa odpowiedzialność. Osobny komponent jest uzasadniony, gdy może przejąć odpowiedzialność za ograniczenie, korzystać z innego modelu lub narzędzia albo być testowany niezależnie — nie tylko dlatego, że „multi-agent” brzmi bardziej zaawansowanie.

W tych opisach niezawodne zgłoszenia uwidaczniały ukryte wymagania operacyjne w narzędziach, walidatorach i pętlach ewaluacyjnych.

Materiały referencyjne

• Enterprise RAG Challenge 3 — oficjalna strona
• Tabele wyników ERC3
• Benchmark: erc3-prod
• Informacje o wydaniach