Gemini 3.8 Flash API-handledning: tänkenivåer, PDF-extraktion och funktionsanrop i Python

Vad är Gemini 3.8 Flash?

Gemini 3.8 Flash är Googles arbetsmodell, allmänt tillgänglig sedan 2 september 2026, under modell-ID gemini-3.8-flash. Den kom 3 veckor efter 3.7 Flash, och Google positionerar den för långsiktig kodning, agentflöden och flerstegsresonemang i specialiserade domäner som finans och juridik.

Specarna som spelar roll för API-anrop är oförändrade från 3.7: 

• ett kontextfönster på 1M token
• 64k max utdata-token
• multimodal indata (text, bilder, video, ljud, PDF:er) med textutdata
• Samma introduktionspris på $0,75 per 1M indatatoken och $3,75 per 1M utdata-token till och med 31 december 2026 (stiger till $1,50 respektive $7,50 från 1 januari 2027)

Det som ändrats är beteendet, inte ytan: Google säger att 3.8 arbetar hårdare med komplexa uppgifter, tar extra resonemangs-steg och anropar verktyg iterativt, vilket kan öka tokenanvändningen på högre ansträngningsnivåer. 3.7 Flash är fortsatt fullt stödd för arbetslaster där effektivitet väger tyngre än djup.

För benchmarkresultat och detaljerad prissättning, läs vår guide till Gemini 3.8 Flash, eller läs guiden What is Google Gemini? för en översikt av plattformen.

Gemini 3.8 Flash vs. 3.8 Flash Cyber

Lanseringen omfattar 2 varianter, och bara 1 av dem har ett modell-ID du kan skriva. 

• Gemini 3.8 Flash är den generella modellen, tillgänglig i Google AI Studio och Gemini API idag. 
• Gemini 3.8 Flash Cyber är en cybersäkerhetsvariant finjusterad för sårbarhetsupptäckt och automatiserad patchning.

Cyber-varianten finns inte på det publika API:t: åtkomst sker via Googles Fairwind-program, som är begränsat till godkända myndigheter, aktörer inom kritisk infrastruktur och programvaruunderhållare.

Om du följer den här handledningen är ditt modell-ID gemini-3.8-flash. Inget nedan kräver eller använder Cyber-varianten.

Interactions API vs. generateContent

För att anropa Gemini 3.8 Flash, använd client.interactions.create() i SDK:n google-genai. Google gjorde Interactions API GA i juni 2026 och rekommenderar det för allt nytt arbete. Även om generateContent fortfarande fungerar, är det nu legacy. Nya funktioner som server-side-historik, bakgrundskörning och observerbara exekveringssteg landar på Interactions först.

Den största praktiska förändringen är tillståndshantering. Flera turer använder nu en server-side previous_interaction_id: du skickar det senaste interaktions-ID:t, och servern hanterar återställning av tillstånd. Du behöver inte längre manuellt lägga till eller skicka om hela chathistoriken från din klient. Undvik också att förfylla modell-turer; det är ett legacy-mönster från generateContent och kommer att gå sönder på Gemini 3.x.

En sak fångar nästan alla, och den kommer tillbaka i PDF-avsnittet: previous_interaction_id återställer konversationshistoriken och inget annat. tools, system_instruction, generation_config och response_format är interaktionsbundna, så alla turer som behöver dem måste skicka dem igen.

thinking_level ersätter samplingreglagen

På äldre Gemini-modeller använde utvecklare temperature, top_p och top_k för att styra slumpmässighet i utdata. Gemini 3.x tar bort dessa samplingreglage och ersätter dem med thinking_level, som nu är det enda vredet.

Det accepterar 3 värden:

• low: minst resonemangs-token, snabbast och billigast. Passar extraktion, klassificering och allt du själv kommer att kontrollera.

• medium: standard och Googles rekommendation för kod och agentarbete.

• high: störst resonemangsbudget, för svår flerstegslogik och uppgifter med tung verktygsanvändning.

Skicka inte minimal. Det är ogiltigt sedan Gemini Flash 3.7 och returnerar ett 400-valideringsfel. 

En annan regel som följer med från 3.7: frequency_penalty, presence_penalty och candidate_count kastar nu ett aktivt API-fel, så ta bort dem också från legacy-konfigurationer.

