Kev-4B je kompaktní rozhodovací model pro odpovídání na typované otázky o dodaném stavu. Stav je hodnocený dokument nebo záznam a každá otázka definuje možnosti, které model může hodnotit. Výsledkem je rozdělení pravděpodobností a typovaný rozhodovací záznam, užitečný pro klasifikaci dokumentů, směrování, prvotní třídění, volby při extrakci a kontroly podle stanovených kritérií.
Model kombinuje zmrazený základ Qwen3.5-4B-Base s adaptérem LoRA a ukazovací výstupní hlavou. Základ má 32 vrstev, z toho 24 vrstev Gated DeltaNet a osm vrstev plného mechanismu pozornosti. Adaptér se zaměřuje na projekce pozornosti, MLP a DeltaNet; ukazovací hlava hodnotí dodané možnosti a převádí skóre na pravděpodobnosti. Jde o rozhodovací postup pouze ve fázi prefill, v němž možnosti tvoří prostor odpovědí.
Ve stejném požadavku se mohou objevit tři typy otázek. Otázka choice přijímá 1–255 pojmenovaných možností, případně s popisy, a vrací nejpravděpodobnější možnost, samostatnou hodnotu jistoty a pravděpodobnosti možností. Otázka ano/ne, ve formátu výrobce nazývaná noul, vrací pravděpodobnost odpovědi ano. Význam ano definujte v otázce, místo předpokladu, že vysoké číslo vždy znamená pozitivní výsledek pro aplikaci.
Otázka s uspořádaným skóre přijímá 1–255 úrovní a vrací pravděpodobnosti úrovní a jejich očekávaný index. Indexy úrovní začínají od nuly. Formát výsledku výrobce nese také legendu úrovní a samostatnou hodnotu jistoty. Očekávaný index může být zlomkový: shrnuje rozdělení vašich uspořádaných úrovní, místo aby vybíral nový textový štítek. Uchovejte pořadí úrovní a legendu s výsledkem, aby bylo možné hodnocení interpretovat konzistentně.
Otázky sdílejí stejný stav, ale jsou vyhodnocovány nezávisle. Jedna otázka nemůže číst odpověď jiné a stav se vypočítá jednou a opakovaně použije. Pokud pozdější rozhodnutí závisí na výsledku dřívějšího, vyjádřete tuto závislost výslovně v následném stavu, místo očekávání, že otázky v jednom požadavku vytvoří řetězec. Sdílený stav je tak vhodný pro několik nezávislých kontrol stejného dokumentu.
Připravte stav s podklady, které otázky skutečně vyžadují. Může jít o prostý text nebo objekt či pole JSON zobrazené jako text se štítky. Udržujte názvy polí, jednotky, podmínky pravidel a příslušné zdrojové pasáže jasné. Pro každou otázku napište konkrétní pokyn a dejte jejím možnostem významy rozlišitelné ze záznamu. U původní úlohy směrování podpory může stav obsahovat požadavek a jeho kontext, zatímco možnosti definují kategorie doručení, přístupu a podpory produktu s krátkými popisy.
Druhá otázka může posoudit naléhavost a uspořádaná otázka ohodnotit, kolik následné práce požadavek potřebuje. Odpovídají na různé provozní otázky, proto každou definujte samostatně. Pokud to úloha volby vyžaduje, zahrňte vhodnou možnost kontroly nebo chybějících podkladů a při více věrohodných kategoriích uchovejte úplné rozdělení. Aplikace rozhoduje, jak výsledek směrovat nebo kontrolovat; model dodává ohodnocený záznam.
Kev-4B je určen pro typovaná rozhodnutí nad dokumenty o několika tisících tokenů. Servírovací profil výrobce přijímá stavy do 65 536 tokenů a rezervuje další prostor pro každou otázku, zatímco ověřená délka kontextu tohoto checkpointu je 8192 tokenů. Jde o různé hranice: přijetí delšího stavu nedokládá stejně spolehlivá rozhodnutí při každé délce. Při přípravě dlouhého záznamu ke klasifikaci udržujte rozhodující pasáže stručné a zachovejte jejich štítky.
Vydaný profil je anglický. Jeho užitečné úlohy závisí na podkladech v dodaném stavu a definovaných možnostech, nikoli na otevřeném chatu, shrnování nebo širokém odpovídání založeném na znalostech. Zvláštním omezením je počítání s daty na úrovni dnů: výrobce poskytuje samostatný předzpracovač údajů o datech, který dodává vypočtené intervaly. Pro kontrolu termínu zahrňte do stavu příslušná data a vypočtené intervaly ve dnech spolu s pravidlem, které je používá.
Checkpoint je dodáván s přizpůsobenou kalibrací pravděpodobností, ale jistota se může měnit podle domény dokumentu a návrhu otázky. Výrobce dokumentuje také dolaďování otevřeného checkpointu na štítcích konkrétní úlohy a přizpůsobování jeho pravděpodobnostní kalibrace daným úlohám; jde o samostatný postup úprav odlišný od hodnocení dodaného stavu. Rozhodovací prahy volte pomocí označených příkladů skutečných úloh a udržujte nejisté případy viditelné ke kontrole. Výrobce vylučuje plně automatizovaná rozhodnutí se závažnými důsledky pro lidi bez lidské kontroly. Pořadí možností také může ovlivnit odpověď, proto při porovnávání výsledků zachovejte stabilní řazení. Zvolený štítek, samostatné pole jistoty a rozdělení pravděpodobností posuzujte podle role, kterou každý prvek plní ve vašem pracovním postupu.
Aktuální vydání Kev-4B popsané výrobcem patří do Kev 1.0 a používá základ Qwen3.5. Dřívější vydání založená na Qwen3 a vydání omezená pouze na fázi dokumentu zůstávají odlišnými verzemi. Při vývoji postupu pro konkrétní úlohu udržujte zvolené vydání a definice otázek spojené s výstupy, místo míchání výsledků různých profilů.
Užitečným konečným artefaktem je pojmenovaná sada rozhodovacích záznamů s původními otázkami, definicemi možností, rozděleními a případnými legendami uspořádaných úrovní. Při kontrole kvality odpovědi má stav zahrnovat navrhovanou odpověď, podklady a zkoušené kritérium. Při prvotním třídění podle pravidel má zahrnovat příslušné pravidlo a relevantní fakta. Uchovejte tento vstup vedle výsledku, aby kontrola mohla určit, proč bylo rozhodnutí vhodné nebo který chybějící fakt je třeba doplnit.
", "aboutText": "Kev-4B je kompaktní rozhodovací model pro odpovídání na typované otázky o dodaném stavu. Stav je hodnocený dokument nebo záznam a každá otázka definuje možnosti, které model může hodnotit. Výsledkem je rozdělení pravděpodobností a typovaný rozhodovací záznam, užitečný pro klasifikaci dokumentů, směrování, prvotní třídění, volby při extrakci a kontroly podle stanovených kritérií.\n\nModel kombinuje zmrazený základ Qwen3.5-4B-Base s adaptérem LoRA a ukazovací výstupní hlavou. Základ má 32 vrstev, z toho 24 vrstev Gated DeltaNet a osm vrstev plného mechanismu pozornosti. Adaptér se zaměřuje na projekce pozornosti, MLP a DeltaNet; ukazovací hlava hodnotí dodané možnosti a převádí skóre na pravděpodobnosti. Jde o rozhodovací postup pouze ve fázi prefill, v němž možnosti tvoří prostor odpovědí.\n\nVe stejném požadavku se mohou objevit tři typy otázek. Otázka choice přijímá 1–255 pojmenovaných možností, případně s popisy, a vrací nejpravděpodobnější možnost, samostatnou hodnotu jistoty a pravděpodobnosti možností. Otázka ano/ne, ve formátu výrobce nazývaná noul, vrací pravděpodobnost odpovědi ano. Význam ano definujte v otázce, místo předpokladu, že vysoké číslo vždy znamená pozitivní výsledek pro aplikaci.\n\nOtázka s uspořádaným skóre přijímá 1–255 úrovní a vrací pravděpodobnosti úrovní a jejich očekávaný index. Indexy úrovní začínají od nuly. Formát výsledku výrobce nese také legendu úrovní a samostatnou hodnotu jistoty. Očekávaný index může být zlomkový: shrnuje rozdělení vašich uspořádaných úrovní, místo aby vybíral nový textový štítek. Uchovejte pořadí úrovní a legendu s výsledkem, aby bylo možné hodnocení interpretovat konzistentně.\n\nOtázky sdílejí stejný stav, ale jsou vyhodnocovány nezávisle. Jedna otázka nemůže číst odpověď jiné a stav se vypočítá jednou a opakovaně použije. Pokud pozdější rozhodnutí závisí na výsledku dřívějšího, vyjádřete tuto závislost výslovně v následném stavu, místo očekávání, že otázky v jednom požadavku vytvoří řetězec. Sdílený stav je tak vhodný pro několik nezávislých kontrol stejného dokumentu.\n\nPřipravte stav s podklady, které otázky skutečně vyžadují. Může jít o prostý text nebo objekt či pole JSON zobrazené jako text se štítky. Udržujte názvy polí, jednotky, podmínky pravidel a příslušné zdrojové pasáže jasné. Pro každou otázku napište konkrétní pokyn a dejte jejím možnostem významy rozlišitelné ze záznamu. U původní úlohy směrování podpory může stav obsahovat požadavek a jeho kontext, zatímco možnosti definují kategorie doručení, přístupu a podpory produktu s krátkými popisy.\n\nDruhá otázka může posoudit naléhavost a uspořádaná otázka ohodnotit, kolik následné práce požadavek potřebuje. Odpovídají na různé provozní otázky, proto každou definujte samostatně. Pokud to úloha volby vyžaduje, zahrňte vhodnou možnost kontroly nebo chybějících podkladů a při více věrohodných kategoriích uchovejte úplné rozdělení. Aplikace rozhoduje, jak výsledek směrovat nebo kontrolovat; model dodává ohodnocený záznam.\n\nKev-4B je určen pro typovaná rozhodnutí nad dokumenty o několika tisících tokenů. Servírovací profil výrobce přijímá stavy do 65 536 tokenů a rezervuje další prostor pro každou otázku, zatímco ověřená délka kontextu tohoto checkpointu je 8192 tokenů. Jde o různé hranice: přijetí delšího stavu nedokládá stejně spolehlivá rozhodnutí při každé délce. Při přípravě dlouhého záznamu ke klasifikaci udržujte rozhodující pasáže stručné a zachovejte jejich štítky.\n\nVydaný profil je anglický. Jeho užitečné úlohy závisí na podkladech v dodaném stavu a definovaných možnostech, nikoli na otevřeném chatu, shrnování nebo širokém odpovídání založeném na znalostech. Zvláštním omezením je počítání s daty na úrovni dnů: výrobce poskytuje samostatný předzpracovač údajů o datech, který dodává vypočtené intervaly. Pro kontrolu termínu zahrňte do stavu příslušná data a vypočtené intervaly ve dnech spolu s pravidlem, které je používá.\n\nCheckpoint je dodáván s přizpůsobenou kalibrací pravděpodobností, ale jistota se může měnit podle domény dokumentu a návrhu otázky. Výrobce dokumentuje také dolaďování otevřeného checkpointu na štítcích konkrétní úlohy a přizpůsobování jeho pravděpodobnostní kalibrace daným úlohám; jde o samostatný postup úprav odlišný od hodnocení dodaného stavu. Rozhodovací prahy volte pomocí označených příkladů skutečných úloh a udržujte nejisté případy viditelné ke kontrole. Výrobce vylučuje plně automatizovaná rozhodnutí se závažnými důsledky pro lidi bez lidské kontroly. Pořadí možností také může ovlivnit odpověď, proto při porovnávání výsledků zachovejte stabilní řazení. Zvolený štítek, samostatné pole jistoty a rozdělení pravděpodobností posuzujte podle role, kterou každý prvek plní ve vašem pracovním postupu.\n\nAktuální vydání Kev-4B popsané výrobcem patří do Kev 1.0 a používá základ Qwen3.5. Dřívější vydání založená na Qwen3 a vydání omezená pouze na fázi dokumentu zůstávají odlišnými verzemi. Při vývoji postupu pro konkrétní úlohu udržujte zvolené vydání a definice otázek spojené s výstupy, místo míchání výsledků různých profilů.\n\nUžitečným konečným artefaktem je pojmenovaná sada rozhodovacích záznamů s původními otázkami, definicemi možností, rozděleními a případnými legendami uspořádaných úrovní. Při kontrole kvality odpovědi má stav zahrnovat navrhovanou odpověď, podklady a zkoušené kritérium. Při prvotním třídění podle pravidel má zahrnovat příslušné pravidlo a relevantní fakta. Uchovejte tento vstup vedle výsledku, aby kontrola mohla určit, proč bylo rozhodnutí vhodné nebo který chybějící fakt je třeba doplnit.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "afdafd8ba0a37d5c21e7127cab0f2727c958969f27c0d306c22195f61b63d4b5", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "cs", "methods": [ { "html": "jaredpalmer/kev-4bKev-4B hodnotí typované otázky o dodaném anglickém dokumentu a vrací kalibrované pravděpodobnosti možností, které definujete. Používejte otázky ano/ne, choice a uspořádané skóre pro klasifikaci, směrování, prvotní třídění a kontroly vyžadující strukturované rozhodnutí namísto generovaného textu.
Tento popis zahrnuje schopnosti modelu. Vstupy, výstupy a možnosti dostupné v Ailoot jsou uvedeny níže pro vybranou metodu.
Kev-4B je kompaktní rozhodovací model pro odpovídání na typované otázky o dodaném stavu. Stav je hodnocený dokument nebo záznam a každá otázka definuje možnosti, které model může hodnotit. Výsledkem je rozdělení pravděpodobností a typovaný rozhodovací záznam, užitečný pro klasifikaci dokumentů, směrování, prvotní třídění, volby při extrakci a kontroly podle stanovených kritérií.
Model kombinuje zmrazený základ Qwen3.5-4B-Base s adaptérem LoRA a ukazovací výstupní hlavou. Základ má 32 vrstev, z toho 24 vrstev Gated DeltaNet a osm vrstev plného mechanismu pozornosti. Adaptér se zaměřuje na projekce pozornosti, MLP a DeltaNet; ukazovací hlava hodnotí dodané možnosti a převádí skóre na pravděpodobnosti. Jde o rozhodovací postup pouze ve fázi prefill, v němž možnosti tvoří prostor odpovědí.
Ve stejném požadavku se mohou objevit tři typy otázek. Otázka choice přijímá 1–255 pojmenovaných možností, případně s popisy, a vrací nejpravděpodobnější možnost, samostatnou hodnotu jistoty a pravděpodobnosti možností. Otázka ano/ne, ve formátu výrobce nazývaná noul, vrací pravděpodobnost odpovědi ano. Význam ano definujte v otázce, místo předpokladu, že vysoké číslo vždy znamená pozitivní výsledek pro aplikaci.
Otázka s uspořádaným skóre přijímá 1–255 úrovní a vrací pravděpodobnosti úrovní a jejich očekávaný index. Indexy úrovní začínají od nuly. Formát výsledku výrobce nese také legendu úrovní a samostatnou hodnotu jistoty. Očekávaný index může být zlomkový: shrnuje rozdělení vašich uspořádaných úrovní, místo aby vybíral nový textový štítek. Uchovejte pořadí úrovní a legendu s výsledkem, aby bylo možné hodnocení interpretovat konzistentně.
Otázky sdílejí stejný stav, ale jsou vyhodnocovány nezávisle. Jedna otázka nemůže číst odpověď jiné a stav se vypočítá jednou a opakovaně použije. Pokud pozdější rozhodnutí závisí na výsledku dřívějšího, vyjádřete tuto závislost výslovně v následném stavu, místo očekávání, že otázky v jednom požadavku vytvoří řetězec. Sdílený stav je tak vhodný pro několik nezávislých kontrol stejného dokumentu.
Připravte stav s podklady, které otázky skutečně vyžadují. Může jít o prostý text nebo objekt či pole JSON zobrazené jako text se štítky. Udržujte názvy polí, jednotky, podmínky pravidel a příslušné zdrojové pasáže jasné. Pro každou otázku napište konkrétní pokyn a dejte jejím možnostem významy rozlišitelné ze záznamu. U původní úlohy směrování podpory může stav obsahovat požadavek a jeho kontext, zatímco možnosti definují kategorie doručení, přístupu a podpory produktu s krátkými popisy.
Druhá otázka může posoudit naléhavost a uspořádaná otázka ohodnotit, kolik následné práce požadavek potřebuje. Odpovídají na různé provozní otázky, proto každou definujte samostatně. Pokud to úloha volby vyžaduje, zahrňte vhodnou možnost kontroly nebo chybějících podkladů a při více věrohodných kategoriích uchovejte úplné rozdělení. Aplikace rozhoduje, jak výsledek směrovat nebo kontrolovat; model dodává ohodnocený záznam.
Kev-4B je určen pro typovaná rozhodnutí nad dokumenty o několika tisících tokenů. Servírovací profil výrobce přijímá stavy do 65 536 tokenů a rezervuje další prostor pro každou otázku, zatímco ověřená délka kontextu tohoto checkpointu je 8192 tokenů. Jde o různé hranice: přijetí delšího stavu nedokládá stejně spolehlivá rozhodnutí při každé délce. Při přípravě dlouhého záznamu ke klasifikaci udržujte rozhodující pasáže stručné a zachovejte jejich štítky.
Vydaný profil je anglický. Jeho užitečné úlohy závisí na podkladech v dodaném stavu a definovaných možnostech, nikoli na otevřeném chatu, shrnování nebo širokém odpovídání založeném na znalostech. Zvláštním omezením je počítání s daty na úrovni dnů: výrobce poskytuje samostatný předzpracovač údajů o datech, který dodává vypočtené intervaly. Pro kontrolu termínu zahrňte do stavu příslušná data a vypočtené intervaly ve dnech spolu s pravidlem, které je používá.
Checkpoint je dodáván s přizpůsobenou kalibrací pravděpodobností, ale jistota se může měnit podle domény dokumentu a návrhu otázky. Výrobce dokumentuje také dolaďování otevřeného checkpointu na štítcích konkrétní úlohy a přizpůsobování jeho pravděpodobnostní kalibrace daným úlohám; jde o samostatný postup úprav odlišný od hodnocení dodaného stavu. Rozhodovací prahy volte pomocí označených příkladů skutečných úloh a udržujte nejisté případy viditelné ke kontrole. Výrobce vylučuje plně automatizovaná rozhodnutí se závažnými důsledky pro lidi bez lidské kontroly. Pořadí možností také může ovlivnit odpověď, proto při porovnávání výsledků zachovejte stabilní řazení. Zvolený štítek, samostatné pole jistoty a rozdělení pravděpodobností posuzujte podle role, kterou každý prvek plní ve vašem pracovním postupu.
Aktuální vydání Kev-4B popsané výrobcem patří do Kev 1.0 a používá základ Qwen3.5. Dřívější vydání založená na Qwen3 a vydání omezená pouze na fázi dokumentu zůstávají odlišnými verzemi. Při vývoji postupu pro konkrétní úlohu udržujte zvolené vydání a definice otázek spojené s výstupy, místo míchání výsledků různých profilů.
Užitečným konečným artefaktem je pojmenovaná sada rozhodovacích záznamů s původními otázkami, definicemi možností, rozděleními a případnými legendami uspořádaných úrovní. Při kontrole kvality odpovědi má stav zahrnovat navrhovanou odpověď, podklady a zkoušené kritérium. Při prvotním třídění podle pravidel má zahrnovat příslušné pravidlo a relevantní fakta. Uchovejte tento vstup vedle výsledku, aby kontrola mohla určit, proč bylo rozhodnutí vhodné nebo který chybějící fakt je třeba doplnit.
POST /v1/systemonetextdecisions| Pole | Typ | Požadavek | Hodnoty a limity | Výchozí |
|---|---|---|---|---|
Polemodel | Typstring | PožadavekPovinné | Hodnoty a limity jaredpalmer/kev-4b | Výchozí— |
Poleprovider | Typschema | PožadavekVolitelné | Hodnoty a limity | Výchozí— |
Polequestions | Typobject | PožadavekPovinné | Hodnoty a limity | Výchozí— |
Polesession_id | Typstring | PožadavekVolitelné | Hodnoty a limity | Výchozí— |
Polestate | Typschema | PožadavekPovinné | Hodnoty a limity | Výchozí— |
Poletrace | Typschema | PožadavekVolitelné | Hodnoty a limity | Výchozí— |
Poleuser | Typstring | PožadavekVolitelné | Hodnoty a limity | Výchozí— |
Polequestions.<id>.type | Typstring | PožadavekPovinné | Hodnoty a limity noul, choice, score | Výchozí— |
Polequestions.<id>.instructions | Typstring|object|array | PožadavekPovinné | Hodnoty a limity | Výchozí— |
Polequestions.<id>.criteria | Typobject|array | PožadavekVolitelné | Hodnoty a limity Podmínky: choice/score: povinné; noul: volitelné. Kritéria choice tvoří objekt; score je pole s minItems1. | Výchozí— |
Polequestions.<id>.criteria.true | Typstring|object|array | PožadavekPovinné | Hodnoty a limity Platí, když: Je zadán objekt kritérií noul | Výchozí— |
Polequestions.<id>.criteria.false | Typstring|object|array | PožadavekPovinné | Hodnoty a limity Platí, když: Je zadán objekt kritérií noul | Výchozí— |
noul · Povinné: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Povinné: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Povinné: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Parametr | Kontrakt |
|---|---|
Parametrcontent_type | Kontraktapplication/json |
Parametrrequired | Kontraktmodel, state, questions |
Parametrmaterial_types | Kontrakttext |
Parametroptional_controls | Kontraktprovider, session_id, trace, user |
Parametrmultimodal_input_binding | Kontraktnull |
Životní cyklus: synchronous
Odešlete přesné ID modelu a uchovejte celou nativní odpověď.
Údaje o tarifech nepřidávají možnosti požadavku. Podporované parametry jsou uvedeny u vybrané metody.
Přiřaďte každý poplatek k uvedeným podmínkám. Pro každou sadu alternativních konfigurací použijte jednu sazbu.
| Konfigurace | Tabulka sazeb | Tokeny kontextu, více než | Tokeny kontextu, do uvedené hodnoty včetně | Poplatek |
|---|---|---|---|---|
| KonfiguraceZákladní sazby za tokeny | Tabulka sazebZákladní sazba | Tokeny kontextu, více než— | Tokeny kontextu, do uvedené hodnoty včetněBez horní meze | Poplatek Vstup · Vstupní tokeny $0.000084 / 1K tokenů Výstup · Výstupní tokeny $0 / 1K tokenů Vstup · Čtení z mezipaměti — / 1K tokenů Vstup · Zápis do mezipaměti — / 1K tokenů Vstup · Zápis do mezipaměti, 1 hodina — / 1K tokenů |
| KonfiguracePásmo délky požadavku 1 | Tabulka sazeb— | Tokeny kontextu, více než0 | Tokeny kontextu, do uvedené hodnoty včetněBez horní meze | Poplatek Vstup · Vstupní tokeny $0.000084 / 1K tokenů Výstup · Výstupní tokeny $0 / 1K tokenů Vstup · Čtení z mezipaměti — / 1K tokenů Vstup · Zápis do mezipaměti — / 1K tokenů Vstup · Zápis do mezipaměti, 1 hodina — / 1K tokenů |
Ailoot před požadavkem rezervuje odhadovanou částku. Po výsledku vyúčtuje konečný poplatek podle naměřeného využití. Při streamování se účtování řídí konečným záznamem využití. Jak funguje rezervace a vyúčtování →
{\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
Uchovejte každou úplnou vrácenou odpověď, soubor i část obsahu.
Zachovává se každá poskytnutá odpověď přiřazená k ID otázky, její přesný typ, hodnota noul/choice/score, míra jistoty, pravděpodobnosti a legenda. Celý původní JSON se uloží a vrátí až po vyúčtování.
Zachovejte původní operaci a úplnou či částečnou odpověď; požadavek POST neopakujte.
| Pole | Typ |
|---|---|
Polemodel | Typstring |
Poleid | Typstring |
Poleprovider | Typstring |
Poleanswers.<id>.type | Typstring |
Poleanswers.<id>.noul | Typnumber |
Poleanswers.<id>.choice | Typstring |
Poleanswers.<id>.score | Typnumber |
Poleanswers.<id>.confidence | Typnumber |
Poleanswers.<id>.probabilities | Typobject |
Poleanswers.<id>.legend | Typobject |
Poleusage.input_tokens | Typinteger |
Poleusage.output_tokens | Typinteger |
Poleusage.cost | Typnumber |
| Odpověď | Podmínka | Další krok |
|---|---|---|
Odpověď400 · invalid_request_error | PodmínkaNeplatné povinné pole, způsob zadání nebo hodnota | Další krokOpravte označené pole požadavku. |
Ailoot Ultra jaredpalmer/kev-4b
Použijte cesty metod uvedené výše.