Ад zero-shot да self-consistency: практычная лесвіца тэхнік промптынгу

Калі програма ужо выявіла, што можа бачыць мадэль, якія дакументы неабходна запрашаць, што трэба сконцэнтравіць, а што застаецца параду, пачынаецца іншыя проблема — правільна формулаванне самай запіту. Не існуе ўніверсальнага методу стварэння запітаў. Розумныя правілы — пачынаць з самай простай інструкцыі, якая можа запрацаваць, і прыменяць прыклады чы роўнавышнай структуру толькі тады, калі заведама, што гэта неабходна.

Прыклад сцэнарыю, які рассматрываецца, — гэта асістэнт падтрымкі кліентаў.

Пачатак без жадных прыкладоў

Запіт без прыкладоў опісвае задачу, але не паказвае, як выглядае правільны выхід. Для асістэнта падтрымкі гэта можа быць запіт у аднай лініі пра стварэнне падсумку скаргі, пры чым сама скарга пакладаецца пад яго:

Summarize the following customer complaint in one sentence.
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Мадэль атрымлее заданне і нічога больш. Самэй гэтая простасць і ўсё, што спакушае спробаваць яе першай. Кожны элемент, дадзены ў запіт, караецца пляцоўкай: прыклады з’ядзеюць кантэкст, дадатковыя інструкцыі падымаюць складнасць, а кожны новы элемент стварае ўсё больш месцаў для суперсцяжэння двух правілаў. Калі простая інструкцыя вялікі ўжо дае надзеяны выхад, то слоўнае оформленне — гэта лек проты хворобы, якой ніхто не мае.

Што адпавядае хорашая інструкцыя

Добра сформульаваная інструкцыя да задання выясняе чатырнацца пунктав: дзеініцыяўкі дзеяння, матэрыял, з якога трэба скорыстацца, дапускныя межы і форма, якой павінен быць адпаведны выхад. Болей дакладная версія запіта выглядае так:

Task:
Summarize the customer complaint.

Source:
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Constraints:
- Use only the information in the complaint.
- Do not infer the cause of the damage.
- Use one sentence.

Output:
Return only the summary.

Ён болей дзялёгі, чым простае запітанне «Паракстатыце гэта», пры тым кожна дадзеная лінія зменшае колькасць спэкуляцый. Модэлю больш не трэба думаць, чы хацець гадаць пра прычыны, як далека існаваць у сваіх выкладках, чы прыемлівыя ўвагі. Рэкамендаціі, выданыя вялікімі вэндорамі модэляў, таксама паказваюць той жа направленні: трэба чытаць, калікі ў заведамасці, калікі мае быць выходны рэзультат, якія існуюць обмежэнні і які кантэкст мае значэнне, замест таго, каб спадзявацца, што модэль гэта з’ясуе сам. Проста кажучы, кожныя трэбаванні, якія маюць значэнне для прыемлівання, трэба запісаць.

Конкрэтныя цялі лепшыя за дружэльныя

„Быць адказным“ практычна не дае модэлю нічога, к чаму ён мог бы старавацца. „Назваць проблему, якую опісвае кліент, і паракулькаваць яе ў адной фразе“ дае яму чыткую мету. Пораўняйце два інструкцыі для інструмента падтрымкі: слабкія прасіць адказаць кліенту, тым часам як адназначныя прасіць назваць проблему аутантыкацыі, якую опісвае кліент, а таксама не болей чым трохі крокаў для адлучэння прычыны, падтрымленаўых паданай дакументацыяй.

Гэта мае значэнне, таму што модэль можа продаваць адказ у багацько можлівых напрамках. Нечыткая мета залішае прыгоду для таго, каб ён выбраў тлумачэнне, якое не збігаецца з намерамі распрацоўшчыка, тады калі чыткая мета зменшае гэты прыгод.

Ліміты павінны быць у самай задачы

Некалікатэўскі асістэнт ніколі не павінен выдумваць спосаб рашэння, якога няма ў дасведчэннях. Гэта ўмова продукту, таму у запіце неабходна яе прызначыць: выкорыстоўваць толькі паданыя дасведчэння, а калі яны не пакрываюць запітанне, зазначыць, што наявной інфармацыі недастатнька. Пораўняйце гэта з трэбованнем «Быць точным», якое называе бажаны рэзультат, але не дае інструкцый пра тое, што робіць у разе неяснасці.

