Vigtigste pointer
- Context windows combine prompt and completion, so long histories drain limits faster than expected.
- Streaming kræver, at man håndterer SSE-events omhyggeligt for at undgå korrupt JSON eller tabte tokens.
- JSON mode demands strict schema adherence; malformed responses cause silent parsing failures.
- Forudbetalt kryptobetaling betyder, at fejl er gratis, men tælling af tokens skal være præcis for at undgå overraskelser.
Hvorfor din API-nøgle kan blive afvist
API-nøgler afvises, når klienten sender ugyldige headers, eller når grænsen for anmodningskrop overskrides. Serveren validerer autentificeringsheaderen, før nogen logik behandles. Hvis headeren mangler eller indeholder ekstra mellemrum, mislykkes anmodningen øjeblikkeligt.
En anden almindelig årsag er at sende en payload, der overstiger grænsen for kropstørrelsen på 8 MB. Store kontekstvinduer med mange beskeder kan nemt overskride denne grænse. Tjek længden af din besked-array og antallet af tokens, før du sender.
- Sørg for, at Authorization-headeren bruger 'Bearer'-præfikset korrekt.
- Verify the request body size stays under 8 MB.
- Tjek at API-nøglen er aktiv og ikke udløbet.
Forståelse af kontekstvinduesbegrænsninger
Kontekstvinduet omfatter både input-prompten og den genererede færdiggørelse. Vores API understøtter et vindue på 100,000 tokens, men du skal tage højde for begge sider. Hvis du sender 80,000 tokens kontekst, har du kun 20,000 tilbage til svaret.
De fleste modeller har som standard en lille outputgrænse, hvis du ikke angiver max_tokens. Dette kan forkorte lange svar uventet. Indstil max_tokens til din ønskede længde kun, hvis du ønsker en grænse. Husk, at grænsen gælder for hele anmodningen, ikke kun for prompten.
Håndtering af streamingafbrydelser korrekt
Streaming via Server-Sent Events (SSE) kræver robust fejlhåndtering. Hvis forbindelsen afbrydes, kan du miste det sidste token eller brugsmetadata. Buffer altid indkommende chunks og rekonstruer hele svaret på klientsiden.
Brugsdata for tokens sendes typisk i den sidste del af streamet. Hvis du afslutter forbindelsen for tidligt, kan du gå glip af det nøjagtige tokenantal. Dette påvirker faktureringsnøjagtigheden i forudbetalte systemer. Implementer en gentagelsesmekanisme med eksponentiel backoff til at håndføre midlertidige netværksproblemer.
Brug en dedikeret streaming-klient, der håndterer SSE-parsing automatisk. Dette reducerer risikoen for parsing-fejl og sikrer, at du fanger alle data.
Fejl ved fortolkning af JSON-tilstand
Når du bruger response_format: {"type": "json_object"}, skal modellen returnere gyldig JSON. Afvigelser vil forårsage fejl ved fortolkning i din applikation. Sørg for, at din prompt eksplicit instruerer modellen til kun at outputte JSON.
Nogle gange indeholder modellen markdown-kodeblokke omkring JSON, hvilket ødelægger strenge parsere. Fjern -omgivelserne før parsing. Valider også JSON-strukturen på klientsiden, før du bruger dataene.
Brug en schema-valideringsbibliotek til at fange fejl tidligt. Dette forhindrer kras, når modellen returnerer uventede nøgler eller typer.
Overraskelser ved tokenoptælling og fakturering
Forudbetalt fakturering opkræver kun for faktisk tokenforbrug. Fejl og afvisninger er gratis, hvilket er en betydelig fordel i forhold til abonnementsmodeller. Tokenoptælling kan dog være besværlig, hvis du ikke tager højde for hele konteksten.
Hver besked i samtalehistorikken tæller med i grænsen for input-tokens. Lange samtaler forbruger din forudbetalte kredit hurtigere, end du måske tror. Overvåg din brug regelmæssigt for at undgå at løbe tør for kredit undervejs i en session.
Indstil advarsler for lave kreditbalancer. Dette sikrer, at du kan opfylde, før dine anmodninger fejler. Husk, at kreditter udløber aldrig, så du kan opfylde, når det passer dig.
Undgå bløde afslag i NSFW-prompts
Bløde afvisninger opstår, når modellen tøver eller giver et delvist svar i stedet for et direkte svar. Dette sker ofte ved kontroversielle eller voksne emner. Selv i en ucensureret model kan visse udløsere forårsage tøven.
Juster temperature-parameteren for at reducere tilfældigheden. En lavere temperatur gør modellen mere deterministisk og mindre tilbøjelig til at være tvivlende. Sørg også for, at din prompt er klar og direkte. Undgå tvetydig sprogbrug, der kan forvirre modellen.
Hvis du oplever hyppige bløde afvisninger, kan du prøve at omformulere prompten lidt. Små ændringer i formuleringen kan ofte omgå tøven og give et direkte svar.
Ratelimit-toppe og backoff-strategier
API'en tillader 300 anmodninger i minuttet og 8 samtidige anmodninger per nøgle. Trafiktoppe kan hurtigt ramme disse grænser. Implementér eksponentiel backoff for at håndtere rate limit-fejl på en elegant måde.
Når du modtager en 429-statuskode, skal du vente, før du prøver igen. Start med en kort forsinkelse og øg den med hvert forsøg. Dette forhindrer, at serveren bliver overbelastet i travle perioder.
Overvåg din anmodningshastighed og juster dine samtidighedsniveauer tilsvarende. Hvis du udfører mange samtidige anmodninger, bør du overveje at sprede dem over tid. Dette sikrer en jævn gennemstrømning uden at ramme grænserne.
Strukturer for funktionssamkald
Funktionssamtaler kræver en specifik payload-struktur. Definer dine funktioner i tools-parameteren, og angiv tool_choice. Modellen returnerer et funktionssamtale, hvis den vurderer, at det er det passende svar.
Sørg for, at dine funktionsdefinitioner er nøjagtige og komplette. Manglende parametre eller forkerte typer kan få modellen til at generere ugyldige kald. Valider altid argumenterne til funktionskaldet, før du udfører dem.
Brug tool_choice-parameteren til at kontrollere, hvornår modellen kalder funktioner. Du kan tvinge et funktionskald, lade modellen afgøre det selv eller helt deaktivere funktionskald. Dette giver dig finjusteret kontrol over modellens adfærd.
Fejlsøgning af 400- vs 500-fejl
400-fejl indikerer problemer på klientsiden, såsom ugyldig JSON eller manglende parametre. 500-fejl tyder på problemer på serversiden, såsom interne fejl eller tidsudløb. At skelne mellem de to hjælper dig med at fejlsøge hurtigere.
For 400-fejl skal du tjekke fejlmeddelelsen, der er angivet i svaret. Den peger normalt direkte på problemet. For 500-fejl skal du gentage anmodningen efter en kort forsinkelse. Hvis fejlen fortsætter, skal du kontakte support med anmodnings-ID'et.
Log både anmodnings- og svar detaljer for hver fejl. Dette hjælper med at identificere mønstre og tilbagevendende problemer. Brug en logningstjeneste til at spore fejl over tid og forbedre din API-integration.
