Een beslissingsworkload verplaatsen van Drex Max naar Gemini Decision 1

De overstap ziet eruit als een URL-wijziging, maar is dat niet. Drex Max v1.1 en Gemini Decision 1 nemen beide een blok context en een reeks getypeerde vragen als invoer en retourneren waarschijnlijkheden, dus de eerste middag van een migratie verloopt soepel: het veld hernoemen, de client naar een ander basispad laten wijzen, de testsuite draaien. Wat misgaat, is de tweede week, wanneer het volume binnenkomt en de twee factureringsmodellen het oneens blijken te zijn over wat je koopt. Dit is het verslag van wat er werkelijk moet veranderen, geschreven voor iemand met een werkende Drex Max v1.1-integratie die zich afvraagt of de opvallende score van het nieuwere model de overstap rechtvaardigt.

Begin met de eerlijke versie van de afweging. Op de Artificial Analysis Decision Index v2.1 scoort Drex Max v1.1 73 en Gemini Decision 1 scoort 66. Het oudere model wint, en het wint met 6,6 punten, waarvan het grootste deel in de component die 30% van de samengestelde score bepaalt. Als je workload documenttriage is, is de migratie een downgrade vermomd als een upgrade. Is het iets anders, lees dan verder, want de twee eindpunten lijken niet zo op elkaar als de vorm van hun requests doet vermoeden.

Het verschil dat op geen enkele ranglijst staat

Drex Max v1.1 geeft elke vraag een eigen budget van 131.072 tokens. Gemini Decision 1 geeft het hele verzoek 262.144 tokens, gedeeld tussen de invoer en elke vraag erin. Die twee zinnen beschrijven dezelfde productcategorie en leiden tot tegenovergesteld engineeringadvies.

Op Drex kost het stellen van 200 vragen 200 afzonderlijke budgetten, en het praktische plafond voor een verzoek is je snelheidslimiet in plaats van de context. Op Gemini Decision 1 passen 200 vragen en één contract van 200.000 tokens niet in hetzelfde verzoek: 200.000 tokens aan invoer laat 62.144 over voor de vragen en instructies, wat ruim voldoende is, maar een invoer van 250.000 tokens laat 12.144 over en het verzoek mislukt. Het plafond is reëel, het wordt gedeeld en het verschuift afhankelijk van hoeveel je verstuurt.

Dit is de enkele wijziging die het meest waarschijnlijk een werkende Drex-integratie breekt, omdat de faalmodus bij laag volume geen fout is. Een testsuite die 20 vragen over een document van 30.000 tokens afwerkt, past gemakkelijk in beide systemen. Productie, met een record van 180.000 tokens en 900 vragen, past in het ene en niet in het andere.

Wat de prijs per token verbergt

Drex Max v1.1 staat vermeld voor $0.03 per miljoen invoertokens als introductieprijs tegen een lijsttarief van $0.06, en Gemini Decision 1 kost $0.10. Geen van beide rekent kosten voor uitvoer. Kijk alleen naar die kolom en Drex is tussen 1.7 en 3.3 keer goedkoper, wat genoeg is om de discussie te beëindigen voor een team met een hoog volume.

Gemeten per taak wordt de kloof kleiner. Artificial Analysis plaatst Drex Max v1.1 op $103 per miljoen beslissingstaken en Gemini Decision 1 op $345, een verhouding van ongeveer 3,3 — de vergelijking op basis van de lijstprijs, niet de introductieprijs. De reden is dat Gemini Decision 1 meer tokens leest om tot een antwoord te komen. De gedeelde context is twee keer zo groot, en de componentscores suggereren dat het meer invoer per vraag verwerkt in plaats van minder. Per taak is de eerlijke verhouding ongeveer drie tegen één in het voordeel van Drex, en de introductiekorting is een tijdelijke omstandigheid die je tweede contractverlenging niet zal overleven.

Wat betekent dat de prijsvraag niet is "wat is goedkoper", maar "voor welk deel van je taken zou je 3× betalen om het goed te krijgen". Een regel die supporttickets naar een wachtrij routeert, is niets waard als hij 5% vaker fout zit dan het alternatief. Een regel die een contractclausule markeert voor juridische beoordeling, is het verschil onmiddellijk waard.