Гэты патэрн можа быць запашчэнны. Не толькі трэба опісаць ідэальны рэзультат; трэба таксама апісаць, што модэль павінен робіць, калі гэты рэзультат нельга безпечна атрымаць. Гэта ўжо болей важліва пазней, для вызоўвання інструментаў і структураванага выходу.

Дзе дастатнік zero-shot

Простая інструкцыя зазвычай падходзіць, калі задача простая, ўсё можна легка выразіць словамі, мадэль вясна, што за задача, правіла выходу простыя, а у вхідных даных няма чагось незвычайнага. Запіт на версію продукту ў паведамленні, толькі номер версіі, — гэта такая задача. Пераклад зместу на французскія — іншая. Адразу пяць дэманстрацый мало дапамагаюць.

Таму першыя правіла оптымізацыі запітоў ёсць крыху консерватывныя: пачніце з методу zero-shot і дадзіце дапамогу толькі пасля таго, як адзынак пакажае такую неабходнасць.

Способы, калі метод zero-shot не працуе

Павтараюцца калькі тыпаў неудач.

Амбігуітэт. Фраза «Зробіце гэта лепшая» ставяе пытанне: корачэ, пераканаючэ, тачнэй, фармальнэй? Модэль вынужана здагадвацца. Пораўняйце гэта з просьбай перапісаць адпаведзь на запыткі падтрымкі так, каб яна была канкрэтная, прафесыянальная і зрозумелая не-тэхнічнаму кліенту, пры чым усі факты застаўаліся недыскрэтаванымі. Такі варыянт мае набліжнае абмежэнне.

Відсутны кантэкст. Модэль не можа паспакоўвацца фактамі, якія ёй ніколі не былі даны і якія яна не можа запрашаць. Запытайце яе, чаму аутэнтыфікацыя кліента не выйшла, не падаючы паведамлення пра адказку чы сведчынні сістэмы, і жадна перапісва не стварыць нехватную інфармацыю. У такім случае рашэннем ёсць лепшы кантэкст, а не крашчая інструкцыя. Гэта явны момент, а таксама справжняя межа інжынерыі запыткаў.

Суперасунутыя трэбаванні. Запрос, які прасіць даёмую адказ у роўна дзесяць слоў, выклікае два патрабаванні, якія нельгае адпрацаваць належна. Хорашыя прыметы запітаў прабываюць узбегнуць такім суперасунам, замест таго каб пакладацца на мадэль, што яна сама ўсё рашыць.

Незгаданыя прыпускі. Распрацоўшчык, які пішае "Падсумаваць прытварэнне", можа мяркуваць пра "спісаванне толькі тых фактов, якія згадаў кліент". Мадэль жа можа вернуць плавны падсумак з разумнымі заключэннямі, якія ў яго ўключаны. Якшча гэтае разніце мае значэнне, інструкцыя павінна яе чытальна апісаць. Прыпускі, якія маюць значэнне для сістэмы, павінны стаць чытальнымі, машыннымі трэбаваннямі.

Дадаць прыклады

Калі звычная інструкцыя недасцца, наступным спосабам ёсць prompt-ы з канламі прыкладаў: падача працавальных прыкладаў задання ў кантэкст. Класыфікатор, які сортавае паведамленні на катэгорыі білінгу, тэхнічныя і аблікавыя, можа паказаць калькі паведамленняў з атрыбутамі раней, чым паказаць рэальнае паведамленне:

Task:
Classify the customer message as BILLING, TECHNICAL, or ACCOUNT.

Example 1:
"My invoice contains an unexpected charge."
→ BILLING

Example 2:
"The application crashes when I upload a file."
→ TECHNICAL

Example 3:
"I cannot reset my password."
→ ACCOUNT

Now classify:
"I was charged twice for my subscription."

З тых дэманстрацыяў модэль выводзіць схему адносаў. Гэта называецца навчаннем у кантэксце, адтолькі ў момент выканання паказанага запіту модэль зміняе сваю дзеяльнасьць, выкарыстоўваючы прыклады з свайго „вікна“, тады як яе базовыя параметры застаюцца незменнымі. По суты, прыклады кажуць: „Гэта як выглядае задача на практыцы“, і яны можу парадкаваць дэталі, якія важка адобразіць у прозе.

