Flytta en beslutsarbetsbelastning från Drex Max till Gemini Decision 1

Portningen ser ut som en URL-ändring men är det inte. Drex Max v1.1 och Gemini Decision 1 tar båda emot ett kontextblock och en uppsättning typade frågor och returnerar sannolikheter, så den första eftermiddagen av en migrering går bra: byt namn på fältet, peka klienten mot en annan basväg, kör testsviten. Det som fallerar är den andra veckan, när volymen kommer och de två faktureringsmodellerna visar sig vara oense om vad du köper. Det här är redogörelsen för vad som faktiskt måste ändras, skriven för någon som har en fungerande Drex Max v1.1-integration och undrar om den nyare modellens toppsiffra motiverar bytet.

Börja med den ärliga versionen av bytet. På Artificial Analysis Decision Index v2.1 får Drex Max v1.1 73 poäng och Gemini Decision 1 får 66. Den äldre modellen vinner, och den vinner med 6,6 poäng, varav det mesta i komponenten som står för 30 % av sammansättningen. Om din arbetsbelastning är dokumenttriagering är migreringen en nedgradering utklädd till en uppgradering. Om den är något annat, fortsätt läs, eftersom de två ändpunkterna inte är så lika som deras förfrågningsformer antyder.

Skillnaden som inte finns på någon resultattavla

Drex Max v1.1 ger varje fråga en egen budget på 131,072 tokens. Gemini Decision 1 ger hela förfrågan 262,144 tokens, delade mellan indatan och varje fråga i den. De två meningarna beskriver samma produktkategori och leder till motsatta tekniska rekommendationer.

På Drex kostar 200 frågor 200 separata budgetar, och den praktiska övre gränsen för en begäran är din hastighetsbegränsning snarare än kontexten. I Gemini Decision 1 får 200 frågor och ett kontrakt på 200 000 token inte plats i samma begäran: 200 000 token indata lämnar 62 144 för frågorna och instruktionerna, vilket är bekvämt, men 250 000 token indata lämnar 12 144 och begäran misslyckas. Taket är verkligt, det är delat och det förflyttar sig beroende på hur mycket du skickar.

Detta är den enskilda ändring som mest sannolikt bryter en fungerande Drex-integration, eftersom felläget inte är ett fel vid låg volym. En testsvit som ställer 20 frågor till ett dokument på 30 000 tokens får bekvämt plats i båda systemen. Produktion, med en post på 180 000 tokens och 900 frågor, får plats i det ena men inte i det andra.

Vad priset per token döljer

Drex Max v1.1 listas till $0,03 per miljon indatatoken som lanseringspris mot ett listpris på $0,06, och Gemini Decision 1 ligger på $0,10. Ingen av dem tar betalt för utdata. Läser man bara den kolumnen är Drex mellan 1,7 och 3,3 gånger billigare, vilket räcker för att avsluta diskussionen för ett team med hög volym.

Mätt per uppgift minskar gapet. Artificial Analysis anger Drex Max v1.1 till $103 per miljon beslutsuppgifter och Gemini Decision 1 till $345, ett förhållande på omkring 3,3 — jämförelsen av listpris, inte lanseringspriset. Anledningen är att Gemini Decision 1 läser fler tokens för att nå ett svar. Dess delade kontext är dubbelt så stor och dess delpoäng tyder på att den skickar mer indata genom varje fråga snarare än mindre. Per uppgift är den ärliga skillnaden ungefär tre mot ett till Drex fördel, och lanseringsrabatten är en tillfällig omständighet som inte kommer att överleva din andra avtalsförnyelse.

Vilket innebär att prissättningsfrågan inte är ”vilket är billigare” utan ”vilken andel av dina uppgifter skulle du betala 3× för att få rätt”. En regel som dirigerar supportärenden till en kö är värd ingenting om den har fel 5 % oftare än alternativet. En regel som flaggar en avtalsklausul för juridisk granskning är värd skillnaden omedelbart.

Dokumenthantering är där poängen kommer ifrån

Det sammansatta gapet på 6,6 punkter är inte jämnt fördelat, och migrationsargumentet beror på att man vet var det finns.

• AA-Paperclip, 30 % vikt — Drex Max v1.1 får 72,8 och klarar 63 % av dokumenten direkt i allt-eller-inget-testet; Gemini Decision 1 får 56,8 och klarar 33 %. Den här enda komponenten står för större delen av skillnaden i sammansatt poäng.

• When2Call, 10% — Drex 95,3 mot Geminis 80,5, en skillnad på 14,8 punkter i bedömningen av verktygsanrop, det största proportionella försprånget Drex har någonstans.

• EvalSafe-O*NET-AA, 15 % — 88,3 mot 87,1. Ett avrundningsfel, och det enda säkerhetsnära testet i uppsättningen.

• AA-Omniscience-Decision v1.1, 15 % — Drex 60,3, Gemini 66,3. Geminis ledning, och anledningen till att dess lanseringsbevakning ledde med kunskap.

• HLE-MultiChoice v1.1, 15 % — Drex 46,6, Gemini 48,7. Liten marginal, och båda modellerna avstår hellre än gissar tillräckligt ofta för att den råa träffsäkerheten ska ligga långt under dessa siffror.

• AA-Symmetry v1.1, 15% — Drex 79,8 mot 70,5. Huruvida svaret står sig när frågan ordnas om, märks om och negeras, vilket är det närmaste man kommer ett stabilitetstest på tavlan.