Documentafhandeling is waar de scores vandaan komen.

De samengestelde kloof van 6,6 punten is niet gelijkmatig verdeeld, en het migratieargument hangt ervan af dat je weet waar die kloof zit.

• AA-Paperclip, 30% gewicht — Drex Max v1.1 scoort 72,8 en slaagt bij 63% van de documenten direct op de alles-of-niets-test; Gemini Decision 1 scoort 56,8 en slaagt bij 33%. Deze ene component is verantwoordelijk voor het grootste deel van het verschil in de samengestelde score.

• When2Call, 10% — Drex 95,3 tegenover de 80,5 van Gemini, een verschil van 14,8 punten in de beoordeling van tool-calling, de grootste proportionele voorsprong die Drex waar dan ook heeft.

• EvalSafe-O*NET-AA, 15% — 88,3 tegen 87,1. Een afrondingsfout, en de enige veiligheidsgerelateerde test in de set.

• AA-Omniscience-Decision v1.1, 15% — Drex 60,3, Gemini 66,3. De voorsprong van Gemini, en de reden waarom de berichtgeving over de lancering met kennis begon.

• HLE-MultiChoice v1.1, 15% — Drex 46,6, Gemini 48,7. Een kleine marge, en beide modellen weigeren vaak genoeg in plaats van te gokken, waardoor de ruwe nauwkeurigheid ver onder deze cijfers ligt.

• AA-Symmetry v1.1, 15% — Drex 79,8 tegen 70,5. Of het antwoord standhoudt wanneer de vraag wordt herordend, opnieuw gelabeld en ontkend, wat op het bord het dichtst bij een stabiliteitstest komt.

Twee van die rijen zijn een tweede blik waard voordat je de knoop doorhakt. Bij documentextractie is Drex bijna twee keer zo betrouwbaar op een strikte metriek, en op symmetrie is het negen punten stabieler — wat betekent dat een op Drex gebaseerde pipeline minder antwoorden oplevert die omslaan wanneer dezelfde vraag anders wordt geformuleerd. Als je product één antwoord aan een gebruiker toont, is instabiliteit een bugmelding. Als het een stroomafwaartse score voedt, is instabiliteit variantie die je kunt wegmiddelen.

Snelheid, en het argument om beide te behouden

Drex Max v1.1 voert een taak uit in een mediaan van 283 milliseconden. Gemini Decision 1 doet dezelfde taak in 211. Het nieuwere model is sneller ondanks dat het meer werk verzet, en dat is de enige plek waar de migratie zonder voorbehoud helpt. Voor een synchrone controle vóór een actie die de gebruiker te zien krijgt, is 70 milliseconden niet niets.

Snelheid, prijs en nauwkeurigheid vallen zelden zo netjes in één richting samen, en hier is dat niet het geval: Gemini is sneller en slechter, Drex is langzamer en beter, en de kostenverhouding volgt de kwaliteitsverhouding in plaats van de latentieverhouding. Dat is het kenmerk van twee modellen met werkelijk verschillende ontwerpen, in plaats van dat het ene een strikte verbetering is.

Dat is de eigenlijke aanbeveling. Een beslissingsdienst met één scoringsmodel heeft één storingspunt en één mening. Beide draaien kost een tweede integratie en levert een signaal van onenigheid op: wanneer de twee modellen bij hoge betrouwbaarheid verschillende antwoorden geven, is het geval echt ambigu en zou het waarschijnlijk niet geautomatiseerd moeten worden. Dat patroon is oud, het is saai, en het vangt fouten op die geen enkele betrouwbaarheidsscore van één model zal vangen.

Het porteren van de oproep zelf

Het mechanische deel is kleiner dan het boekhoudkundige deel, met drie valkuilen die het vermelden waard zijn voordat je begint.