Дэманстрацыі выучаюць задачу, а не толькі ўзоркі

Багатыя распрацоўшчыкі вважаюць прыклады з некалькіма кейсамі толькі адказам на пытанні пра фарматаванне. Але ў яны ёсць большае значэньне. Возьмім прыклад пары „програма працюе медленна“ з атрыбутам TECHNICAL. Гэта паказвае фармат выходу, але таксама і тое, як гэтая програма розумее катэгорыю TECHNICAL. Прыклады формуюць розуменьне самай задачы у модэля.

Дзеўа прычына, чаму паслабыя прыклады ўскладнююць сітуацыю — гэта рызык. Нестабільныя атрыбуты, нехтаўныя уперадзеўкі чы адлікі, якія суперачаюць правілам, могу быць перакопіраваны модэлем.

Выбір прыкладаў, якія трэба адначасова включыць

Калі ёсць 10 000 історычных запыткаў, немагчыма включыць іх усе ў запрос, таму трэба выбраць частку з іх. Адбіранне на адной засадзе ўзэйцоў — глупы падход. Лепшы варыянт — цэлесапраўдна выбіраць прыклады, якія ўособліваюць розныя сцэнарыі:

Example 1: straightforward billing issue
Example 2: straightforward technical issue
Example 3: ambiguous issue
Example 4: boundary case
Example 5: short, poorly written request

Тое, што лягае ў парадок добранага выбору, залежыць ад задачы. Для класыфікацыі неабходна прадстаўлення галоўных класоў і ўзламаў меж між ямі. Для задачы фарматавання патрэбны прыклады, якія паказваюць неабходную структуру. Для задач, якія выкарыстоўваюць большую частку разумовых вырахункаў, корыстны прыклады, якія паказваюць, як расчланіць задачу або як яе пераканаць. У кожным случае прыклад здобывае свае месца завдзяк інфармацыі, яку ён несе, а не таму, што ён доступны.

Скількі

Больш не значыць апошнія. Якшчо адзін рэштрыкавана выбраны прыклад робіць працэздатнасць зрозумелай, трыдцаць іншых можа дадаць тыячы токенав без жадных выгод і моцнаўвесты да суперсучасных шаблонаў. Такім чынам, метод керавання за дапамою некалькіх прыкладоў спадчынае тую ж напругу ў кантэкстным бюджэце, што і іншыя падходы, і правільная колькасць прыкладоў трэба знаходзіць праз тэставанне.

Ёнтлі промпт-інжынія тут пачынае адгукваць экспэрыментальнай працы. Пытанне перастае быць у тым, чы рэчыцы промпта звучыць лепшая, і стае у тым, чы гэта версія парадныя лепша ў тэстовых кейсах. Гэта змена стае ключовай, калі прыходзіць час ацэнкі.

Разнаўтнасць у прыкладах

Калі кожны прыклад — гэта короткая, чыстая, добра напісаная просьба, мадэль можа выучыць вузкі шаблон, якога не следуе рэальныя корыстувальнікі. Рэальныя паведамленні выглядаюць так:

"can't login"
"I've been locked out since yesterday"
"Password reset isn't sending me anything"
"login broken after changing phone"

Усе гэтыя прыклады опісваюць схожыя проблемы, але разнымі словамі. Хорашы набор прыкладаў па канкрэтным сценарыям парадкавае тыя варыяцыі, якія чакае аплікацыя. Гэта не значыць дадаванне прыкладаў аднойчынна; гэта значыць намеравана паказаць значымых разліків.

Паказаць, чаго трэба ухіліцца

Дзякуючы спароўванню хорашага і паслабленага рэзультата, дзеякія заведаменні стаюць корыстнымі, тады мадэль можа бачыць межу. У разе падтрымкі паведамленне пра запаздзелыя пакеты можа супакоўвацца з аднойчынным і некорэктным підсумкам:

Input:
"The customer says the package arrived late."
Good output:
"The customer reports that the package arrived late."
Bad output:
"The courier lost the package."
Reason:
The customer did not state that the courier lost it.

