Табыстар:
- Ағынның не екенін, оқиға түрлерін және оның не үшін қажет екенін түсіндіре алады.
- max_tokens күту уақытын және 128K ұзақ шығыс қатынасын түсінеді
- Жұмыс жүктемесіне сәйкес ағынды және ағынсыз сұраулар арасында дұрыс таңдау жасай алады
Чат интерфейсінде жауап сөзден сөзге «терілгенін» байқаған боларсыз. Бұл көрнекі гүлдену емес; Бұл ағындық деп аталатын әдістеменің нәтижесі және көбінесе өндірістік сапалы LLM интеграциясы үшін міндетті болып табылады. Бұл бөлімде сіз ағынның не екенін, оның қандай оқиғалардан тұратынын, оның ұзақ шығыс және күту уақытымен байланысын және ағынды қашан пайдалану керектігін және қай кезде пайдаланбау керектігін білесіз. Біз тақырыпты кәсіби маманның нақты міндеттері — тірі ассистент, ұзақ есеп шығару, пакетті өңдеу арқылы қарастырамыз.
Flow дегеніміз не?
Ағынсыз (синхронды) сұраумен модель бүкіл жауапты жасағанша күтесіз; Жауап дайын болғанда, ол бір бөлікке келеді. Ағынды сұрауда сервер үлгі жасаған кезде жауапты бөлікпен жібереді. Техникалық тұрғыдан бұл серверден жіберілген оқиғалармен орындалады (SSE — Server-Sent Events, сервер ашық қосылым арқылы шағын оқиғаларды ретімен жіберетін әдіс).
Айырмашылық пайдаланушы тәжірибесінде айқын болады: 8 секундқа созылатын жауапта ағынсыз пайдаланушы 8 секунд бойы бос экранға қарап тұрады; Ағынды пайдаланушы алғашқы сөздерді ~0,5 секундта көреді және мәтін ағып бастайды. Қабылданған кідіріс — пайдаланушы сезетін күту — айтарлықтай қысқарады, ал жалпы уақыт өзгеріссіз қалады.
Ағынның оқиға түрлері
Ағын – оқиғалар тізбегі. Тұжырымдама бойынша әдеттегі ағын келесідей болады:
оқиға
Мағынасы
хабарлама_бастау
Жауап басталды; Үлгі және идентификатор сияқты тақырып ақпараты келді.
мазмұнды_блоктау_бастау
Мазмұн блогы (мысалы, мәтін) басталды
content_block_delta
Мәтіннің шағын бөлігі (дельта) келді; мыналарды жинайсың
content_block_stop
блок аяқталды
хабар_дельта
Stop_reason және пайдалану сияқты аяқталу ақпараты жаңартылды
хабарлама_тоқтату
Жауап беру
Кодыңыз мәтін бөліктерін content_block_delta оқиғаларында дәйекті түрде біріктіреді; сіз ағынсыз жауап сияқты дәл мәтінмен аяқталасыз. пайдалану (таңбалауыш сандар) әдетте ағынның соңында анық болады — ағын аяқталғаннан кейін шығындарды қадағалап отырасыз.
Кеңес: Көптеген ресми SDK (бағдарламалық жасақтаманы әзірлеу жинағы — провайдердің дайын кітапханасы) сізге ағынды жинайтын көмекші береді (мысалы, stream.get_final_message()). Барлық тректерді қолмен басқарудың қажеті жоқ; Толық мәтінді, жеке оқиғаларды өңдеуді, бірақ тікелей басып шығаруды қаласаңыз, осы көмекшіні пайдаланыңыз.
Ұзақ жауаптар, max_tokens және күту уақыты
Ағынның екінші және техникалық себебі - күту уақыты. HTTP сұрауы белгілі бір уақыт ішінде аяқталмаса, клиент қосылымды тоқтатады. Үлгіден үлкен нәтижені (мысалы, 40 000 таңбалауыш есеп) сұраған кезде, ағынсыз қоңырау осы шектен асып кетуі және күту уақыты аяқталуы мүмкін — сұрау сәтсіз аяқталады және жасалған таңбалауыштар үшін төлеуге тура келеді.
Заманауи үлгілер бір сұрауда 128 000 таңбалауышқа дейін шығара алады. Бірақ негізгі ереже анық: `max_tokens` мәні жоғары болса (шамамен 16 000-нан жоғары) ағындарды пайдаланыңыз. Ағын қосылымды сақтайды және күту уақытын болдырмайды; Сондай-ақ прогресті бірден көресіз.
- `max_tokens`: үлгі шығара алатын максималды шығыс таңбалауыштары; қатты төбе. Егер үзіліс орын алса, stop_reason max_tokens қайтарылады.
- Мәтінмәндік терезе: Енгізу+шығыс қосындысы сәйкес келетін терезе. max_tokens - шығыстың төбесі; Екеуін араластырмаңыз.
Абайлаңыз: үлкен max_tokens бар ағынсыз сұрауларды шығару өндірістегі классикалық қате болып табылады. Жауап болмаса, қосылым үзіледі, пайдаланушы қатені көреді және таңбалауыш құны босқа кетеді. Ұзын шығыс = ағын.
Қашан ағу керек және қашан болмайды?
Күй
артықшылық
Неліктен
Тікелей чат / көмекші
ағын
Қабылданатын кідіріс төмендейді, пайдаланушы ілгерілеуді көреді
Ұзақ есеп/құжат жасау
ағын
Күтудің алдын алады, үлкен өнімді қауіпсіз тасымалдайды
Қысқаша жіктеу (мысалы, бір сөздік тег)
ағын жоқ
Шығару қазірдің өзінде аз; қосымша күрделілік қажет емес
Пакеттік өңдеу
ағынсыз/топтама
Нәтижелер бірден көрсетілмейді; 7-бірлікті қараңыз
Автоматтандыру қадамы (фонда)
Әдетте ағын жоқ
Нәтижені келесі қадамға өткізесіз, тікелей көрсетілмейді
Көшіретін шақыру/үлгілер
Ағынның өзі шақыру емес, бірақ шақырулар ағынмен шығарылатын шығысты басқару үшін маңызды. Ұзын және ағынды өндірістерде құрылымды алдыңғы жағынан таңу сапаны да, бақылауды да арттырады.
# Ұзын есепті бөлімдерге бөліңіз (прогресс ағында көрінетіндей) Есепті келесі тақырыптармен дәл осы ретпен жазыңыз. Әрбір тақырыпты "##" деп бастаңыз:## Түйіндеме## Қорытынды## Ұсыныстар## Келесі қадамдар
# Ұзақ өндірісте қысқартуды болдырмау үшін мақсатты ұзындықты беріңіз. Жалпы мәтін шамамен 800 сөзді құрайды. Бөлшектерді теңестіріңіз; Соңында жарты сөйлем қалдырмаңыз.
# Ағынды көмекші үшін бірінші сөйлемді дереу айтыңыз. Алдымен бір сөйлемнен тұратын тікелей жауап беріңіз, содан кейін егжей-тегжейлі айтыңыз. Осылайша, пайдаланушы күту кезінде бірден нәтижені көреді.
# Ұзын шығысты құрылымды ұстаңыз (оны кейінірек талдауға болады) Осы бөлімдердегі шығысты шығарып, әр бөлімді бөлек '### ' тақырыбымен белгілеңіз, осылайша мен оны бағдарламалық түрде талдай аламын: ### КІРІСПЕ ### МЕКЕН ### КӨЗДЕР
Әлсіз жедел / Күшті жедел (ұзақ өндіріс)
# ӘЛСІЗ Осы тақырып бойынша ұзақ және егжей-тегжейлі баяндама жазыңыз.
# STRONG Осы тақырып бойынша шамамен 900 сөзден тұратын есеп жазыңыз. Тақырыптар: ## Түйіндеме, ## Талдау, ## Тәуекелдер, ## Ұсыныстар. Әрбір тақырып ең көбі 3 абзацтан тұруы керек. Соңында жарты сөйлем қалдырмаңыз.
Күшті нұсқасы; Ол ұзындығын, құрылымын және әрлеу сапасын алдын ала анықтайды. Бөлімдер ағынға келгенде, пайдаланушы ілгерілеуді анық көреді және үлгінің үзілу қаупіне қарсы ұзындықты өзі басқарады.
Үш шағын корпус
1-жағдай — бос экран шағымы. Консалтингтік топтың клиент көмекшісі ағынсыз жауап берді; Орташа жауап 7 секундты алады, пайдаланушылар «қатып қалады ма?» деп сұрайды. ол шағымданды. Мен ағынға кіргенімде, бірінші сөз ~0,6 секундта келді; Жалпы уақыт өзгеріссіз қалды, бірақ «баяу» шағымдар дерлік жоғалып кетті.
2-жағдай — Ескірген есеп. Қаржы тобы 30 беттік тоқсандық есепті дайындады; max_tokens: 30000 көмегімен ағынсыз сұрау 60 секундтық клиент күту уақытында тұрып қалады, сұрау сәтсіз аяқталады және жасалған таңбалауыштар шот-фактураға жазылады. Олар ағынмен жүрді; байланыс үзіліссіз қалды, есеп толығымен жеткізілді және бос шығындар жойылды.
3-жағдай — Қажетсіз ағын. Операциялық топ кіріс электрондық хаттарды «шұғыл/тұрақты» деп белгіледі; Шығару бір сөз болды, бірақ олар әдетте ағынды пайдаланды. Ағын бір сөзден тұратын жауапта ешқандай пайда әкелмеді, бұл кодты қажетсіз күрделі етеді. Мен ағынсыз режимге ауысқанда, код жеңілдетілді және мінез-құлық өзгеріссіз қалды. Сабақ: ағынды беру барлық жерде емес, ұзақ/өмірлік нәтижеде құнды.
Жалпы қателер
- Ұзақ шығыста ағындарды пайдаланбау: күту уақыты және бос таңбалауыш құны.
- Қысқа нәтижеде ағынды пайдалану: қажетсіз күрделілік, нөлдік пайда.
- Ағынның соңында «тоқтату_себебі» тексерілмейді: max_tokens көмегімен қысқартылған жауап аяқталды деп саналады.
- Дельталарды қате біріктіру: SDK көмекшісімен қолмен қосу реттілік/жетілмеген бөліктер қатесін тудырады.
- 'usage' орта ағынын оқуға тырысу: Токен сандары әдетте соңында анық болады; Соңында шығындарды қадағалаңыз.
- Шығындарды азайту үшін ағынмен қателесу: ағынмен жұмыс істеу тәжірибе мен төзімділікті жақсартады; Ол токен бағасын өзгертпейді.
Тереңірек: ағынның үзілуі және тұрақтылық
Ағын - бұл тікелей байланыс; Бұл оның күштілігі де, осалдығы да. Егер қосылым ортасына түссе (желінің ауытқуы, клиент күту уақыты), сіз осы уақытқа дейін жинақтаған мәтінді сақтайсыз, бірақ жауап толық емес болады. Бұл үшін өндіріс сапасының ағындық клиенті дайын болуы керек: ол ішінара мәтінді «аяқталған жауап» ретінде қарастырмауы керек және ол message_stop оқиғасын көрмейінше жауапты аяқталды деп санамауы керек.
Екінші нәзіктік - бұл ағынның құнын өзгертпейді. Жауапты ағынмен немесе ағынсыз алуыңыз токен бағасына әсер етпейді; ағын тек тәжірибе мен төзімділікті арттырады. «Егер біз стримингке барсақ, олар арзанырақ бола ма?» Сұраққа жауап жоқ — құны бойынша 5-ші және 6-шы блокты қараңыз (үлгіні таңдау, кэш).
Үшінші тармақ - практикалық тепе-теңдікті сақтау: тірі көмекшілермен бірінші сөздің жылдам келуі (қабылданған кешігу) жоғары бағаланады; Сондықтан, модельден жауапты тікелей енгізуді және алдымен қысқа нәтиже беруді сұрау (4-ші блоктағы жүйелік нұсқау арқылы) ағынның пайдасын көбейтеді. Егер пайдаланушы бірінші секундта маңызды нәрсені көрсе, олар келесі мәліметтерді шыдамдылықпен күтеді. Екінші жағынан, ағынның шығысы автоматтандырудың келесі қадамына өтетін фондық режимде орындалатын тапсырмаларға үлесі жоқ; Ондағы жалғыз критерий - жұмыстың дұрыс және толық орындалуы.
Қысқаша айтқанда
Ағын жауапты бөлік-бөлшектеп шығарып, қабылданатын кідірісті азайтады және үлкен өткізу қабілеттіктерінде күту уақытын болдырмайды. Тікелей көмекші және ұзақ құжатты жасау үшін міндетті дерлік; Бұл қысқа/фондық жұмыс үшін қажет емес. Ұзын өндірістерде құрылым мен ұзындықты алдыңғы жағынан жылдам таңу сапаны да, қадағалануды да арттырады; Ағын аяқталған кезде, тоқтату_себебі және пайдалану міндетті түрде тексеріледі.
Қолданбалы тапсырма
Екі сценарийді таңдаңыз: біреуі тікелей/ұзақ (мысалы, тұтынушыға есеп беру), бір қысқа/фон (мысалы, тегтеу). (1) Әрқайсысы үшін ағынды пайдалануды шешіп, негіздеңіз. (2) Ұзын сценарий үшін құрылымды жүктейтін шақыруды жазыңыз (тақырыптар + мақсатты ұзындық). (3) max_token мәндерін анықтаңыз. (4) Ағынның соңында тоқтату_себебі және пайдалану арқылы орындайтын тексерулерді тізімдеңіз.
бақылау парағы
- [ ] Мен ағынның не екенін және ол қабылданатын кідірісті қалай азайтатынын түсіндіре аламын.
- [ ] Мен ағын мен дельтаны біріктірудің негізгі оқиға түрлерін түсіндім.
- [ ] Мен үлкен max_tokens бар ағынның қажеттілігі және күту уақыты қатынасы туралы білемін.
- [ ] Мен қай жұмыс жүктемесінде ағынды қолданатынымды және қайсысында қолданбайтынымды шеше аламын.
- [ ] Мен ағынның соңында тоқтату_себебі мен пайдалануды тексере аламын.