Добици:
- Може да објасни шта је стриминг, врсте догађаја и зашто је потребан.
- мак_токенс прихвата временско ограничење и 128К дуг излазни однос
- Може направити прави избор између захтева за стримовање и нестриминг захтева у складу са обимом посла
Можда сте приметили да је у интерфејсу за ћаскање одговор „укуцан“ реч по реч. Ово није визуелни процват; То је резултат технике која се зове стримовање и често је обавезна за интеграцију ЛЛМ квалитета производње. У овој јединици ћете научити шта је ток, од којих догађаја се састоји, његов однос са дугим излазом и временским ограничењем, и када користити ток, а када не. Тему ћемо покрити кроз стварне задатке професионалца — помоћника уживо, генерисање дугог извештаја, групну обраду.
Шта је Флов?
Са нестриминг (синхроним) захтевом, чекате док модел не произведе цео одговор; Када је одговор готов, стиже у једном комаду. У захтеву за стриминг, сервер шаље одговор део по део док модел генерише. Технички, ово се ради са догађајима које шаље сервер (ССЕ — Сервер-Сент Евентс, метода у којој сервер шаље мале догађаје узастопно преко отворене везе).
Разлика постаје очигледна у корисничком искуству: на одговор који траје 8 секунди, корисник који није у стриму гледа у празан екран 8 секунди; Корисник стримовања види прве речи за ~0,5 секунди и текст почиње да тече. Уочено кашњење — чекање које корисник осећа — је знатно смањено, док укупно време остаје непромењено.
Догађај Типови тока
Ток је низ догађаја. Концептуално, типичан ток иде овако:
инцидент
Значење
мессаге_старт
Почео је одговор; Стигле су информације заглавља као што су модел и ИД.
цонтент_блоцк_старт
Започео је блок садржаја (нпр. текст).
цонтент_блоцк_делта
Стигао је мали део текста (делта); скупљаш ове
цонтент_блоцк_стоп
блок завршен
мессаге_делта
Ажуриране информације о завршетку као што су стоп_реасон и употреба
мессаге_стоп
Одговори преко
Ваш код секвенцијално комбинује делове текста у догађајима цонтент_блоцк_делта; на крају добијате исти текст као и одговор који није стримован. употреба (бројеви токена) су обично јасни на крају тока — ви пратите трошкове када се ток заврши.
Савет: Већина званичних пакета за развој софтвера (Софтваре Девелопмент Кит — готова библиотека добављача) пружа помоћника који прикупља стрим за вас (нпр. стреам.гет_финал_мессаге()). Не морате ручно да управљате свим нумерама; Користите овај помоћник ако желите цео текст, обрадите појединачне догађаје, али за штампање уживо.
Дуги одговори, мак_токени и временско ограничење
Други и више технички узрок стримовања је временско ограничење. Ако ХТТП захтев није довршен у одређеном временском периоду, клијент прекида везу. Када затражите велики излаз из модела (нпр. извештај од 40.000 токена), позив без протока може премашити ово ограничење и временско ограничење — захтев неће успети, а ви ћете морати да платите за генерисане токене.
Модерни модели могу да дају до 128.000 токена у једном захтеву. Али правило је јасно: користите стримове ако је вредност `мак_токенс` висока (отприлике изнад 16.000). Стримовање одржава везу живом и спречава временско ограничење; Такође ћете одмах видети напредак.
- `мак_токенс`: Максимални излазни токени које модел може да произведе; тврд плафон. Ако дође до прекида, стоп_реасон мак_токенс се враћа.
- Контекст прозор: Прозор у који збир улаза + излаза мора да стане. мак_токенс је плафон излаза; Не мешај то двоје.
Опрез: Избацивање захтева без протока са великим мак_токенима је класична грешка у производњи. Без одговора, веза се прекида, корисник види грешку, а трошак токена се губи. Дугачак излаз = ток.
Када тећи, а када не?
Статус
преференција
Зашто
Ливе цхат / асистент
ток
Примећено кашњење опада, корисник види напредак
Израда дугачког извештаја/документа
ток
Спречава временско ограничење, безбедно преноси велики излаз
Кратка класификација (нпр. ознака од једне речи)
нема протока
Излаз је већ мали; додатна сложеност непотребна
Батцх обрада
без протока / шаржа
Резултати се не приказују одмах; Види јединицу 7
Корак аутоматизације (у позадини)
Обично нема протока
Резултат прослеђујете на следећи корак, без приказа уживо
Промпт/шаблони који се могу копирати
Сам стреам није промпт, али упити су критични за управљање излазом који производи стреам. У дугим и течним продукцијама, наметање структуре са предње стране повећава и квалитет и следљивост.
# Поделите дугачак извештај на одељке (тако да је напредак видљив у току) Напишите извештај са следећим насловима, тачним редоследом. Започните сваки наслов са '##':## Резиме## Налази## Препоруке## Следећи кораци
# Дајте циљну дужину да бисте избегли скраћивање у дугој производњи. Укупан текст ће бити око 800 речи. Држите порције у равнотежи; Не остављајте пола реченице на крају.
# Одмах дајте прву реченицу за помоћника за стриминг. Прво дајте директан одговор у једној реченици, а затим идите у детаље. Дакле, корисник види тренутни резултат док чека.
# Одржавајте дуги излаз структурираним (како би касније могао да се рашчлани) Изнесите излаз у ове одељке и означите сваки одељак посебним '###' заглављем како бих могао да га програмски рашчланим: ### УВОД ### ТИЈЕЛО ### ИЗВОРИ
Слабо обавештење / Јако обавештење (дуга производња)
# СЛАБОНапишите дугачак и детаљан извештај о овој теми.
# СНАЖНО Напишите извештај од приближно 900 речи о овој теми. Наслови: ## Резиме, ## Анализа, ## Ризици, ## Препоруке. Сваки наслов треба да има највише 3 пасуса. Не остављајте пола реченице на крају.
Моћна верзија; Унапред одређује дужину, структуру и квалитет завршне обраде. Како секције долазе у току, корисник јасно види напредак и сам управља дужином против ризика од прекида модела.
Три мини кућишта
Случај 1 — Жалба на празан екран. Помоћник клијента консултантског тима је без протока одговарао; просечан одговор траје 7 секунди, корисници питају "да ли се замрзава?" пожалио се. Када сам ушао у ток, прва реч је дошла за ~0,6 секунди; Укупно време је остало исто, али "споре" жалбе су скоро нестале.
Случај 2 — Застарели извештај. Финансијски тим је припремао квартални извештај од 30 страница; Са мак_токенс: 30000, захтев без протока би се заглавио у временском ограничењу клијента од 60 секунди, захтев би пропао — и генерисани токени би били уписани у фактуру. Ишли су са током; веза је остала активна, извештај је достављен у потпуности, а изгубљени трошкови су елиминисани.
Случај 3 — Непотребан ток. Оперативни тим је означавао долазну е-пошту као „хитно/редовно“; Излаз је био једна реч, али су обично користили ток. Ток није дао никакву корист у одговору од једне речи, чинећи код непотребно сложеним. Када сам прешао на фловлесс, код се поједноставио и понашање је остало исто. Лекција: стриминг је драгоцен у дуготрајном/живом излазу, не свуда.
Уобичајене грешке
- Не коришћење токова у дугом излазу: временско ограничење и трошак токена.
- Коришћење стримовања у кратком излазу: Непотребна сложеност, нула користи.
- Не проверава `стоп_реасон` на крају тока: скраћени одговор са мак_токенсом се сматра потпуним.
- Нетачно спајање делта: Ручно сумирање помоћу СДК помоћника производи грешку секвенце/делова који недостају.
- Покушај читања „употребе“ усред тока: бројеви токена обично постају јасни на крају; Пратите трошкове на крају.
- Грешка за стриминг за смањење трошкова: стриминг побољшава искуство и издржљивост; То не мења цену токена.
Дубље: ломови протока и отпорност
Стреаминг је веза уживо; Ово је и њена снага и њена рањивост. Ако веза падне на средини (флуктуација мреже, временско ограничење клијента), задржаћете текст који сте до сада акумулирали, али одговор ће бити непотпун. Клијент за стриминг квалитета производње треба да буде спреман за ово: не би требало да третира делимични текст као „довршен одговор“, нити да сматра да је одговор завршен док не види догађај мессаге_стоп.
Друга суптилност је да ток не мења цену. Да ли ћете добити одговор са или без стриминга не утиче на цену токена; проток само побољшава искуство и издржљивост. Дакле, „ако идемо на стриминг, да ли ће бити јефтинији?“ Одговор на питање је не — за цену погледајте 5. и 6. јединицу (избор модела, кеш меморија).
Трећа тачка је успостављање практичне равнотеже: код помоћника уживо, брз долазак прве речи (опажено кашњење) се веома цени; Стога, тражење од модела да директно унесе одговор и прво да кратак резултат (преко системског одзивника у 4. јединици) умножава корист тока. Ако корисник види нешто значајно у првој секунди, стрпљиво чека на детаљ који следи. Са друге стране, ток нема допринос пословима који се извршавају у позадини, чији излаз иде на следећи корак аутоматизације; Једини критеријум је да је посао обављен коректно и у потпуности.
Укратко
Стреаминг преузима одговор део по део, смањујући уочено кашњење и спречавајући тајмауте при великом протоку. Готово обавезно за ливе асистента и продукцију дугог документа; Непотребан је за кратак/позадински рад. У дугим продукцијама, наметање структуре и дужине са предње стране са брзином повећава и квалитет и следљивост; Када се ток заврши, стоп_реасон и употреба су дефинитивно проверени.
Задатак апликације
Изаберите два сценарија: један уживо/дуги (нпр. извештај клијенту), један кратак/позадински (нпр. означавање). (1) Одлучите и образложите да ли ћете користити проток за сваки. (2) Напишите промпт који намеће структуру за дугачку скрипту (наслови + циљна дужина). (3) Одредите мак_токенс вредности. (4) Наведите које провере ћете извршити са стоп_реасон и употребом на крају тока.
контролна листа
- [ ] Могу да објасним шта је стриминг и како смањује уочено кашњење.
- [ ] Разумео сам основне типове догађаја у вези са стримом и делта спајањем.
- [ ] Знам за потребу за стримовањем са великим мак_токенима и односом временског ограничења.
- [ ] Могу да одлучим у ком радном оптерећењу ћу користити стриминг, а у ком не.
- [ ] Могу да проверим стоп_реасон и употребу на крају стрима.