Няправільны прыклад паказуе меры: не трэба выводзіць факты, якія не падтрымваюцца інфармацыяй, якая дана. Аднак з негатывнымі прыкладамі трэба быць абераглівым. Адны прыклад, пазначаны як няправільны, можа віпадкова навучыць самэй той поведэнцы, якую планавалася запобiec, особліва калі разлік ўсё ж такі тонкі. Програма должна пераканацца, чы розгляд негатывных прыкладоў павышае рэзультаты, а не проста гадаць, што так і будзе.

Прыклады для структуры

Калі важка опісаць структуру выходу, прыклад дапамагае. Падазроўваючы, што асістэнт павінен адпаведзець трыма радкамі з пазначэннямі: проблема, доказы і дзеянне:

Issue: ...
Evidence: ...
Action: ...

Адзін працюючы прыклад адразу ж уявляе гэтыя макеты:

Input:
"The login token expired after 30 days."
Output:
Issue: Expired authentication token
Evidence: Token expiration is reported after 30 days
Action: Regenerate the authentication token

Ён выправляе як шаблон контэнту, так і яго адказ. Аднак прыклады не завжды ўсунуць усі проблемы. Калі програмнаму забаве патрэбны JSON-даныя, якія можа прачытаць апарат і якія маюць гарантаваную правамернасць, тады функцыя выходу, абмежаная схемай, можа быць надзейней, чым проста показаць модэлю прыклад.

Зберагчы цэласообразнасц прыкладоў

Запросы з малым колікствам прыкладоў паслаба рэагуюць на суперасункі. Разглянем два практычныя прыклады з аднаковым вхідным даным — „Не можаць заўязацца“; у аднам з іх пазначэнне — ACCOUNT, а ў другім — TECHNICAL:

Example 1:
"Can't log in" → ACCOUNT
Example 2:
"Can't log in" → TECHNICAL

У модэлі няма чыста парадыгмы, якая дапамагаў бы ёй з’ясавіць, які самэльт фармуецца. Нават болей тонкія несувярэннасці таксама шкодзяць. Калі дзеяныя прыклады выкарыстоўваюць абазаванне «BILLING», а іншыя — фразу «Billing issue», тады рэзультаты становяцца нечыткімі. Абазаванні, фарматаванне, тэрмінологія, рагульнасць дэталяў і спосаб прыемлівання крайніх кейсаў павінны быць аднаковымі ў всіх прыкладах. Дэманстрацыі ўскладненняў ўходзяць у склад спецыфікацыі і таксама заслугвалі на тое ж адносленне.

Навчанне ў межах кантэксту

Навчанне ў кантэксце — гэта загальная ідэя, якая стоіць за методам кількісных прапаноў: прыклады знаходзяцца ў чынным кантэксце, і поведзенне модэлі зміняецца пад час такой взаімадзеі. Гэта не значыць, што модэлі перманентна абсорбуе іх. Калі прыкладнае рашэнне адправляе адны прыклад з абазаваннем, а пасля — паведамленне ад корыстніка пра немагчымасць доступу да абліквоты:

Example:
"Password reset email never arrived." → ACCOUNT
User:
"I can't access my account."

Мадэль можа выкарыстоўваць практычны прыклад для адпаведнага запіту. Яе параметры не адкорэгулююцца, а прыклад не дадаецца да яе стойкіх знанняў. Гэта адпавядае ранейшам разлічэнню між кантэкстам і памяцюю. Методы, якія зміняюць параметры, напрыклад тонкая наладка на дадатковых даных для навчання, ўтвараюць адзінэчны механізм, і ўпораўнэнне іх з методамі падказак прыходзіць значна пазней. Наразе метод падказак на канікуле лепей спрыяе тымчасовай наладзе задачы праз адпаведны кантэкст.

Выбір між двума методамі

Эфектыўны працэс прыняцтва рашэння пачынаецца з апісання таго, чаму выходны рэзультат не ўсунуўся. Неясная задача вымагае болей чыстага формулювання. Недастатак інформацыі — лепшага кантэксту. Калі мадэль працягвае ігнораваць якую-небудзь тонкую прымету, тады прыклады можу стаць адпаведным рашэннем. Калі задача выкарыстоўвае тэчную арыфметыку або доступ да базы дадзеных, большая колькасць тэксту ў падказцы можа выступіць абсалютна неправым спосабам рашэння.