Hur ställer du in Gemini 3.8 Flash API?

Att konfigurera din miljö tar cirka 2 minuter. Du behöver en API-nyckel från Google AI Studio och det uppdaterade Python-biblioteket google-genai.

Skaffa en API-nyckel från Google AI Studio

Besök Google AI Studio i din webbläsare och logga in med ditt Google-konto. Klicka på Create API Key, välj eller skapa ett Google Cloud-projekt och kopiera din hemliga nyckelsträng. 

Öppna din terminal och spara nyckeln som en miljövariabel med export GEMINI_API_KEY=<your-key>.

Skicka aldrig nyckeln som en ?key=-frågeparameter i en URL; frågesträngar hamnar i serverloggar, webbläsares historik och proxycachar. Om du vill utforska modellen i en sandbox innan du skriver kod, täcker Google AI Studio Tutorial Chat-, Build- och Stream-lägen; den här artikeln håller sig till API:t.

För produktionssystem ser autentisering annorlunda ut: Vertex AI (numera en del av Gemini Enterprise Agent Platform) ger dig OAuth, IAM-roller och regionala endpoints i stället för en rå API-nyckel. Allt i den här handledningen använder AI Studio-nycklar eftersom det är snabbast för inlärning, men planera Vertex-migreringen innan något rör verkliga användardata.

Installera google-genai och skapa en klient

Många handledningar säger fortfarande att du ska installera google-generativeai. Det är det gamla SDK:t och det har inget Interactions API. Installera google-genai (version 2.3.0 eller senare):

pip install -U google-genai

När det är installerat, verifiera att Python laddar biblioteket och initierar din klient utan fel:

from google import genai # reads GEMINI_API_KEY from the environment
client = genai.Client() 
print("Client initialized successfully.")

Gör ditt första anrop till Interactions API

Varje begäran till Interactions API skapar en Interaction-resurs, som sparar hela turen: din indata, modellens tankar, eventuella verktygsanrop och slututdata. SDK:n exponerar sluttexten via egenskapen output_text, så du behöver sällan gå igenom stegen manuellt.

from google import genai
client = genai.Client()
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=(
        "Write a pandas one-liner that adds a 7-day rolling average "
        "revenue column per store_id to a DataFrame with columns "
        "date, store_id, revenue. Reply with only the code, no explanation."
    ),
    generation_config={"thinking_level": "medium"},
)
print(interaction.output_text)
usage = interaction.usage
print(
    f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
    f"thinking={usage.total_thought_tokens} | total={usage.total_tokens}"
)

På min maskin svarade modellen med en kedjad pandas one-liner, och den här användningsraden:

De siffrorna döljer den första verkliga skillnaden från 3.7. Jag körde samma uppgift igen med en längre prompt och utan utdata-begränsning, och 3.8 lade 1 436 thinking-tokens mot 870 utdata-token. Med begränsningen lade den 1 515 mot 42. Resonemangsbudgeten rörde sig knappt, vilket är motsatsen till 3.7, där samma två promptar svängde tänkandet från 838 till 1 530.

Med andra ord avgör 3.8 hur hårt den ska tänka baserat på uppgiften, inte på hur du formulerar uppgiften, vilket stämmer med Googles påstående att modellen medvetet resonerar och verifierar mer. Thinking debiteras till utdata-priset, så på det begränsade anropet var cirka 97% av de debiterade tokenen resonemang jag aldrig såg. Det är därför nästa avsnitt finns. 

Strömma svaret

För chattgränssnitt eller allt en person tittar på känns det långsamt att vänta flera sekunder på hela svaret. Skicka stream=True till client.interactions.create() och skriv ut bitar allt eftersom de kommer:

	from google import genai

	client = genai.Client()

	stream = client.interactions.create(
	   model="gemini-3.8-flash",
	   input="Explain the difference between a JOIN and a correlated subquery in SQL.",
	   generation_config={"thinking_level": "low"},
	   stream=True,
	)

	for event in stream:
	   if event.event_type == "step.delta" and event.delta.type == "text":
	       print(event.delta.text, end="", flush=True)
	print() 

När jag körde detta returnerade modellen ett långt, välorganiserat svar på thinking_level: "low": en konceptuell jämförelse, en sammanfattande tabell och 2 SQL-exempel för att hitta varje kunds senaste order, 1 med ett join på en härledd tabell och 1 med en korrelerad subfråga i SELECT-listan. De första orden dök upp nästan direkt, vilket är hela poängen.

