Kev-4B är en kompakt beslutsmodell för att besvara typade frågor om ett angivet tillstånd. Tillståndet är det dokument eller den post som bedöms, och varje fråga definierar de alternativ som modellen kan poängsätta. Resultatet är en sannolikhetsfördelning och en typad beslutspost, vilket gör modellen användbar för dokumentklassificering, routning, triagering, val vid extraktion och kontroller mot angivna kriterier.
Modellen kombinerar en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter och ett pekarhuvud. Ryggraden har 32 lager, varav 24 Gated DeltaNet-lager och åtta lager med full attention. Adaptern riktar sig mot attention-, MLP- och DeltaNet-projektioner; pekarhuvudet poängsätter de angivna alternativen och omvandlar poängen till sannolikheter. Detta är ett beslutsflöde som enbart består av prefill-steget, där alternativen utgör svarsrummet.
Tre frågetyper kan förekomma i samma begäran. En valfråga accepterar 1–255 namngivna alternativ, valfritt med beskrivningar, och returnerar det mest sannolika alternativet, ett separat konfidensvärde och sannolikheter för alternativen. En ja/nej-fråga, som kallas noul i tillverkarens format, returnerar sannolikheten för ja. Definiera vad ja betyder i frågan i stället för att anta att ett högt tal alltid innebär ett positivt utfall för applikationen.
En fråga med ordnad poäng accepterar 1–255 nivåer och returnerar sannolikheter för nivåerna och deras förväntade index. Nivåindexen börjar på noll. Tillverkarens resultatformat innehåller också nivåförklaringen och ett separat konfidensvärde. Ett förväntat index kan vara ett decimaltal: det sammanfattar fördelningen över dina ordnade nivåer i stället för att välja en ny textetikett. Behåll nivåordningen och förklaringen tillsammans med resultatet så att ett betyg kan tolkas konsekvent.
Frågorna delar samma tillstånd men utvärderas oberoende av varandra. En fråga kan inte läsa en annan frågas svar, och tillståndet beräknas en gång och återanvänds. Om ett senare beslut beror på ett resultat från ett tidigare beslut, gör det beroendet explicit i ett efterföljande tillstånd i stället för att förvänta dig att frågorna i en begäran bildar en kedja. Det gör flödet med gemensamt tillstånd lämpligt för flera oberoende kontroller av samma dokument.
Förbered tillståndet med det underlag som frågorna faktiskt kräver. Det kan vara vanlig text eller ett JSON-objekt eller en JSON-array som återges som märkt text. Håll fältnamn, enheter, policyvillkor och relevanta källavsnitt tydliga. Skriv en specifik instruktion för varje fråga och ge dess alternativ betydelser som går att särskilja utifrån posten. I ett eget exempel på supportroutning kan tillståndet innehålla förfrågan och dess kontext, medan valen definierar kategorierna leverans, åtkomst och produktsupport med korta beskrivningar.
En andra fråga kan bedöma brådska, och en ordnad fråga kan betygsätta hur mycket uppföljning förfrågan kräver. De besvarar olika operativa frågor, så definiera var och en för sig. Ta med ett lämpligt alternativ för granskning eller saknat underlag när valuppgiften behöver det, och behåll hela fördelningen när flera kategorier är rimliga. Applikationen avgör hur ett resultat ska routas eller granskas; modellen levererar den poängsatta posten.
Kev-4B är avsedd för typade beslut över dokument på några tusen token. Tillverkarens driftprofil accepterar tillstånd på upp till 65 536 token och reserverar ytterligare utrymme för varje fråga, medan den validerade kontextlängden för denna checkpoint är 8192 token. Det är olika gränser: att ett längre tillstånd accepteras innebär inte lika tillförlitliga beslut vid varje längd. Håll avgörande avsnitt kompakta och bevara deras etiketter när du förbereder en lång post för klassificering.
Den släppta profilen är engelskspråkig. Dess användbara uppgifter bygger på underlaget i det angivna tillståndet och på de definierade alternativen, snarare än på öppen chatt, sammanfattning eller breda kunskapsbaserade svar. Datumaritmetik på dagsnivå är en särskild begränsning: tillverkaren tillhandahåller en separat förprocessor för datumfakta som anger beräknade intervall. För en kontroll av tidsfrister tar du med de relevanta datumen och beräknade dagintervall i tillståndet, tillsammans med regeln som använder dem.
Checkpointen levereras med anpassad sannolikhetskalibrering, men konfidensen kan förändras med dokumentdomänen och frågeutformningen. Tillverkaren dokumenterar också finjustering av den öppna checkpointen på uppgiftsspecifika etiketter och anpassning av dess sannolikhetskalibrering till den arbetslasten; detta är ett separat anpassningsflöde, skilt från poängsättning av ett angivet tillstånd. Välj beslutströsklar med hjälp av märkta exempel från den faktiska arbetslasten och håll osäkra fall synliga för granskning. Tillverkaren utesluter helt automatiserade beslut med betydande konsekvenser för människor utan mänsklig granskning. Alternativens ordning kan också påverka ett svar, så behåll en stabil ordning när du jämför resultat. Bedöm den valda etiketten, det separata konfidensfältet och sannolikhetsfördelningen utifrån den roll var och en spelar i ditt arbetsflöde.
Den aktuella Kev-4B-versionen som tillverkaren beskriver tillhör Kev 1.0 och använder Qwen3.5-basen. Tidigare Qwen3-baserade versioner och versioner som enbart omfattar dokumentsteget är fortfarande separata versioner. Håll den valda utgåvan och frågedefinitionerna kopplade till utdatan när du utvecklar ett uppgiftsspecifikt arbetsflöde, i stället för att blanda resultat från olika profiler.
En användbar slutlig artefakt är en namngiven uppsättning beslutsposter med de ursprungliga frågorna, alternativens definitioner, fördelningarna och eventuella förklaringar för ordnade nivåer. För en kontroll av svarskvalitet ska tillståndet innehålla det föreslagna svaret, underlaget och det kriterium som testas. För policytriagering ska det innehålla den tillämpliga regeln och relevanta fakta. Bevara den indatan bredvid resultatet så att en granskning kan fastställa varför ett beslut var lämpligt eller vilket saknat faktum som behöver tillföras.
", "aboutText": "Kev-4B är en kompakt beslutsmodell för att besvara typade frågor om ett angivet tillstånd. Tillståndet är det dokument eller den post som bedöms, och varje fråga definierar de alternativ som modellen kan poängsätta. Resultatet är en sannolikhetsfördelning och en typad beslutspost, vilket gör modellen användbar för dokumentklassificering, routning, triagering, val vid extraktion och kontroller mot angivna kriterier.\n\nModellen kombinerar en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter och ett pekarhuvud. Ryggraden har 32 lager, varav 24 Gated DeltaNet-lager och åtta lager med full attention. Adaptern riktar sig mot attention-, MLP- och DeltaNet-projektioner; pekarhuvudet poängsätter de angivna alternativen och omvandlar poängen till sannolikheter. Detta är ett beslutsflöde som enbart består av prefill-steget, där alternativen utgör svarsrummet.\n\nTre frågetyper kan förekomma i samma begäran. En valfråga accepterar 1–255 namngivna alternativ, valfritt med beskrivningar, och returnerar det mest sannolika alternativet, ett separat konfidensvärde och sannolikheter för alternativen. En ja/nej-fråga, som kallas noul i tillverkarens format, returnerar sannolikheten för ja. Definiera vad ja betyder i frågan i stället för att anta att ett högt tal alltid innebär ett positivt utfall för applikationen.\n\nEn fråga med ordnad poäng accepterar 1–255 nivåer och returnerar sannolikheter för nivåerna och deras förväntade index. Nivåindexen börjar på noll. Tillverkarens resultatformat innehåller också nivåförklaringen och ett separat konfidensvärde. Ett förväntat index kan vara ett decimaltal: det sammanfattar fördelningen över dina ordnade nivåer i stället för att välja en ny textetikett. Behåll nivåordningen och förklaringen tillsammans med resultatet så att ett betyg kan tolkas konsekvent.\n\nFrågorna delar samma tillstånd men utvärderas oberoende av varandra. En fråga kan inte läsa en annan frågas svar, och tillståndet beräknas en gång och återanvänds. Om ett senare beslut beror på ett resultat från ett tidigare beslut, gör det beroendet explicit i ett efterföljande tillstånd i stället för att förvänta dig att frågorna i en begäran bildar en kedja. Det gör flödet med gemensamt tillstånd lämpligt för flera oberoende kontroller av samma dokument.\n\nFörbered tillståndet med det underlag som frågorna faktiskt kräver. Det kan vara vanlig text eller ett JSON-objekt eller en JSON-array som återges som märkt text. Håll fältnamn, enheter, policyvillkor och relevanta källavsnitt tydliga. Skriv en specifik instruktion för varje fråga och ge dess alternativ betydelser som går att särskilja utifrån posten. I ett eget exempel på supportroutning kan tillståndet innehålla förfrågan och dess kontext, medan valen definierar kategorierna leverans, åtkomst och produktsupport med korta beskrivningar.\n\nEn andra fråga kan bedöma brådska, och en ordnad fråga kan betygsätta hur mycket uppföljning förfrågan kräver. De besvarar olika operativa frågor, så definiera var och en för sig. Ta med ett lämpligt alternativ för granskning eller saknat underlag när valuppgiften behöver det, och behåll hela fördelningen när flera kategorier är rimliga. Applikationen avgör hur ett resultat ska routas eller granskas; modellen levererar den poängsatta posten.\n\nKev-4B är avsedd för typade beslut över dokument på några tusen token. Tillverkarens driftprofil accepterar tillstånd på upp till 65 536 token och reserverar ytterligare utrymme för varje fråga, medan den validerade kontextlängden för denna checkpoint är 8192 token. Det är olika gränser: att ett längre tillstånd accepteras innebär inte lika tillförlitliga beslut vid varje längd. Håll avgörande avsnitt kompakta och bevara deras etiketter när du förbereder en lång post för klassificering.\n\nDen släppta profilen är engelskspråkig. Dess användbara uppgifter bygger på underlaget i det angivna tillståndet och på de definierade alternativen, snarare än på öppen chatt, sammanfattning eller breda kunskapsbaserade svar. Datumaritmetik på dagsnivå är en särskild begränsning: tillverkaren tillhandahåller en separat förprocessor för datumfakta som anger beräknade intervall. För en kontroll av tidsfrister tar du med de relevanta datumen och beräknade dagintervall i tillståndet, tillsammans med regeln som använder dem.\n\nCheckpointen levereras med anpassad sannolikhetskalibrering, men konfidensen kan förändras med dokumentdomänen och frågeutformningen. Tillverkaren dokumenterar också finjustering av den öppna checkpointen på uppgiftsspecifika etiketter och anpassning av dess sannolikhetskalibrering till den arbetslasten; detta är ett separat anpassningsflöde, skilt från poängsättning av ett angivet tillstånd. Välj beslutströsklar med hjälp av märkta exempel från den faktiska arbetslasten och håll osäkra fall synliga för granskning. Tillverkaren utesluter helt automatiserade beslut med betydande konsekvenser för människor utan mänsklig granskning. Alternativens ordning kan också påverka ett svar, så behåll en stabil ordning när du jämför resultat. Bedöm den valda etiketten, det separata konfidensfältet och sannolikhetsfördelningen utifrån den roll var och en spelar i ditt arbetsflöde.\n\nDen aktuella Kev-4B-versionen som tillverkaren beskriver tillhör Kev 1.0 och använder Qwen3.5-basen. Tidigare Qwen3-baserade versioner och versioner som enbart omfattar dokumentsteget är fortfarande separata versioner. Håll den valda utgåvan och frågedefinitionerna kopplade till utdatan när du utvecklar ett uppgiftsspecifikt arbetsflöde, i stället för att blanda resultat från olika profiler.\n\nEn användbar slutlig artefakt är en namngiven uppsättning beslutsposter med de ursprungliga frågorna, alternativens definitioner, fördelningarna och eventuella förklaringar för ordnade nivåer. För en kontroll av svarskvalitet ska tillståndet innehålla det föreslagna svaret, underlaget och det kriterium som testas. För policytriagering ska det innehålla den tillämpliga regeln och relevanta fakta. Bevara den indatan bredvid resultatet så att en granskning kan fastställa varför ett beslut var lämpligt eller vilket saknat faktum som behöver tillföras.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "bbfd341746a298796e60361a82f0711cf601f102f11dfc5075dc352366b648f6", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B poängsätter typade frågor om ett angivet engelskt dokument och returnerar kalibrerade sannolikheter över de alternativ du definierar. Använd ja/nej-frågor, valfrågor och frågor med ordnad poäng för klassificering, routning, triagering och kontroller som kräver ett strukturerat beslut i stället för genererad löptext.
Den här beskrivningen omfattar modellens förmågor. Tillgängliga indata, utdata och alternativ i Ailoot anges nedan för den valda metoden.
Kev-4B är en kompakt beslutsmodell för att besvara typade frågor om ett angivet tillstånd. Tillståndet är det dokument eller den post som bedöms, och varje fråga definierar de alternativ som modellen kan poängsätta. Resultatet är en sannolikhetsfördelning och en typad beslutspost, vilket gör modellen användbar för dokumentklassificering, routning, triagering, val vid extraktion och kontroller mot angivna kriterier.
Modellen kombinerar en fryst Qwen3.5-4B-Base-ryggrad med en LoRA-adapter och ett pekarhuvud. Ryggraden har 32 lager, varav 24 Gated DeltaNet-lager och åtta lager med full attention. Adaptern riktar sig mot attention-, MLP- och DeltaNet-projektioner; pekarhuvudet poängsätter de angivna alternativen och omvandlar poängen till sannolikheter. Detta är ett beslutsflöde som enbart består av prefill-steget, där alternativen utgör svarsrummet.
Tre frågetyper kan förekomma i samma begäran. En valfråga accepterar 1–255 namngivna alternativ, valfritt med beskrivningar, och returnerar det mest sannolika alternativet, ett separat konfidensvärde och sannolikheter för alternativen. En ja/nej-fråga, som kallas noul i tillverkarens format, returnerar sannolikheten för ja. Definiera vad ja betyder i frågan i stället för att anta att ett högt tal alltid innebär ett positivt utfall för applikationen.
En fråga med ordnad poäng accepterar 1–255 nivåer och returnerar sannolikheter för nivåerna och deras förväntade index. Nivåindexen börjar på noll. Tillverkarens resultatformat innehåller också nivåförklaringen och ett separat konfidensvärde. Ett förväntat index kan vara ett decimaltal: det sammanfattar fördelningen över dina ordnade nivåer i stället för att välja en ny textetikett. Behåll nivåordningen och förklaringen tillsammans med resultatet så att ett betyg kan tolkas konsekvent.
Frågorna delar samma tillstånd men utvärderas oberoende av varandra. En fråga kan inte läsa en annan frågas svar, och tillståndet beräknas en gång och återanvänds. Om ett senare beslut beror på ett resultat från ett tidigare beslut, gör det beroendet explicit i ett efterföljande tillstånd i stället för att förvänta dig att frågorna i en begäran bildar en kedja. Det gör flödet med gemensamt tillstånd lämpligt för flera oberoende kontroller av samma dokument.
Förbered tillståndet med det underlag som frågorna faktiskt kräver. Det kan vara vanlig text eller ett JSON-objekt eller en JSON-array som återges som märkt text. Håll fältnamn, enheter, policyvillkor och relevanta källavsnitt tydliga. Skriv en specifik instruktion för varje fråga och ge dess alternativ betydelser som går att särskilja utifrån posten. I ett eget exempel på supportroutning kan tillståndet innehålla förfrågan och dess kontext, medan valen definierar kategorierna leverans, åtkomst och produktsupport med korta beskrivningar.
En andra fråga kan bedöma brådska, och en ordnad fråga kan betygsätta hur mycket uppföljning förfrågan kräver. De besvarar olika operativa frågor, så definiera var och en för sig. Ta med ett lämpligt alternativ för granskning eller saknat underlag när valuppgiften behöver det, och behåll hela fördelningen när flera kategorier är rimliga. Applikationen avgör hur ett resultat ska routas eller granskas; modellen levererar den poängsatta posten.
Kev-4B är avsedd för typade beslut över dokument på några tusen token. Tillverkarens driftprofil accepterar tillstånd på upp till 65 536 token och reserverar ytterligare utrymme för varje fråga, medan den validerade kontextlängden för denna checkpoint är 8192 token. Det är olika gränser: att ett längre tillstånd accepteras innebär inte lika tillförlitliga beslut vid varje längd. Håll avgörande avsnitt kompakta och bevara deras etiketter när du förbereder en lång post för klassificering.
Den släppta profilen är engelskspråkig. Dess användbara uppgifter bygger på underlaget i det angivna tillståndet och på de definierade alternativen, snarare än på öppen chatt, sammanfattning eller breda kunskapsbaserade svar. Datumaritmetik på dagsnivå är en särskild begränsning: tillverkaren tillhandahåller en separat förprocessor för datumfakta som anger beräknade intervall. För en kontroll av tidsfrister tar du med de relevanta datumen och beräknade dagintervall i tillståndet, tillsammans med regeln som använder dem.
Checkpointen levereras med anpassad sannolikhetskalibrering, men konfidensen kan förändras med dokumentdomänen och frågeutformningen. Tillverkaren dokumenterar också finjustering av den öppna checkpointen på uppgiftsspecifika etiketter och anpassning av dess sannolikhetskalibrering till den arbetslasten; detta är ett separat anpassningsflöde, skilt från poängsättning av ett angivet tillstånd. Välj beslutströsklar med hjälp av märkta exempel från den faktiska arbetslasten och håll osäkra fall synliga för granskning. Tillverkaren utesluter helt automatiserade beslut med betydande konsekvenser för människor utan mänsklig granskning. Alternativens ordning kan också påverka ett svar, så behåll en stabil ordning när du jämför resultat. Bedöm den valda etiketten, det separata konfidensfältet och sannolikhetsfördelningen utifrån den roll var och en spelar i ditt arbetsflöde.
Den aktuella Kev-4B-versionen som tillverkaren beskriver tillhör Kev 1.0 och använder Qwen3.5-basen. Tidigare Qwen3-baserade versioner och versioner som enbart omfattar dokumentsteget är fortfarande separata versioner. Håll den valda utgåvan och frågedefinitionerna kopplade till utdatan när du utvecklar ett uppgiftsspecifikt arbetsflöde, i stället för att blanda resultat från olika profiler.
En användbar slutlig artefakt är en namngiven uppsättning beslutsposter med de ursprungliga frågorna, alternativens definitioner, fördelningarna och eventuella förklaringar för ordnade nivåer. För en kontroll av svarskvalitet ska tillståndet innehålla det föreslagna svaret, underlaget och det kriterium som testas. För policytriagering ska det innehålla den tillämpliga regeln och relevanta fakta. Bevara den indatan bredvid resultatet så att en granskning kan fastställa varför ett beslut var lämpligt eller vilket saknat faktum som behöver tillföras.
POST /v1/systemonetextdecisions| Fält | Typ | Krav | Värden & gränser | Standard |
|---|---|---|---|---|
Fältmodel | Typstring | KravObligatoriskt | Värden & gränser jaredpalmer/kev-4b | Standard— |
Fältprovider | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältquestions | Typobject | KravObligatoriskt | Värden & gränser | Standard— |
Fältsession_id | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältstate | Typschema | KravObligatoriskt | Värden & gränser | Standard— |
Fälttrace | Typschema | KravValfritt | Värden & gränser | Standard— |
Fältuser | Typstring | KravValfritt | Värden & gränser | Standard— |
Fältquestions.<id>.type | Typstring | KravObligatoriskt | Värden & gränser noul, choice, score | Standard— |
Fältquestions.<id>.instructions | Typstring|object|array | KravObligatoriskt | Värden & gränser | Standard— |
Fältquestions.<id>.criteria | Typobject|array | KravValfritt | Värden & gränser Villkor: choice/score: obligatoriskt; noul: valfritt. Kriterier för choice är ett objekt; score är en array med minItems1. | Standard— |
Fältquestions.<id>.criteria.true | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
Fältquestions.<id>.criteria.false | Typstring|object|array | KravObligatoriskt | Värden & gränser Gäller när: Ett kriterieobjekt för noul har angetts | Standard— |
noul · Krävs: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Krävs: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Krävs: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parameter | Avtal |
|---|---|
Parametercontent_type | Avtalapplication/json |
Parameterrequired | Avtalmodel, state, questions |
Parametermaterial_types | Avtaltext |
Parameteroptional_controls | Avtalprovider, session_id, trace, user |
Parametermultimodal_input_binding | Avtalnull |
Livscykel: synchronous
Skicka det exakta modell-ID:t och behåll hela svaret i leverantörens format.
Tariffuppgifter lägger inte till begäransalternativ. Parametrar som stöds anges för den valda metoden.
Matcha varje avgift mot de visade villkoren. Använd ett pris för varje uppsättning alternativa konfigurationer.
| Konfiguration | Prislista | Kontexttoken, fler än | Kontexttoken, upp till och med | Avgift |
|---|---|---|---|---|
| KonfigurationGrundpriser för token | PrislistaGrundpris | Kontexttoken, fler än— | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.000084 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
| KonfigurationNivå 1 för förfrågans längd | Prislista— | Kontexttoken, fler än0 | Kontexttoken, upp till och medIngen övre gräns | Avgift Indata · Indatatoken $0.000084 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning — / 1K token Indata · Skrivning till cache — / 1K token Indata · Skrivning till cache, 1 tim — / 1K token |
Ailoot reserverar ett uppskattat belopp före en begäran. Efter resultatet slutregleras avgiften utifrån uppmätt förbrukning. Slutreglering för strömning använder den slutliga förbrukningsposten. Så fungerar reservation och slutreglering →
{\n "model": "jaredpalmer/kev-4b",\n "questions": {\n "is_bug": {\n "criteria": {\n "false": "The customer is asking a question or requesting a feature.",\n "true": "The customer describes broken or unexpected product behavior."\n },\n "instructions": "Is the customer reporting a software defect?",\n "type": "noul"\n },\n "team": {\n "criteria": {\n "account": "Login, permissions, or profile issues.",\n "frontend": "Rendering, layout, or browser compatibility issues.",\n "payments": "Checkout, billing, or payment processing issues."\n },\n "instructions": "Which team should own this ticket?",\n "type": "choice"\n },\n "urgency": {\n "criteria": [\n "Can wait for the next release",\n "Should be fixed this week",\n "Blocking revenue right now"\n ],\n "instructions": "How urgent is this ticket?",\n "type": "score"\n }\n },\n "state": {\n "customer_tier": "enterprise",\n "ticket": "My checkout page shows a blank screen after I click Pay. I have tried two browsers."\n }\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_REQUEST_FILE:?Set your actual JSON request file}"\nexport AILOOT_REQUEST_FILE\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads(Path(os.environ['AILOOT_REQUEST_FILE']).read_text(encoding='utf-8'))\nif not isinstance(p,dict): raise SystemExit('Request must be a JSON object')\np['model']='jaredpalmer/kev-4b'\nPath('request.json').write_text(json.dumps(p,ensure_ascii=False),encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/systemone \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nprint(json.dumps(json.loads(Path('result.json').read_text()),ensure_ascii=False,indent=2))\nPY_RESULT\njson
Behåll varje fullständigt returnerat svar, fil och innehållsdel.
Varje angivet svar för ett fråge-ID behålls med sin exakta typ, värdet noul/choice/score, konfidens, sannolikheter och teckenförklaring. Hela det ursprungliga JSON-svaret lagras och returneras först efter avräkning.
Bevara den ursprungliga operationen och hela eller det partiella svaret; upprepa inte POST.
| Fält | Typ |
|---|---|
Fältmodel | Typstring |
Fältid | Typstring |
Fältprovider | Typstring |
Fältanswers.<id>.type | Typstring |
Fältanswers.<id>.noul | Typnumber |
Fältanswers.<id>.choice | Typstring |
Fältanswers.<id>.score | Typnumber |
Fältanswers.<id>.confidence | Typnumber |
Fältanswers.<id>.probabilities | Typobject |
Fältanswers.<id>.legend | Typobject |
Fältusage.input_tokens | Typinteger |
Fältusage.output_tokens | Typinteger |
Fältusage.cost | Typnumber |
| Svar | Villkor | Nästa steg |
|---|---|---|
Svar400 · invalid_request_error | VillkorOgiltigt obligatoriskt fält, ogiltig representation eller ogiltigt värde | Nästa stegKorrigera det angivna fältet i begäran. |
Ailoot Ultra jaredpalmer/kev-4b
Använd metodsökvägarna som visas ovan.