A Kev-4B kompakt döntési modell megadott állapotra vonatkozó típusos kérdések megválaszolásához. Az állapot az értékelt dokumentum vagy rekord, és minden kérdés meghatározza a modell által pontozható lehetőségeket. Eredménye valószínűségi eloszlás és típusos döntési rekord, így dokumentumosztályozáshoz, továbbirányításhoz, triázshoz, adatkinyerési választásokhoz és megadott kritériumok szerinti ellenőrzésekhez használható.
A modell fagyasztott Qwen3.5-4B-Base alapmodellt kapcsol össze LoRA-adapterrel és mutatófejjel. Az alapmodell 32 rétegből áll: 24 Gated DeltaNet rétegből és nyolc teljes figyelmi rétegből. Az adapter a figyelmi, MLP- és DeltaNet-projekciókat célozza; a mutatófej pontozza a megadott lehetőségeket, és ezeket a pontszámokat valószínűségekké alakítja. Ez kizárólag prefill szakaszt használó döntési munkafolyamat, amelyben a lehetőségek alkotják a választeret.
Ugyanabban a kérésben három kérdéstípus szerepelhet. A choice kérdés 1–255 elnevezett lehetőséget fogad, opcionális leírásokkal, és visszaadja a legvalószínűbb lehetőséget, egy külön megbízhatósági értéket és a lehetőségek valószínűségeit. Az igen/nem kérdés, amelyet a gyártó formátuma noul néven nevez, az igen valószínűségét adja vissza. Az igen jelentését a kérdésben határozza meg, ne feltételezze, hogy a magas szám mindig pozitív kimenetelt jelent az alkalmazás számára.
A rendezett pontozási kérdés 1–255 szintet fogad, és visszaadja a szintek valószínűségeit és várható indexüket. A szintindexek nullától indulnak. A gyártó eredményformátuma a szintjelmagyarázatot és egy külön megbízhatósági értéket is hordoz. A várható index tört érték lehet: az Ön rendezett szintjeinek eloszlását összegzi, nem új szöveges címkét választ. A szintek sorrendjét és jelmagyarázatát tartsa az eredménnyel együtt, hogy az értékelés következetesen értelmezhető legyen.
A kérdések ugyanazon állapoton osztoznak, de egymástól függetlenül értékelődnek. Egy kérdés nem olvashatja egy másik válaszát, az állapotot pedig egyszer számítja ki és használja újra a rendszer. Ha egy későbbi döntés egy korábbi döntés eredményétől függ, ezt a függőséget egy következő állapotban tegye egyértelművé, ne várja el, hogy egy kérés kérdései láncot alkossanak. Ez alkalmassá teszi a közös állapotú munkafolyamatot ugyanazon dokumentum több független ellenőrzésére.
Az állapotot a kérdésekhez ténylegesen szükséges bizonyítékkal készítse elő. Lehet egyszerű szöveg, vagy címkézett szöveggé alakított JSON-objektum vagy -tömb. A mezőnevek, mértékegységek, szabályfeltételek és releváns forrásrészletek legyenek világosak. Minden kérdéshez írjon konkrét utasítást, és a lehetőségeknek olyan jelentést adjon, amely a rekord alapján megkülönböztethető. Egy eredeti ügyfélszolgálati továbbirányítási feladatnál az állapot tartalmazhatja a kérést és kontextusát, a választások pedig rövid leírásokkal meghatározhatják a kézbesítési, hozzáférési és terméktámogatási kategóriákat.
Egy második kérdés felmérheti a sürgősséget, egy rendezett kérdés pedig értékelheti, mennyi utókövetést igényel a kérés. Ezek eltérő működési kérdésekre válaszolnak, ezért külön határozza meg őket. Szerepeltessen megfelelő ellenőrzési vagy hiányzó bizonyítékot jelző lehetőséget, ha a választási feladatnak szüksége van rá, és tartsa meg a teljes eloszlást, ha több kategória is hihető. Az alkalmazás dönti el, hogyan irányítja tovább vagy ellenőrzi az eredményt; a modell a pontozott rekordot szolgáltatja.
A Kev-4B néhány ezer tokenes dokumentumok fölötti típusos döntésekre készült. A gyártó kiszolgálási profilja legfeljebb 65 536 tokenes állapotokat fogad, és minden kérdéshez további helyet tart fenn, míg e checkpoint validált kontextushossza 8192 token. Ezek különböző határok: a hosszabb állapot elfogadása nem igazol minden hosszon egyformán megbízható döntéseket. Tartsa tömören a döntő részleteket, és őrizze meg címkéiket, amikor hosszú rekordot készít elő osztályozáshoz.
A kiadott profil angol nyelvű. Hasznos feladatai a megadott állapot bizonyítékától és a meghatározott lehetőségektől függenek, nem nyitott végű csevegéstől, összefoglalástól vagy széles körű tudásalapú válaszadástól. Külön korlát a nap pontosságú dátumszámítás: a gyártó külön dátumtény-előfeldolgozót ad, amely kiszámított időközöket szolgáltat. Határidő-ellenőrzésnél az állapotba foglalja bele a releváns dátumokat és a kiszámított napintervallumokat, valamint az ezeket használó szabályt.
A checkpoint illesztett valószínűség-kalibrálással érkezik, de a megbízhatósági érték változhat a dokumentum szakterületével és a kérdések kialakításával. A gyártó dokumentálja a nyílt checkpoint feladatspecifikus címkéken végzett finomhangolását és valószínűség-kalibrálásának az adott munkaterheléshez illesztését is; ez a megadott állapot pontozásától különálló testreszabási munkafolyamat. A tényleges munkaterhelés címkézett példáival válassza ki a döntési küszöböket, és a bizonytalan esetek maradjanak láthatók ellenőrzéshez. A gyártó kizárja az embereket érintő, jelentős következményekkel járó teljesen automatizált döntéseket emberi ellenőrzés nélkül. A lehetőségek sorrendje is befolyásolhatja a választ, ezért eredmények összehasonlításakor tartson stabil sorrendet. A választott címkét, a külön megbízhatósági mezőt és a valószínűségi eloszlást a munkafolyamatban betöltött saját szerepük szerint értékelje.
A gyártó által leírt aktuális Kev-4B kiadás a Kev 1.0-hoz tartozik, és a Qwen3.5 alapmodellt használja. A korábbi Qwen3-alapú és kizárólag dokumentumszakaszt használó kiadások különálló verziók maradnak. Feladatspecifikus munkafolyamat fejlesztésekor a kiválasztott kiadást és a kérdésdefiníciókat tartsa a kimenetekhez kapcsolva, ne keverje a különböző profilok eredményeit.
A hasznos végső eredmény döntési rekordok elnevezett készlete az eredeti kérdésekkel, lehetőségdefiníciókkal, eloszlásokkal és a rendezett szintek esetleges jelmagyarázataival. Válaszminőség-ellenőrzéshez az állapotnak tartalmaznia kell a javasolt választ, a bizonyítékot és a vizsgált kritériumot. Szabályalapú triázshoz az alkalmazandó szabályt és a releváns tényeket kell tartalmaznia. Ezt a bemenetet az eredmény mellett őrizze meg, hogy az ellenőrzés megállapíthassa, miért volt megfelelő a döntés, vagy melyik hiányzó tényt kell megadni.
", "aboutText": "A Kev-4B kompakt döntési modell megadott állapotra vonatkozó típusos kérdések megválaszolásához. Az állapot az értékelt dokumentum vagy rekord, és minden kérdés meghatározza a modell által pontozható lehetőségeket. Eredménye valószínűségi eloszlás és típusos döntési rekord, így dokumentumosztályozáshoz, továbbirányításhoz, triázshoz, adatkinyerési választásokhoz és megadott kritériumok szerinti ellenőrzésekhez használható.\n\nA modell fagyasztott Qwen3.5-4B-Base alapmodellt kapcsol össze LoRA-adapterrel és mutatófejjel. Az alapmodell 32 rétegből áll: 24 Gated DeltaNet rétegből és nyolc teljes figyelmi rétegből. Az adapter a figyelmi, MLP- és DeltaNet-projekciókat célozza; a mutatófej pontozza a megadott lehetőségeket, és ezeket a pontszámokat valószínűségekké alakítja. Ez kizárólag prefill szakaszt használó döntési munkafolyamat, amelyben a lehetőségek alkotják a választeret.\n\nUgyanabban a kérésben három kérdéstípus szerepelhet. A choice kérdés 1–255 elnevezett lehetőséget fogad, opcionális leírásokkal, és visszaadja a legvalószínűbb lehetőséget, egy külön megbízhatósági értéket és a lehetőségek valószínűségeit. Az igen/nem kérdés, amelyet a gyártó formátuma noul néven nevez, az igen valószínűségét adja vissza. Az igen jelentését a kérdésben határozza meg, ne feltételezze, hogy a magas szám mindig pozitív kimenetelt jelent az alkalmazás számára.\n\nA rendezett pontozási kérdés 1–255 szintet fogad, és visszaadja a szintek valószínűségeit és várható indexüket. A szintindexek nullától indulnak. A gyártó eredményformátuma a szintjelmagyarázatot és egy külön megbízhatósági értéket is hordoz. A várható index tört érték lehet: az Ön rendezett szintjeinek eloszlását összegzi, nem új szöveges címkét választ. A szintek sorrendjét és jelmagyarázatát tartsa az eredménnyel együtt, hogy az értékelés következetesen értelmezhető legyen.\n\nA kérdések ugyanazon állapoton osztoznak, de egymástól függetlenül értékelődnek. Egy kérdés nem olvashatja egy másik válaszát, az állapotot pedig egyszer számítja ki és használja újra a rendszer. Ha egy későbbi döntés egy korábbi döntés eredményétől függ, ezt a függőséget egy következő állapotban tegye egyértelművé, ne várja el, hogy egy kérés kérdései láncot alkossanak. Ez alkalmassá teszi a közös állapotú munkafolyamatot ugyanazon dokumentum több független ellenőrzésére.\n\nAz állapotot a kérdésekhez ténylegesen szükséges bizonyítékkal készítse elő. Lehet egyszerű szöveg, vagy címkézett szöveggé alakított JSON-objektum vagy -tömb. A mezőnevek, mértékegységek, szabályfeltételek és releváns forrásrészletek legyenek világosak. Minden kérdéshez írjon konkrét utasítást, és a lehetőségeknek olyan jelentést adjon, amely a rekord alapján megkülönböztethető. Egy eredeti ügyfélszolgálati továbbirányítási feladatnál az állapot tartalmazhatja a kérést és kontextusát, a választások pedig rövid leírásokkal meghatározhatják a kézbesítési, hozzáférési és terméktámogatási kategóriákat.\n\nEgy második kérdés felmérheti a sürgősséget, egy rendezett kérdés pedig értékelheti, mennyi utókövetést igényel a kérés. Ezek eltérő működési kérdésekre válaszolnak, ezért külön határozza meg őket. Szerepeltessen megfelelő ellenőrzési vagy hiányzó bizonyítékot jelző lehetőséget, ha a választási feladatnak szüksége van rá, és tartsa meg a teljes eloszlást, ha több kategória is hihető. Az alkalmazás dönti el, hogyan irányítja tovább vagy ellenőrzi az eredményt; a modell a pontozott rekordot szolgáltatja.\n\nA Kev-4B néhány ezer tokenes dokumentumok fölötti típusos döntésekre készült. A gyártó kiszolgálási profilja legfeljebb 65 536 tokenes állapotokat fogad, és minden kérdéshez további helyet tart fenn, míg e checkpoint validált kontextushossza 8192 token. Ezek különböző határok: a hosszabb állapot elfogadása nem igazol minden hosszon egyformán megbízható döntéseket. Tartsa tömören a döntő részleteket, és őrizze meg címkéiket, amikor hosszú rekordot készít elő osztályozáshoz.\n\nA kiadott profil angol nyelvű. Hasznos feladatai a megadott állapot bizonyítékától és a meghatározott lehetőségektől függenek, nem nyitott végű csevegéstől, összefoglalástól vagy széles körű tudásalapú válaszadástól. Külön korlát a nap pontosságú dátumszámítás: a gyártó külön dátumtény-előfeldolgozót ad, amely kiszámított időközöket szolgáltat. Határidő-ellenőrzésnél az állapotba foglalja bele a releváns dátumokat és a kiszámított napintervallumokat, valamint az ezeket használó szabályt.\n\nA checkpoint illesztett valószínűség-kalibrálással érkezik, de a megbízhatósági érték változhat a dokumentum szakterületével és a kérdések kialakításával. A gyártó dokumentálja a nyílt checkpoint feladatspecifikus címkéken végzett finomhangolását és valószínűség-kalibrálásának az adott munkaterheléshez illesztését is; ez a megadott állapot pontozásától különálló testreszabási munkafolyamat. A tényleges munkaterhelés címkézett példáival válassza ki a döntési küszöböket, és a bizonytalan esetek maradjanak láthatók ellenőrzéshez. A gyártó kizárja az embereket érintő, jelentős következményekkel járó teljesen automatizált döntéseket emberi ellenőrzés nélkül. A lehetőségek sorrendje is befolyásolhatja a választ, ezért eredmények összehasonlításakor tartson stabil sorrendet. A választott címkét, a külön megbízhatósági mezőt és a valószínűségi eloszlást a munkafolyamatban betöltött saját szerepük szerint értékelje.\n\nA gyártó által leírt aktuális Kev-4B kiadás a Kev 1.0-hoz tartozik, és a Qwen3.5 alapmodellt használja. A korábbi Qwen3-alapú és kizárólag dokumentumszakaszt használó kiadások különálló verziók maradnak. Feladatspecifikus munkafolyamat fejlesztésekor a kiválasztott kiadást és a kérdésdefiníciókat tartsa a kimenetekhez kapcsolva, ne keverje a különböző profilok eredményeit.\n\nA hasznos végső eredmény döntési rekordok elnevezett készlete az eredeti kérdésekkel, lehetőségdefiníciókkal, eloszlásokkal és a rendezett szintek esetleges jelmagyarázataival. Válaszminőség-ellenőrzéshez az állapotnak tartalmaznia kell a javasolt választ, a bizonyítékot és a vizsgált kritériumot. Szabályalapú triázshoz az alkalmazandó szabályt és a releváns tényeket kell tartalmaznia. Ezt a bemenetet az eredmény mellett őrizze meg, hogy az ellenőrzés megállapíthassa, miért volt megfelelő a döntés, vagy melyik hiányzó tényt kell megadni.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "c1a80485178979e811ef22bf43ef69522b469af6a4aeffbe9970ba93021c2790", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "hu", "methods": [ { "html": "jaredpalmer/kev-4bA Kev-4B megadott angol dokumentumra vonatkozó típusos kérdéseket pontoz, és kalibrált valószínűségeket ad vissza az Ön által meghatározott lehetőségekhez. Igen/nem, choice és rendezett score kérdésekkel végezzen osztályozást, továbbirányítást, triázst és olyan ellenőrzéseket, amelyek generált próza helyett strukturált döntést igényelnek.
Ez a leírás a modell képességeit ismerteti. Az Ailootban elérhető bemenetek, kimenetek és lehetőségek alább, a kiválasztott metódusnál láthatók.
A Kev-4B kompakt döntési modell megadott állapotra vonatkozó típusos kérdések megválaszolásához. Az állapot az értékelt dokumentum vagy rekord, és minden kérdés meghatározza a modell által pontozható lehetőségeket. Eredménye valószínűségi eloszlás és típusos döntési rekord, így dokumentumosztályozáshoz, továbbirányításhoz, triázshoz, adatkinyerési választásokhoz és megadott kritériumok szerinti ellenőrzésekhez használható.
A modell fagyasztott Qwen3.5-4B-Base alapmodellt kapcsol össze LoRA-adapterrel és mutatófejjel. Az alapmodell 32 rétegből áll: 24 Gated DeltaNet rétegből és nyolc teljes figyelmi rétegből. Az adapter a figyelmi, MLP- és DeltaNet-projekciókat célozza; a mutatófej pontozza a megadott lehetőségeket, és ezeket a pontszámokat valószínűségekké alakítja. Ez kizárólag prefill szakaszt használó döntési munkafolyamat, amelyben a lehetőségek alkotják a választeret.
Ugyanabban a kérésben három kérdéstípus szerepelhet. A choice kérdés 1–255 elnevezett lehetőséget fogad, opcionális leírásokkal, és visszaadja a legvalószínűbb lehetőséget, egy külön megbízhatósági értéket és a lehetőségek valószínűségeit. Az igen/nem kérdés, amelyet a gyártó formátuma noul néven nevez, az igen valószínűségét adja vissza. Az igen jelentését a kérdésben határozza meg, ne feltételezze, hogy a magas szám mindig pozitív kimenetelt jelent az alkalmazás számára.
A rendezett pontozási kérdés 1–255 szintet fogad, és visszaadja a szintek valószínűségeit és várható indexüket. A szintindexek nullától indulnak. A gyártó eredményformátuma a szintjelmagyarázatot és egy külön megbízhatósági értéket is hordoz. A várható index tört érték lehet: az Ön rendezett szintjeinek eloszlását összegzi, nem új szöveges címkét választ. A szintek sorrendjét és jelmagyarázatát tartsa az eredménnyel együtt, hogy az értékelés következetesen értelmezhető legyen.
A kérdések ugyanazon állapoton osztoznak, de egymástól függetlenül értékelődnek. Egy kérdés nem olvashatja egy másik válaszát, az állapotot pedig egyszer számítja ki és használja újra a rendszer. Ha egy későbbi döntés egy korábbi döntés eredményétől függ, ezt a függőséget egy következő állapotban tegye egyértelművé, ne várja el, hogy egy kérés kérdései láncot alkossanak. Ez alkalmassá teszi a közös állapotú munkafolyamatot ugyanazon dokumentum több független ellenőrzésére.
Az állapotot a kérdésekhez ténylegesen szükséges bizonyítékkal készítse elő. Lehet egyszerű szöveg, vagy címkézett szöveggé alakított JSON-objektum vagy -tömb. A mezőnevek, mértékegységek, szabályfeltételek és releváns forrásrészletek legyenek világosak. Minden kérdéshez írjon konkrét utasítást, és a lehetőségeknek olyan jelentést adjon, amely a rekord alapján megkülönböztethető. Egy eredeti ügyfélszolgálati továbbirányítási feladatnál az állapot tartalmazhatja a kérést és kontextusát, a választások pedig rövid leírásokkal meghatározhatják a kézbesítési, hozzáférési és terméktámogatási kategóriákat.
Egy második kérdés felmérheti a sürgősséget, egy rendezett kérdés pedig értékelheti, mennyi utókövetést igényel a kérés. Ezek eltérő működési kérdésekre válaszolnak, ezért külön határozza meg őket. Szerepeltessen megfelelő ellenőrzési vagy hiányzó bizonyítékot jelző lehetőséget, ha a választási feladatnak szüksége van rá, és tartsa meg a teljes eloszlást, ha több kategória is hihető. Az alkalmazás dönti el, hogyan irányítja tovább vagy ellenőrzi az eredményt; a modell a pontozott rekordot szolgáltatja.
A Kev-4B néhány ezer tokenes dokumentumok fölötti típusos döntésekre készült. A gyártó kiszolgálási profilja legfeljebb 65 536 tokenes állapotokat fogad, és minden kérdéshez további helyet tart fenn, míg e checkpoint validált kontextushossza 8192 token. Ezek különböző határok: a hosszabb állapot elfogadása nem igazol minden hosszon egyformán megbízható döntéseket. Tartsa tömören a döntő részleteket, és őrizze meg címkéiket, amikor hosszú rekordot készít elő osztályozáshoz.
A kiadott profil angol nyelvű. Hasznos feladatai a megadott állapot bizonyítékától és a meghatározott lehetőségektől függenek, nem nyitott végű csevegéstől, összefoglalástól vagy széles körű tudásalapú válaszadástól. Külön korlát a nap pontosságú dátumszámítás: a gyártó külön dátumtény-előfeldolgozót ad, amely kiszámított időközöket szolgáltat. Határidő-ellenőrzésnél az állapotba foglalja bele a releváns dátumokat és a kiszámított napintervallumokat, valamint az ezeket használó szabályt.
A checkpoint illesztett valószínűség-kalibrálással érkezik, de a megbízhatósági érték változhat a dokumentum szakterületével és a kérdések kialakításával. A gyártó dokumentálja a nyílt checkpoint feladatspecifikus címkéken végzett finomhangolását és valószínűség-kalibrálásának az adott munkaterheléshez illesztését is; ez a megadott állapot pontozásától különálló testreszabási munkafolyamat. A tényleges munkaterhelés címkézett példáival válassza ki a döntési küszöböket, és a bizonytalan esetek maradjanak láthatók ellenőrzéshez. A gyártó kizárja az embereket érintő, jelentős következményekkel járó teljesen automatizált döntéseket emberi ellenőrzés nélkül. A lehetőségek sorrendje is befolyásolhatja a választ, ezért eredmények összehasonlításakor tartson stabil sorrendet. A választott címkét, a külön megbízhatósági mezőt és a valószínűségi eloszlást a munkafolyamatban betöltött saját szerepük szerint értékelje.
A gyártó által leírt aktuális Kev-4B kiadás a Kev 1.0-hoz tartozik, és a Qwen3.5 alapmodellt használja. A korábbi Qwen3-alapú és kizárólag dokumentumszakaszt használó kiadások különálló verziók maradnak. Feladatspecifikus munkafolyamat fejlesztésekor a kiválasztott kiadást és a kérdésdefiníciókat tartsa a kimenetekhez kapcsolva, ne keverje a különböző profilok eredményeit.
A hasznos végső eredmény döntési rekordok elnevezett készlete az eredeti kérdésekkel, lehetőségdefiníciókkal, eloszlásokkal és a rendezett szintek esetleges jelmagyarázataival. Válaszminőség-ellenőrzéshez az állapotnak tartalmaznia kell a javasolt választ, a bizonyítékot és a vizsgált kritériumot. Szabályalapú triázshoz az alkalmazandó szabályt és a releváns tényeket kell tartalmaznia. Ezt a bemenetet az eredmény mellett őrizze meg, hogy az ellenőrzés megállapíthassa, miért volt megfelelő a döntés, vagy melyik hiányzó tényt kell megadni.
POST /v1/systemonetextdecisions| Mező | Típus | Követelmény | Értékek és korlátok | Alapértelmezett |
|---|---|---|---|---|
Mezőmodel | Típusstring | KövetelményKötelező | Értékek és korlátok jaredpalmer/kev-4b | Alapértelmezett— |
Mezőprovider | Típusschema | KövetelményOpcionális | Értékek és korlátok | Alapértelmezett— |
Mezőquestions | Típusobject | KövetelményKötelező | Értékek és korlátok | Alapértelmezett— |
Mezősession_id | Típusstring | KövetelményOpcionális | Értékek és korlátok | Alapértelmezett— |
Mezőstate | Típusschema | KövetelményKötelező | Értékek és korlátok | Alapértelmezett— |
Mezőtrace | Típusschema | KövetelményOpcionális | Értékek és korlátok | Alapértelmezett— |
Mezőuser | Típusstring | KövetelményOpcionális | Értékek és korlátok | Alapértelmezett— |
Mezőquestions.<id>.type | Típusstring | KövetelményKötelező | Értékek és korlátok noul, choice, score | Alapértelmezett— |
Mezőquestions.<id>.instructions | Típusstring|object|array | KövetelményKötelező | Értékek és korlátok | Alapértelmezett— |
Mezőquestions.<id>.criteria | Típusobject|array | KövetelményOpcionális | Értékek és korlátok Feltételek: choice/score: kötelező; noul: opcionális. A choice feltételei objektumot alkotnak; a score tömb, minItems1 megkötéssel. | Alapértelmezett— |
Mezőquestions.<id>.criteria.true | Típusstring|object|array | KövetelményKötelező | Értékek és korlátok Akkor alkalmazandó, ha: noul feltételobjektum megadva | Alapértelmezett— |
Mezőquestions.<id>.criteria.false | Típusstring|object|array | KövetelményKötelező | Értékek és korlátok Akkor alkalmazandó, ha: noul feltételobjektum megadva | Alapértelmezett— |
noul · Kötelező: state, questions.<id>.type=noul, questions.<id>.instructions
choice · Kötelező: state, questions.<id>.type=choice, questions.<id>.instructions, criteria object
score · Kötelező: state, questions.<id>.type=score, questions.<id>.instructions, criteria array with minItems1
| Paraméter | Szerződés |
|---|---|
Paramétercontent_type | Szerződésapplication/json |
Paraméterrequired | Szerződésmodel, state, questions |
Paramétermaterial_types | Szerződéstext |
Paraméteroptional_controls | Szerződésprovider, session_id, trace, user |
Paramétermultimodal_input_binding | Szerződésnull |
Életciklus: synchronous
Küldje el a pontos modellazonosítót, és őrizze meg a teljes natív választ.
A díjszabás nem ad új kérési lehetőségeket. A támogatott paraméterek a kiválasztott módszernél szerepelnek.
Minden díjat a megjelenített feltételekhez rendeljen. Az alternatív beállítások minden csoportjához egy díjtételt használjon.
| Beállítás | Díjtáblázat | Kontextustokenek, több mint | Kontextustokenek, legfeljebb | Díj |
|---|---|---|---|---|
| BeállításTokenenkénti alapárak | DíjtáblázatAlapdíj | Kontextustokenek, több mint— | Kontextustokenek, legfeljebbNincs felső korlát | Díj Bemenet · Bemeneti tokenek $0.000084 / 1K token Kimenet · Kimeneti tokenek $0 / 1K token Bemenet · Gyorsítótár olvasása — / 1K token Bemenet · Írás a gyorsítótárba — / 1K token Bemenet · Írás a gyorsítótárba, 1 óra — / 1K token |
| BeállításA kéréshossz szerinti 1. ársáv | Díjtáblázat— | Kontextustokenek, több mint0 | Kontextustokenek, legfeljebbNincs felső korlát | Díj Bemenet · Bemeneti tokenek $0.000084 / 1K token Kimenet · Kimeneti tokenek $0 / 1K token Bemenet · Gyorsítótár olvasása — / 1K token Bemenet · Írás a gyorsítótárba — / 1K token Bemenet · Írás a gyorsítótárba, 1 óra — / 1K token |
Az Ailoot a kérés előtt becsült összeget foglal le. Az eredmény után a mért használat alapján elszámolja a végső díjat. Folyamatos átvitel esetén a végső használati rekordot használja. A foglalás és az elszámolás működése →
{\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
Őrizzen meg minden teljes visszaadott választ, fájlt és tartalomrészt.
Minden megadott kérdésazonosítóhoz tartozó válasz megmarad a pontos típusával, noul/choice/score értékével, megbízhatóságával, valószínűségeivel és jelmagyarázatával együtt. A teljes eredeti JSON tárolásra kerül, és csak az elszámolás után adható vissza.
Őrizze meg az eredeti műveletet és a teljes vagy részleges választ; ne ismételje meg a POST kérést.
| Mező | Típus |
|---|---|
Mezőmodel | Típusstring |
Mezőid | Típusstring |
Mezőprovider | Típusstring |
Mezőanswers.<id>.type | Típusstring |
Mezőanswers.<id>.noul | Típusnumber |
Mezőanswers.<id>.choice | Típusstring |
Mezőanswers.<id>.score | Típusnumber |
Mezőanswers.<id>.confidence | Típusnumber |
Mezőanswers.<id>.probabilities | Típusobject |
Mezőanswers.<id>.legend | Típusobject |
Mezőusage.input_tokens | Típusinteger |
Mezőusage.output_tokens | Típusinteger |
Mezőusage.cost | Típusnumber |
| Válasz | Feltétel | Következő lépés |
|---|---|---|
Válasz400 · invalid_request_error | FeltételÉrvénytelen kötelező mező, megadási forma vagy érték | Következő lépésJavítsa a kérés megjelölt mezőjét. |
Ailoot Ultra jaredpalmer/kev-4b
Használja a fent látható metódusútvonalakat.