Warstwa 4: analizowanie wzorców i ciągłe ulepszanie agenta

Po sklasyfikowaniu pojedynczych błędów przypadków testowych możesz zastosować poprawki, ale nadal nie zauważyć znaczącej poprawy ogólnej wydajności agenta. Ten wynik często wskazuje na problem systemowy, a nie zbiór niepowiązanych ze sobą błędów.

Analiza wzorców umożliwia identyfikację powtarzających się sygnałów i wspólnych przyczyn źródłowych wśród wielu nieudanych przypadków testowych. Użyj analizy wzorców, aby skupić się na zmianach rozwiązujących grupy błędów naraz zamiast naprawiać każdy błąd osobno.

Ważne

Korzystaj z tych wskazówek po zakończeniu triage nieudanych i wdrożeniu zmian w celu naprawy. Analiza wzorców jest najbardziej przydatna po ocenie co najmniej pięciu awarii.

Kiedy stosować analizę wzorców

Analiza wzorców jest najskuteczniejsza, gdy zaobserwujesz jeden lub więcej z następujących przypadków:

  • Wiele awarii w tym samym zbiorze ewaluacyjnym.
  • Powtarzające się błędy o podobnych symptomach.
  • Ulepszenia poszczególnych przypadków testowych, które nie wpływają na ogólne wyniki.
  • Ulepszenia w jednym obszarze powodujące regresje w innym.

Usuwanie błędów pojedynczo jest nieefektywne w takich sytuacjach. Analiza wzorców umożliwia zidentyfikowanie wspólnych cech błędów, dzięki czemu można zająć się ich podstawową przyczyną.

Analiza koncentracji

Po klasyfikacji poszczególnych niepowodzeń poszukaj wzorców w całym zestawie.

Wzorzec Co oznacza Zalecana akcja
80% lub więcej niepowodzeń wynika z problemów z konfiguracją zestawu ewaluacyjnego Zestaw ewaluacyjny wymaga kalibracji, a nie zmian w konfiguracji agentów Wstrzymaj iterację agenta. Najpierw przeprowadź audyt i popraw jakość ewaluacji, a następnie ponownie uruchom testy, aby uzyskać czytelny wynik.
80% lub więcej niepowodzeń to problemy konfiguracyjne agenta w jednym obszarze (np. wszystkie związane z wiedzą) Systemowa luka w konfiguracji agenta Skoncentruj naprawę na tym obszarze. Ten problem jest często problemem architektonicznym (na przykład strukturą źródła wiedzy), a nie indywidualnymi poprawkami przypadków testowych.
80% lub więcej niepowodzeń jest spowodowanych ograniczeniami platformy Agent sięga ograniczeń platformy Oceń ponownie zakres agenta. Eskaluj do zespołu platformy. Dostosuj progi lub potraktuj dotknięte elementy jako znane ograniczenia, w razie potrzeby.
Niepowodzenia rozkładają się równomiernie na typy podstawowych przyczyn Nie ma pojedynczego problemu systemowego Kontynuuj działania naprawcze indywidualnie, korzystając z mapowania korekcyjnego.

Jak przeprowadzić analizę koncentracji

  1. Zlicz swoje sklasyfikowane błędy według typu przyczyny:

    • Problemy z konfiguracją ewaluacji
    • Problemy z konfiguracją agenta
    • Ograniczenia platformy
    • Niesklasyfikowane

  2. Oblicz udział procentowy dla każdego typu.

  3. Jeśli którykolwiek typ osiąga 80% lub więcej — co wskazuje na problem systemowy — napraw całą kategorię, a nie pojedyncze przypadki.

  4. Jeśli problemy z konfiguracją agenta koncentrują się w jednym sygnale jakości (na przykład pięć z sześciu to ugruntowanie wiedzy), ten wzorzec wskazuje na architektoniczną przyczynę źródłową.

Wzorce sygnałów przekrojowych

Gdy niepowodzenia obejmują wiele zestawów ewaluacyjnych, często wskazują na wspólną przyczynę. Poszukaj następujących wzorców:

