d1 är Liquid AI:s driftade beslutsmodell för avgränsade uppgifter inom klassificering, routning och poängsättning. Denna profil omfattar dess arbetsflöde för textbeslut: ange underlaget som ett tillstånd, definiera en eller flera frågor och få typade numeriska svar över kända utfall. Liquid beskriver dessa beslut som utvärderingar som returnerar sannolikheter direkt, med noll genererade utdatatoken. Det användbara resultatet är ett definierat beslut och dess osäkerhet snarare än ett nyskrivet textstycke.
Ange den text som gör beslutet möjligt, inklusive den kontext som behövs för att tolka den. Håll tillståndet åtskilt från instruktionerna som beskriver vad som ska utvärderas. Ett supportmeddelande kan behöva en produkt- eller problembeskrivning; ett dokumentavsnitt kan behöva användarens sökfråga. Definiera svarsmängden innan du ställer frågan, och ge varje alternativ en betydelse som passar det avsedda arbetsflödet. Korta etiketter kan fungera som stabila utdatanycklar, medan beskrivningarna förklarar gränserna mellan dem.
Använd namngivna frågor över ett gemensamt tillstånd. Ett tydligt namn som intent, urgency eller relevant håller utdatan kopplad till det beslut den representerar. Ett meddelande som rapporterar att en sida inte fungerar kan till exempel stödja ett avsiktsval, en bedömning av brådska enligt en matris och en ja/nej-kontroll av ett rapporterat fel. Varje fråga ska behålla sitt eget kriterium i stället för att alla tre bedömningarna kombineras i en enda tvetydig etikett.
En choice-fråga väljer en etikett ur en oordnad mängd och returnerar fördelningen över de namngivna alternativen. Definiera alternativen genom kriteriebeskrivningar; resultatet innehåller det valda alternativet, sannolikheter och konfidens. För dokumentorganisering definierar du de möjliga mapparna eller ämnena och anger vilket innehåll som hör hemma i var och en. För routning av förfrågningar beskriver du de destinationer som faktiskt finns. En applikation kan använda den resulterande etiketten för att välja sitt nästa steg och samtidigt behålla de konkurrerande sannolikheterna för granskning.
En illustrativ arkiveringsuppgift kan skilja mellan en produktfråga, ett integrationsproblem och ett åtkomstproblem, med ett övrigt-alternativ för material utanför dessa definitioner. Håll gränserna konkreta: ett meddelande där autentiseringen misslyckas skiljer sig från ett som frågar hur en funktion konfigureras. Den returnerade etiketten väljer bland angivna betydelser; den skapar ingen saknad destination och utför ingen ändring i ett annat system.
En noul-fråga returnerar en sannolikhet från 0 till 1 för att det definierade ja/nej-villkoret är uppfyllt. Liquid visar binära kontroller för innehållsgranskning och för relevans hos textavsnitt. Formulera villkoret exakt och välj hur den resulterande sannolikheten ska användas: flagga en sannolik träff, filtrera ett textavsnitt eller skicka ett osäkert fall till granskning. Tröskeln hör till den mottagande uppgiften, och en sannolikhet ska inte behandlas som ett garanterat faktiskt avgörande.
För relevansfiltrering anger du både sökfrågan och kandidatavsnittet. Fråga om avsnittet hjälper till att besvara sökfrågan och behåll sedan det ursprungliga avsnittet tillsammans med dess sannolikhet. Det kan stödja valet av källmaterial för ett senare svar utan att d1 ombeds skriva det svaret själv. Om relevansen behöver flera grader i stället för ett ja/nej-villkor, definiera en ordnad bedömningsmatris och använd en score-fråga.
En score-fråga placerar tillståndet på en bedömningsmatris med ordnade, beskrivna nivåer. Nivåindexen börjar på 0, och poängen är deras sannolikhetsviktade position, som kan hamna mellan nivåer. Resultatet innehåller också nivåfördelningen och konfidens. För brådska definierar du vad som skiljer ett problem utan omedelbar påverkan, en betydande olägenhet och en blockerad uppgift. En matris med fyra nivåer har därför index 0 till och med 3; dess förväntade poäng är inte automatiskt en kategori numrerad 1 till och med 4.
Använd decimalpoängen för ordning eller aggregering när det är det avsedda resultatet, och behåll hela fördelningen när tvetydighet spelar roll. Kategorier som avdelningar har ingen naturlig ordning och hör hemma i en choice-fråga. Konfidens sammanfattar i det dokumenterade gränssnittet hur entydigt det rapporterade svaret är; den ska hållas åtskild från uppgiftens önskade poäng och från ett antaget löfte om att beslutet är korrekt.
Flera frågor kan utvärdera samma tillstånd i ett enda producentanrop, där var och en behåller sin typ och sina sannolikheter. Liquids textexempel omfattar filtrering av supportärenden, arkivering av dokument i en mapptaxonomi, val av sökvägar för kodsökning, val bland tillgängliga agentåtgärder och beslut om vilket material från verktygsutdata som ska behållas. Alla dessa arbetsflöden har ett avgränsat nästa beslut. Ett kodsökningssteg kan välja en lovande mapp utifrån dess beskrivning; ett steg för innehållsurval kan välja att behålla, korta eller ta bort angivet material. Den omgivande applikationen hämtar fortfarande källdata och utför den valda åtgärden.
De dokumenterade primitiverna passar för kända utfall, betyg enligt bedömningsmatris och villkorskontroller. Ny löptext, sammanfattningar, kod och en öppen konversation kräver ett genereringsflöde och följer inte av beslutsresultatet från d1. Utforma en fråga kring observerbart underlag och behåll frågans definitioner tillsammans med utdatan så att en etikett eller poäng kan tolkas senare.
Håll varje tillstånd fokuserat på det underlag som besvarar dess definierade frågor, och separera orelaterade beslutsuppgifter så att deras kriterier förblir tydliga. Håll källmaterialet relevant, definiera reservbetydelser för ofullständig kategoritäckning och bedöm sannolikhetströsklar med märkta exempel från uppgiften. En användbar artefakt registrerar den valda kategorin eller den förväntade poängen tillsammans med dess fördelning, frågans identitet och det ursprungliga underlaget.
", "aboutText": "d1 är Liquid AI:s driftade beslutsmodell för avgränsade uppgifter inom klassificering, routning och poängsättning. Denna profil omfattar dess arbetsflöde för textbeslut: ange underlaget som ett tillstånd, definiera en eller flera frågor och få typade numeriska svar över kända utfall. Liquid beskriver dessa beslut som utvärderingar som returnerar sannolikheter direkt, med noll genererade utdatatoken. Det användbara resultatet är ett definierat beslut och dess osäkerhet snarare än ett nyskrivet textstycke.\n\n### Förbered underlaget och frågan tillsammans\n\nAnge den text som gör beslutet möjligt, inklusive den kontext som behövs för att tolka den. Håll tillståndet åtskilt från instruktionerna som beskriver vad som ska utvärderas. Ett supportmeddelande kan behöva en produkt- eller problembeskrivning; ett dokumentavsnitt kan behöva användarens sökfråga. Definiera svarsmängden innan du ställer frågan, och ge varje alternativ en betydelse som passar det avsedda arbetsflödet. Korta etiketter kan fungera som stabila utdatanycklar, medan beskrivningarna förklarar gränserna mellan dem.\n\nAnvänd namngivna frågor över ett gemensamt tillstånd. Ett tydligt namn som intent, urgency eller relevant håller utdatan kopplad till det beslut den representerar. Ett meddelande som rapporterar att en sida inte fungerar kan till exempel stödja ett avsiktsval, en bedömning av brådska enligt en matris och en ja/nej-kontroll av ett rapporterat fel. Varje fråga ska behålla sitt eget kriterium i stället för att alla tre bedömningarna kombineras i en enda tvetydig etikett.\n\n### Choice för kategorier och routning\n\nEn choice-fråga väljer en etikett ur en oordnad mängd och returnerar fördelningen över de namngivna alternativen. Definiera alternativen genom kriteriebeskrivningar; resultatet innehåller det valda alternativet, sannolikheter och konfidens. För dokumentorganisering definierar du de möjliga mapparna eller ämnena och anger vilket innehåll som hör hemma i var och en. För routning av förfrågningar beskriver du de destinationer som faktiskt finns. En applikation kan använda den resulterande etiketten för att välja sitt nästa steg och samtidigt behålla de konkurrerande sannolikheterna för granskning.\n\nEn illustrativ arkiveringsuppgift kan skilja mellan en produktfråga, ett integrationsproblem och ett åtkomstproblem, med ett övrigt-alternativ för material utanför dessa definitioner. Håll gränserna konkreta: ett meddelande där autentiseringen misslyckas skiljer sig från ett som frågar hur en funktion konfigureras. Den returnerade etiketten väljer bland angivna betydelser; den skapar ingen saknad destination och utför ingen ändring i ett annat system.\n\n### Noul för villkorskontroller och relevans\n\nEn noul-fråga returnerar en sannolikhet från 0 till 1 för att det definierade ja/nej-villkoret är uppfyllt. Liquid visar binära kontroller för innehållsgranskning och för relevans hos textavsnitt. Formulera villkoret exakt och välj hur den resulterande sannolikheten ska användas: flagga en sannolik träff, filtrera ett textavsnitt eller skicka ett osäkert fall till granskning. Tröskeln hör till den mottagande uppgiften, och en sannolikhet ska inte behandlas som ett garanterat faktiskt avgörande.\n\nFör relevansfiltrering anger du både sökfrågan och kandidatavsnittet. Fråga om avsnittet hjälper till att besvara sökfrågan och behåll sedan det ursprungliga avsnittet tillsammans med dess sannolikhet. Det kan stödja valet av källmaterial för ett senare svar utan att d1 ombeds skriva det svaret själv. Om relevansen behöver flera grader i stället för ett ja/nej-villkor, definiera en ordnad bedömningsmatris och använd en score-fråga.\n\n### Score för ordnade nivåer\n\nEn score-fråga placerar tillståndet på en bedömningsmatris med ordnade, beskrivna nivåer. Nivåindexen börjar på 0, och poängen är deras sannolikhetsviktade position, som kan hamna mellan nivåer. Resultatet innehåller också nivåfördelningen och konfidens. För brådska definierar du vad som skiljer ett problem utan omedelbar påverkan, en betydande olägenhet och en blockerad uppgift. En matris med fyra nivåer har därför index 0 till och med 3; dess förväntade poäng är inte automatiskt en kategori numrerad 1 till och med 4.\n\nAnvänd decimalpoängen för ordning eller aggregering när det är det avsedda resultatet, och behåll hela fördelningen när tvetydighet spelar roll. Kategorier som avdelningar har ingen naturlig ordning och hör hemma i en choice-fråga. Konfidens sammanfattar i det dokumenterade gränssnittet hur entydigt det rapporterade svaret är; den ska hållas åtskild från uppgiftens önskade poäng och från ett antaget löfte om att beslutet är korrekt.\n\n### Flera frågor och producentens tillämpningar\n\nFlera frågor kan utvärdera samma tillstånd i ett enda producentanrop, där var och en behåller sin typ och sina sannolikheter. Liquids textexempel omfattar filtrering av supportärenden, arkivering av dokument i en mapptaxonomi, val av sökvägar för kodsökning, val bland tillgängliga agentåtgärder och beslut om vilket material från verktygsutdata som ska behållas. Alla dessa arbetsflöden har ett avgränsat nästa beslut. Ett kodsökningssteg kan välja en lovande mapp utifrån dess beskrivning; ett steg för innehållsurval kan välja att behålla, korta eller ta bort angivet material. Den omgivande applikationen hämtar fortfarande källdata och utför den valda åtgärden.\n\n### Omfång och en användbar beslutsartefakt\n\nDe dokumenterade primitiverna passar för kända utfall, betyg enligt bedömningsmatris och villkorskontroller. Ny löptext, sammanfattningar, kod och en öppen konversation kräver ett genereringsflöde och följer inte av beslutsresultatet från d1. Utforma en fråga kring observerbart underlag och behåll frågans definitioner tillsammans med utdatan så att en etikett eller poäng kan tolkas senare.\n\nHåll varje tillstånd fokuserat på det underlag som besvarar dess definierade frågor, och separera orelaterade beslutsuppgifter så att deras kriterier förblir tydliga. Håll källmaterialet relevant, definiera reservbetydelser för ofullständig kategoritäckning och bedöm sannolikhetströsklar med märkta exempel från uppgiften. En användbar artefakt registrerar den valda kategorin eller den förväntade poängen tillsammans med dess fördelning, frågans identitet och det ursprungliga underlaget.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "1ad883d2ca2bfe8919cfaec56f8bbffa774839de7062e55c3944b112dd252a06", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "sv", "methods": [ { "html": "liquid/d1Arbetsflödet för textbeslut i Liquid AI d1 utvärderar angivet underlag mot fasta utfall och returnerar sannolikheter, ett kategorival eller en poäng enligt en bedömningsmatris. Det stöder klassificering, routning, relevansfiltrering och prioritering utan att generera ett skrivet svar.
Den här beskrivningen omfattar modellens förmågor. Tillgängliga indata, utdata och alternativ i Ailoot anges nedan för den valda metoden.
d1 är Liquid AI:s driftade beslutsmodell för avgränsade uppgifter inom klassificering, routning och poängsättning. Denna profil omfattar dess arbetsflöde för textbeslut: ange underlaget som ett tillstånd, definiera en eller flera frågor och få typade numeriska svar över kända utfall. Liquid beskriver dessa beslut som utvärderingar som returnerar sannolikheter direkt, med noll genererade utdatatoken. Det användbara resultatet är ett definierat beslut och dess osäkerhet snarare än ett nyskrivet textstycke.
Ange den text som gör beslutet möjligt, inklusive den kontext som behövs för att tolka den. Håll tillståndet åtskilt från instruktionerna som beskriver vad som ska utvärderas. Ett supportmeddelande kan behöva en produkt- eller problembeskrivning; ett dokumentavsnitt kan behöva användarens sökfråga. Definiera svarsmängden innan du ställer frågan, och ge varje alternativ en betydelse som passar det avsedda arbetsflödet. Korta etiketter kan fungera som stabila utdatanycklar, medan beskrivningarna förklarar gränserna mellan dem.
Använd namngivna frågor över ett gemensamt tillstånd. Ett tydligt namn som intent, urgency eller relevant håller utdatan kopplad till det beslut den representerar. Ett meddelande som rapporterar att en sida inte fungerar kan till exempel stödja ett avsiktsval, en bedömning av brådska enligt en matris och en ja/nej-kontroll av ett rapporterat fel. Varje fråga ska behålla sitt eget kriterium i stället för att alla tre bedömningarna kombineras i en enda tvetydig etikett.
En choice-fråga väljer en etikett ur en oordnad mängd och returnerar fördelningen över de namngivna alternativen. Definiera alternativen genom kriteriebeskrivningar; resultatet innehåller det valda alternativet, sannolikheter och konfidens. För dokumentorganisering definierar du de möjliga mapparna eller ämnena och anger vilket innehåll som hör hemma i var och en. För routning av förfrågningar beskriver du de destinationer som faktiskt finns. En applikation kan använda den resulterande etiketten för att välja sitt nästa steg och samtidigt behålla de konkurrerande sannolikheterna för granskning.
En illustrativ arkiveringsuppgift kan skilja mellan en produktfråga, ett integrationsproblem och ett åtkomstproblem, med ett övrigt-alternativ för material utanför dessa definitioner. Håll gränserna konkreta: ett meddelande där autentiseringen misslyckas skiljer sig från ett som frågar hur en funktion konfigureras. Den returnerade etiketten väljer bland angivna betydelser; den skapar ingen saknad destination och utför ingen ändring i ett annat system.
En noul-fråga returnerar en sannolikhet från 0 till 1 för att det definierade ja/nej-villkoret är uppfyllt. Liquid visar binära kontroller för innehållsgranskning och för relevans hos textavsnitt. Formulera villkoret exakt och välj hur den resulterande sannolikheten ska användas: flagga en sannolik träff, filtrera ett textavsnitt eller skicka ett osäkert fall till granskning. Tröskeln hör till den mottagande uppgiften, och en sannolikhet ska inte behandlas som ett garanterat faktiskt avgörande.
För relevansfiltrering anger du både sökfrågan och kandidatavsnittet. Fråga om avsnittet hjälper till att besvara sökfrågan och behåll sedan det ursprungliga avsnittet tillsammans med dess sannolikhet. Det kan stödja valet av källmaterial för ett senare svar utan att d1 ombeds skriva det svaret själv. Om relevansen behöver flera grader i stället för ett ja/nej-villkor, definiera en ordnad bedömningsmatris och använd en score-fråga.
En score-fråga placerar tillståndet på en bedömningsmatris med ordnade, beskrivna nivåer. Nivåindexen börjar på 0, och poängen är deras sannolikhetsviktade position, som kan hamna mellan nivåer. Resultatet innehåller också nivåfördelningen och konfidens. För brådska definierar du vad som skiljer ett problem utan omedelbar påverkan, en betydande olägenhet och en blockerad uppgift. En matris med fyra nivåer har därför index 0 till och med 3; dess förväntade poäng är inte automatiskt en kategori numrerad 1 till och med 4.
Använd decimalpoängen för ordning eller aggregering när det är det avsedda resultatet, och behåll hela fördelningen när tvetydighet spelar roll. Kategorier som avdelningar har ingen naturlig ordning och hör hemma i en choice-fråga. Konfidens sammanfattar i det dokumenterade gränssnittet hur entydigt det rapporterade svaret är; den ska hållas åtskild från uppgiftens önskade poäng och från ett antaget löfte om att beslutet är korrekt.
Flera frågor kan utvärdera samma tillstånd i ett enda producentanrop, där var och en behåller sin typ och sina sannolikheter. Liquids textexempel omfattar filtrering av supportärenden, arkivering av dokument i en mapptaxonomi, val av sökvägar för kodsökning, val bland tillgängliga agentåtgärder och beslut om vilket material från verktygsutdata som ska behållas. Alla dessa arbetsflöden har ett avgränsat nästa beslut. Ett kodsökningssteg kan välja en lovande mapp utifrån dess beskrivning; ett steg för innehållsurval kan välja att behålla, korta eller ta bort angivet material. Den omgivande applikationen hämtar fortfarande källdata och utför den valda åtgärden.
De dokumenterade primitiverna passar för kända utfall, betyg enligt bedömningsmatris och villkorskontroller. Ny löptext, sammanfattningar, kod och en öppen konversation kräver ett genereringsflöde och följer inte av beslutsresultatet från d1. Utforma en fråga kring observerbart underlag och behåll frågans definitioner tillsammans med utdatan så att en etikett eller poäng kan tolkas senare.
Håll varje tillstånd fokuserat på det underlag som besvarar dess definierade frågor, och separera orelaterade beslutsuppgifter så att deras kriterier förblir tydliga. Håll källmaterialet relevant, definiera reservbetydelser för ofullständig kategoritäckning och bedöm sannolikhetströsklar med märkta exempel från uppgiften. En användbar artefakt registrerar den valda kategorin eller den förväntade poängen tillsammans med dess fördelning, frågans identitet och det ursprungliga underlaget.
POST /v1/systemonetextdecisions| Fält | Typ | Krav | Värden & gränser | Standard |
|---|---|---|---|---|
Fältmodel | Typstring | KravObligatoriskt | Värden & gränser liquid/d1 | 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.00008 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning $0.00008 / 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.00008 / 1K token Utdata · Utdatatoken $0 / 1K token Indata · Cacheläsning $0.00008 / 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": "liquid/d1",\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']='liquid/d1'\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 liquid/d1
Använd metodsökvägarna som visas ovan.