Inzicht¶

Core legt bij elk verzoek vast wat er gebeurde. Vier onderdelen laten dat zien, elk voor een andere vraag: Gebruik zegt hoeveel er is verbruikt en wat het kostte, limieten begrenzen dat, Audit zegt wie wat deed en wat er is geweigerd, en Traces tonen wat er precies naar een model ging en wat terugkwam. Verbeteringen leest dat gebruik terug en stelt voor wat er aan je agents en skills beter kan.

Wanneer gebruik je dit¶

Het request-id dat Core bij elk antwoord teruggeeft, verbindt ze: met dat id vind je de auditgebeurtenissen, het verbruik en de trace van hetzelfde verzoek.

Gebruik¶

Core meet per verzoek wat er is verbruikt: modeltokens, embedding-tokens, toolaanroepen, zoekopdrachten, verwerkte en gecrawlde pagina's, afbeeldingen en de tijd dat een computer klaarstond. Elke regel noemt de sleutel, en de persoon als het verzoek een subject noemde. Werk dat in de console begint, staat op naam van de beheerder.

Verbruik wordt omgerekend naar euro met de prijs die voor de organisatie geldt (Modellen en routering). Opslag is een meter: je ziet hoeveel bytes er staan, en dat telt niet mee tegen een limiet.

Limieten¶

Een kostenlimiet per maand is een bedrag in euro per kalendermaand. Er zijn er twee:

• op een organisatie, over al haar sleutels samen. De beheerder van de organisatie erboven zet hem; een organisatie bepaalt haar eigen plafond niet.
• op een sleutel. De limiet van de organisatie geldt daarnaast altijd.

Is een limiet bereikt, dan antwoordt Core op een nieuwe beurt 429. Een beurt die al liep, loopt af. Een achtergrondrun die de limiet bereikt, eindigt failed met de code usage_cap_exceeded en wordt niet hervat. Vanaf het begin van de volgende maand neemt Core nieuwe beurten weer aan. Per mail kun je een melding krijgen voordat de limiet is bereikt (Meldingen per mail).

Audit¶

Het auditspoor heeft twee delen:

• Beheer: wijzigingen aan de organisatie en haar sleutels, zoals aanmaken, hernoemen, opschorten, registreren en roteren. Dit blijft bewaard nadat een organisatie is verwijderd.
• Aanroepen: wat verzoeken deden: antwoorden, tooluitvoeringen, gebruikte prompts en skills, aangemaakte bestanden. Elke controle van de policy levert een gebeurtenis policy.decision op, ook als het verzoek is geweigerd, met de regel die besliste.

Daarnaast kan een product dat op Core is gebouwd zijn eigen gebeurtenissen aan het spoor leveren: wat er in het product gebeurde dat Core niet ziet, zoals een rol die erin werd toegekend. Elke gebeurtenis zegt haar origin: core, of product met de naamruimte en de naam van het product, zodat je alles wat één persoon deed op één plek leest. Lever als product alleen wat Core niet al zelf vastlegt (De eigen gebeurtenissen van je product leveren).

Het auditspoor bevat geen inhoud van gesprekken en geen inloggegevens. Het zegt dat iets gebeurde, door wie en met welke uitkomst. Een sleutel leest via de API alleen haar eigen aanroepgebeurtenissen.

Traces¶

Een trace is de vastlegging van één modelaanroep: het verzoek dat Core naar de provider stuurde, het antwoord, en een leesbare weergave daarvan. Eén beurt kan meerdere modelaanroepen doen, bijvoorbeeld bij toolrondes; elke aanroep heeft een eigen trace, met de tools die erna zijn uitgevoerd.

Traces bevatten de volledige invoer en uitvoer. Daarom gelden er eigen regels:

• Vastleggen staat per organisatie aan of uit (Modelaanroepen vastleggen).
• Traces vallen onder de bewaartermijn van de organisatie en kunnen een kortere eigen termijn krijgen.
• Het document van een trace lezen levert zelf een auditgebeurtenis op (trace.read).

Verbeteringen¶

