AI-agent do sprawdzania TZ: rozwój, architektura, praktyka

Opracowanie agenta AI do audytu specyfikacji technicznych: doświadczenie praktyczne

Stworzenie narzędzia do automatycznej weryfikacji specyfikacji technicznych w oparciu o uczenie maszynowe wymaga jasnej strategii i zrozumienia typowych błędów. Eksperyment z opracowaniem takiego agenta pokazał, że kluczem do sukcesu jest wysokiej jakości zestaw treningowy i hybrydowa architektura, łącząca LLM z klasycznymi algorytmami.

Formowanie zestawu treningowego

Pierwszym i najbardziej krytycznym etapem było zbieranie i oznaczanie danych. Do trenowania modelu stworzono reprezentatywną bazę z 90 specyfikacji technicznych, podzielonych na trzy kategorie:

• Jakościowe TZ (30 przykładów), które pomyślnie przeszły rozwój z minimalnymi poprawkami.
• Problematyczne TZ (30 przykładów), prowadzące do konfliktów, przeróbek i przekroczenia terminów.
• Średnie TZ (30 przykładów), działające, ale zawierające niedociągnięcia wykryte w procesie.

Każda specyfikacja została uzupełniona szczegółową recenzją analityka, w której zaznaczono mocne i słabe strony. Aby zwiększyć różnorodność danych, do zestawu włączono zadania od różnych autorów i dla projektów z różnych dziedzin biznesowych (handel, produkcja, usługi).

Klasyfikacja typowych błędów w TZ

Analiza problematycznych TZ pozwoliła wyodrębnić systemowe błędy, które agent powinien nauczyć się wykrywać. Główne kategorie:

• Opis tylko pozytywnych scenariuszy. Wymaganie opisuje idealny proces pracy, ale ignoruje obsługę błędów, wyjątkowych i granicznych stanów.
• Niejednoznaczne sformułowania. Użycie subiektywnych lub rozmytych kryteriów, takich jak «szybko», «wygodnie», «elastycznie», bez konkretnych metryk.
• Niesprawdzalne wymagania. Niemożność stworzenia jednoznacznego przypadku testowego do weryfikacji wyniku.
• Wewnętrzne sprzeczności. Niespójność między różnymi sekcjami lub punktami jednej specyfikacji.
• Brak warunków granicznych. Nie określono zachowania systemu przy ekstremalnych lub niestandardowych danych wejściowych.

Przykłady transformacji niesprawdzalnych wymagań

Typowe sformułowania i sposoby ich konkretyzacji:

• Oryginalne: «Użytkownik powinien mieć możliwość elastycznego konfigurowania raportu».

Konkretne: «W raporcie powinny być dostępne ustawienia: okres (dowolny interwał), kontrahent (wybór wielokrotny). Ustawienia są zapisywane dla każdego użytkownika. Powinna być możliwość wyświetlenia raportu z grupowaniem według kontrahentów i według magazynów».

• Oryginalne: «System powinien poprawnie przetwarzać duże ilości danych».

Konkretne: «Przy ładowaniu 10 000 dokumentów z całkowitą liczbą wierszy 500 000 czas przetwarzania nie powinien przekraczać 15 minut. Zużycie pamięci operacyjnej — nie więcej niż 2 GB».

• Oryginalne: «Wszystkie formularze ekranowe powinny być dostosowane do jednolitego stylu».

Konkretne: «We wszystkich formularzach dokumentów przyciski "Zapisz" i "Przeprowadź" znajdują się w prawym górnym rogu. Kolor przycisków — zielony (R=0, G=128, B=0). Czcionka — Arial, 10pt».

Kryteria jakości i architektura agenta

Do oceny TZ ustalono listę kontrolną, obejmującą sprawdzanie celu biznesowego, kompletności scenariuszy, jednoznaczności, sprawdzalności, spójności i wykonalności wymagań. Te kryteria stanowiły podstawę promptów i logiki agenta.

Architektura rozwiązania to model hybrydowy, łączący Retrieval-Augmented Generation (RAG) i klasyfikację opartą na drzewach decyzyjnych.

• Komponent RAG odpowiada za kontekstowe wyszukiwanie. Podczas analizy nowego wymagania agent szuka semantycznie podobnych fragmentów w bazie wiedzy (90 oznaczonych TZ), co pozwala «przypomnieć» typowe błędy i ich kontekst.
• Drzewa decyzyjne są używane do kategoryzacji błędów na podstawie ustrukturyzowanych cech. Agent LLM wstępnie analizuje surowy tekst wymagania i wyodrębnia z niego cechy w ustrukturyzowanej formie (na przykład JSON), który jest następnie podawany na wejście klasyfikatora.

Realizacja techniczna analizy

Proces weryfikacji jednego wymagania obejmuje kilka kroków:

• Wyodrębnianie cech: Agent oparty na LLM (Analizator) przekształca tekstowe wymaganie w wektor cech. Na przykład:

* has_numbers: 1 (jeśli jest konkretna cyfrowa informacja) lub 0.

* has_negative_keywords: 1 (jeśli wymienione są warunki "jeśli", "w przeciwnym razie", "błąd") lub 0.

* boundary_conditions_mentioned: 1 (jeśli opisane są przypadki graniczne) lub 0.

* stopword_score: waga słów-znaczników subiektywności ("elastyczny", "intuicyjny").

• Klasyfikacja: Uzyskany ustrukturyzowany wektor cech jest przekazywany modelowi opartemu na drzewie decyzyjnym (na przykład z Scikit-learn), który przypisuje wymaganie do jednej z kategorii błędów lub oznacza je jako poprawne.
• Formowanie raportu: Agent generuje rozbudowany komentarz, wskazując typ potencjalnego problemu, jego lokalizację w tekście i rekomendacje do poprawy, oparte na analogiach z bazy wiedzy.

Takie rozdzielenie odpowiedzialności — LLM do zrozumienia sensu i wyodrębniania danych, a klasyfikator do ścisłej logicznej kategoryzacji — zapewnia przejrzystość i kontrolowalność procesu.

Co jest ważne

• Jakość danych decyduje o wszystkim. Bez reprezentatywnego i wysokiej jakości zestawu treningowego (co najmniej dziesiątki przykładów) nie można wyszkolić efektywnego modelu.
• Podejście hybrydowe jest skuteczniejsze. Kombinacja RAG do pracy z kontekstem i drzew decyzyjnych do jasnej klasyfikacji błędów daje bardziej niezawodny i interpretowalny wynik niż użycie tylko LLM.
• Skupienie na sprawdzalności. Kluczowym kryterium dobrej specyfikacji jest możliwość stworzenia jednoznacznego przypadku testowego. Wszystkie wymagania powinny być sformułowane mierzalnie i konkretnie.
• Automatyzacja rutyny. Agent nie zastępuje analityka, ale przejmuje rolę «świeżego oka», systemowo sprawdzając TZ na typowe błędy, co oszczędza czas i redukuje czynnik ludzki.
• Ciągłe uczenie. Bazę wiedzy agenta należy okresowo uzupełniać nowymi przykładami TZ i recenzjami, aby zwiększyć dokładność i dostosować się do nowych typów projektów.

— Editorial Team