Pamatojums-piepūles maršrutēšana AI API vārtejā: kontrolējiet domāšanas marķierus, latentumu un izmaksas starp pakalpojumu sniedzējiem

Spriešanas dziļums vairs nav vienkārša modeļa iespēja. Daži pakalpojumu sniedzēji atklāj enum stila piepūles līmeņus. Citi atklāj simbolisku budžetu, dinamisku domāšanu vai modeļu ģimenes, kurās domāšanu nevar pilnībā atspējot. Redzamā atbilde var būt īsa, kamēr slēptā argumentācija patērē apmaksājamos izvades marķierus. Ja katra lietojumprogrammu komanda tieši iestata šīs vadīklas, izmaksas, latentumu un kvalitāti kļūst grūti izskaidrot.

Praktiskā atbilde ir pārvietot argumentācijas un piepūles kontroli API vārtejā. Vārtejai ir jāklasificē darba slodze, jāsaista tā ar pakalpojumu sniedzēja specifisku argumentācijas kontroli, jāpiemēro nomnieku budžeti, jāreģistrē faktiskais argumentācijas lietojums un jāpadara analīzē redzami lēmumi par pazemināšanu. Modeļa ID, pakalpojuma līmenim, maksimālajai izlaidei un argumentācijas dziļumam ir jābūt atsevišķām politikas dimensijām.

Lasītāja problēma: vienkārši pieprasījumi maksā padziļinātu pamatojumu

Komandas, kas pieņem argumentāciju spējīgus modeļus, parasti sāk ar saprātīgu mērķi: uzlabot grūto uzdevumu kvalitāti. Problēma parādās vēlāk, kad tie paši noklusējuma iestatījumi tiek atkārtoti izmantoti izvilkšanai, īsiem kopsavilkumiem, formatēšanai un klasifikācijai. Šiem pieprasījumiem nav nepieciešams dārgs testa laika aprēķins, taču tie joprojām var to aktivizēt.

Tas rada trīs darbības kļūmes:

• Izmaksu necaurredzamība: lietotājs redz īsu atbildi, bet virsgrāmatā ir slēpti argumentācijas marķieri vai pakalpojumu sniedzējam raksturīgi ekvivalenti.
• Latentums kļūst par lēnu piepūles novirzi aiz tā paša iemesla. aizstājvārds.
• Politikas sadrumstalotība: katra produktu komanda apgūst dažādus pakalpojumu sniedzēja parametrus un piemēro dažādus ierobežojumus.

Vārtejas līmeņa argumentācijas politika atrisina kontroles problēmu, pirms tā kļūst par norēķinu problēmu.

Fakti: pakalpojumu sniedzēja pamatojuma vadīklas nav līdzvērtīgas.AI>< ieteikumus

Ieviešana ir fakti

Ieteikums: izveidojiet pakalpojumu sniedzējam neitrālus spriešanas profilus

Definējiet nelielu iekšējo vārdnīcu, ko produktu komandas var saprast, neizlasot visas pakalpojumu sniedzēja API atsauces.Lielākajai daļai vārteju pietiek ar pieciem profiliem:

Profils ir līgums, kas attiecas uz lietojumprogrammu. Pakalpojumu sniedzēja parametri kļūst par adaptera informāciju. Tas saglabā klienta kodu pārnēsājamu un ļauj platformu īpašniekiem atjaunināt kartējumus, mainoties pakalpojumu sniedzēja API.

Kartēt darba slodzes klases pirms kartēšanas pakalpojumu sniedzējiem

Spriešanas uzdevums ir jāizvēlas no darba slodzes, nevis no personīgās izvēles vai modeļa popularitātes. Pievienojiet vārtejas lauku, piemēram, workload_class, ko nodrošina klients vai kas izriet no apstiprinātas maršruta konfigurācijas.

Darba slodzes politikas piemērs

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "nav",
      "max_reasoning_profile": "zems",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "nav",
      "max_reasoning_profile": "zems",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "zems",
      "max_reasoning_profile": "standarta",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standarta",
      "max_reasoning_profile": "dziļi",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "dziļi",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standarta",
      "max_reasoning_profile": "dziļi",
      "max_output_tokens": 5000
    }
  }
}

