Hoe train je een infrastructuur-LLM-agent om niet te liegen

Er is een interne, alleen-lezen LLM-agent gebouwd om infrastructuurvragen te beantwoorden zoals 'waarom retourneert de service een 502?'. Het gebruikte Go, zonder LangChain, en riep modellen DeepSeek-V4-Flash en Qwen3.6-27B-FP8 aan via een OpenAI-compatibele API. De eerste versie gebruikte een vrije ReAct-loop en produceerde antwoorden die formeel correct waren maar vaak misleidend. Bijvoorbeeld, toen een 502-fout werd veroorzaakt door een te grote responseheader bij de proxy, concludeerde de agent 'geen fout op applicatieniveau', waarbij de werkelijke oorzaak werd gemist. Vijf foutenklassen werden geïdentificeerd: verkeerde scope, verkeerde tijdsemantiek, verkeerde negatieve conclusies, verlies van bewijs, en ongecontroleerde herplanning. De oplossing was om de LLM in te bedden in een strikt applicatieframework. Toolaanroepen worden geregeerd door een uitgebreid contract x-agent dat bewijs, uitvoertype, versheid, negatieve semantiek en alleen-lezen status definieert. De planner bouwt eerst doelstellingen op (bijvoorbeeld symptom.http_502, route.edge_to_ingress) en een stopconditie: elke vereiste doelstelling moet worden opgelost of expliciet niet beschikbaar zijn. Een bewijsguard voorkomt dat de finalizer concludeert voordat alle doelstellingen zijn bereikt. Toolselectie gebeurt in fasen: policyfilter, lexicaal prefilter, LLM-rerank (top 8), vervolgens doelrelevantiepoort. Risicovolle intenties hebben deterministische preroutes. In de uiteindelijke evaluatie slaagden 44 van de 45 scenario's (29 van de 29 verplichte), elk twee keer uitgevoerd. De enige mislukte test was een optioneel capaciteitsrapportformaat. De agent blijft alleen-lezen; mensen beslissen over productiewijzigingen.