36-წუთიანი სამუშაო სესია იმაზე, როგორ დავაპროგრამოთ მოდელი, რომლის სრულად წინასწარმეტყველებაც შეუძლებელია — პრომპტები როგორც თქვენი API, ტიპიზებული JSON გამოსავალი, მოდელისთვის თქვენი კოდის გამოძახების უფლება, სტრიმინგი სისწრაფის შეგრძნებისთვის და როგორ დაამტკიცოთ, რომ ეს მუშაობს.
ყველა კოდის სტრიქონი, რომელიც აქამდე დაგიწერიათ, დეტერმინისტულია: ერთი და იგივე შესატანი, ერთი და იგივე გამოსავალი, ყოველთვის. LLM ამ დაპირებას არღვევს. ერთი და იგივე პრომპტი ყოველ გამოძახებაზე სხვადასხვა ტექსტს აბრუნებს, და ვერავინ — მისი შემქმნელებიც კი — ვერ გეტყვით ზუსტად, რატომ. კარგად აგება ნიშნავს, დააპროექტოთ ამ გაურკვევლობის გარშემო, ნაცვლად იმისა, რომ თავი მოიტყუოთ, თითქოს ის არ არსებობს.
ერთი და იგივე გამოძახება, დამაჯერებელი პასუხების სპექტრი — უმეტესობა კარგი, ზოგი მცდარი. დააპროექტეთ სპექტრზე, არა ერთ მნიშვნელობაზე.
არასდროს შეამოწმოთ სტრიქონების ზუსტი ტოლობა. დაავალიდირეთ ფორმა და თვისებები ("არის ეს ვალიდური JSON ამ ველებით?"), და არა ზუსტი სიტყვები.
მოდელი ხანდახან გამოიგონებს ფაქტებს, სახელებს ან API-ებს, რომლებიც სწორად ჟღერს. ის არ იტყუება — ის პატერნს ასრულებს. დააფუძნეთ და შეამოწმეთ (ნაწილი 05).
იხდით თითოეულ ტოკენზე (ტექსტის ნაწილი, სიტყვის ~¾) შესვლისა და გამოსვლისას, დიდი მოდელები კი უფრო ნელა პასუხობენ. მოდელის არჩევა რეალური საინჟინრო კომპრომისია და არა შემდგომში მოსაფიქრებელი წვრილმანი.
ჩვეულებრივი ბიბლიოთეკის შემთხვევაში ფუნქციის ხელმოწერას კითხულობთ. LLM-თან კი პრომპტი არის ინტერფეისი, რომელსაც თქვენ აპროექტებთ: ის განსაზღვრავს როლს, წესებს, მაგალითებს და იმ ფორმას, რომელიც პასუხად გინდათ. ბუნდოვანი პრომპტი — ბუნდოვანი პროდუქტი. ზუსტი, სტრუქტურირებული პრომპტი ყველაზე დიდი ბერკეტია, რომელსაც თქვენ აკონტროლებთ.
system = მუდმივი კონტრაქტი; user = ცვალებადი მოთხოვნა. წესები system შეტყობინებაში დატოვეთ, რომ ყოველი ჯერი დაემორჩილოს მათ.
UNKNOWN").ჰგავს ახალი თანამშრომლის ადაპტაციას: მკაფიო როლი, ორიოდე გარჩეული მაგალითი და აკრძალვების სია სასარგებლო პირველ დღეს გაძლევთ.
პროზა შესანიშნავია ადამიანისთვის და უსარგებლო თქვენი პროგრამის დანარჩენი ნაწილისთვის. ორი შესაძლებლობა ჩატ-სათამაშოს სამშენებლო აგურად აქცევს: სტრუქტურირებული გამოსავალი (მოდელი აბრუნებს მონაცემებს, რომლებიც თქვენ მიერ განსაზღვრულ სქემას შეესაბამება) და ინსტრუმენტების გამოძახება (მოდელი ითხოვს, რომ თქვენი ფუნქციები გაეშვას და შედეგებს იყენებს).
zod ან JSON Schema), SDK ამით ზღუდავს მოდელს და უკან იღებთ ტიპიან ობიექტს, რომელიც პირდაპირ გამოგადგებათ — არავითარი მყიფე სტრიქონების პარსინგი და არავითარი "გთხოვ, JSON-ად უპასუხე" და იმედი.import { generateObject } from "ai" import { z } from "zod" const { object } = await generateObject({ model, schema: z.object({ category: z.enum(["billing", "bug", "other"]), urgency: z.number().min(1).max(5), }), prompt: ticket.body, }) // object.category is a typed string — use it directly
სქემა არის კონტრაქტი. უკან იღებთ ტიპიან ობიექტს და არა აბზაცს, რომელიც უნდა დაპარსოთ და იმედი იქონიოთ.
getWeather({city:"Berlin"}). რეალურ ფუნქციას თქვენი კოდი უშვებს და შედეგს უკან აწვდის, შემდეგ კი მოდელი პასუხს რეალური მონაცემებით ასრულებს.const { text } = await generateText({ model, prompt: "How many open billing tickets today?", tools: { countTickets: { description: "Count tickets by status", parameters: z.object({ status: z.string() }), execute: async ({ status }) => db.count(status), }, }, }) // model asks → your code runs → model answers with the number
მოდელი თქვენს მონაცემთა ბაზას არასდროს ეხება. ის ინსტრუმენტს ითხოვს; თქვენ უშვებთ და შედეგს აბრუნებთ; ის კი რეალური მონაცემებით პასუხობს.
ინსტრუმენტების ხელით ჩართვა ყოველ აპლიკაციაში მოსაბეზრებელი ხდება. MCP არის ღია სტანდარტი (წარადგინა Anthropic-მა), რომელიც ნებისმიერ ჰოსტს — Claude Desktop, Claude Code, IDE-ს გაფართოება — საშუალებას აძლევს, დაუკავშირდეს სერვერს, რომელიც საერთო პროტოკოლით გასცემს ინსტრუმენტებს, რესურსებსა და პრომპტებს. ტრანსპორტებია stdio (ლოკალური) და streamable HTTP (დისტანციური). სერვერს ერთხელ ააგებთ; ყველა MCP ჰოსტი გამოიყენებს. ღრმად ვსაუბრობთ MCP-ის დეკში.
კარგ პასუხს დასრულებამდე შეიძლება მრავალი წამი დასჭირდეს. თუ სანამ რამეს აჩვენებდეთ, მთელს დაელოდებით, აპლიკაცია გატეხილი მოგეჩვენებათ. სტრიმინგი პასუხს ტოკენ-ტოკენ აგზავნის, ასე რომ მომხმარებელი სიტყვების გამოჩენას მაშინვე ხედავს — იგივე საერთო დრო, სრულიად სხვა შეგრძნება.
ორივე ერთსა და იმავე მომენტში სრულდება. სტრიმინგი უბრალოდ იმას შველის, რომ მომხმარებელი მთელი გზა მკვდარ სპინერს არ უყუროს.
import { streamText } from "ai" const result = streamText({ model, prompt: ticket.body, }) // pipe straight to the browser; UI renders as it flows return result.toUIMessageStreamResponse()
ვერ დაწერთ assert(output === expected) მოდელისთვის, რომელიც თავს არასდროს იმეორებს. ამიტომ სხვანაირად ტესტავთ: აგებთ შეფასებული მაგალითების პატარა ნაკრებს (შეფასებები), ყოველ ცვლილებას მათზე ქულავთ და ცოცხალ სისტემას ახვევთ გარდრეილებით, რომლებიც ცუდ გამოსავალს იჭერს, სანამ მომხმარებელი მას დაინახავს.
გაუშვით ნაკრები, შეაფასეთ პასუხები, თვალი ადევნეთ გავლის მაჩვენებელს. პრომპტი ან მოდელი მხოლოდ მაშინ შეცვალეთ, თუ ციფრი იზრდება.
category ეტიკეტს? იაფი, ობიექტური, თქვენი თავდაცვის პირველი ხაზი.მოაშორეთ ან უარყავით პრომპტ-ინექციის მცდელობები და აშკარად ცუდი შესატანი. შეზღუდეთ სიგრძე, რომ გიგანტურმა ჩასმამ თქვენი ტოკენების ბიუჯეტი არ ააფეთქოს.
სტრუქტურირებული გამოსავალი ხელახლა შეამოწმეთ სქემასთან. თუ ინსტრუმენტი "გამოიძახეს", გაშვებამდე დარწმუნდით, რომ არგუმენტები საღია. მოდელის ტექსტზე არასდროს გაუშვათ eval().
ჩადეთ პრომპტში რეალური მონაცემები (ნამდვილი დავალება, ნამდვილი პოლიტიკა) და უთხარით მოდელს, პასუხი მხოლოდ მათზე დაყრდნობით გასცეს — და თქვას, როცა პასუხი იქ არაა. სწორედ ამას აავტომატებს RAG.
ჰგავს სამზარეულოს: შეფასებები არის რეცეპტთან შედარებით დაგემოვნება სერვისამდე; გარდრეილები კი სანიტარი ინსპექტორია, რომელიც ცუდ კერძს მაგიდამდე მისვლის საშუალებას არ აძლევს.
LLM-აპლიკაციას ორი არჩევანი აყალიბებს: რომელი მოდელი პასუხობს პრომპტს და რომელი SDK-ით აშენებთ. არცერთი არაა სამუდამო — კარგი დიზაინი მოდელების ერთი ინტერფეისის უკან გამოცვლის საშუალებას გაძლევთ — მაგრამ ლანდშაფტის ცოდნა გიცავთ იმისგან, რომ უბრალოდ ბოლო ბლოგპოსტის არჩევანი გაიმეოროთ.
დადებითი: ძლიერი მსჯელობა, კოდირება და ინსტრუმენტების გამოყენება; თითო საფეხური თითო საჭიროებაზე — Opus (ყველაზე ღრმა), Sonnet (დაბალანსებული), Haiku (სწრაფი/იაფი).
უარყოფითი: ზედა საფეხური ტოკენზე უფრო ძვირია, ვიდრე პატარა ღია მოდელები.
დადებითი: უზარმაზარი ეკოსისტემა, მომწიფებული ინსტრუმენტები, ფართო ნაცნობობა გუნდებში.
უარყოფითი: ერთი ვენდორი; შესაძლებლობებისა და ფასების საფეხურები იცვლება, ამიტომ ვერსიები დააფიქსირეთ.
დადებითი: ძალიან დიდი კონტექსტის ფანჯრები და მჭიდრო თავსებადობა, თუ უკვე Google Cloud-ზე ცხოვრობთ.
უარყოფითი: ინსტრუმენტები და ქცევა დანარჩენებისგან განსხვავდება — პორტირების დრო ბიუჯეტში ჩადეთ.
დადებითი: თავად უშვებთ — კონფიდენციალურობა, ტოკენზე ანგარიშის გარეშე, სრული კონტროლი; შესანიშნავია დიდი მოცულობისთვის.
უარყოფითი: GPU-ები, მასშტაბირება და ოპერაციები თქვენზეა; ხარისხით საუკეთესო დახურულ მოდელებს ჯერ კიდევ ჩამორჩება.
როგორ აირჩიოთ: პროტოტიპი ძლიერ ჰოსტირებულ მოდელზე გააკეთეთ (Sonnet / GPT / Gemini), შემდეგ კი დავალების მიხედვით უფრო იაფ ან ღია მოდელზე ჩამოდით მას შემდეგ, რაც შეფასებები დაამტკიცებს, რომ ხარისხი შენარჩუნებულია. მარტივი გამოძახებები პატარა მოდელებს მიმართეთ, რთული — დიდებს.
import { generateText } from "ai" import { anthropic } from "@ai-sdk/anthropic" const { text } = await generateText({ model: anthropic("claude-..."), prompt, }) // same code; swap provider import to change model
დაიწყეთ Vercel AI SDK-ით, რომელიც ძლიერ ჰოსტირებულ მოდელს ესაუბრება. LangGraph-ს მხოლოდ მაშინ მიმართეთ, როცა ორკესტრაცია ნამდვილად მრავალნაბიჯიანი ხდება, LlamaIndex-ს კი მაშინ, როცა რეალური პრობლემა თქვენს საკუთარ მონაცემებში მოძიებაა. პირველ ფუნქციონალს უმეტესად არცერთი მძიმე ფრეიმვორკი არ სჭირდება — SDK და კარგი პრომპტი შორს წაგიყვანთ.
ავაწყოთ ნაწილები ერთ რეალურ, პატარა ფუნქციონალად: შემოსული მხარდაჭერის ტიკეტების ავტომატური სორტირება. ამ დეკის ყოველი იდეა ზუსტად ერთხელ ჩნდება.
პრომპტი → სტრუქტურირებული გამოძახება → ვალიდაცია → ინსტრუმენტი. შეფასებები გვერდით დგას, როგორც ყოველი ცვლილების უსაფრთხოების ბადე.
{ category, urgency }-ს, ტიპიანს და დასაპარსად ვარგისს.assign() ინსტრუმენტი ტიკეტს რეალური მონაცემებით სწორ რიგში მიმართავს.urgency 1–5 დიაპაზონში ჩააქციეთ."მოექეცით მოდელს როგორც სწრაფ, შეცდომისკენ მიდრეკილ კოლეგას — მიეცით მკაფიო ინსტრუქციები და მერე შეამოწმეთ ნამუშევარი."
ხუთი სწრაფი კითხვა არადეტერმინიზმზე, პრომპტინგზე, სტრუქტურირებულ გამოსავალზე, სტრიმინგსა და შეფასებებზე — მყისიერი უკუკავშირი, ავტორიზაციის გარეშე.
ნავიგაცია ← → ღილაკებით ან სქროლით · უკან ბიბლიოთეკაში