Šī politika veic divas noderīgas lietas. Pirmkārt, tas neļauj vienkāršiem galapunktiem mantot dārgus noklusējuma iestatījumus. Otrkārt, tas sniedz administratoriem konkrētu pārskatīšanas virsmu: kurām darbplūsmām ir atļauts pieprasīt dziļu pamatojumu un ar kādiem ierobežojumiem?

Izveidojiet saderības matricu

Vārtejas adapterim ir jāuztur matrica katram pakalpojumu sniedzējam un modeļu saimei. Saglabājiet vismaz, vai modelis atbalsta argumentācijas atspējošanu, uzskaites piepūli, skaitlisko budžetu, dinamisko domāšanu, maksimālo atbalstīto budžetu un argumentācijas pilnvaru lietošanas laukus.

Matricas formas piemērs

{
  "providers": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": taisnība,
        "control_type": "effort_enum",
        "allowed_values": ["nav", "minimāls", "zems", "vidējs", "augsts", "xhigh"],
        "can_disable": taisnība,
        "reports_reasoning_tokens": taisnība
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": taisnība,
        "control_type": "budžeta_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": nepatiess,
        "reports_reasoning_tokens": taisnība
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": taisnība,
        "control_type": "domāšanas_līmenis",
        "allowed_values": ["minimāls", "zems", "vidējs", "augsts"],
        "can_disable": nepatiess,
        "reports_reasoning_tokens": taisnība
      }
    }
  }
}

Saderības matrica nav dokumentācija tikai cilvēkiem. Tai jābūt izpildāmai politikai. Pieprasījuma maršrutētājam tas ir jāizmanto pirms nosūtīšanas, un norēķinu virsgrāmatai tas jāizmanto norēķinu laikā.

Iekšējo profilu tulkošana nodrošinātāja parametros

Pakalpojumu sniedzēja kartējumiem ir jābūt precīziem un versijām. Nepaļaujieties uz neskaidru frāzi, piemēram, "izmantojiet gudrāku argumentāciju". Vārtejai precīzi jāzina, kurš nodrošinātāja parametrs tika nosūtīts.

Kartēšanas piemērs

{
  "reasoning_profile_mappings": {
    "nav": {
      "effort_enum": "nav",
      "budžeta_tokens": 0,
      "domāšanas_līmenis": "minimāls"
    },
    "zems": {
      "effort_enum": "zems",
      "budget_tokens": 2048,
      "domāšanas_līmenis": "zems"
    },
    "standarta": {
      "effort_enum": "vidējs",
      "budžeta_tokens": 8192,"domāšanas_līmenis": "vidējs"
    },
    "dziļi": {
      "effort_enum": "augsts",
      "budget_tokens": 20000,
      "domāšanas_līmenis": "augsts"
    },
    "capped-deep": {
      "effort_enum": "augsts",
      "budget_tokens": 12000,
      "domāšanas_līmenis": "augsts"
    }
  }
}

Šie skaitļi ir piemēri, nevis universāli noklusējuma iestatījumi. Pareizie budžeti ir atkarīgi no modeļu saimes, cenām, latentuma prasībām un novērtēšanas rezultātiem. Svarīga ieviešanas detaļa ir tāda, ka vārtejai pieder kartēšana un katram pieprasījumam tiek reģistrēts atrisinātais nodrošinātāja parametrs.

Kļūme aizvērta, ja kartēšana nav droša

Neatbalstītas argumentācijas vadīklas nedrīkst klusībā kļūt par nodrošinātāja noklusējuma vērtībām. Noklusējumi var būt dārgi, un laika gaitā tie var mainīties.

Ja pieprasīto profilu nevar droši kartēt, izmantojiet vienu no trim iznākumiem:

• Atļaut: pakalpojumu sniedzējs/modelis atbalsta pieprasīto profilu un nomnieka politika to atļauj.
• Pazemināt: pieprasītais profils tiek piemērots augstākajam profilam. pazemināt.
• Noraidīt: profilu nevar attēlot droši, nomniekam ir nepieciešama stingra rīcība, vai arī pazemināšana var pārkāpt produkta cerības.

Lēmuma ieraksta piemērs

{
  "request_id": "req_123",
  "īrnieka_id": "īrnieks_42",
  "api_key_id": "key_abc",
  "darbplūsma": "code_review",
  "requested_reasoning_profile": "dziļi",
  "applied_reasoning_profile": "standarta",
  "lēmums": "pazemināts",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "piepūle": "vidēja"
  }
}