Een verbeteranalyse leest hoe de agents en skills van je organisatie worden gebruikt en stelt concrete wijzigingen voor. Ze draait op een klok die je zelf kiest, kijkt naar de beurten, toolaanroepen en traces van een recente periode, en schrijft voorstellen. Een voorstel is één bevinding: wat er opviel, de cijfers erachter, een korte uitleg en, waar Core de wijziging zelf kan maken, een uitgewerkte wijziging die je in één keer toepast.

Elf controles in totaal, elk zoekt naar iets anders. Vier lezen gesprekken:

Twee controles lezen geheugen in plaats van gesprekken: ze maken van een feit dat meerdere mensen hebben een gedeeld geheugenrecord, en leren een skill uit wat de sessies van meerdere mensen gemeen hebben. Vijf nieuwere controles staan uit tot je ze aanzet (de nieuwere controles):

Een slankere agent wordt geprobeerd voordat hij wordt voorgesteld. Een proef voert de eigen evaluatie van de agent twee keer uit, een keer op de gepubliceerde versie en een keer op een concept met de wijziging, en het voorstel wordt alleen geschreven als de gewijzigde versie het niet slechter deed. Een proef gebruikt de echte tools van de agent: een tool die verstuurt, schrijft of boekt, doet dat tijdens de proef echt. Hij draait als een sleutel die jij kiest, wiens maandplafond het budget van de proeven is (Proeven).

Een voorstel staat open zolang niemand erover besliste. Je kunt het accepteren (je vindt het een goed idee, maar het is nog niet doorgevoerd), negeren (het komt een tijd niet terug, tenzij het probleem verdubbelt) of toepassen. Vindt een latere analyse het probleem niet meer, dan staat het voorstel op opgelost.

Toepassen maakt altijd iets nieuws. Een analyse schrijft voorstellen. Toepassen doet een persoon in de console, een applicatie met een sleutel, of de analyse zelf voor de soorten voorstellen waarvoor je organisatie dat koos (Toepassen zonder beoordeling). Core maakt dan een nieuwe versie van de agent, de prompt of de skill, of een nieuwe agent, via dezelfde route en met dezelfde controles als wanneer je die zelf maakt. Er wordt niets overschreven: wie een vaste versie gebruikt, houdt die. Alleen een verzoek om een nieuwe koppeling voert Core niet zelf door: die koppeling moet iemand bouwen.

Alles wat een model leest, is gepseudonimiseerd. Voor de controles die gesprekken lezen (de vier hierboven, Een werkwijze die meerdere agents herhalen en Een evaluatie uit echte gesprekken) leest een model een steekproef van gesprekken. Voordat het iets ziet, vervangt Core persoonsgegevens door plaatshouders zoals <PERSON_1>. Dat gebeurt altijd, wat de sleutels die de gesprekken voerden ook instellen; je kiest alleen welke soorten gegevens worden vervangen en hoe streng. De plaatshouders blijven in de voorgestelde tekst staan, en een wijziging met een plaatshouder past Core niet toe: je vervangt hem eerst.

Bij Steeds dezelfde eerste aanroep leest geen model: Core vergelijkt de toolaanroepen zelf. Het voorstel neemt het resultaat van de tool dan letterlijk over, maar alleen als dat resultaat hetzelfde was in de gesprekken van minstens drie verschillende mensen. Zo komt wat van één persoon is niet in een voorstel.

Gesprekken lezen kan alleen zolang traces aanstaan. Staan ze uit, dan leveren drie controles alleen cijfers, en slaan er drie zich helemaal over en schrijven niets: Steeds dezelfde eerste aanroep, Een werkwijze die meerdere agents herhalen en Een evaluatie uit echte gesprekken.

Analyses hebben een eigen model. Ze gebruiken het analysemodel, los van het hulpmodel dat in de console voorzetten schrijft: een analyse redeneert over tientallen gesprekken en vraagt een sterker model. Kies je er geen, dan geldt de standaard van de installatie. Is die er ook niet, dan leveren de drie controles die een model nodig hebben alleen cijfers, zonder uitleg en zonder wijziging; Steeds dezelfde eerste aanroep werkt zonder model en stelt nog steeds een wijziging voor. Core valt nooit terug op het hulpmodel.

Aanzetten is toestemming, en het kost geld. Analyses staan standaard uit. Wie ze aanzet, geeft toestemming dat het analysemodel de gesprekken van de organisatie gepseudonimiseerd leest. Elke analyse doet modelaanroepen, tot een maximum dat je zelf zet, en die tellen mee voor de kostenlimiet: is die bereikt, dan stopt de analyse. Wat Core daarbij naar het model stuurde, staat als trace bij je organisatie.