Två av de raderna är värda en andra titt innan du bestämmer dig. När det gäller dokumentextraktion är Drex nästan dubbelt så tillförlitligt på ett strikt mått, och när det gäller symmetri är det nio punkter stabilare – vilket innebär att en Drex-baserad pipeline producerar färre svar som slår om när samma fråga formuleras annorlunda. Om din produkt visar ett enda svar för en användare är instabilitet en buggrapport. Om det matar in i en nedströms poäng är instabilitet varians som du kan medelvärdesbilda bort.

Hastighet, och argumentet för att behålla båda

Drex Max v1.1 kör en uppgift på median 283 millisekunder. Gemini Decision 1 kör samma uppgift på 211. Den nyare modellen är snabbare trots att den utför mer arbete, vilket är det enda stället där migreringen hjälper utan förbehåll. För en synkron kontroll före en användarvänd åtgärd är 70 millisekunder inte ingenting.

Hastighet och pris och noggrannhet sammanfaller sällan så här snyggt i en enda riktning, och här gör de det inte: Gemini är snabbare och sämre, Drex är långsammare och bättre, och kostnadsförhållandet följer kvalitetsförhållandet snarare än latensförhållandet. Det är kännetecknet för två modeller med genuint olika design snarare än att den ena är en strikt förbättring.

Vilket är den faktiska rekommendationen. En beslutstjänst som har en enda poängsättningsmodell har en enda felpunkt och en enda åsikt. Att köra båda kostar en andra integration och köper en oenighetssignal: när de två modellerna ger olika svar med hög konfidens är fallet genuint tvetydigt och bör förmodligen inte automatiseras. Det mönstret är gammalt, det är tråkigt, och det fångar fel som ingen enskild modells konfidenspoäng kommer att göra.

Portning av själva anropet

Den mekaniska delen är mindre än redovisningsdelen, med tre fallgropar värda att nämna innan du börjar.

Drex anropas på /v1/systemone med modell-id:t låst som drex-max; aliaset drex-latest i snabbstarten är inte det låsta id:t, och om du använder det ändras din modell under fötterna på dig utan en driftsättning. Gemini Decision 1 har det motsatta problemet: det finns inget alias alls, bara gemini-decision-1, och en begäran som anger gemini-decision kommer inte att gå att slå upp. Lås på båda sidor och behandla modell-id:t som ett versionsnummer i din konfiguration, inte som en konstant i din källkod.

För det andra översätts inte mediagränser. Drex Max v1.1 tar emot upp till 8 bilder per begäran. Gemini Decision 1 tar emot text, bild, ljud, video och PDF med gränser på 100 MB inline base64, 50 MB per PDF och 15 MB per HTTPS-URL, och avvisar YouTube-länkar och gs://-URI:er helt. En Drex-pipeline som samlar åtta sidavskanningar per begäran blir en Gemini-pipeline som antingen skickar sidorna som en enda PDF eller delar upp batchen.

För det tredje är frågetyperna snarlika, men gränserna är inte identiska. Båda har stöd för ja/nej, val och poäng. Gemini begränsar val och poäng till 2–255 alternativ eller nivåer och klämmer ja/nej-sannolikheten till 0,01–0,99, så alla tröskelvärden som din Drex-kod har satt över 0,99 utlöses aldrig utan varning efter portningen. Kontrollera varje tröskelkonstant i kodbasen, inte bara de i konfigurationsfilen.

Var en router passar in, och var den inte gör det

OrcaRouter tillhandahåller varken gemini-decision-1 eller drex-max. Båda är endpoints som endast ger sannolikheter, och en router av vårt slag ligger framför chat-completions-mål; att påstå något annat vore ett tillgänglighetspåstående som fallerar vid första förfrågan. Det routern är till för i den här migreringen är den del av pipeline som inte är scorern.

Nästan varje beslutstjänst utkastas innan den poängsätts: en generativ modell extraherar kandidatklausuler, föreslår bedömningskriterierna eller sammanfattar underlaget till det delade sammanhang som beslutsmodellen sedan läser. Det är i det anropet som leverantörsvalet faktiskt spelar roll och där ett andra avtal gör skada, och det kan köras över mer än 200 modeller på en och samma slutpunkt, med leverantörens listpris vidarebefordrat med 0 % påslag. Routing-DSL:en är viktigare här än i en chattprodukt, eftersom utkastanropen är heterogena – en billig modell för triage, en långkontextmodell för underlaget på 180 000 token – och att uttrycka det som regler är bättre än att uttrycka det som tre SDK:er.

Den ärliga begränsningen: failover skyddar anropet för utkastgenerering, inte anropet för poängsättning. Det finns en plats att skicka en beslutsförfrågan till, och om den är otillgänglig är din tjänst otillgänglig. Om det beroendet är oacceptabelt är mönstret med två modeller ovan inte bara en noggrannhetsåtgärd – det är den enda verkliga redundansen som finns, eftersom det är det enda sättet att ha två oberoende poängsättningsslutpunkter.

Slutsatsen

Byt till Gemini Decision 1 om dina beslut är kunskapsformade, om hastighet spelar roll, eller om du vill ha en delad kontext som är stor nog att rymma en hel post på en gång. Stanna kvar på Drex Max v1.1 om de är dokumentformade — och godkännandegraden säger att de förmodligen är det, eftersom dokumentutvinning är vad de flesta beslutsarbetsbelastningar visar sig vara när man väl tittar. Kör båda om ett felaktigt svar är dyrt, och budgetera för kostnadsförhållandet tre till ett innan du lovar någon en besparing. Migreringen är en dags arbete och ett kvartal av omtrimning; beslutet att göra den handlar om vilken komponent i indexet din arbetsbelastning faktiskt liknar.