30-წუთიანი სამუშაო სესია იმაზე, როგორ დაიწეროს პრომპტი, რომელიც ორჯერ ერთნაირად იქცევა — იმით დაწყებული, როგორ კითხულობს მოდელი თქვენს ტექსტს, მკაფიო ინსტრუქციებით, მაგალითებით, სტრუქტურირებული გამოსავლითა და ინსტრუმენტების გამოძახებით, მსჯელობის ტექნიკებით და prompt injection-ისგან თავდაცვით.
სანამ მოდელს მართავთ, გამოგადგებათ იცოდეთ, რას აკეთებს ის სინამდვილეში: თქვენს ტექსტს ჭრის ტოკენებად, ყველაფერს ატევს ფიქსირებულ კონტექსტის ფანჯარაში და თავის ყურადღებას არათანაბრად ანაწილებს თქვენს ინსტრუქციებზე. კარგი პრომპტინგი ძირითადად ამ სამ ფაქტთან ერთად მუშაობაა და არა მათ წინააღმდეგ.
Summarize შეიძლება ასე დაიშალოს: Sum + mar + ize.თქვენი ტექსტი იშლება ტოკენებად; მოდელი მათ კითხულობს და შემდეგ სათითაოდ გენერირებს ყველაზე სავარაუდო მომდევნო ტოკენს.
ყველაფერი ერთსა და იმავე ფიქსირებულ ბიუჯეტს ეცილება. თუ მას ისტორიით ამოავსებთ, მოდელს პასუხისთვის ადგილი აღარ დარჩება.
მოდელი უფრო დიდი სისტემის ერთი ნაწილია — ხელახალი მცდელობები, სტრიმინგი და მეხსიერება მის ირგვლივ არსებულ აპლიკაციაში ცხოვრობს. ეს შრე ცალკე თემაა: LLM აპლიკაციების აგება.
პრომპტინგში ყველაზე დიდი ბერკეტი ამავე დროს ყველაზე მოსაწყენია: ზუსტად თქვით, რა გინდათ. დაასახელეთ როლი, აუდიტორია, ფორმატი, სიგრძე და ის, რა უნდა ქნას მოდელმა, როცა დარწმუნებული არ არის. მოდელი ორაზროვნებას საშუალო ვარაუდით ავსებს — თქვენი საქმეა, ნაკლები დატოვოთ გამოსაცნობი.
გარე შრეები წესებს ადგენს; შიდა შრეები მოთხოვნას ავსებს. რაც უფრო შიგნით მიდიხართ, ნდობა მცირდება — ეს მე-6 ნაწილისთვის მნიშვნელოვანია.
<doc>…</doc>), რომ მოდელმა თქვენი ინსტრუქციები მონაცემებისგან გაარჩიოს.ზოგი შაბლონი უფრო ადვილი საჩვენებელია, ვიდრე აღსაწერი — რთული გამოსავლის ფორმატი, ეტიკეტირების წესი, კონკრეტული ტონი. ჩასვით პრომპტში რამდენიმე გარჩეული მაგალითი და მოდელი შაბლონს გაიმეორებს. სწორედ ეს არის few-shot პრომპტინგი.
input → output მაგალითს, რომ მოდელმა შაბლონი ანალოგიით ამოიცნოს. „shot“ უბრალოდ მაგალითს ნიშნავს: ერთი მაგალითი one-shot არის, რამდენიმე — few-shot.მაგალითები პასუხის ზუსტ ფორმას აფიქსირებს — გაცილებით სანდოა, ვიდრე ფორმატის სიტყვებით აღწერა.
როგორც კი მოდელის გამოსავალი სხვა პროგრამას კვებავს, თავისუფალი ტექსტი რისკად იქცევა. ამას ორი შესაძლებლობა ასწორებს: სტრუქტურირებული გამოსავალი პასუხს თქვენ მიერ განსაზღვრულ სქემაში აქცევს, ხოლო ინსტრუმენტების გამოძახება მოდელს აძლევს საშუალებას, სთხოვოს თქვენს კოდს რაღაცის გაკეთება და შედეგი გამოიყენოს.
მოდელი თავად არაფერს უშვებს — ის ითხოვს გამოძახებას, თქვენი აპლიკაცია ასრულებს მას და შედეგი პრომპტში ბრუნდება.
მრავალნაბიჯიან ამოცანებზე — მათემატიკა, ლოგიკა, დაგეგმვა, ფრთხილი ამოღება — მოდელი, რომელიც პირველსავე ტოკენს ისვრის, ხშირად ცდება. ისეთი ტექნიკები, როგორიცაა chain-of-thought, დაშლა და თვითშემოწმება, რამდენიმე დამატებით ტოკენს ცვლის შესამჩნევად უკეთეს პასუხებში, რადგან მოდელს ხმამაღლა მსჯელობის საშუალებას აძლევს.
ნაბიჯების გავლა მომდევნო ტოკენებს სწორ საყრდენს აძლევს — ერთი იმპულსური ვარაუდის ნაცვლად.
„უფრო ჭკვიანად ჩანს“ მტკიცებულება არ არის. ნამდვილად შველის თუ არა CoT, მეტი მაგალითი ან უფრო დიდი მოდელი — ეს ემპირიული შეკითხვაა: გაუშვით ფიქსირებულ სატესტო ნაკრებზე და შეადარეთ. ეს დისციპლინა ცალკე თემაა: LLM Evals & LLMOps.
პრომპტი, რომელიც playground-ში მუშაობს, შეიძლება ჩუმად გაუარესდეს, როცა ერთ სიტყვას შეცვლით, მოდელს გამოცვლით ან ახალ შემავალს წააწყდებით. ორი პრაქტიკა გინარჩუნებთ პატიოსანს: ცვლილებები გაზომეთ შეფასებებით და ჩათვალეთ, რომ გარედან მოსული ნებისმიერი ტექსტი პოტენციურად მტრულია.
მონაცემებში დამალულმა მტრულმა ტექსტმა შეიძლება თქვენი ინსტრუქციები გადაფაროს და ბოროტად გამოიყენოს ის ინსტრუმენტები, რაც მოდელს უჭირავს.
აღჭურვილობის თავად აგება საჭირო არ არის. ერთი სტრიქონი იმაზე, სად ჯდება თითოეული ინსტრუმენტი — და რა კომპრომისს ითხოვს:
დეკლარაციული სატესტო შემთხვევები, რომლებიც ერთ პრომპტს რამდენიმე შემავალსა და მოდელზე უშვებს, მტკიცებებითა და გვერდიგვერდ შედარებით.
პრომპტებს პარამეტრებად აღიქვამს და თქვენ მიერ განსაზღვრული მეტრიკის მიხედვით არეგულირებს — მაგალითების შერჩევის ჩათვლით.
ამოწმებს სტრუქტურირებულ გამოსავალს სქემასთან ან წესებთან და შეუსაბამობისას ხელახლა ცდის ან ასწორებს.
იჭერს ნამდვილ ტრაფიკს, აგებს მონაცემთა ნაკრებებს და დროთა განმავლობაში ქულავს წესებით ან LLM-მსაჯით (Langfuse, LangSmith, Braintrust).
პროვაიდერის, SDK-ის ან მოდელის არჩევა — სტრიმინგი, ხელახალი მცდელობები, ღირებულება — ცალკე გადაწყვეტილებაა და აქ არის განხილული: LLM აპლიკაციების აგება; გაზომვის დისციპლინა კი უფრო ღრმად აქ არის: LLM Evals & LLMOps.
თითქმის ყველა სანდო პრომპტი რამდენიმე ჩვევას უბრუნდება — და თითქმის ყველა არასტაბილური რამდენიმე შეცდომას იმეორებს. აირჩიეთ ყველაზე მსუბუქი ტექნიკა, რომელიც საქმეს აკეთებს; მძიმეს მხოლოდ მაშინ მიმართეთ, როცა მარტივი ვარიანტი დამტკიცებულად ვერ ართმევს თავს.
მიმართეთ ყველაზე მარტივ სტრიქონს, რომელიც მუშაობს; ქვემოთ მხოლოდ მაშინ ჩადით, როცა ის აღარ კმარა.
„მოდელს ნაკლები დაუტოვეთ გამოსაცნობი — მერე კი დაამტკიცეთ, რომ გამოვიდა.“
ხუთი სწრაფი შეკითხვა ტოკენებზე, ინსტრუქციებზე, few-shot-ზე, ინსტრუმენტების გამოძახებასა და prompt injection-ზე — მყისიერი უკუკავშირი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში