Ik ontdekte dat één enkele safety-gate-metriek een volledige dag aan downtime verborg in een door AI gegenereerde uitlegfunctie. Door "gate rejection" en "model load failure" als hetzelfde te behandelen, gaf de metriek een vals gevoel van gezondheid. Er werden vier afwijzingen en nul successen geregistreerd, maar het model draaide helemaal niet tijdens die periode — een fout die operators blind had kunnen maken voor een defect systeem.
Hoe de verwarring ontstond
De functie gebruikt een lokaal taalmodel om ruwe machine-logica om te zetten in menselijk leesbare zinnen. Een safety gate stroomafwaarts blokkeert elke output die de vooraf gedefinieerde regels overtreedt. In productie heb ik een enkele teller (counter) blootgesteld die telkens toenam wanneer de gate een zin afwees. Toen de drone vier AI-uitlegberichten logde, rapporteerde de teller vier afwijzingen en geen succesvolle outputs. Ik zag dit als de gate die zijn werk deed, en niet als een defecte functie.
Wat de teller verborg, was een fout in twee fasen:
- Model draait niet – Het model deelt een machine met de rest van het systeem. Om geheugen te besparen, laadt de host het model na inactiviteit uit.
- Timeout bij herladen – Toen er een nieuwe dreiging verscheen, probeerde het systeem ongeveer twee gigabyte aan modelgegevens opnieuw te laden. Het herladen overschreed de timeout van dertig seconden voor de respons, waardoor de aanvraag een timeout kreeg en een leeg antwoord retourneerde.
Omdat de teller een afwijzing door de gate en een door een timeout veroorzaakt leeg antwoord als hetzelfde evenement behandelde, toonde het dashboard een "werkende safety gate", terwijl de AI-functie in feite volledig uitgevallen was.
Waarom dit belangrijk is
In door AI gestuurde producten stoppen safety gates schadelijke of onzinnige output. Operators houden de fire rate van de gate in de gaten als een signaal voor de gezondheid van het systeem. Wanneer dat signaal versmelt met ongerelateerde foutmodi, wordt de metriek een stille leugen: het geeft gerust terwijl de dienst niet beschikbaar is.
De oplossing die de zichtbaarheid herstelde
Ik heb drie praktische wijzigingen doorgevoerd:
- Houd het model in het geheugen – De host is aangepast om het model in het geheugen te houden, waardoor de vertraging bij het herladen wordt geëlimineerd.
- Verleng de timeout – Het tijdvenster voor de respons is vergroot om incidentele trage laadtijden op te vangen.
- Splits de teller – De enkele "rejected by gate"-metriek is vervangen door vier afzonderlijke tellers: accepted, rejected, empty response en no answer.
De derde stap bleek doorslaggevend. In plaats van één enkel getal dat op beide manieren geïnterpreteerd kon worden, laat de uitsplitsing in vier delen zien of de safety gate actief is, of het model antwoordt, of dat de aanvraag het model helemaal niet heeft bereikt.
Afwegingen en tegenargumenten
Waar je voortaan op moet letten
Ontwikkelaars die AI-componenten uitrollen, zouden geaggregeerde tellers moeten controleren die veiligheidscontroles mengen met fouten op systeemniveau. Het opbouwen van een gedetailleerd geschiedenislogboek dat het pad van elke aanvraag vastlegt — start van het laden van het model, evaluatie door de gate, uiteindelijke uitkomst — biedt de forensische gegevens die nodig zijn om verborgen problemen op te sporen.
Kernpunt: Een enkele "gate-rejection"-metriek kan een defecte AI-service maskeren; het splitsen van die metriek in de afzonderlijke gebeurtenissen onthult de waarheid en voorkomt een vals gevoel van vertrouwen in een systeem dat in werkelijkheid niet werkt.