Den sista print() finns där av en anledning. Utan den slutar sista chunk:en mitt i en rad, och zsh visar ett ensamt % före prompten, eftersom strömmen stannar exakt där modellens text slutar. Dessutom bär deltan text bara om du loggar tokenräkningar per begäran; läs dem från den sista completion-händelsen i stället för att summera bitar.

Hur ändrar thinking_level kostnad och kvalitet?

thinking_level anger hur mycket resonemang Gemini 3.8 Flash gör innan den skriver svaret. Resonemangs-token debiteras till utdata-priset $3,75 per 1M, så nivån du väljer styr kostnad och latens direkt, och Google säger att 3.8 lutar in i detta med flit: den tar extra resonemangs-steg vid komplexa uppgifter och kan spendera fler token på högre ansträngningsnivåer än 3.7 gjorde.

Kör en prompt på low, medium och high

Testet är en race condition i en funktion för att försöka om betalningar som skickas med samma prompt på alla 3 nivåer. Samtidighetsbuggar straffar slarvläsning, så om nivåerna skiljer sig åt är det här det borde synas. Om du bara kör 1 kodblock från den här artikeln, låt det vara detta, eftersom siffrorna argumenterar bättre än någon prosa kan.

import time

from google import genai

client = genai.Client()

BUGGY_CODE = '''
import threading

payment_attempts = {}

def retry_payment(order_id, charge_fn, max_retries=3):
    """Retry a failed payment up to max_retries times."""
    if order_id not in payment_attempts:
        payment_attempts[order_id] = 0

    while payment_attempts[order_id] < max_retries:
        success = charge_fn(order_id)
        if success:
            del payment_attempts[order_id]
            return True
        payment_attempts[order_id] += 1
    return False
'''

PROMPT = (
    "Two worker threads can call retry_payment() with the same order_id "
    "at the same time. Identify the concurrency bug that can double-charge "
    "a customer, and rewrite the function to fix it.\n\n" + BUGGY_CODE
)

for level in ["low", "medium", "high"]:
    start = time.perf_counter()
    interaction = client.interactions.create(
        model="gemini-3.8-flash",
        input=PROMPT,
        generation_config={"thinking_level": level},
    )
    elapsed = time.perf_counter() - start
    usage = interaction.usage
    print(f"\n=== thinking_level: {level} | {elapsed:.1f}s ===")
    print(interaction.output_text)
    print(
        f"input={usage.total_input_tokens} | output={usage.total_output_tokens} | "
        f"thinking={usage.total_thought_tokens}"
    )

För sammanhang: sårbarheten är en icke-atomär check-then-act på payment_attempts[order_id]. Vid samtidighet kan 2 trådar båda passera while-villkoret och båda anropa charge_fn() innan någon av dem ökar räknaren. Att fixa det betyder att kapsla in läs-kontroll-debitera-öka-flödet i en lås per order, eller att använda en idempotency-nyckel i gatewayen.

Jämföra resultaten

Resultat från mina körningar:

Alla 3 nivåer hittade dubbeldebiteringen, och alla 3 levererade lås per order, så orelaterade order körs parallellt. Den andra delen är rubriken om du jämför detta på 3.7: där lindade low in allt i ett globalt lås som hölls under nätverksanropet, och lås per order dök bara upp på medium. På 3.8 skriver low den bättre designen på 0 thinking-token, på 7,8 sekunder, för mindre än en tredjedels cent.

Så vad köper nivåerna nu? Granskningsdjup. Den här koden har 4 distinkta felmoder (dubbeldebiteringen, en KeyError vid samtidiga borttagningar, en omdebitering efter att lyckad väg tar bort tillstånd, och icke-atomära räkneökningar), och high var den enda nivån som namngav alla 4; low missade omdebiteringsfallet och medium missade räknaren. 

high var också den enda som tydligt beskrev felvägens semantik i sin fix: när försöken är slut får senare anropare False tillbaka i stället för att debitera igen.