Wzorzec Co to prawdopodobnie oznacza Co zbadać
Dokładność faktów i ugruntowanie wiedzy są niedostateczne Problem ze źródłem wiedzy (błędne, brakujące, niedostępne lub nieaktualne) Konfiguracja wiedzy, status indeksowania i świeżość treści
Zarówno wywołanie narzędzia, jak i routing wyzwalaczy zawodzą Problem z konfiguracją orkiestracji — tematy i narzędzia nie są poprawnie połączone Przejrzyj, jak tematy są kierowane do narzędzi. Sprawdź, czy istnieją rozłączone lub źle skonfigurowane przepływy.
Ton niedostateczny, ale dokładność wystarczająca Agent generuje poprawną odpowiedź, ale przedstawia ją w nieodpowiedni sposób Skup się na instrukcjach dotyczących stylu poleceń; dokładność infrastruktury jest solidna.
Zabezpieczenia są wystarczające, ale dokładność niedostateczna Agent może być nadmiernie ograniczony — zbyt ostrożny, odmawia udzielenia odpowiedzi, gdy powinien Przejrzyj instrukcje dotyczące bezpieczeństwa pod kątem zbyt szerokich ograniczeń, które blokują uzasadnione odpowiedzi.
Wszystkie elementy są wystarczające z wyjątkiem przypadków brzegowych Podstawowe zachowanie jest poprawne Skup się na zwiększaniu odporność w przypadkach brzegowych; to dobry znak.
Dokładność się poprawia, ale ton się pogarsza Konflikt instrukcji — nowe instrukcje dotyczące dokładności mogą wypierać wytyczne dotyczące tonu Przejrzyj ostatnie zmiany w poleceniach i miej na uwadze "budżet instrukcji".
Wiele zestawów oceny powoduje jednoczesne obniżenie wydajności Prawdopodobnie jedna przyczyna źródłowa o szerokim wpływie Sprawdź, czy wystąpiły ostatnie zmiany w poleceniach systemowych, aktualizacje źródeł wiedzy lub aktualizacje modelu systemowego platformy.

Co zrobić z wzorcami sygnałów krzyżowych

  1. Zidentyfikuj wspólną przyczynę: Jeśli dwa sygnały zawodzą jednocześnie, najprawdopodobniej korzystają z tej samej zależności, takiej jak źródło wiedzy, sekcja polecenia lub konfiguracja narzędzia.
  2. Napraw wspólną zależność: Nie naprawiaj każdego sygnału osobno.
  3. Uruchom ponownie oba zestawy ewaluacyjne: Po poprawce potwierdź, że oba zestawy wykazują poprawę.
  4. Jeśli tylko jeden się poprawi, sygnały nie mają wspólnego źródła. Klasyfikuj pozostałe awarie niezależnie.

Analiza trendów w kolejnych iteracjach

Śledź, jak wyniki zmieniają się przez kolejne iteracje, aby zrozumieć, czy strategia naprawcza działa.

Trend Interpretacja Akcja
Wyniki poprawiające się w kolejnych iteracjach Działania naprawcze są skuteczne Kontynuuj, aż zostaną osiągnięte ustalone progi.
Wyniki pozostają bez zmian mimo wprowadzonych zmian Działania naprawcze nie są skierowane na prawdziwą przyczynę problemu Ponowna analiza; klasyfikacja przyczyny źródłowej może być błędna.
Wyniki pogarszają się po wprowadzeniu zmiany Regresja — zmiana spowodowała awarię Cofnij zmianę. Zbadaj, co uległo regresji i dlaczego.
Jeden zestaw ewaluacyjny wykazuje poprawę, drugi pogorszenie Kompromis: poprawa jednego wymiaru negatywnie wpływa na inny Zbadaj sprzężenie, często spowodowane konfliktem instrukcji (patrz Podróż 3).
Wyniki wahają się między przebiegami (więcej niż +/-10% odchylenia) Niestabilność modułu oceniającego lub niedeterminizm agenta Najpierw zweryfikuj wiarygodność modułu oceniającego (patrz walidacja modułu oceniającego). Uruchamiaj co najmniej trzy razy w każdej iteracji.

