AI-agent pro kontrolu TZ: vývoj, architektura, praxe

Vývoj AI-agenta pro audit technických specifikací: praktické zkušenosti

Vytvoření nástroje pro automatickou kontrolu TZ na základě strojového učení vyžaduje jasnou strategii a pochopení typických chyb. Experiment s vývojem takového agenta ukázal, že klíčem k úspěchu je kvalitní trénovací sada a hybridní architektura, která kombinuje LLM s klasickými algoritmy.

Formování trénovací sady

Prvním a nejkritičtějším krokem byl sběr a označování dat. Pro trénování modelu byla vytvořena reprezentativní databáze z 90 technických specifikací, rozdělených do tří kategorií:

• Kvalitní TZ (30 příkladů), které úspěšně prošly vývojem s minimálními úpravami.
• Problémové TZ (30 příkladů), které vedly ke konfliktům, předělávkám a zpoždění termínů.
• Průměrné TZ (30 příkladů), funkční, ale obsahující nedostatky zjištěné během procesu.

Každá TZ byla doplněna podrobnou recenzí analytika, kde byly zaznamenány silné a slabé stránky. Pro zvýšení rozmanitosti dat byla do sady zařazena zadání od různých autorů a pro projekty z různých obchodních oblastí (obchod, výroba, služby).

Klasifikace typických chyb v TZ

Analýza problémových TZ umožnila identifikovat systematické chyby, které se agent musí naučit detekovat. Hlavní kategorie:

• Popis pouze pozitivních scénářů. Požadavek popisuje ideální pracovní postup, ale ignoruje zpracování chyb, výjimečných a hraničních stavů.
• Nejednoznačné formulace. Použití subjektivních nebo nejasných kritérií, jako „rychle“, „pohodlně“, „flexibilně“, bez konkrétních metrik.
• Neprověřitelné požadavky. Nemožnost vytvořit jednoznačný testovací případ pro ověření výsledku.
• Vnitřní rozpory. Nesoulad mezi různými částmi nebo body jedné TZ.
• Absence hraničních podmínek. Není uvedeno chování systému při extrémních nebo nestandardních vstupních datech.

Příklady transformace neprověřitelných požadavků

Typické formulace a způsoby jejich konkretizace:

• Původní: „Uživatel musí mít možnost flexibilně konfigurovat sestavu.“

Konkrétní: „V sestavě musí být dostupné nastavení: období (libovolný interval), odběratel (vícečetný výběr). Nastavení se ukládá pro každého uživatele. Musí být možnost zobrazit sestavu se seskupením podle odběratelů a podle skladů.“

• Původní: „Systém musí správně zpracovávat velké objemy dat.“

Konkrétní: „Při nahrání 10 000 dokumentů s celkovým počtem řádků 500 000 čas zpracování nesmí přesáhnout 15 minut. Využití operační paměti — ne více než 2 GB.“

• Původní: „Všechny obrazovkové formuláře musí být uvedeny do jednotného stylu.“

Konkrétní: „Ve všech formulářích dokumentů jsou tlačítka „Zapsat“ a „Provést“ umístěna v pravém horním rohu. Barva tlačítek — zelená (R=0, G=128, B=0). Písmo — Arial, 10pt.“

Kritéria kvality a architektura agenta

Pro hodnocení TZ byl definován kontrolní seznam zahrnující kontrolu obchodního cíle, úplnosti scénářů, jednoznačnosti, prověřitelnosti, konzistence a realizovatelnosti požadavků. Tato kritéria tvořila základ promptů a logiky agenta.

Architektura řešení představuje hybridní model, který kombinuje Retrieval-Augmented Generation (RAG) a klasifikaci na základě stromů rozhodování.

• RAG-komponenta odpovídá za kontextové vyhledávání. Při analýze nového požadavku agent hledá sémanticky podobné fragmenty v bázi znalostí (90 označených TZ), což umožňuje „vzpomenout si“ na typické chyby a jejich kontext.
• Stromy rozhodování se používají pro kategorizaci chyb na základě strukturovaných příznaků. LLM-agent předběžně analyzuje surový text požadavku a extrahuje z něj příznaky ve strukturované formě (například JSON), který je poté předán klasifikátoru.

Technická realizace analýzy

Proces kontroly jednoho požadavku zahrnuje několik kroků:

• Extrakce příznaků: Agent na základě LLM (Analyzátor) transformuje textový požadavek na vektor příznaků. Například:

* has_numbers: 1 (je číselná konkretizace) nebo 0.

* has_negative_keywords: 1 (jsou zmíněny podmínky „pokud“, „jinak“, „chyba“) nebo 0.

* boundary_conditions_mentioned: 1 (jsou popsány hraniční případy) nebo 0.

* stopword_score: váha slov-značek subjektivity („flexibilní“, „intuitivní“).

• Klasifikace: Získaný strukturovaný vektor příznaků je předán modelu na základě stromu rozhodování (například z Scikit-learn), který zařadí požadavek do jedné z kategorií chyb nebo jej označí jako korektní.
• Formování zprávy: Agent generuje rozšířený komentář, uvádějící typ potenciálního problému, jeho lokalizaci v textu a doporučení k nápravě založená na analogiích z báze znalostí.

Toto rozdělení odpovědnosti — LLM pro pochopení smyslu a extrakci dat a klasifikátor pro přísnou logickou kategorizaci — zajišťuje transparentnost a kontrolovatelnost procesu.

Co je důležité

• Kvalita dat rozhoduje o všem. Bez reprezentativní a kvalitně označené sady (alespoň desítek příkladů) nelze efektivně trénovat model.
• Hybridní přístup je efektivnější. Kombinace RAG pro práci s kontextem a stromů rozhodování pro jasnou klasifikaci chyb poskytuje spolehlivější a interpretovatelnější výsledek než použití pouze LLM.
• Zaměření na prověřitelnost. Klíčové kritérium dobré TZ — možnost vytvořit jednoznačný testovací případ. Všechny požadavky musí být formulovány měřitelně a konkrétně.
• Automatizace rutiny. Agent nenahrazuje analytika, ale přebírá roli „čerstvého pohledu“, systematicky kontroluje TZ na typické chyby, což šetří čas a snižuje lidský faktor.
• Neustálé učení. Bázi znalostí agenta je nutné pravidelně doplňovat novými příklady TZ a recenzemi pro zvýšení přesnosti a adaptaci na nové typy projektů.

— Editorial Team