Thinking-kolumnen är Googles ”3.8 arbetar hårdare”-påstående som syns i en terminal. Mot samma prompt på 3.7 gick medium från 2 343 thinking-token till 3 158, och high från 2 217 till 4 512, ungefär dubbelt, och de extra tokenen gav en mer komplett analys snarare än ett annat utlåtande. Latensen ökade i takt denna körning (7,8 s, 16,6 s, 25,5 s), men enkelkörnings-tider på dessa modeller svänger, så jämför tokenräkningar snarare än sekunder.

Välj ett standardläge och när du ska eskalera

Detta är min tumregel för tänkenivåer:

• På 3.8 förtjänade low en större roll än Googles standard medium antyder: den producerade en korrekt, väl utformad fix på 0 thinking-token, så börja där för allt som en människa läser innan det spelar roll (triage, utkast, sammanfattningar, kod du kommer att granska). 

• Behåll medium där utdata skeppas oläst, eftersom det extra tänkandet gav en mer komplett analys av felmoder, och en oläst pipeline är exakt där den felmod du inte listade är den som triggas.

• Reservera high för utdata där själva felvägen är produkten, som betalningsflöden, migrationer eller allt en granskare skulle gå igenom rad för rad. I min körning var det den enda nivån som fångade alla 4 buggar och dokumenterade vad som händer när försöken är slut.

Med 6.6× kostnaden för low för high läses den avvägningen väldigt olika vid $3,75 per 1M utdata-token nu jämfört med $7,50 efter den 31 december 2026, så eskalera per begäran snarare än globalt.

En utväg värd att känna till är att Google säger att 3.7 Flash förblir fullt stödd för effektivitet-först-arbetslaster. Om 3.8:s extra noggrannhet kostar mer än din uppgift behöver, är det ett stödd val att stanna på gemini-3.7-flash för den arbetslasten, inte ett hack.

Hur extraherar du strukturerad data från en PDF?

Gemini 3.8 Flash läser PDF:er direkt som indata, så du kan skicka en faktura eller en rapport och ställa frågor om den. Jag använde en 1-sidig leverantörsfaktura med fakturanummer, datum, 4 rader och en totalsumma.

Bifoga en PDF till prompten

Låt oss ladda upp en lokal faktura-PDF med Files API. Files API hanterar fillagring och cache på Googles infrastruktur:

	from google import genai
	client = genai.Client()
	print("Uploading invoice...")
	doc = client.files.upload(file="invoice_aug_2026.pdf")
	print(f"File uploaded: {doc.uri}\n")

	interaction = client.interactions.create(
	   model="gemini-3.8-flash",
	   input=[
	       {
	           "type": "text",
	           "text": "Extract the invoice number, total amount due, and due date.",
	       },
	       {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
	   ],
	)
	print(interaction.output_text)

Utdata från min faktura:

Alla 3 värden är korrekta. Uppladdningen sker en gång, och filen finns tillgänglig för senare begäranden, vilket spelar roll så snart du ställer fler än 1 fråga om samma dokument. Svaret kommer tillbaka som markdown-punkter, vilket är bra för läsning men inte för att mata in i en pipeline.

Tvinga JSON med ett svarsschema

För att få JSON i stället för prosa, skicka ett schema i response_format. På Interactions API är detta en toppnivå-parameter; inställningen responseMimeType inuti generationConfig som du ser i äldre handledningar hör till det äldre generateContent-endpointet.

import json

from google import genai
from pydantic import BaseModel

client = genai.Client()


class Invoice(BaseModel):
    invoice_number: str
    total_due_usd: float
    due_date: str  # ISO 8601


doc = client.files.upload(file="invoice_aug_2026.pdf")

interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input=[
        {
            "type": "text",
            "text": "Extract the invoice number, total amount due in USD, and due date.",
        },
        {"type": "document", "uri": doc.uri, "mime_type": doc.mime_type},
    ],
    response_format={
        "type": "text",
        "mime_type": "application/json",
        "schema": Invoice.model_json_schema(),
    },
)

invoice = json.loads(interaction.output_text)
print(invoice)

Detta är utdata jag fick: 

Din Pydantic-klass definierar obligatoriska fält och datatyper, medan model_json_schema() genererar JSON-schemat som krävs av Gemini API:t. När det väl är bearbetat konverterar json.loads() modellens utdata till en vanlig Python-ordlista. Härifrån är den strukturerade datan redo att göras om till en DataFrame-rad, committas till en databas eller läggas till i ett Google-kalkylark.

Ställ en följdfråga med previous_interaction_id

För en andra fråga om samma dokument, skicka den första interaktionens id som previous_interaction_id. Servern har redan PDF:en och det första utbytet, så du skickar inte något av dem igen:

follow_up = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input="List each line item on the invoice with its amount.",
)

print(follow_up.output_text)

Den returnerade alla 4 rader i ordning, inklusive den upprepade compute-raden, utan att kommentera upprepningen. Det är rätt beteende för frågan som ställdes; om du vill att den ska flagga avvikelser, be om det. 

För vad det är värt, 3.7 betedde sig identiskt här, så 3.8:s extra noggrannhet gäller dess eget resonemang, inte att frivilligt göra granskningar du inte begärt.

2 saker att veta om detta anrop: 

• response_format följde inte med, eftersom det är interaktionsbundet, så den här turen returnerade prosa. 

• Och interaktioner lagras som standard (store=True) i 55 dagar på betalnivån och 1 dag på gratistier; store=False gör ett anrop tillståndslöst, men då kan du inte kedja ett previous_interaction_id från det.

Hur lägger du till funktionsanrop i Gemini 3.8 Flash?

Funktionsanrop på Gemini 3.8 Flash är en loop: modellen ber om ett verktyg, din kod kör det, du skickar tillbaka resultatet och modellen skriver det slutliga svaret. Detta avsnitt bygger den loopen för hand.

Om du vill att Google ska köra loopen åt dig med hostade multi-verktygsagenter, läs vår handledning om  ”Managed Agents” i Gemini API härnäst. Och om agenter är dit du siktar på längre sikt, bygger kursen Building AI Agents with Google ADK en full kundsupportassistent på samma primitiv.

Definiera ett verktyg och kör interaktionsloopen

Verktyget är lookup_exchange_rate(currency, date), backat av en liten in-memory dict, så exemplet körs utan ett externt API. Deklarationen är ett JSON-schema. Modellen kör aldrig funktionen; den returnerar ett function_call-steg som ber din kod att:

import json

from google import genai

client = genai.Client()

# Local "data source" standing in for a real FX API
RATES = {
    ("USD", "2026-08-03"): 87.42,
    ("USD", "2026-08-10"): 87.15,
    ("EUR", "2026-08-03"): 95.08,
}


def lookup_exchange_rate(currency: str, date: str) -> dict:
    rate = RATES.get((currency.upper(), date))
    if rate is None:
        return {"error": f"No rate for {currency} on {date}"}
    return {"currency": currency.upper(), "date": date, "inr_rate": rate}


rate_tool = {
    "type": "function",
    "name": "lookup_exchange_rate",
    "description": "Look up the INR exchange rate for a currency on a date (YYYY-MM-DD).",
    "parameters": {
        "type": "object",
        "properties": {
            "currency": {"type": "string", "description": "ISO code, e.g. USD"},
            "date": {"type": "string", "description": "YYYY-MM-DD"},
        },
        "required": ["currency", "date"],
    },
}

# Turn 1: the model decides to call the tool
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="What was the USD to INR exchange rate on 2026-08-03?",
    tools=[rate_tool],
)

fc_step = next(s for s in interaction.steps if s.type == "function_call")
print(f"Model requested: {fc_step.name}({fc_step.arguments})")

# Your code executes the function locally
result = lookup_exchange_rate(**fc_step.arguments)

# Turn 2: send the result back; tools must be re-specified (interaction-scoped)
final = client.interactions.create(
    model="gemini-3.8-flash",
    previous_interaction_id=interaction.id,
    input=[
        {
            "type": "function_result",
            "name": fc_step.name,
            "call_id": fc_step.id,
            "result": [{"type": "text", "text": json.dumps(result)}],
        }
    ],
    tools=[rate_tool],
)

print(final.output_text)

Utdata: 

3 saker hände här:  

1. Tur 1 returnerade ett function_call-steg med ett namn, strukturerade argument och ett id.

2. Din Python körde uppslaget.

3. Tur 2 skickade ett function_result-block som refererar till det anropet. 

Parametern tools skickas igen på tur 2 av samma skäl som response_format behövde skickas igen i PDF-avsnittet: previous_interaction_id bär historik, inte konfiguration.

Vanliga misstag vid funktionsanrop på Gemini 3.x