Гэты последні случай ведае да сложнейшых сітуацыяў. Дзеянні, якія занадта складныя, ўскладненыя для надзеянага адкрыцця за дапамой адной інструкцыі і аднай адпаведзі. Іх неабходна разбіць на меншыя крокі, пераканацца ў ўсім або прыўязаць да зовнішніх вычыслаў. Пасля певнай парады вызов ужэ не ў тым, каб знайсці ідэальныя словы; ён у тым, каб разрабіць невялікую процедуру, якую мае следаваць мадэль.

Разглядзім тыкет, у яком кліент не можа зайсці ў сістэму адразу пасля змены пароля, і асістэнту прыказваюць пераглянуць історыю, выявіць верагодную прычыну і напісаць адпаведзь. Гэта выглядае як адна задача. У практыцы ў ёй крыюцца калькі іншых: з’ясаванне таго, што сталося, пошук актуальных доказаў, разлік фактов і прыпускаў, аналіз можлівых прычын, выявленне таго, што можна безпечна рэкамендаваць, пераканацца ў гэтай рэкамендацыі і напісанне заканчальнай адпаведзі. Розумеўшы гэта, можна прыйсці да разбівання задачы на часткі.

Разбіўка адной задачы на калькі

Дэкомпазія заменяе адну складную задачу калькамі меншых задач, якія маюць чыстыя межы. У зменшэнні до таго, каб прасіць пра все заодно, прыкладнэць можа распісаць запіт на адзіныя этапы:

Task:
Analyze this customer support case.

Step 1:
Extract the relevant facts.

Step 2:
Identify the customer's actual problem.

Step 3:
List plausible causes supported by the evidence.

Step 4:
Select the safest supported resolution.

Step 5:
Draft the customer-facing response.

Модэлю буквальна наявнасць слова „Крок“ не ўсё так важна. Галоўнае — калі нечыясны цэль ператвараецца на серыю кантролюемых дзеянняў. Гэта особліва дапамагае, калі элементы маюць разную прыроду: выявленне фактов — гэта задача інформацыйнага характэру, выбір дыягназу — гэта працэс разумовага аналізу, а напісанне паведамлення — гэта форма кантакту. Аднальванне ўсіх гэтых элементаў у адну незрозумелую інструкцыю ускладнюе кераванне рэзультатам і яго ацэнку.

Разбітыя на часты сістэмы таксама даюць больш можлівасцей для тэставання. Калі канечны адказ некарэктны, можна выявіць, чы не паспела задача выявлення фактов, дыягназування чы напісання адказу. Зміна падходу заключаецца у тым, што запіт можна структураваць як ланцюг дзеяння, а не толькі напісаць у вопытнай форме.

Спачатку плануйце, а потым дзеяйце

Адзін з супаўналежных методаў — гэта прыказ модэлю падготавіць план пры выкананні складнай задачы. Ён дапамагае, калі модэлю неабходна спачатку выбраць, якія дзеянні трэба адрабаты, перш чым ён зможа даць адказ. Памочны асістэнт можа пачаць з меты і арганізаванага плану:

Goal:
Resolve the customer's login problem using only supported evidence.
Plan:
1. Read the latest customer message.
2. Check the relevant conversation history.
3. Identify authentication-related evidence.
4. Compare the evidence with the known troubleshooting guidance.
5. Produce a response that does not claim unsupported facts.

Планаванне адзельнае рашэнне пра тое, як чаго-небудзь спрацавіць, ад самага спрацоўвання. Гэта адзельнае рашэнне становіць большую значымасць, калі ўжо ўжываюцца інструменты, адтуды модэлю можа знадобіцца вынікнуць, што яму трэба спачатку шукань у базе знанняў, абмовіцца з дакументамі абліковача або выконаць вылічэння. Заданне задачы можа стварыць структуру працы ўсё раней, чым яна пачнёцца.

Гэта мае сваю цэну. Разбіўка на часткі падвайніць дужыну запіта, а калі кожны этап ёсць самастоятным запітам, дадаецца ўсё больш запытоў да модэлю і затрымкі. Працэс з пяцьма этапамі можа коштаць значна больш, чым адзін запыт. Гэта мае сэнс, калі даданы контроль і надзеяна надзеянае карыстнае рашэнне падтрымваюць такую цэну, а не таму, што больша колькасць этапаў за сваёй сутнасцю лепшая.

Ствараць, аналізаваць, перрабляць

Іншы сільны прынцып дазваляе модэлі зноў адзірнуцца на свой саставлены праект. Першая адпаведзь не спрымваецца як фінальная; другі перагляд праблематызуе яе на адповіднасць чыстаракавым крэтэрыям. Для сістэмы падтрымкі гэта значыць саставіць адпаведзь, а пасля пераканацца, чы рэшэння паспаўляе да спісу апісаных проблем:

First:
Draft the response.

Then:
Check the draft for:
- unsupported claims,
- missing evidence,
- incorrect troubleshooting steps,
- promises the support team cannot make,
- failure to answer the customer's actual question.

Finally:
Revise the response to correct any problems.

Гэта працюе таму, што стварэнне і адзінакоŭванне — гэта разныя задачы. Стварэнне значыць падготавліванне чаго-небудзь правдападобнага. Перагляд ужэ існуючай адпаведзі разрахоўваець на тое, што ён знайдзе наявнасць нарушэнняў паказанага спіса. Указванне крэтарыяў зазвычай ёсць эфектывнейшым, чым проста прасіць яго пра больш глыбокае размышленне.

Гэты патэрн можа быць прыменены на разныя глыбіні: праця над чэрнавіком, перагляд, фінальная адпаведзь, або, для болей структураванай задачы, выкарыстоўванне дадзеных, перакананне ў правядласці выкарыстоўвання, класыфікацыя, перакананне ў правядласці класыфікацыі, стварэнне. Другі варыант лёгкій да дыбагавання, таму што кожны этап мае чыткая структура.

Ўсім важна адна меры. Мадэль, якой прасівае крытыкаваць сябе, не становіць такім чынам незалежнага джэрага правды. Калі первісны адказ апоўнены хыбным прыпускам, крытык таксама можа яго перадаць. Самакрытыка можа павышыць адпаведнасць, але не гарантуе правільнасці, і для рашэнняў з вялікімі наследкамы варта пераканацца ў ўсём на адной з зовнішніх аснов: у базе дадзеных, вядомым правіле, расчытку, запрашаным дакуменце чыя дэтэрміністычным кодзе.

Запросы, якія адкрываюць структуру разумовых працэсаў

Даследжэнні ўжывання запросаў з пашырэннем логічных крокаў паказалі, што прадстаўленне модэлі прыкладаў з проміжнымі крокамі разумовых працэсаў можа павысіць рэзультаты ў дзеяных багатых на крокі задачах, пры чым фіксаваліся павышэнні ў арыфмэтычных, здаровага сэнсу і сімвалічных тэстах. Урокі інжынерыі ўсё шырэй за гэтыя фразы. Комплексныя задачы можу практычна павысіць свою эфектыўнасць, калі запрос чытка паказвае ўсю проміжную структуру ўсіх працэсаў.

Identify the relevant facts.
Determine which facts support each possible conclusion.
Eliminate conclusions that require unsupported assumptions.
Select the conclusion supported by the evidence.

Гэта ўпор на логічныя механізмы: формаванне задачы так, каб проміжныя рашэнні былі дастаткова ясныя для керавання модэллю да бажанага рэзультата. Гэта не вымагае, каб прыкладны програма паказвала корыстніку внутрэшнюю логіку модэлі. Часта лепшы інтэрфейс запрашвае рэзультат пераканання, а не дзялёга адказа. Програма можа выкарыстоўваць кампактны внутрэшні фікс, падобны таму, што паказана ніжэй, а пасля отрымліваць окрэмы короткі адказ для кліента:

classification: password_reset_issue
evidence_supported: true
recommended_action: resend_reset_link
confidence: high

