Qazanclar:
- Axın nə olduğunu, hadisə növlərini və nə üçün lazım olduğunu izah edə bilər.
- max_tokens vaxt aşımı və 128K uzun çıxış əlaqəsini başa düşür
- İş yükünə uyğun olaraq axın və yayımsız sorğular arasında düzgün seçim edə bilər
Söhbət interfeysində cavabın sözbəsöz “yazıldığını” fərq etmiş ola bilərsiniz. Bu vizual çiçəklənmə deyil; O, axın adlı texnikanın nəticəsidir və istehsal keyfiyyətli LLM inteqrasiyası üçün çox vaxt məcburidir. Bu bölmədə siz axının nə olduğunu, hansı hadisələrdən ibarət olduğunu, uzun çıxış və vaxt aşımı ilə əlaqəsini və axının nə vaxt istifadə ediləcəyini və nə vaxt istifadə edilməməsini öyrənəcəksiniz. Mövzunu peşəkarın real vəzifələri - canlı köməkçi, uzun hesabat yaratmaq, toplu işləmə vasitəsilə əhatə edəcəyik.
Flow nədir?
Streaming olmayan (sinxron) sorğu ilə siz modelin bütün cavabı hazırlamasını gözləyin; Cavab hazır olduqda, bir parça olaraq gəlir. Axın sorğusunda server model yaratdığı kimi cavabı hissə-hissə göndərir. Texniki cəhətdən bu, server tərəfindən göndərilən hadisələrlə həyata keçirilir (SSE — Server tərəfindən Göndərilən Hadisələr, serverin açıq əlaqə üzərindən ardıcıl olaraq kiçik hadisələri göndərdiyi üsul).
Fərq istifadəçi təcrübəsində aydın olur: 8 saniyə çəkən cavabda, yayımdan kənar istifadəçi 8 saniyə boş ekrana baxır; Axın istifadəçisi ilk sözləri ~0,5 saniyə ərzində görür və mətn axmağa başlayır. Qəbul edilən gecikmə - istifadəçinin hiss etdiyi gözləmə müddəti - xeyli azalır, ümumi vaxt isə dəyişməz qalır.
Hadisə axınının növləri
Axın hadisələrin ardıcıllığıdır. Konseptual olaraq, tipik bir axın belə olur:
hadisə
Mənası
mesaj_start
Cavab başladı; Model və ID kimi başlıq məlumatları gəldi.
content_block_start
Məzmun bloku (məsələn, mətn) başladı
content_block_delta
Kiçik bir mətn parçası (delta) gəldi; bunları yığarsan
content_block_stop
blok tamamlandı
mesaj_delta
stop_reason və istifadə kimi son məlumat yeniləndi
mesaj_stop
Üstündən cavab verin
Kodunuz ardıcıl olaraq content_block_delta hadisələrindəki mətn hissələrini birləşdirir; axın olunmayan cavabla eyni mətnlə başa çatırsınız. istifadə (token nömrələri) adətən axının sonunda aydın olur — axın bitdikdən sonra siz xərcləri izləyirsiniz.
İpucu: Əksər rəsmi SDK-lar (Proqram Təminatı İnkişaf etdirmə Dəsti — provayderin hazır kitabxanası) sizin üçün axını toplayan köməkçi təmin edir (məsələn, stream.get_final_message()). Bütün trekləri əl ilə idarə etmək lazım deyil; Tam mətni, fərdi hadisələri emal etmək, ancaq canlı çap üçün istəyirsinizsə, bu köməkçidən istifadə edin.
Uzun Cavablar, max_tokens və Taymout
Axının ikinci və daha çox texniki səbəbi fasilədir. HTTP sorğusu müəyyən müddət ərzində tamamlanmazsa, müştəri əlaqəni kəsir. Modeldən böyük bir çıxış tələb etdikdə (məsələn, 40.000 tokendən ibarət hesabat), qeyri-axın zəng bu limiti keçə bilər və vaxt aşımına uğraya bilər – sorğu uğursuz olacaq və siz yaradılan tokenlər üçün ödəniş etməli olacaqsınız.
Müasir modellər bir sorğuda 128.000 token çıxara bilər. Lakin əsas qayda aydındır: `max_tokens` dəyəri yüksək olduqda (təxminən 16,000-dən yuxarı) axınlardan istifadə edin. Axın əlaqəni canlı saxlayır və fasilələrin qarşısını alır; Siz həmçinin dərhal tərəqqi görəcəksiniz.
- `max_tokens`: Modelin istehsal edə biləcəyi maksimum çıxış tokenləri; sərt tavan. Əgər fasilə baş verərsə, stop_reason max_tokens qaytarılır.
- Kontekst pəncərəsi: Giriş + çıxış cəminin uyğun olması lazım olan pəncərə. max_tokens çıxışın tavanıdır; İkisini qarışdırmayın.
Diqqət: Böyük max_tokens ilə qeyri-axın sorğuların atılması istehsalda klassik səhvdir. Cavab olmadıqda, əlaqə kəsilir, istifadəçi xəta görür və token dəyəri boşa gedir. Uzun çıxış = axın.
Nə vaxt axmalı və nə vaxt yox?
Vəziyyət
üstünlük
Niyə
Canlı söhbət / köməkçi
axın
Qəbul edilən gecikmə azalır, istifadəçi irəliləyiş görür
Uzun hesabat / sənəd istehsalı
axın
Zaman aşımının qarşısını alır, böyük çıxışı təhlükəsiz daşıyır
Qısa təsnifat (məsələn, tək söz etiketi)
axın yoxdur
Çıxış artıq kiçikdir; lazımsız əlavə mürəkkəblik
Toplu emal
axınsız/toplu
Nəticələr dərhal göstərilmir; 7-ci bölməyə baxın
Avtomatlaşdırma addımı (arxa fonda)
Adətən axın yoxdur
Nəticəni növbəti mərhələyə keçirsiniz, canlı ekran yoxdur
Kopyalana bilən sorğu/şablonlar
Axının özü xəbərdar deyil, lakin göstərişlər axın tərəfindən istehsal olunan çıxışı idarə etmək üçün vacibdir. Uzun və axıcı istehsallarda quruluşun öndən tətbiq edilməsi həm keyfiyyəti, həm də izlənilmə qabiliyyətini artırır.
# Uzun hesabatı bölmələrə ayırın (proqramda irəliləyiş görünsün) Hesabatı aşağıdakı başlıqlarla, bu dəqiq ardıcıllıqla yazın. Hər başlığa '## ' ilə başlayın:## Xülasə## Tapıntılar## Tövsiyələr## Növbəti addımlar
# Uzun istehsalda kəsilmənin qarşısını almaq üçün hədəf uzunluğu verin. Ümumi mətn təxminən 800 söz olacaq. Porsiyaları balanslı saxlayın; Sonda yarım cümlə qoymayın.
# Axın köməkçisi üçün dərhal ilk cümləni verin. Əvvəlcə birbaşa bir cümləlik cavab verin, sonra təfərrüata keçin. Beləliklə, istifadəçi gözləyərkən dərhal nəticə görür.
# Uzun çıxışı strukturlaşdırılmış saxlayın (sonra təhlil oluna bilsin) Çıxışı bu bölmələrdə çıxarın və hər bir bölməni ayrıca '### ' başlığı ilə qeyd edin ki, mən onu proqramlı şəkildə təhlil edə bilim: ### GİRİŞ ### BADƏ ### MƏNBƏLƏR
Zəif tez / Güclü tez (uzun istehsal)
# ZƏFS Bu mövzuda uzun və ətraflı hesabat yazın.
# STRONGBu mövzuda təxminən 900 sözdən ibarət hesabat yazın. Başlıqlar: ## Xülasə, ## Təhlil, ## Risklər, ## Tövsiyələr. Hər başlıq maksimum 3 abzas olmalıdır. Sonda yarım cümlə qoymayın.
Güclü versiya; Uzunluğunu, quruluşunu və bitmə keyfiyyətini əvvəlcədən müəyyənləşdirir. Bölmələr axınına gəldikdə, istifadəçi tərəqqini aydın görür və modelin kəsilməsi riskinə qarşı uzunluğu özü idarə edir.
Üç mini qutu
Case 1 - Boş ekran şikayəti. Məsləhətçi qrupun müştəri köməkçisi hərəkətsiz cavab verirdi; orta cavab 7 saniyə çəkir, istifadəçilər "dondururmu?" şikayətləndi. Mən axına daxil olduqdan sonra ilk söz ~0,6 saniyə ərzində gəldi; Ümumi vaxt eyni qaldı, lakin "yavaş" şikayətlər demək olar ki, yox oldu.
Case 2 – Köhnəlmiş hesabat. Maliyyə komandası 30 səhifəlik rüblük hesabat hazırlayırdı; max_tokens: 30000 ilə, axınsız sorğu 60 saniyəlik müştəri fasiləsində ilişib qalacaq, sorğu uğursuz olacaq və yaradılan tokenlər fakturaya yazılacaq. Onlar axınla getdilər; əlaqə canlı qaldı, hesabat tam şəkildə çatdırıldı və israf edilmiş xərclər aradan qaldırıldı.
3-cü vəziyyət - Lazımsız axın. Əməliyyat qrupu daxil olan e-poçtları “təcili/müntəzəm” kimi etiketləyirdi; Çıxış bir söz idi, lakin onlar adətən axın istifadə edirdilər. Axın bir sözdən ibarət cavabda heç bir fayda vermədi və kodu lazımsız dərəcədə mürəkkəb etdi. Mən axınsız rejimə keçəndə kod sadələşdi və davranış eyni qaldı. Dərs: axın hər yerdə deyil, uzun/canlı çıxışda dəyərlidir.
Ümumi səhvlər
- Uzun çıxışda axınlardan istifadə edilməməsi: Zaman aşımı və sərf edilmiş token dəyəri.
- Qısa çıxışda axından istifadə: Lazımsız mürəkkəblik, sıfır fayda.
- Yayın sonunda `stop_reason` yoxlanılmır: max_tokens ilə kəsilmiş cavab tamamlanmış hesab olunur.
- Deltaların səhv birləşdirilməsi: SDK köməkçisi ilə əl ilə toplama ardıcıllıq/çatışmayan hissələr xətası yaradır.
- `istifadə`-ni oxumağa çalışırıq: Token nömrələri adətən sonunda aydın olur; Sonda xərcləri izləyin.
- Xərcləri azaltmaq üçün axınla səhv salmaq: Yayım təcrübə və dözümlülüyü artırır; Token qiymətini dəyişmir.
Daha dərin: Axın fasilələri və möhkəmlik
Axın canlı əlaqədir; Bu onun həm gücü, həm də zəifliyidir. Əgər əlaqə ortada düşərsə (şəbəkə dalğalanması, müştərinin fasiləsi), indiyə qədər topladığınız mətni saxlayacaqsınız, lakin cavab natamam olacaq. İstehsal keyfiyyətli axın müştərisi bunun üçün hazırlanmalıdır: o, qismən mətnə "tamamlanmış cavab" kimi yanaşmamalı, mesaj_stop hadisəsini görənə qədər cavabı bitmiş hesab etməməlidir.
İkinci incəlik ondan ibarətdir ki, axın maya dəyərini dəyişmir. Yayımla və ya yayımsız cavab almağınız token qiymətinə təsir göstərmir; axın yalnız təcrübə və dözümlülüyü artırır. Beləliklə, "axın etməyə getsək, onlar daha ucuz olacaq?" Sualın cavabı yox - qiymət üçün 5-ci və 6-cı bölməyə baxın (model seçimi, keş).
Üçüncü nöqtə, praktiki tarazlıq yaratmaqdır: canlı köməkçilərlə, ilk sözün sürətli gəlişi (qavranılan gecikmə) yüksək qiymətləndirilir; Buna görə də, modeldən birbaşa cavabı daxil etməyi və əvvəlcə qısa bir nəticə verməsini xahiş etmək (4-cü bölmədə sistem sorğusu vasitəsilə) axının faydasını artırır. İstifadəçi ilk saniyədə mənalı bir şey görürsə, səbirlə sonrakı təfərrüatı gözləyir. Digər tərəfdən, axının arxa planda işləyən işlərə heç bir töhfəsi yoxdur, çıxışı növbəti avtomatlaşdırma mərhələsinə keçir; Orada yeganə meyar işin düzgün və tam yerinə yetirilməsidir.
Xülasə
Streaming cavabı hissə-hissə əldə edir, qəbul edilən gecikməni azaldır və böyük ötürmələrdə fasilələrin qarşısını alır. Canlı köməkçi və uzun sənəd istehsalı üçün demək olar ki, məcburidir; Qısa/fon işi üçün lazımsızdır. Uzun istehsallarda quruluşun və uzunluğun öndən tez bir şəkildə tətbiq edilməsi həm keyfiyyəti, həm də izlənilmə qabiliyyətini artırır; Axın başa çatdıqda, stop_reason və istifadə mütləq yoxlanılır.
Tətbiq tapşırığı
İki ssenari seçin: biri canlı/uzun (məsələn, müştəriyə hesabat), biri qısa/fon (məsələn, etiketləmə). (1) Hər biri üçün axın istifadə edib-etməyəcəyinizə qərar verin və əsaslandırın. (2) Uzun skript üçün strukturu tətbiq edən əmr yazın (başlıqlar + hədəf uzunluğu). (3) max_tokens dəyərlərini təyin edin. (4) axının sonunda stop_reason və istifadə ilə həyata keçirəcəyiniz yoxlamaları sadalayın.
yoxlama siyahısı
- [ ] Mən axın nə olduğunu və onun qəbul edilən gecikməni necə azaltdığını izah edə bilərəm.
- [ ] Mən axın və delta birləşməsinin əsas hadisə növlərini başa düşdüm.
- [ ] Mən böyük max_tokens ilə axın ehtiyacı və vaxt aşımı əlaqəsi haqqında bilirəm.
- [ ] Hansı iş yükündə axından istifadə edəcəyimə və hansı iş yükündə istifadə etməyəcəyimə qərar verə bilərəm.
- [ ] Mən axının sonunda stop_reason və istifadəni yoxlaya bilərəm.