Ten eerste wordt Drex aangeroepen op /v1/systemone met de model-id vastgezet als drex-max; de alias drex-latest in de quickstart is niet de vastgezette id, en als je die gebruikt, verandert je model onder je voeten zonder een deploy. Gemini Decision 1 heeft het tegenovergestelde probleem: er is helemaal geen alias, alleen gemini-decision-1, en een verzoek met de naam gemini-decision wordt niet opgelost. Zet aan beide kanten vast, en behandel de model-id als een versienummer in je configuratie, niet als een constante in je broncode.

Ten tweede: mediabeperkingen vertalen zich niet. Drex Max v1.1 accepteert maximaal 8 afbeeldingen per verzoek. Gemini Decision 1 accepteert tekst, afbeelding, audio, video en PDF met limieten van 100 MB inline base64, 50 MB per PDF en 15 MB per HTTPS-URL, en weigert YouTube-links en gs://-URI's categorisch. Een Drex-pipeline die acht paginascans per verzoek bundelt, wordt een Gemini-pipeline die de pagina's ofwel als één PDF verstuurt, ofwel de batch opsplitst.

Ten derde: de vraagtypen lijken sterk op elkaar, maar de grenzen zijn niet identiek. Beide ondersteunen ja/nee, keuze en score. Gemini beperkt keuze en score tot 2–255 opties of niveaus en begrenst de ja/nee-waarschijnlijkheid tot 0,01–0,99, dus elke drempelwaarde die je Drex-code boven 0,99 heeft ingesteld, wordt na de port stilzwijgend nooit geactiveerd. Controleer elke drempelconstante in de codebase, niet alleen die in het configuratiebestand.

Waar een router past, en waar niet

OrcaRouter ondersteunt noch gemini-decision-1 noch drex-max. Beide zijn endpoints die alleen waarschijnlijkheden leveren, en een router zoals wij die inrichten, bedient chat-completions-doelen; iets anders beweren zou een beschikbaarheidsclaim zijn die bij het eerste verzoek al faalt. Waar de router in deze migratie voor dient, is het deel van de pipeline dat niet de scorer is.

Bijna elke beslissingsdienst wordt opgesteld voordat hij wordt gescoord: een generatief model extraheert kandidaatclausules, stelt de rubric voor of vat het dossier samen in de gedeelde context die het beslissingsmodel vervolgens leest. Die aanroep voor het opstellen is waar de keuze van de leverancier echt telt en waar een tweede contract pijn doet, en hij kan draaien over meer dan 200 modellen op één endpoint, waarbij de lijstprijs van de provider tegen 0% markup wordt doorgegeven. Routing DSL is hier belangrijker dan in een chatproduct, omdat aanroepen voor het opstellen heterogeen zijn — een goedkoop model voor triage, een lang-contextmodel voor het dossier van 180.000 tokens — en dat als regels uitdrukken is beter dan het als drie SDK's uitdrukken.

De eerlijke beperking: failover beschermt de aanroep voor het opstellen, niet de aanroep voor het scoren. Er is één plek waar je een beslissingsverzoek naartoe stuurt, en als die niet beschikbaar is, is je dienst niet beschikbaar. Als die afhankelijkheid onacceptabel is, is het bovenstaande tweemodelpatroon niet alleen een maatstaf voor nauwkeurigheid — het is de enige echte redundantie die beschikbaar is, want het is de enige manier om twee onafhankelijke scoring-endpoints te hebben.

Kortom

Stap over naar {{1}}Gemini Decision 1{{/1}} als je beslissingen de vorm van kennis hebben, als snelheid ertoe doet, of als je een gedeelde context wilt die groot genoeg is om een heel record in één keer te bevatten. Blijf bij {{2}}Drex Max v1.1{{/2}} als ze de vorm van documenten hebben — en het slagingspercentage zegt dat ze dat waarschijnlijk zijn, want documentextractie blijkt de meeste beslissingsworkloads te zijn zodra je ernaar kijkt. Draai beide als een fout antwoord duur is, en houd rekening met de kostenverhouding van drie op één voordat je iemand een besparing belooft. De migratie is een dag werk en een kwartaal hertunen; de beslissing om het te doen draait erom op welk onderdeel van de index je workload eigenlijk lijkt.