Live checks¶

Een live check houdt elke echte beurt van een agent aan een regel, terwijl de beurt plaatsvindt. Hij leest de vraag die iemand echt stelde, of het antwoord dat het model echt gaf, en beslist ter plekke of die beurt verder mag. Drie voorbeelden:

• "het antwoord bevat nooit een rekeningnummer" — een patroon op het antwoord;
• "de vraag gaat over onze producten" — een beoordelingsmodel op de vraag;
• "het antwoord blijft beleefd" — een beoordelingsmodel op het antwoord, achteraf, op een steekproef van beurten.

Je schrijft live checks op een versie van een agent, naast het model en de instructies. Elke aanroep die de agent noemt, wordt eraan gehouden, wie hem ook aanroept.

Live checks en evaluaties¶

Een evaluatie en een live check gebruiken dezelfde soorten checks, zodat een regel in allebei hetzelfde betekent. Ze verschillen in wanneer de regel wordt toegepast en in wat er gebeurt als hij niet klopt.

Gebruik een evaluatie om te beslissen of je een versie publiceert. Gebruik een live check om af te dwingen wat bij elke beurt moet kloppen, en om te zien hoe vaak een regel in de praktijk wordt gebroken.

Invoer of uitvoer¶

Een check kijkt naar een van twee plekken, zijn stage:

• input — wat de beller in dit verzoek schreef, voordat er een model wordt aangeroepen: de berichten van de gebruiker en de ontwikkelaar, het transcript van een opname, en de waarden die het verzoek invult in de prompt van de agent. Bijgevoegde bestanden, afbeeldingen en tooluitvoer die je terugstuurt, worden niet gelezen. Op een thread wordt alleen het nieuwe verzoek gelezen; de berichten die er al staan, worden niet opnieuw gecontroleerd.
• output — het antwoord van het model, als een ronde eindigt zonder om een tool te vragen. Twee soorten, "bevat geen tekst" en een patroon, lezen ook de tekst die een model naast een toolaanroep schrijft, zodat verboden tekst ook nooit bij een tool aankomt.

Blokkeren of achteraf beoordelen¶

Een check heeft ook een mode: wat er gebeurt als hij faalt.

• Blokkeren. De check beslist over de beurt zelf. Faalt een check op de invoer, dan krijgt de beller het standaardantwoord van de agent en wordt er geen model aangeroepen. Faalt een check op de uitvoer, dan wordt het antwoord achtergehouden. Een regelcheck kost microseconden; een beoordeelde check voegt één modelaanroep aan de beurt toe.
• Achteraf beoordelen. De check raakt de beurt nooit aan. Nadat de beurt is opgeslagen, geeft een beoordelingsmodel het antwoord een score, op een steekproef van beurten — één op de tien, tenzij je iets anders kiest — en de uitkomst wordt vastgelegd. Gebruik dit voor een kwaliteit die je wilt volgen in plaats van afdwingen, zoals de toon. Alleen een beoordeelde check op de uitvoer kan achteraf draaien, en alleen een beurt die op een thread is opgeslagen, wordt beoordeeld.

Een check die niet kan beslissen — het beoordelingsmodel antwoordde bijvoorbeeld niet op tijd — is errored. Een blokkerende check die niet kan beslissen, houdt de beurt tegen zoals een gefaalde check dat doet, tenzij je op die beoordeelde check on_error: "pass" zet: dan gaat de beurt door alsof de check slaagde, en de uitkomst wordt toch als errored vastgelegd en telt mee voor zijn melding. Daarmee ruil je veiligheid in voor beschikbaarheid; het past bij een check zoals de toon, nooit bij een check die vertrouwelijke gegevens bewaakt. Zonder die instelling laat een check een beurt nooit door omdat hij niet kon worden uitgevoerd.

Wat de beller ziet¶

Het antwoord houdt de vorm van de API van de leverancier die je aanroept, zodat een client die al omgaat met een weigering van een model of een afgekapt antwoord, ook met een live check omgaat. De antwoordheader X-Core-Check zegt welke check de beurt tegenhield, met een vaste code, en nooit het patroon, de verwachte tekst of de redenering van een beoordelaar.

Op POST /messages zijn een geweigerde vraag en een achtergehouden antwoord allebei stop_reason: "refusal". De naam van de check staat in de header, dus een naam bevat nooit iets geheims.

Streamen¶

Een blokkerende check op de uitvoer moet het antwoord lezen voordat de beller dat doet, en verandert daarom hoe een gestreamd antwoord binnenkomt:

• Alleen patrooncontroles. Het antwoord streamt zoals gewoonlijk, een paar tekens achter het model aan: Core houdt zoveel tekens achter als de langste treffer die een patroon toestaat (hooguit 200). Bij een treffer stopt het antwoord waar de treffer begint. Wat ervoor stond, is verstuurd, de treffer nooit, en de beurt eindigt incomplete met content_filter.
• Een andere blokkerende check op de uitvoer. Het antwoord komt in één keer binnen zodra elke check is geslaagd. De stream brengt intussen de samenvattingen van het redeneren en de toolaanroepen wel gewoon wanneer ze gebeuren, tenzij een check het antwoord opnieuw vraagt: dan wordt er niets van een ronde getoond, ook het redeneren niet, tot het antwoord is geslaagd.
• Checks op de invoer draaien voordat de stream begint; een beoordeelde vertraagt het eerste token met één aanroep van de beoordelaar.