Структура аргументацыі і пояснення для кліента — гэта разныя трэбаванні. Іх раздзелэнне таксама дапамагае ухіліцца ад распашчайшага ошыбкі, калі люды прыпускаюць, што чым больш аргументаў відна, тым надзеянней адпаведны адказ. Нават проміжныя крокі можу містыць аберанціі. Даследжэнні методу chain-of-thought паказалі, што такія характэрыстыкі дэманстрацый, як іх значэнне і парадак, маюць вельмі важлівую ролю, таму проста дадаць дужыя аргументы не ўсуне гэтую проблему.

Калькі спроб, а потым галасаванне

Стварэнне адказа ўражаецца верыятнасцямі, таму адна задача можа даваць разныя адказы пад разнымі запускамі. Метод сама-кансістэнціі выкарыстоўвае гэта, прыменяючы калькі шляхоў аргументацыі і выбіраючы той адказ, які падтрымвае большасць з іх, замест таго, каб паверыць толькі аднаму з выбранных шляхоў.

Падзеймім, што сістэма падтрымкі не ведае, чы рэчыця стосуецца проблемы з перазначэннем пароля чы блокаванняя адказу. У замест на тое, каб прыняць адну класыфікацыю, яна можа стварыць калькіляванні і парабяліць рэзультаты, якія яны даюць.

Адпаведнасць усё ж недастатнька, каб паведаміць правду. Калі мадэль сталякі неправаляўна адлічвае сітуацыю, многа незалежных калькыляванняя можу дасягнуць таго ж няправільнага адпаведнага рэшэння. Адпаведнасць — гэта паказанні стабільнасці, а не доказ правільнасці. Кроме таго, гэта выклікае большыя вычыслювальныя затраты і падвышае затрымкі, таму такі падход ўжыткавы толькі для задач, якія настолькі складныя, што падыш у надзеямнасці прабачае такія вітраты.

Дзе запросы трэба перадаць коду

Хтоць тут і ёсць межа межа між все болей складзімі запітамі і гарным праектаваннем сістэмы. Уявіце, што трэба вычысліць суму счытку з 17 пунктамі, кожны з якіх коштае ₹1500. Мадэль, верагацыя, можа вырахаваць такую суму, але калі важна точная фінансавая цыфра, няма прычыны прымусваць яе імітаваць арыфметычныя вычыскі за дапамою все дужэй дужэй довгіх інструкцый. Калькулятор або звычная програма вырахоўвае суму дэтэрміністычна.

Тая ж логіка прыменяецца і да іншых задач:

• Даныя рахунку павінны прыходзіць з запыту да базы дадзеных, а не з памяці модэлі.
• Трэба запрашваць актуальныя факты, а не прыгадваць іх з перыоду навчання.
• Арыфметыка належыць калькулятору або программе.
• Перакананне схемы — задача парсера і верыфікатора.
• Автарызацыя стосуецца коду прыемлівача і правіл кантролю доступу.
• Крытычныя бізнес-правіла павінны быць закодаваны дэтэрміністычна, калі гэта можліва.

Існуе корыстная правіла: выкорыстоўваюце падказкі для керавання поведэннем мовных модэляў, а таксама выкорыстоўваюце дэтэрміністычныя програмы, калі задача фактычна выкалікае дэтэрміністычныя вычысленні аб адпаведную рэалізацыю.

Зовнішніе дзеянні падкрэпляюць гэты падход. ReAct — вядомы даследнічы падход, які спалучае разумаванне з дзеяннямі, так што модэль можа аб’являцца да зовнішніх джэрэл аб сераўакоў узамен на тое, каб спакою паслужвацца толькі внутранімі знаннямі; ён паказаў, што такая взаімадзейнасць можа спрыяць рашэнню проблем, такіх як галюцынаціі і распространэнне памылак у дзеякіх задачах.

Гэта ўзьязд да таго, што будзе пасля. Сістэма падтрымкі спачатку была простым запітам, а зараз нагадвае маленькую програму. Калі для пераканання трэбуецца база дадзеных, база знанняў, API чы іншыя зовнішнія можлівасці, мадэль больш не працуе толькі з тэкстам, і пытанне пераходзіць да інжынерыі кантэкста: трэба не толькі выбраць, калія інструкцыі напісаць, але і выбраць, яю інформацыю мадэль павінна прымець.