Het artikel legt uit hoe een standaard LLM, specifiek GLM-5.3-Flash, kan worden getransformeerd tot een 'System One'-beslissingsmodel. In plaats van het genereren van volledige JSON-outputs, wat traag en kostbaar is, maakt deze methode gebruik van de kansverdeling over tokens in een enkele forward pass om direct een getypeerde keuze te maken.
De technische implementatie omvat:
- Het nummeren van opties in de prompt.
- Het gebruik van prefilling (
choice_index:) zodat het model direct een index produceert.
- Het analyseren van de log-probabilities van de specifieke optie-tokens via vLLM.
Belangrijkste conclusies:
- Prestaties: De nauwkeurigheid van GLM-5.3-Flash is vergelijkbaar met die van TypeSafe's Jev op diverse tekstdatasets.
- Multimodaliteit: Een significant voordeel is dat GLM-5.3-Flash beslissingen kan nemen op basis van afbeeldingen (bijv. gescande facturen), wat met Jev niet mogelijk is.
- Efficiëntie: Hoewel Jev goedkoper is in termen van token-kosten, biedt de oplossing via Privatemode voordelen op het gebied van latentie en privacy dankzij confidential computing.
De ontwikkelde Python-library is beschikbaar onder edgelesssys/privatemode-decisions.
Maak van GLM-5.3-Flash een Jev-achtig 'System One'-model
Samenvatting: In dit artikel laten we zien hoe een standaard LLM getypeerde beslissingen kan nemen in één enkele forward pass. Deze aanpak maakt het mogelijk om een LLM om te vormen tot een beslissingsmodel dat vergelijkbaar is met Jev.
We evalueren deze aanpak met GLM-5.3-Flash via Privatemode. Met behulp van een benchmark gebaseerd op openbare datasets tonen we aan dat deze opstelling resultaten levert die op één lijn liggen met TypeSafe's Jev, zowel wat betreft de nauwkeurigheid van de beslissingen als de snelheid. Als bonus maakt de opstelling met GLM-5.3-Flash getypeerde beslissingen op basis van afbeeldingen mogelijk, iets wat met Jev niet kan.
---
Waarom getypeerde beslissingen?
Veel van wat software aan een LLM vraagt, is in feite een beslissing. Voorbeelden hiervan zijn: "Welk team moet dit ticket afhandelen?" of "Hoor deze contractclausule thuis in de sectie aansprakelijkheid?".
In dergelijke gevallen vereist software doorgaans dat de reactie van de LLM een bepaald formaat volgt (zoals JSON) en dat het antwoord komt uit een vooraf gedefinieerde set, zoals "ja" en "nee". Hoewel LLM's dit met de juiste instructies betrouwbaar kunnen uitvoeren, vormen snelheid en kosten bij deze basisbenadering een probleem. Voor elke beslissing moet de LLM een volledig JSON-object schrijven, en een redeneermodel (reasoning model) kan honderden tokens genereren voordat het antwoord volgt. Bovendien is de betrouwbaarheid (confidence) van het model niet direct bekend, tenzij hier expliciet om wordt gevraagd. Deze factoren hebben ertoe geleid dat LLM's tot nu toe minder werden ingezet voor besluitvorming in scenario's met een hoog volume of een hoge doorvoersnelheid.
Gespecialiseerde beslissingsmodellen (of "System One"-modellen), zoals Jev en Laya, zijn ontworpen om dit op te lossen. Je voert een status en een set benoemde opties in, en je krijgt de gekozen optie terug samen met een betrouwbaarheidswaarde (kans) voor elke optie.
Een LLM omzetten naar een beslissingsmodel
We hebben onderzocht of een LLM kan worden omgevormd tot een beslissingsmodel met eigenschappen die vergelijkbaar zijn met die van Jev. Het antwoord is "ja".
Om onze aanpak te begrijpen, is het belangrijk om te weten hoe LLM's werken: een LLM schrijft nooit direct tekst. Gegeven een prompt produceert een LLM een kansverdeling over zijn volledige vocabulair van tokens. Bij tekstgeneratie wordt in het eenvoudigste geval het token met de hoogste kans gekozen als volgend token. Dit token wordt toegevoegd aan de prompt en het proces herhaalt zich. Dit is kostbaar en traag als je enkel een paar velden in een JSON-object wilt invullen.
Ons kerninzicht is dat het onnodig is dat de LLM het volledige JSON-object voorspelt, aangezien we de vorm hiervan al kennen. We zijn alleen geïnteresseerd in het getypeerde oordeel van de LLM voor een gegeven input.
We ontdekten dat het mogelijk is om prompts zo te formuleren dat we het getypeerde oordeel in één run van de LLM krijgen — zonder fine-tuning, direct met het model zoals het wordt geleverd. Dit verschilt van Jev en Laya, die specifiek voor dit doel zijn getraind. De basisstappen zijn als volgt:
- Nummer de opties: De status, de vraag en de output-opties worden als JSON in de prompt geplaatst, waarbij elke optie een index krijgt. De instructie vraagt het model om te antwoorden met
choice_index: gevolgd door een index.
- Vul het antwoord vooraf in (prefill): De prompt eindigt met
choice_index:. Hierdoor is het eerste token dat het model produceert direct een index naar de vooraf gedefinieerde opties.
- Evalueer de output: In plaats van alleen het token te lezen dat het model uitzendt, lezen we de kansen die het model aan alle optie-indexen heeft toegekend op die specifieke positie. Wanneer deze genormaliseerd worden over de opties, krijgen we een waarschijnlijkheid voor elk antwoord, waarna we simpelweg de meest waarschijnlijke kiezen.
Technische implementatie details
We hebben deze stappen geïmplementeerd voor GLM-5.3-Flash op vLLM (in Privatemode). We gebruiken het /chat/completions endpoint met continuefinalmessage en addgenerationprompt: false, zodat het model de vooraf ingevulde beurt van de assistent kan vervolgen in plaats van een nieuwe te starten. Dit maakt het ook mogelijk om afbeeldingen naast de tekst te versturen.
Voor vLLM en GLM-5.3-Flash merkten we dat de volgende details van belang zijn:
allowedtokenids: Deze functie van vLLM kan worden gebruikt om de output van de LLM te beperken tot alleen de toegestane opties. Alle andere tokens worden op $-\infty$ gezet. We gebruiken dit als een vangrail, maar het is geen strikte vereiste.logprobtokenids: De standaard toplogprobs is onvoldoende voor stap 3, omdat deze de distributie rapporteert voordat de beperking wordt toegepast. Hierdoor kunnen formatteringstokens (zoals een spatie) de bovenste plekken innemen, waardoor sommige opties van de lijst vallen. logprobtoken_ids lost dit op door exact de log-kans van de gevraagde token-id's terug te geven.- Token-id's van indexen: De token-id's van indexen zijn afhankelijk van de tokenizer van het model. Cijfers zijn niet altijd enkele tokens (GLM-5.3-Flash heeft bijvoorbeeld een enkel token voor "12"). Om model-specifieke tokenizers te vermijden, haalt de library de token-id's direct van de server via het
/completions endpoint met echo.
De implementatie is beschikbaar in de repository: edgelesssys/privatemode-decisions.
---
Benchmarkresultaten
We hebben onze aanpak geëvalueerd met een custom benchmark (edgelesssys/privatemode-decisions-benchmark). We vergeleken drie systemen op 29 openbare, gelabelde datasets: GLM-5.3-Flash op Privatemode, TypeSafe's Jev, en Convai's Laya.
De datasets bevatten tussen de 2 en 151 opties en dekken domeinen zoals intent routing, sentimentanalyse, topicclassificatie, moderatie, entailment, vraag-antwoord, juridische teksten en gescande documenten (zowel in het Engels als Duits).
Nauwkeurigheid (Accuracy)
Bij de vergelijking over 28 tekstdatasets zijn GLM-5.3-Flash en Jev nagenoeg gelijkwaardig.
- Beide systemen zijn nauwkeuriger op 10 datasets.
- Op de overige 8 datasets liggen ze binnen één procentpunt van elkaar.
- Het mediane verschil is 0,7 procentpunt in het voordeel van Jev, wat statistisch niet significant is ($p = 0,64$).
- Laya (een model met 421 miljoen parameters dat lokaal werd gedraaid) scoort op de meeste datasets aanzienlijk lager, met een mediaan verschil van 13 tot 15 procentpunten ($p < 0,001$).
Het aantal opties heeft een grotere invloed op de nauwkeurigheid dan de keuze tussen Jev en GLM-5.3-Flash. Bijvoorbeeld:
- TREC: Bij een verschuiving van 6 naar 42 opties daalt de nauwkeurigheid van Jev van 92,1% naar 85,6% en die van GLM-5.3-Flash van 91,2% naar 79,6%.
- MASSIVE: Bij een verschuiving van 18 scenario's naar 59 intents stijgen de scores van zowel Jev als GLM-5.3-Flash in beide talen.
Latentie en kosten
De latentie werd gemeten met één request per keer om wachtrijen uit te sluiten. Omdat Privatemode in de EU is gehost en Jev in de VS, varieerden de resultaten per locatie:
- Vanaf Duitsland: Privatemode antwoordde in 180 ms, Jev in 264 ms.
- Vanaf de VS: Jev antwoordde in 164 ms, Privatemode in 299 ms.
Wat betreft de kosten is Jev voordeliger. Eén miljoen beslissingen kosten ongeveer €62 met GLM-5.3-Flash en ongeveer €16 met Jev, gebaseerd op de lijstprijzen.
Het verschil in kosten komt grotendeels door de prijs per input-token en de manier waarop de vraag is verpakt. Jev voegt ongeveer 270 tokens aan vaste overhead toe en ongeveer 10 tokens per optie. GLM-5.3-Flash voegt ongeveer 55 tokens aan vaste overhead toe en ongeveer 20 per optie. Onder de 21 opties verstuurt GLM-5.3-Flash dus minder tokens dan Jev.
---
Multimodale beslissingen
Omdat GLM-5.3-Flash een visueel capabel model is, hoeft de input niet beperkt te zijn tot tekst. Een vraag kan worden vergezeld van afbeeldingen, zoals een gescande factuur, een foto van een beschadigd pakket of een screenshot.
De afbeelding wordt in dezelfde prompt geplaatst en het antwoord blijft een enkel token met een kansverdeling over de opties. Op de RVL-CDIP dataset (1.600 gescande zakelijke documenten in 16 klassen) bereikt GLM-5.3-Flash een nauwkeurigheid van 70,2%. Aangezien Jev en Laya alleen tekst verwerken, is GLM-5.3-Flash het enige van de drie systemen dat deze taak kan uitvoeren.
Een documentbeslissing is duurder dan een tekstbeslissing: de afbeelding voegt ongeveer 1.350 input-tokens toe, waardoor een miljoen documentbeslissingen ongeveer €270 kosten.
---
Mogelijkheden en limieten
Elk systeem loopt tegen grenzen aan bij een zeer hoog aantal opties.
- Laya: De optienamen delen een budget van 192 tokens.
- GLM-5.3-Flash (Privatemode): De implementatie rapporteert maximaal 128 vermeldingen in
logprobtokenids.
Om dit te omzeilen bij meer dan 128 opties (zoals bij CLINC150 met 151 opties), stuurt de library de vraag twee keer identiek. De kansen van de eerste 128 opties worden uit de eerste respons gelezen en die van de resterende 23 uit de tweede. Omdat beide requests dezelfde forward pass uitvoeren, is het resultaat gelijk aan een enkele request. Op CLINC150 bereikt GLM-5.3-Flash zo een nauwkeurigheid van 87,5%, tegenover 78,4% voor Jev.
---
Aanvullende bevindingen
Label-fouten
Sommige fouten in de resultaten liggen aan de labels in de datasets. Wanneer alle systemen het over een antwoord eens zijn, maar het label van de dataset verschilt, is het label vaak een van de twee verdedigbare antwoorden. In banking77 komt dit in ongeveer 17% van de gevallen voor (bijv. het verschil tussen getphysicalcard en orderphysicalcard).
De rol van redeneren (Reasoning)
Als controle hebben we GLM-5.3-Flash toegestaan om te redeneren voordat het antwoordt. Dit verhoogt de nauwkeurigheid in elke categorie van optie-aantallen (bijv. van 85,5% naar 89,9% bij twee opties). De prijs is echter hoog: het model schrijft honderden tokens per beslissing en de kosten stijgen naar ongeveer €350 per miljoen beslissingen.
Ter vergelijking: eenvoudige embedding similarity (zonder beslissingsmodel) scoort aanzienlijk lager, tussen de 45,9% en 72,8%.
Hernoemen van opties
Het vervangen van opties door synoniemen beïnvloedt de systemen verschillend. Op de boolq dataset, waar "true" en "false" werden vervangen door "correct" en "wrong", verloor GLM-5.3-Flash 20 punten, terwijl de andere twee systemen minder dan drie punten verloren.
---
Zelf bouwen
De ontwikkelde library is geschreven in Python en werkt met elk vLLM-backend endpoint. Het maakt gebruik van vLLM-extensies voor de OpenAI API, zoals allowedtokenids en logprobtokenids.
Bij gebruik van Privatemode worden deze beslissingen beschermd door confidential computing: data blijft versleuteld in het geheugen tijdens de verwerking, en de client verifieert het attesteringsrapport van de deployment voordat er data wordt verzonden.
Maak van GLM-5.3-Flash een Jev-achtig 'System One'-model
Samenvatting: In dit artikel laten we zien hoe een standaard LLM getypeerde beslissingen kan nemen in één enkele forward pass. Deze aanpak maakt het mogelijk om een LLM om te vormen tot een beslissingsmodel dat vergelijkbaar is met Jev.
We evalueren deze aanpak met GLM-5.3-Flash via Privatemode. Met behulp van een benchmark gebaseerd op openbare datasets tonen we aan dat deze opstelling resultaten levert die op één lijn liggen met TypeSafe's Jev, zowel wat betreft de nauwkeurigheid van de beslissingen als de snelheid. Als bonus maakt de opstelling met GLM-5.3-Flash getypeerde beslissingen op basis van afbeeldingen mogelijk, iets wat met Jev niet kan.
---
Waarom getypeerde beslissingen?
Veel van wat software aan een LLM vraagt, is in feite een beslissing. Voorbeelden hiervan zijn: "Welk team moet dit ticket afhandelen?" of "Hoor deze contractclausule thuis in de sectie aansprakelijkheid?".
In dergelijke gevallen vereist software doorgaans dat de reactie van de LLM een bepaald formaat volgt (zoals JSON) en dat het antwoord komt uit een vooraf gedefinieerde set, zoals "ja" en "nee". Hoewel LLM's dit met de juiste instructies betrouwbaar kunnen uitvoeren, vormen snelheid en kosten bij deze basisbenadering een probleem. Voor elke beslissing moet de LLM een volledig JSON-object schrijven, en een redeneermodel (reasoning model) kan honderden tokens genereren voordat het antwoord volgt. Bovendien is de betrouwbaarheid (confidence) van het model niet direct bekend, tenzij hier expliciet om wordt gevraagd. Deze factoren hebben ertoe geleid dat LLM's tot nu toe minder werden ingezet voor besluitvorming in scenario's met een hoog volume of een hoge doorvoersnelheid.
Gespecialiseerde beslissingsmodellen (of "System One"-modellen), zoals Jev en Laya, zijn ontworpen om dit op te lossen. Je voert een status en een set benoemde opties in, en je krijgt de gekozen optie terug samen met een betrouwbaarheidswaarde (kans) voor elke optie.
Een LLM omzetten naar een beslissingsmodel
We hebben onderzocht of een LLM kan worden omgevormd tot een beslissingsmodel met eigenschappen die vergelijkbaar zijn met die van Jev. Het antwoord is "ja".
Om onze aanpak te begrijpen, is het belangrijk om te weten hoe LLM's werken: een LLM schrijft nooit direct tekst. Gegeven een prompt produceert een LLM een kansverdeling over zijn volledige vocabulair van tokens. Bij tekstgeneratie wordt in het eenvoudigste geval het token met de hoogste kans gekozen als volgend token. Dit token wordt toegevoegd aan de prompt en het proces herhaalt zich. Dit is kostbaar en traag als je enkel een paar velden in een JSON-object wilt invullen.
Ons kerninzicht is dat het onnodig is dat de LLM het volledige JSON-object voorspelt, aangezien we de vorm hiervan al kennen. We zijn alleen geïnteresseerd in het getypeerde oordeel van de LLM voor een gegeven input.
We ontdekten dat het mogelijk is om prompts zo te formuleren dat we het getypeerde oordeel in één run van de LLM krijgen — zonder fine-tuning, direct met het model zoals het wordt geleverd. Dit verschilt van Jev en Laya, die specifiek voor dit doel zijn getraind. De basisstappen zijn als volgt:
- Nummer de opties: De status, de vraag en de output-opties worden als JSON in de prompt geplaatst, waarbij elke optie een index krijgt. De instructie vraagt het model om te antwoorden met
choice_index: gevolgd door een index.
- Vul het antwoord vooraf in (prefill): De prompt eindigt met
choice_index:. Hierdoor is het eerste token dat het model produceert direct een index naar de vooraf gedefinieerde opties.
- Evalueer de output: In plaats van alleen het token te lezen dat het model uitzendt, lezen we de kansen die het model aan alle optie-indexen heeft toegekend op die specifieke positie. Wanneer deze genormaliseerd worden over de opties, krijgen we een waarschijnlijkheid voor elk antwoord, waarna we simpelweg de meest waarschijnlijke kiezen.
Technische implementatie details
We hebben deze stappen geïmplementeerd voor GLM-5.3-Flash op vLLM (in Privatemode). We gebruiken het /chat/completions endpoint met continuefinalmessage en addgenerationprompt: false, zodat het model de vooraf ingevulde beurt van de assistent kan vervolgen in plaats van een nieuwe te starten. Dit maakt het ook mogelijk om afbeeldingen naast de tekst te versturen.
Voor vLLM en GLM-5.3-Flash merkten we dat de volgende details van belang zijn:
allowedtokenids: Deze functie van vLLM kan worden gebruikt om de output van de LLM te beperken tot alleen de toegestane opties. Alle andere tokens worden op $-\infty$ gezet. We gebruiken dit als een vangrail, maar het is geen strikte vereiste.logprobtokenids: De standaard toplogprobs is onvoldoende voor stap 3, omdat deze de distributie rapporteert voordat de beperking wordt toegepast. Hierdoor kunnen formatteringstokens (zoals een spatie) de bovenste plekken innemen, waardoor sommige opties van de lijst vallen. logprobtoken_ids lost dit op door exact de log-kans van de gevraagde token-id's terug te geven.- Token-id's van indexen: De token-id's van indexen zijn afhankelijk van de tokenizer van het model. Cijfers zijn niet altijd enkele tokens (GLM-5.3-Flash heeft bijvoorbeeld een enkel token voor "12"). Om model-specifieke tokenizers te vermijden, haalt de library de token-id's direct van de server via het
/completions endpoint met echo.
De implementatie is beschikbaar in de repository: edgelesssys/privatemode-decisions.
---
Benchmarkresultaten
We hebben onze aanpak geëvalueerd met een custom benchmark (edgelesssys/privatemode-decisions-benchmark). We vergeleken drie systemen op 29 openbare, gelabelde datasets: GLM-5.3-Flash op Privatemode, TypeSafe's Jev, en Convai's Laya.
De datasets bevatten tussen de 2 en 151 opties en dekken domeinen zoals intent routing, sentimentanalyse, topicclassificatie, moderatie, entailment, vraag-antwoord, juridische teksten en gescande documenten (zowel in het Engels als Duits).
Nauwkeurigheid (Accuracy)
Bij de vergelijking over 28 tekstdatasets zijn GLM-5.3-Flash en Jev nagenoeg gelijkwaardig.
- Beide systemen zijn nauwkeuriger op 10 datasets.
- Op de overige 8 datasets liggen ze binnen één procentpunt van elkaar.
- Het mediane verschil is 0,7 procentpunt in het voordeel van Jev, wat statistisch niet significant is ($p = 0,64$).
- Laya (een model met 421 miljoen parameters dat lokaal werd gedraaid) scoort op de meeste datasets aanzienlijk lager, met een mediaan verschil van 13 tot 15 procentpunten ($p < 0,001$).
Het aantal opties heeft een grotere invloed op de nauwkeurigheid dan de keuze tussen Jev en GLM-5.3-Flash. Bijvoorbeeld:
- TREC: Bij een verschuiving van 6 naar 42 opties daalt de nauwkeurigheid van Jev van 92,1% naar 85,6% en die van GLM-5.3-Flash van 91,2% naar 79,6%.
- MASSIVE: Bij een verschuiving van 18 scenario's naar 59 intents stijgen de scores van zowel Jev als GLM-5.3-Flash in beide talen.
Latentie en kosten
De latentie werd gemeten met één request per keer om wachtrijen uit te sluiten. Omdat Privatemode in de EU is gehost en Jev in de VS, varieerden de resultaten per locatie:
- Vanaf Duitsland: Privatemode antwoordde in 180 ms, Jev in 264 ms.
- Vanaf de VS: Jev antwoordde in 164 ms, Privatemode in 299 ms.
Wat betreft de kosten is Jev voordeliger. Eén miljoen beslissingen kosten ongeveer €62 met GLM-5.3-Flash en ongeveer €16 met Jev, gebaseerd op de lijstprijzen.
Het verschil in kosten komt grotendeels door de prijs per input-token en de manier waarop de vraag is verpakt. Jev voegt ongeveer 270 tokens aan vaste overhead toe en ongeveer 10 tokens per optie. GLM-5.3-Flash voegt ongeveer 55 tokens aan vaste overhead toe en ongeveer 20 per optie. Onder de 21 opties verstuurt GLM-5.3-Flash dus minder tokens dan Jev.
---
Multimodale beslissingen
Omdat GLM-5.3-Flash een visueel capabel model is, hoeft de input niet beperkt te zijn tot tekst. Een vraag kan worden vergezeld van afbeeldingen, zoals een gescande factuur, een foto van een beschadigd pakket of een screenshot.
De afbeelding wordt in dezelfde prompt geplaatst en het antwoord blijft een enkel token met een kansverdeling over de opties. Op de RVL-CDIP dataset (1.600 gescande zakelijke documenten in 16 klassen) bereikt GLM-5.3-Flash een nauwkeurigheid van 70,2%. Aangezien Jev en Laya alleen tekst verwerken, is GLM-5.3-Flash het enige van de drie systemen dat deze taak kan uitvoeren.
Een documentbeslissing is duurder dan een tekstbeslissing: de afbeelding voegt ongeveer 1.350 input-tokens toe, waardoor een miljoen documentbeslissingen ongeveer €270 kosten.
---
Mogelijkheden en limieten
Elk systeem loopt tegen grenzen aan bij een zeer hoog aantal opties.
- Laya: De optienamen delen een budget van 192 tokens.
- GLM-5.3-Flash (Privatemode): De implementatie rapporteert maximaal 128 vermeldingen in
logprobtokenids.
Om dit te omzeilen bij meer dan 128 opties (zoals bij CLINC150 met 151 opties), stuurt de library de vraag twee keer identiek. De kansen van de eerste 128 opties worden uit de eerste respons gelezen en die van de resterende 23 uit de tweede. Omdat beide requests dezelfde forward pass uitvoeren, is het resultaat gelijk aan een enkele request. Op CLINC150 bereikt GLM-5.3-Flash zo een nauwkeurigheid van 87,5%, tegenover 78,4% voor Jev.
---
Aanvullende bevindingen
Label-fouten
Sommige fouten in de resultaten liggen aan de labels in de datasets. Wanneer alle systemen het over een antwoord eens zijn, maar het label van de dataset verschilt, is het label vaak een van de twee verdedigbare antwoorden. In banking77 komt dit in ongeveer 17% van de gevallen voor (bijv. het verschil tussen getphysicalcard en orderphysicalcard).
De rol van redeneren (Reasoning)
Als controle hebben we GLM-5.3-Flash toegestaan om te redeneren voordat het antwoordt. Dit verhoogt de nauwkeurigheid in elke categorie van optie-aantallen (bijv. van 85,5% naar 89,9% bij twee opties). De prijs is echter hoog: het model schrijft honderden tokens per beslissing en de kosten stijgen naar ongeveer €350 per miljoen beslissingen.
Ter vergelijking: eenvoudige embedding similarity (zonder beslissingsmodel) scoort aanzienlijk lager, tussen de 45,9% en 72,8%.
Hernoemen van opties
Het vervangen van opties door synoniemen beïnvloedt de systemen verschillend. Op de boolq dataset, waar "true" en "false" werden vervangen door "correct" en "wrong", verloor GLM-5.3-Flash 20 punten, terwijl de andere twee systemen minder dan drie punten verloren.
---
Zelf bouwen
De ontwikkelde library is geschreven in Python en werkt met elk vLLM-backend endpoint. Het maakt gebruik van vLLM-extensies voor de OpenAI API, zoals allowedtokenids en logprobtokenids.
Bij gebruik van Privatemode worden deze beslissingen beschermd door confidential computing: data blijft versleuteld in het geheugen tijdens de verwerking, en de client verifieert het attesteringsrapport van de deployment voordat er data wordt verzonden.
Groetjes,