Šis lēmumu ieraksts ir vērtīgs atbalsta, norēķinu strīdu un kvalitātes izmeklēšanas laikā. Tas arī novērš neredzamas kvalitātes regresijas budžeta spiediena laikā.

Budžeta vadīklām ir nepieciešams vairāk nekā maksimālais izvades marķieris

Ir nepieciešams maksimālais izvades marķiera ierobežojums, taču tas nav pietiekams. Sprieduma spējīgiem modeļiem modelis var iztērēt lielu daļu no ierobežojuma argumentācijas un atstāt pārāk maz vietas galīgajai atbildei. Pēc tam lietotājs var maksāt par nelietojamu saīsinātu atbildi.

Izmantojiet slāņveida griestus:

• maksimālais_pamatojuma_profils katram nomniekam, API atslēgai un darbplūsmai.
• maksimālais_domāšanas_budžets vai līdzvērtīgs kods katram nodrošinātāja/modeļa pārim.
kopā ģenerēt_kods>tokken_tokken_. kur pakalpojumu sniedzējs saskaita argumentāciju un redzamo rezultātu kopā.
• dienas_dziļi_reasoning_spend uz vienu nomnieku vai tālākpārdevēja klientu.
• deep_reasoning_requests_per_hour liela apjoma galapunktiem.
• reasoning

Budžeta pārbaude jāveic pirms nosūtīšanas. Pēc pakalpojumu sniedzēja atbildes saņemšanas norēķinu solim ir jāsaskaņo faktiskais lietojums. Ja pakalpojumu sniedzējs ziņo par domāšanas marķieriem atsevišķi, glabājiet tos atsevišķi. Ja tiek ziņots tikai par kopējo izvades marķieri, saglabājiet labākos pieejamos normalizētos laukus un atzīmējiet uzticamības līmeni.

Virsgrāmatas lauki pamatojuma lietojumam

Analītikā ir jāparāda atšķirība starp redzamās atbildes garumu un apmaksātu argumentācijas piepūli. Noderīgā virsgrāmatas rindā jāiekļauj:

