Kā centieni samazināt mākslīgā intelekta izmaksas var sabojāt jūsu produktu

Mākslīgā intelekta (AI) un lielo valodas modeļu (LLM) integrācija mūsdienu programmatūrā ir saistīta ar ievērojamām izmaksām. Uzņēmumi, kas strauji mērogo savus pakalpojumus, bieži saskaras ar milzīgiem rēķiniem par API izmantošanu. Dabiska reakcija uz šo izaicinājumu ir optimizācija. Viens no populārākajiem inženiertehniskajiem risinājumiem ir tā saucamā maršrutēšanas slāņa (routing layer) izveide, kas novirza vienkāršākos lietotāju vaicājumus uz lētākiem modeļiem, bet sarežģītākos - uz jaudīgākiem un dārgākiem.

Tomēr praksē šī teorētiski pievilcīgā ideja var radīt negaidītas un smagas sekas produkta darbībā. Kā savā pieredzes stāstā dalās nozares eksperti, kuru pieredze aprakstīta vietnē towardsdatascience.com, šāda arhitektūras sarežģīšana var pilnībā sabojāt lietotāju pieredzi un pat degradēt paša produkta pamatfunkcijas.

Kas ir LLM maršrutēšanas slānis un kā tas darbojas?

LLM maršrutētājs ir starpprogrammatūra (middleware), kas atrodas starp lietotāja saskarni un AI modeļu API. Tās galvenais uzdevums ir analizēt ienākošo vaicājumu (prompt) un pieņemt lēmumu, kurš modelis būs vispiemērotākais un finansiāli izdevīgākais tā apstrādei.

Piemēram, ja lietotājs ieraksta vienkāršu sveicienu kā "Labdien!", sistēma to novirza uz lētu un ātru modeli (piemēram, GPT-4o-mini vai Claude Haiku). Savukārt, ja vaicājums prasa sarežģītu datu analīzi vai loģisko spriešanu, tas tiek sūtīts uz dārgāko pamata modeli (piemēram, GPT-4o). Šādas sistēmas pamatā parasti ir vienkāršs klasifikācijas algoritms vai pat vēl viens, mazāks AI modelis.

def route_prompt(user_prompt):
    # Ātra vaicājuma sarežģītības novērtēšana
    complexity = evaluate_complexity(user_prompt)
    
    if complexity == "low":
        return call_cheap_model(user_prompt)
    else:
        return call_expensive_model(user_prompt)

Trīs iemesli, kāpēc maršrutēšana sabojāja reālu produktu

Lai gan uz papīra šī stratēģija izskatās izdevīga, reālajā darbībā inženieri saskārās ar virkni problēmu, kas būtiski ietekmēja gala lietotājus.

1. Papildu aizture jeb latence

Katrs solis, kas tiek veikts pirms galvenā vaicājuma nosūtīšanas, prasa laiku. Lai maršrutētājs saprastu, vai teksts ir vienkāršs vai sarežģīts, tam ir jāveic priekšapstrāde. Šis process pats par sevi patērē milisekundes vai pat sekundes. Rezultātā lietotājiem bija jāgaida ilgāk, lai saņemtu pat visvienkāršākās atbildes, kas radīja iespaidu, ka lietotne darbojas lēni un nestabili.

2. Klasifikācijas kļūdas un robežgadījumi

Nav iespējams izveidot perfektu klasifikatoru. Gadījumos, kad maršrutētājs kļūdaini novērtēja sarežģītu vaicājumu kā vienkāršu, lietotājs saņēma nekvalitatīvu, nepilnīgu vai pat pilnībā kļūdainu atbildi no lētāka modeļa. Šāda neparedzamība grauj uzticību produktam, jo lietotājs nekad nevar būt drošs par rezultāta precizitāti.

"Ja lietotājs vienreiz saņem izcilu atbildi, bet nākamreiz tajā pašā čatā - pilnīgi bezjēdzīgu, viņš nevainos maršrutētāju. Viņš vienkārši secinās, ka pats produkts ir slikts un nestabils."

3. Konteksta zaudēšana un sistēmas instrukciju nesaderība

Dažādiem modeļiem ir atšķirīga izpratne par sistēmas instrukcijām (system prompts). Modelis, kas ir optimizēts precīzai un strukturētai izvadei, reaģēs citādi nekā mazāks modelis, kuram ir tendence uz halucinācijām. Kad lietotājs veic sarunu, kurā daļa vaicājumu tiek apstrādāti ar vienu modeli, bet daļa ar citu, sarunas konteksts bieži tiek sadrumstalots, padarot asistentu apjukušu.

Salīdzinājums: Tiešais savienojums pret maršrutēšanas arhitektūru

Lai labāk saprastu kompromisus, aplūkosim, kā tiešā modeļu izmantošana atšķiras no dažādām optimizācijas pieejām.

Kā optimizēt izmaksas, nesabojājot lietotāja pieredzi?

Plānojot sava uzņēmuma AI budžetu, ir svarīgi saprast ne tikai infrastruktūras izdevumus, bet arī to, kāpēc dažādiem pakalpojumiem ir atšķirīgas cenas. Detalizētāku ieskatu par to, kā veidojas izdevumi, var gūt, ja tiek izpētītas kredītu un abonementu visas cenas mūsu platformā, kur izmaksas ir skaidri pārskatāmas bez slēptiem riskiem.

Tā vietā, lai ieviestu sarežģītus dinamiskos maršrutētājus, kas reāllaikā šķiro vaicājumus, ieteicams izvērtēt šādas alternatīvas:

• Promptu optimizācija un saīsināšana: Bieži vien izmaksas var samazināt par 20-30%, vienkārši iztīrot sistēmas instrukcijas no lieka teksta un atkārtojumiem.
• Statiskā maršrutēšana: Tā vietā, lai dinamiski vērtētu katru lietotāja teikumu, sadaliet funkcijas pa soļiem izstrādes posmā. Piemēram, datu bāzes vaicājumu ģenerēšanai vienmēr izmantojiet specializētu un lētāku modeli, bet gala atskaites noformēšanai - jaudīgāko.
• Semantiskā kešošana (Semantic Caching): Saglabājiet iepriekš sniegtās atbildes uz līdzīgiem jautājumiem. Ja jauns lietotāja jautājums pēc nozīmes ir ļoti tuvs kādam jau apstrādātam, atbildi var sniegt acumirklī bez jebkādas LLM izsaukšanas.

Secinājums

Mēģinājumi ietaupīt uz AI infrastruktūras rēķina ir saprotams solis jebkuram augošam biznesam, taču tie nedrīkst notikt uz produkta kvalitātes rēķina. Dinamiskie maršrutēšanas slāņi bieži vien rada vairāk problēmu nekā atrisina, palielinot sistēmas sarežģītību un pasliktinot lietotāju pieredzi. Pirms uzsākt šādu arhitektūras pārbūvi, uzņēmumiem ir rūpīgi jāizvērtē, vai tiešais ietaupījums atsver riskus zaudēt klientu lojalitāti un produkta stabilitāti.