Opnieuw vragen¶

Een blokkerende check op de uitvoer kan om herstel vragen: faalt het antwoord, dan vraagt Core het model opnieuw, hooguit het aantal pogingen van de agentversie (twee, tenzij je één tot drie kiest), en de beller krijgt het antwoord dat slaagde. Een voorbeeld: iemand vraagt de agent om te vloeken, het antwoord bevat een verboden woord, en de persoon ziet alleen "Dat mag ik niet doen."

• Het model ziet het afgewezen antwoord nooit. Core vertelt het de regel die het antwoord brak — de omschrijving van de check, of de verwachte tekst, of de naam — en dat het geen correctie mag noemen.
• Een nieuwe poging mag geen tools aanroepen, zodat een poging nooit een handeling herhaalt.
• Elke poging is een modelaanroep die telt op de sleutel waarmee de beurt draaide.
• Herstel werkt waar de beller nog niets van het antwoord heeft gezien: een beurt die niet streamt, een achtergrondrun, en een gestreamde beurt waarvan het antwoord in één keer komt. Streamde het antwoord al, dan kapt een gefaalde check het af.
• Een antwoord wordt alleen opnieuw gevraagd als elke blokkerende check waarvoor het faalde om herstel vraagt. Een check zonder herstel, of een die niet kon beslissen, houdt het antwoord meteen achter; een die niet kon beslissen met on_error: "pass" houdt niets achter en vraagt niets opnieuw.

De beoordelaar¶

Een beoordeelde check — juist formaat, beleefde toon, geen verzinsels of je eigen regel — wordt beslist door een model, dezelfde beoordelaar die een evaluatie gebruikt. Op de invoer leest hij de tekst van de beller en jouw regel; op de uitvoer leest hij het laatste bericht van de gebruiker, het antwoord en jouw regel. Hij leest nooit de instructies van de agent, zijn tools of de rest van het gesprek.

De console noemt de beoordelaar de rechter. De beoordelaar is het eigen beoordelingsmodel van de check, of anders het model waarop de beurt draaide. Een agent met een router als model moet bij elke beoordeelde check een beoordelingsmodel noemen, omdat een router per beurt een ander model kiest. Dat geldt ook voor een agent zonder eigen model die een beller met een router als model aanroept: een beoordeelde check zonder beoordelingsmodel kan dan niet beslissen, en een blokkerende houdt de beurt tegen, tenzij hij on_error: "pass" zegt. De tokens van de beoordelaar tellen op de sleutel waarmee de beurt draaide, net als de beurt zelf. Een sleutel die aan bepaalde regio's is gebonden, bereikt alleen een beoordelingsmodel in die regio's; daarbuiten kan de check niet beslissen, en bepaalt zijn on_error wat er gebeurt, zoals bij elke andere fout.

Wat er wordt vastgelegd¶

Elke check geeft per beurt één uitkomst: passed, failed of errored, met een score bij een beoordeelde check en een reden. De reden van een regel is een vaste zin; die van een beoordelaar is zijn eigen zin. De uitkomsten worden bij de beurt bewaard, verlopen met de beurt onder je bewaartermijn, en worden gewist met de persoon bij wie de beurt hoort.

• Per beurt. De uitkomsten van één beurt lees je terug via de API en op de pagina van het gesprek in de console.
• Slagingspercentages. Per check hoeveel uitkomsten slaagden, faalden of niet konden beslissen over een periode.
• Meldingen. Een check kan een melding geven als te veel van zijn laatste uitkomsten niet slaagden: hooguit één per check per dag, per mail of Slack, aan de beheerders van de organisatie.
• Events. Elke uitkomst die niet slaagde, is een event response.check_failed op je eventfeed en webhooks, met de naam van de check en nooit met tekst.

Waar checks gelden¶

Live checks horen bij de agentversie. Een wijziging eraan is een nieuwe versie, die je als concept kunt opslaan, met een evaluatie kunt meten en daarna publiceert, net als elke andere wijziging aan de agent.

• Elke beurt die de agent draait, past zijn checks toe: een aanroep die hem noemt, een agent die door een andere agent als tool wordt aangeroepen, een achtergrondrun, en een stap van een evaluatierun. Een evaluatierun past de blokkerende checks toe, herstel inbegrepen, zodat een suite meet wat een beller krijgt; de checks die achteraf beoordelen, slaat hij over.
• Een beurt die Core zelf start, waar niemand op een antwoord wacht — een workflowstap, een taak die op de achtergrond start — krijgt geen standaardantwoord als een check op de invoer faalt: de stap eindigt geweigerd en de taak start niet.
• Prompts en modelrouters hebben geen eigen checks.

Verder¶

De melding die een falende check geeft, stel je in bij Meldingen.