• nomnieka_id, api_key_id, end_user_id un darbplūsma.
• pieprasītais_modelis, served_model, nodrošinātājs un modelis. aizstājvārds.
• requested_reasoning_profile un applied_reasoning_profile.
• provider_reasoning_param, kas tiek glabāti kā strukturēts JSON.
• input_tokens, ens_out>, , reasoning_tokens_or_equivalent, kešatmiņas_tokens un total_billable_tokens.
• maksimālie_izvades_tokens un jebkurš pakalpojumu sniedzējam raksturīgs domāšanas budžets.
• latency_to_code_tok>,en_mssttal> un straumes pabeigšanas statuss.
• aptuvenās_izmaksas_pirms_nosūtīšanas, rezervētais_budžets, norēķinātas_izmaksas un saskaņošanas_statuss.
• policy_decision, ><>>>, piemēram, atļauts, pazemināts/atkāpties. pēc noklusējuma nereģistrē neapstrādātu domu ķēdi. Lielākajai daļai pārvaldības un FinOps darbu pietiek ar uzskaiti un politikas lēmumiem. Saglabājot sensitīvu argumentācijas tekstu, var rasties problēmas ar konfidencialitāti, atbilstību un saglabāšanu, no kurām iespējams izvairīties.

  Ieviešanas plūsma

  Ražošanas vārteja var ieviest argumentācijas un piepūles maršrutēšanu kā deterministisku pieprasījumu konveijeru.

  1. Autentificējiet pieprasījumu. Atrisiniet nomnieku, API atslēgu un Ja iespējams, izmantojiet skaidru klienta lauku.Zināmiem galapunktiem maršruta konfigurācijā saistiet darba slodzes klasi.
  2. Ielādēt politiku. Apvienojiet globālos, nomnieku, atslēgu un darbplūsmas ierobežojumus.
  3. Atlasiet modeļu kandidātus. Izmantojiet esošo modeļa aizstājvārdu vai modeļa atlases politiku, pirms atrisināt argumentācijas vadīklas.
  4. Atrisināt darba profilu un pēc tam lietot iemeslus. maksimumi.
  5. Pārbaudiet saderību. Apstipriniet, ka pakalpojumu sniedzēja/modeļa pāris droši atbalsta atlasīto profilu.
  6. Aprēķiniet izmaksas un rezerves budžetu. Iekļaujiet iespējamo argumentācijas lietojumu, ne tikai redzamu izvadi.
  7. Nosūtīšana ar pakalpojumu sniedzēja vietējiem parametriem. Sūtīt uz vai bez pamatojuma, budžeta domāšanas līmeņa. Adapteris.
  8. Normalizējiet lietojumu, reaģējot. Ja iespējams, atdaliet ievadi, redzamo izvadi, argumentāciju, kešatmiņu, rīku un kopējos marķierus.
  9. Noregulējiet un brīdinājiet. Saskaņojiet rezervētās un faktiskās izmaksas, atjauniniet kvotas un izstarojiet anomāliju signālus.

  Šī audita konveijera saglabā pamatojumu. Tas arī nodrošina platformu komandām vienu vietu, kur mainīt noklusējuma iestatījumus, kad pakalpojumu sniedzēju API attīstās.

  Novērtēšana pirms noklusējuma iestatījumu maiņas

  Neveiciniet lielāku argumentāciju, pamatojoties tikai uz dažiem iespaidīgiem piemēriem. Veiciet novērtējumus, pirms maināt darba slodzes klases noklusējuma iestatījumus.

  Novērtējiet vismaz četrus rezultātus:

  • Uzdevuma kvalitāte: precizitāte, pārskatītāja akcepts, shēmas derīgums vai rīka izsaukuma panākumi.
  • Latentums: laiks līdz pirmajai pilnvarai un kopējā izpildes maksa par pieņemto pieprasījumu.
  • atbilde.
  • Kļūmes režīmi: saīsināšana, atteikums, nepareizi veidota izvade, pārmērīgi rīka izsaukumi vai taimauts.

  Galvenā metrika nav “marķieri katram pieprasījumam”. Atbilde ar zemāku marķieri, kas neizdodas validēt, pēc atkārtotajiem mēģinājumiem var būt dārgāka. Spēcīgāka atbilde var būt pamatota drošības pārbaudei, bet izšķērdīga biļešu marķēšanai. Novērtējiet pēc darbplūsmas.

  Kompozīcijas

  Pārvaldības prātošana palielina kontroli, taču tā nav bezmaksas.

  • Pārnesamība salīdzinājumā ar pakalpojumu sniedzēja funkcijām: iekšējie profili nodrošina lietojumprogrammas koda pārnēsājamību, taču progresīvām komandām, iespējams, būs nepieciešama apstiprināta aiztures lūka, lai nodrošinātu pakalpojumu sniedzēja specifiskas kontroles.
  • pretsvarsB kvalitātes aizsardzību. neizbēgami tēriņi, taču pārāk stingri ierobežojumi var saīsināt noderīgas atbildes pēc tam, kad argumentācijas marķieri jau ir iztērēti.
  • Dinamiska domāšana pretstatā paredzamībai: dinamiskas pakalpojumu sniedzēja vadīklas var uzlabot ērtības, taču tās vājina izmaksu aprēķinus pirms nosūtīšanas, ja vien vārteja nereģistrē faktisko lietojumu un nepiemēro norēķinu pieejamības ierobežojumus. argumentācija budžeta spiediena laikā saglabā pieejamību, taču atbilde ir jāiekļauj telemetrijā un jāiekļauj kvalitātes novērtējumā.
  • Analītika pret privātumu: argumentācijas marķiera metrika ir noderīga, taču neapstrādātas argumentācijas pēdas nevajadzētu saglabāt, ja vien nepastāv apzināta, apstiprināta saglabāšanas politika.

  Standard Policy Gateway. ir prognoze, nevis pārbaudīts fakts: argumentācijas centieni kļūs par parastu ražošanas kontroli līdzās modeļa maršrutēšanai, ātruma ierobežojumiem, pakalpojumu līmeņiem un marķieru budžetiem. Tā kā pakalpojumu sniedzēji turpina atklāt dažādas domāšanas vadīklas, lietojumprogrammu komandām būs mazāka vēlme šīs atšķirības iekodēt produkta kodā.

  Vārtijām, kurās argumentācija tiek uzskatīta par pārvaldītu izpildlaika dimensiju, būs skaidrāki nomnieka rēķini, tīrāka pārnesamība un labāka latentuma kontrole.Vārtejām, kas to uzskata par nejaušu modeļa parametru, būs grūti izskaidrot, kāpēc īsas atbildes dažreiz maksā vairāk nekā garas.

  Rīcības kontrolsaraksts

  • Definējiet iekšējos profilus: nav, zems, standarta, dziļš un katrs noklusējuma profils un maksimālais profils. darba slodzes klase.
  • Izveidojiet nodrošinātāja/modeļa saderības matricu argumentācijas vadīklām.
  • Profilus tulkojiet nodrošinātāja vietējiem parametriem adaptera slānī.
  • Neizdevās aizvērt, ja pieprasīto profilu nevar droši kartēt.
  • Rezervējiet budžetu pirms nosūtīšanas, izmantojot argumentāciju,
  pieprasīts aprēķins, profila aprēķini. lietojums, redzamā izvade, latentums un izmaksas.
  • Pievienojiet brīdinājumus par anomālijām par augstu argumentācijas marķieru attiecību un padziļinātu argumentāciju liela apjoma vienkāršās darbplūsmās.
  • Palaidiet darbplūsmas līmeņa novērtējumus pirms noklusējuma darbības maiņas.
  • Izvairieties no neapstrādāta argumentācijas teksta reģistrēšanas pēc noklusējuma; Tā vietā veiciet veikala uzskaiti un politikas lēmumus.

  Secinājums

  Modeļi, kas spēj izdomāt, ir noderīgi, jo tie var vairāk tērēt sarežģītu problēmu risināšanai. Tāda pati iespēja kļūst dārga, ja to izmanto bez izšķirības. Vārtejai ir jāizlemj, kad ir atļauta padziļināta argumentācija, kā tas tiek attiecināts uz katru pakalpojumu sniedzēju, cik daudz budžeta tas var patērēt un kā tiek mērīts rezultāts.

  Ilgtspējīgs modelis ir nodalīt argumentācijas centienus no modeļa ID. Maršruts pēc darba slodzes, ierobežojums pēc īrnieka politikas, pielāgojums katram pakalpojumu sniedzējam un faktiskā lietojuma iestatīšana virsgrāmatā. Tas pārvērš argumentāciju no slēpta izmaksu mainīgā par skaidru vadības virsmu AI API izmaksu kontrolei.

  Saistīta informācija

  • > < Virsgrāmata, ko izsauc katrs modelis, href="https://model-gate.com/en/blog/internal-model-aliases-ai-api-gateway-pin-provider-versions-21/">iekšējie modeļu aizstājvārdi un spēju līgumi
  • FAQ

    Bieži uzdotie jautājumi

    Vai lietojumprogrammu komandām ir jāļauj tieši iestatīt pakalpojumu sniedzēja pamatojuma parametrus?

    Parasti ne pēc noklusējuma. Pakalpojumu sniedzēja neitrāls profils nodrošina klienta kodu pārnēsājamu un ļauj vārtejai piemērot nomnieku budžetus. Uzlabotas komandas joprojām var izmantot pakalpojumu sniedzējam specifiskas vadīklas, izmantojot apstiprinātu evakuācijas lūku ar audita reģistrēšanu.

    Vai ar maksimālo izvades marķieri pietiek, lai kontrolētu argumentācijas izmaksas?

    Nē. Dažos modeļos, kuros var izmantot argumentāciju, argumentācijas pilnvaras un redzamās atbildes pilnvaras koplieto ģenerēto pilnvaru ierobežojumu vai norēķinu kategoriju. Pieprasījums var tērēt daudz pilnvaru argumentācijai un atstāt pārāk maz vietas galīgajai atbildei, tāpēc vārtejai ir jāierobežo arī argumentācijas profils vai domāšanas budžets.

    Vai vārtejai vajadzētu reģistrēt domu ķēdi?

    Nav pēc noklusējuma. Izmaksu kontrolei un analīzei vārtejai parasti ir nepieciešami uzskaites dati, politikas lēmumi, modeļa identifikatori, latentums un izmaksu lauki. Neapstrādāts argumentācijas teksts var radīt privātuma un saglabāšanas risku.

    Kad dziļai argumentācijai jābūt noklusējuma iestatījumam?

    Tikai darbplūsmām, kurās novērtējumi liecina, ka kvalitātes pieaugums attaisno latentumu un izmaksas. Matemātika, daudzpakāpju atkļūdošana, drošības pārskatīšana un augstvērtīgu aģentu plānošana ir izplatītas iespējas; izvilkšana, formatēšana, klasifikācija un īsas faktiskas atbildes parasti nav.