Tworzenie przeglądu trendów

Po każdej iteracji zapisz:

  • Data
  • Dokonano zmiany
  • Zestaw oceny
  • Wynik przed
  • Wynik po
  • Delta

Ta informacja pomaga:

  • Potwierdź, że zbliżasz się do progów
  • Szybko wykrywaj regresje
  • Wykrywaj stagnacje wcześnie (Podróż 2)

Dokumentuj niepowodzenia

Ustrukturyzowane zapisy niepowodzeń budują wiedzę instytucjonalną w cyklach iteracji. Bez dokumentacji zespoły często powtarzają tę samą pracę badawczą.

Dlaczego dokumentować niepowodzenia

  • Przyspiesz klasyfikację w przyszłości: od razu rozpoznajesz znane wzorce błędów.
  • Buduj podstawę do eskalacji: zbieraj dane dotyczące ograniczeń platformy, aby przedstawić silniejsze argumenty zespołowi odpowiedzialnemu za platformę.
  • Umożliwiaj naukę zespołową: Log pomaga zapobiegać powtarzającym się dochodzeniom, gdy wiele osób pracuje nad tym samym agentem.
  • Śledź znane luki: nie zapomnij śledzić błędów sklasyfikowanych jako „nie można rozwiązać” ani „znane ograniczenie”.

Użyj szablonu dziennika awarii

Użyj szablonu dziennika awarii, aby rejestrować awarie w lekkim lub szczegółowym formacie, w zależności od wielkości zespołu i dojrzałości procesu.

Co rejestrować

Zarejestruj co najmniej następujące informacje dotyczące każdej przeglądanej awarii:

  1. Który przypadek testowy nie powiódł się.
  2. Jaki typ przyczyny podstawowej zaklasyfikowano?
  3. Co dokładnie poszło nie tak
  4. Co zmieniono, żeby to naprawić.
  5. Czy naprawa zadziałała.

W przypadku nierozwiązanych błędów należy również zapisać:

  • To, co próbowano do tej pory.
  • Dlaczego pozostaje nierozwiązane.
  • Kiedy ponownie przeanalizować (na przykład „po aktualizacji platformy X”).

Przepływ pracy ciągłego ulepszania

Użyj tej listy kontrolnej po każdym cyklu klasyfikacji i naprawy, aby potwierdzić zarejestrowanie wyników i następnych kroków.

Lista kontrolna po iteracji

Gotowe? Zadanie
✓ Zapisz wszystkie sklasyfikowane niepowodzenia w dzienniku błędów.
✓ Zidentyfikuj i zanotuj skupiska pierwotnych przyczyn.
✓ Sprawdź wzorce powiązań między sygnałami.
✓ Zarejestruj wyniki w celu śledzenia trendów.
✓ Dokumentuj znane ograniczenia wraz z obejściami.
✓ Zidentyfikuj priorytety następnej iteracji na podstawie pozostałych niepowodzeń.
✓ Ustaw harmonogram ponownego uruchamiania (które zestawy oceny, kiedy).

Kiedy zakończyć iterację

Zakończ iterację, gdy:

  • Wszystkie zestawy oceny są powyżej progów.
  • Udokumentowano znane braki.
  • Wyniki są spójne (< 5% odchylenia).
  • Brak nierozwiązanych problemów z konfiguracją agenta dotyczących sygnałów blokujących.

Nie zatrzymuj iteracji, gdy:

  • Nie analizowano uporczywych awarii.
  • Usunięto trudne przypadki testowe, aby osiągnąć progi.
  • Nie dokumentowano ograniczeń platformy.

Dowiedz się więcej w Określ, kiedy iteracja jest zakończona.

Następne kroki

  • Ostatnia aktualizacja o