Toepassen zonder beoordeling¶

Een organisatie kiest per soort voorstel hoe ver een analyse die voorstellen zelf toepast, zonder dat iemand ze eerst leest: voorstellen (de standaard: de analyse stelt alleen voor), concept (ze slaat de wijziging op als concept, dat geen sleutel gebruikt tot een beheerder het publiceert), of publiceren (ze slaat het concept op en publiceert het meteen). Alleen een gedeeld geheugenrecord gaat direct van voorstellen naar publiceren, zonder concept. De tabel zegt wanneer elke soort merkbaar wordt:

Sommige soorten worden alleen voorgesteld, wat je ook kiest: een verzoek om een koppeling (er is niets toe te passen), een skill buiten gebruik, een nieuwe evaluatie, scenario’s voor een evaluatie en een slankere agent.

De analyse past toe als de organisatie. Er is geen sleutel en geen persoon bij betrokken. De analyse mag wat de capabilities van de organisatie toestaan, en elke regel uit de policy van de organisatie en van de organisaties erboven geldt. Omdat niemand de wijziging las, geldt de hele policy, ook waar een persoon in de console alleen aan de regiokeuzes ervan wordt gehouden.

Een weigering laat het voorstel open. Kan de analyse een voorstel niet toepassen, bijvoorbeeld omdat er nog een plaatshouder in de tekst staat, de agent intussen een nieuwere versie heeft of een regel van de policy het niet toestaat, dan verandert er niets. Het voorstel blijft open met de reden erbij, en een persoon beslist erover. Een voorstel dat iemand al accepteerde of negeerde, past een analyse nooit zelf toe.

Wat een analyse toepaste, is te herkennen. Zo'n voorstel staat op toegepast met de markering dat de analyse het deed, en het auditspoor legt het vast zoals een toepassing door een persoon. Elke analyse telt per controle hoeveel voorstellen ze toepaste en hoeveel ze open liet.

Terugdraaien gaat zoals bij elke nieuwe versie: zet de oude versie vast, of verwijder wat er is gemaakt. Er is niets overschreven.

Je kiest de soorten in de console of via de API.

Een klantorganisatie bekijken vanuit de organisatie erboven¶

Als partner wil je het verbruik van je klanten zien zonder bij elke klant apart in te loggen.

• In de console open je een klantorganisatie en lees je haar Gebruik en Audit. Op je eigen organisatie kies je bij Bereik voor Inclusief onderliggende om de hele tak op te tellen, met de kosten per organisatie. Geldt er een markup, dan staan Doorbelast en Betaald naast elkaar.
• Via de API leest een sleutel met management het verbruik en de auditgebeurtenissen van een organisatie eronder op /organisations/{id}/usage en /organisations/{id}/audit/events.
• Met voorbehouden houd je de gebruikscijfers of het auditspoor van aanroepen bij jou: de eigen beheerders van de klant zien ze dan niet. Een sleutel van de klant die haar eigen gegevens leest met GET /usage, GET /audit/events of GET /key merkt daar niets van. Een sleutel van de klant met management krijgt wel 403 op het verbruik en de auditgebeurtenissen van haar eigen organisatie onder /organisations/{id}/..., en bij voorbehouden sleutelbeheer op het wijzigen van sleutels.

Limieten horen bij één organisatie. De limiet van een bovenliggende organisatie is niet de som van de organisaties eronder.

Hoe het samenhangt¶

• Verbruik en audit worden toegeschreven aan een sleutel en, als het verzoek er een noemt, aan een persoon.
• Elke beslissing van de policy staat in het auditspoor.
• Een trace laat zien welke tools een beurt uitvoerde en welk model antwoordde, ook na een fallback of een keuze van een router.
• Een evaluatie meet een agent vooraf; gebruik, audit en traces laten zien wat er daarna in het echt gebeurde.
• Een verbeteranalyse leest dezelfde beurten en traces terug en stelt een nieuwe versie van een agent voor; met een evaluatie meet je of die versie beter werkt.

Verder¶

Tutorial: Bouw een agent die knowledge én tools combineert.