Om en verktygsloop bryts är det nästan alltid 1 av 2 saker. 

För det första måste varje resultat mappas tillbaka till sitt anrop. På Interactions API är det call_id och name på function_result-blocket; på det äldre generateContent-API:t måste FunctionResponse matcha id och name för föregående FunctionCall. Inget av dem är valfritt på Gemini 3.x.

För det andra uppstår ett Malformed_Function_Call-fel vanligtvis när modellen skickar kommentarer före verktygsanropet. Googles 3.8-utvecklarguide säger att du ska rensa bort inledande text före verktyg, formatera inline-instruktioner med \n\n och kapsla in arbetsanteckningar i ett dedikerat funktionsanrop i stället för råtext. Skärp systeminstruktionen; återförsök inte blint.

Vad går sönder när du byter till Gemini 3.8 Flash?

Det beror på var du börjar. 

• Från Gemini 3.7 Flash: inget. Ändra modellsträngen till gemini-3.8-flash, så körs varje snippet i den här artikeln oförändrad, eftersom API-ytan är identisk. 

• Från Gemini 3.6 Flash eller tidigare kräver modellspecen samma 15-minuters granskning som tidigare.

Migrationschecklista (från 3.6 Flash eller tidigare)

Gå igenom dessa i ordning. Punkt 1 till 3 orsakar omedelbara 400:or; punkt 4 och 5 orsakar tysta kvalitetsproblem.

1. Ändra modell-ID till gemini-3.8-flash.

2. Ta bort döda samplingparametrar: temperature, top_p och top_k ignoreras eller avvisas på Gemini 3.x, och frequency_penalty, presence_penalty och candidate_count kastar ett aktivt API-fel. Ta bort alla 6 från legacy-konfigurationer.

3. Ersätt thinking_budget med thinking_level: använd endast low, medium eller high. Det gamla värdet minimal returnerar ett valideringsfel. Att skicka både thinking_budget och thinking_level i samma begäran returnerar en 400.

4. Ta bort förifyllda modell-turer: rensa dessa från alla konversationer du bygger, och se till att den sista användarturen har icke-tom text. Historikpayloads kan inte sluta med en modelltur.

5. Standardisera flöden med flera turer: förlita dig på previous_interaction_id i stället för att spela upp historik på klientsidan. Du måste specificera dina tools, system_instruction och generation_config på varje tur där de spelar roll.

Google publicerar den auktoritativa versionen i modellspecen för Gemini API, inklusive en automatiserad väg om din kodagent stöder skills. Läs den själv en gång ändå; en automatiserad migrering kommer inte att berätta varför din temperature=0.2 fanns där från början.

Fel du kommer att stöta på i produktion

Här är de 4 statuskoderna värda att koppla hanterare för, och vad var och en faktiskt betyder på det här API:t:

2 ytterligare saker här:

• Sätt explicita klient-timeouts när du kombinerar thinking_level: "high" med långa verktygsloopar, eftersom en hängd begäran är värre än en misslyckad, och 3.8:s extra noggrannhet gör långa resonemangskörningar mer sannolika, inte mindre. 

• Och logga interaction.id med varje begäran; det är ditt handtag för att hämta, felsöka eller radera lagrade interaktioner senare.

Avslutande tankar

Allt i den här artikeln kan spåras till 3 skiften. Interactions API ändrade anropskonventionen, thinking_level ersatte varje samplingvred du brukade finjustera, och server-side-tillstånd via previous_interaction_id är det som gjorde både PDF-följdfrågan och verktygsloopen till enradiga turer i stället för historikuppspelningar. Gemini 3.8 Flash ändrade inget av den ytan; det som ändrades är hur hårt modellen arbetar inuti den, vilket är varför mätningarna i den här artikeln togs färska på 3.8 i stället för att föras över från 3.7.

Innan du tar mina nivårekommendationer på tro, peka jämförelseskriptet mot en uppgift från din egen backlogg; nivån som vinner på ett race i betalningsåterförsök kan förlora på din SQL-genereringsarbetslast. 

När enstaka API-anrop inte räcker längre och du vill ha produktionsklara AI-system, täcker vår Associate AI Engineer for Developers-väg hela resan, och Associate AI Engineer for Data Scientists-vägen gör samma sak från datasidan.