ბოლო ორი წელია AI-ფიჩებს ვაყენებ პროდუქშენში ორ კოდბაზაში — ერთი .NET-ზე, მეორე TypeScript-ზე — და ამავდროულად ვასწავლი ინჟინრებს ამავე საქმეს. სადღაც მეთვრამეტე თვეზე ის, რასაც ყოველდღე ვაკეთებ, prompt engineering-ის მსგავსი აღარ იყო — სხვა რაღაცა გახდა.
ეს სხვებმაც შენიშნეს. „Context engineering” უკვე ერთ წელზე მეტია, ჩუმად ცვლის „prompt engineering”-ს AI-ინჟინერიის სერიოზულ დისკურსში, ხოლო 2026-ში ეს უკვე დარგის მეტა-თემაა. ეს ის პოსტია, რომელიც პირველ დღეს მინდოდა გადმოეცა ვინმეს. არა — ტუტორიალი, არამედ ფრეიმი.
თეზისი მარტივია. Prompt engineering ყოველთვის არასწორი სახელი იყო. მუშაობა არასოდეს ჭკვიანი სიტყვების შერჩევას ეხებოდა. ის იმის გადაწყვეტას ეხებოდა, რა დაინახავს მოდელი გაშვებისას — და რას არ დაინახავს. ეს სისტემური დიზაინის ამოცანაა. და მხოლოდ ეს უნარი მასშტაბდება, როცა დემოდან პროდუქტამდე გადახვალთ.
რატომ იყო „prompt engineering” არასწორი სახელი
პრომპტი ერთი ცვლადია ძალიან გრძელ გამოსახულებაში.
როცა რეალური პროდუქშენ-ფიჩი მოდელს მიმართავს, შესასვლელზე მიდის მომხმარებლის შეტყობინება — დიახ. მაგრამ ასევე სისტემური პრომპტი, ყველა ხელსაწყოს სქემა, დიალოგის ისტორიის ნაჭერი, ახლად ამოღებული დოკუმენტების ნაკრები, ძველი ხელების შეჯამებები, მომხმარებლის პროფილი, ამოცანის მიმდინარე მდგომარეობა, შესაძლოა ორი წამის წინ გაშვებული დამგეგმავის გამოსავალი, და შეზღუდვების ნაკრები, რომელიც იურისტებმა სამი თვის წინ markdown-ში ჩაწერეს. მომხმარებლის რეალური ფრაზა იმის დაახლოებით ხუთი პროცენტია, რასაც მოდელი კითხულობს.
დანარჩენი ოთხმოცდათხუთმეტი პროცენტი განსაზღვრავს, მუშაობს ფიჩი თუ არა.
ამის prompt engineering-ად დარქმევა ისეთივეა, როგორც SQL-ის „სტრიქონის ფორმატირებად” დარქმევა. ეს უბრალოდ პრობლემას სცდება. საინტერესო კითხვები „როგორ უკეთ ვთქვა?” კი არ არის. ის — „რა უნდა იყოს ამ ფანჯარაში? რა არ უნდა იყოს? საიდან მოდის? როდის ძველდება? რამდენი შემიძლია?”
ეს საინჟინრო კითხვებია. მათ ახლა აქვთ სახელი: context engineering.
რა არის კონტექსტი სინამდვილეში
გამოსადეგი ფრეიმი: კონტექსტი არ არის ერთი რამ. ეს მინიმუმ ხუთი განსხვავებული ფენაა, თითოეულს თავისი მტყუნების რეჟიმი აქვს, თუ შეცდომას დაუშვებთ.
| ფენა | რა არის ეს | რა იშლება, თუ შეცდი |
|---|---|---|
| სისტემა და როლი | მუდმივი ვინაობა, როლი და მოდელის შეზღუდვები | მოდელი „იშლება”, წნეხის ქვეშ წესებს უგულებელყოფს, მომხმარებელს თქვენი დაცვის რელსების მიღმა მიყვება |
| ხელსაწყოები | ფუნქციები, რომელთა გამოძახებაც მოდელს შეუძლია, მათი სქემები და აღწერები | არასწორი ხელსაწყო ეშვება, უსასრულო ციკლები, სქემაში ინიექციები, უსაფრთხოების ხვრელები |
| ამოღებული ცოდნა | მოთხოვნაზე ჩასმული დოკუმენტები, ნაწილები, ფაქტები (RAG) | მოძველებული პასუხები, თავდაჯერებული ჰალუცინაციები, ლატენტობა, ღირებულების ნახტომები |
| დიალოგის/აგენტის ისტორია | რა უკვე ითქვა, რა უკვე გაკეთდა, რა გადაწყდა | დაკარგული მდგომარეობა, განმეორებითი სამუშაო, წინააღმდეგობები, გასლაითინგი |
| ამოცანისა და მომხმარებლის მდგომარეობა | მიმდინარე მიზანი, მომხმარებლის მონაცემები, გარემო, რომელშიც მოდელი მოქმედებს | ზოგადი პასუხები, პერსონალიზაციის ნაკლებობა, აშკარა კონტექსტის გამოტოვება |
როცა პროდუქშენ-AI-ფიჩში რაღაც იშლება, ეს თითქმის არასოდეს ხდება პრომპტის ცუდი ფორმულირების გამო. ის იშლება იმიტომ, რომ ერთ-ერთი ამ ხუთი ფენიდან გაიჟონა, მოძველდა, აკლდა ან ძალიან დიდი იყო. ინჟინრები, რომლებიც ვერ ამბობენ, რომელი ფენა გატყდა, ისინი არიან, ვინც კიდევ თავს prompt engineers-ად უწოდებს.
კონტექსტ-ინჟინერიის ოთხი რთული ამოცანა
დისციპლინა ოთხ ამოცანას მოდის ბოლოს, რომელიც ნებისმიერ არატრივიალურ AI-ფიჩში ჩნდება. არცერთი მათგანი ლამაზი პრომპტით არ წყდება. ოთხივე — სისტემური ინჟინერიის ამოცანაა.
არჩევანი: რა შედის შიგნით?
კონტექსტის ფანჯარა სასრულია. ორას ათასი ტოკენის მქონე მოდელებზეც კი მთელი თქვენი კორპუსის ჩაყრა შეუძლებელია — არა იმიტომ, რომ ვერ მოეტევა, არამედ იმიტომ, რომ მოდელის ყურადღება ირელევანტურ მასალაზე იფანტება, თქვენი ანგარიში კი ვერტიკალურად მაღლა მიდის.
არჩევანი retrieval-ინჟინერიის ამოცანაა. BM25-ისა და მკვრივი ემბედინგების ჰიბრიდი, reranking, მოთხოვნის გადაწერა, სიახლის ბუსტები, დედუპლიკაცია, წყაროების წონები. ორას ათასი ტოკენის კორპუსიდან სწორი რვა ათასი ტოკენის არჩევა უფრო რთულია, ვიდრე SQL-ისთვის სწორი ინდექსის არჩევა, და აქ შეცდომები გაცილებით უფრო რთულია.
გუნდები, რომელთა AI-ფიჩები სტაბილურად მუშაობს, retrieval-ს დამოუკიდებელ ქვესისტემად ექცევიან, საკუთარი მეტრიკებით, evals-ით და მორიგეებით. დანარჩენებთან „რაღაც სახით” კეთდება, შემდეგ კი იკითხავენ, რატომ დეგრადირდება პასუხების ხარისხი ჩუმად.
შეკუმშვა: როგორ ჩავტიოთ მეტი დანაკარგების გარეშე
აგენტის გრძელი გაშვებები კონტექსტს უფრო სწრაფად აგროვებენ, ვიდრე ფანჯარას შეუძლია დაიტიოს. გულუბრყვილო პასუხია — შემოკლება. ზრდასრული პასუხია — შეჯამება, რეკურსიულად, სტრუქტურირებულ ჩექპოინტებზე.
ერთი შეხედვით მარტივად ჟღერს. არ არის მარტივი. შეჯამების ყოველი ნაბიჯი დანაკარგებიანია, და დანაკარგები გროვდება. გადაწყვეტილება „რა ღირს საჯამოში დატოვებად” სწორედ ის გადაწყვეტილებაა, რომელსაც მოდელი ცუდად იღებს ზედამხედველობის გარეშე. შეცდებით — და აგენტი ამოცანის შუაში ივიწყებს შეზღუდვას, რომელიც ხუთი წუთის წინ მიიღო.
პრაქტიკაში მუშაობს ფორმა: სტრუქტურირებული მდგომარეობა — ფაქტები, გადაწყვეტილებები, ღია კითხვები, მიმდინარე მიზანი — რომელსაც თავად აგენტი წერს და აახლებს, მაგრამ თქვენ მიერ კონტროლირებადი სქემით. თავისუფალი საჯამოები დეგრადირდება. სტრუქტურირებული მდგომარეობა გადარჩება.
მარშრუტიზაცია: რომელი კონტექსტი რომელ ნაბიჯს
მრავალნაბიჯიან აგენტებს ერთი და იგივე კონტექსტი არ სჭირდებათ ყოველ ნაბიჯზე. დაგეგმვის ნაბიჯს სჭირდება სრული მიზანი და ხელმისაწვდომი შესაძლებლობები; ხელსაწყოს გაშვების ნაბიჯს — მხოლოდ ის ნაჭერი, რომელიც ამ გამოძახებას ეხება; სინთეზის ნაბიჯს — დამგეგმავის კვალი და ხელსაწყოების გამოსავლები.
თუ ყოველ ნაბიჯზე ყველაფრის გაერთიანებას ანებებთ, ამისთვის ტოკენებში, ლატენტობასა და ხარისხში იხდით. მოდელები სიმახვილეს კარგავენ გრძელ, არადიფერენცირებულ ფანჯრებში. ისინი ფოკუსირებულებში მახვილდებიან.
კონტექსტის ნაბიჯებად მარშრუტიზაცია ბევრად უფრო სისტემურ დიზაინს ჰგავს, ვიდრე prompt design-ს. თქვენ წყვეტთ, რომელი ქვესისტემა ხედავს მდგომარეობის რომელ ჭრილს. ეს არქიტექტურული ამოცანაა.
ევიქცია: რა გადააგდო და როდის
დავიწყება ფიჩია. რთული არ არის დამახსოვრება — რთულია იმის გადაწყვეტა, რა არის უსაფრთხო დასავიწყებლად.
პრაქტიკაში მიდიხართ იარუსიან მეხსიერებამდე: ცხელი კონტექსტი ფანჯარაში ახლა, თბილი — შეჯამებული და მოთხოვნაზე ხელმისაწვდომი, ცივი — დაარქივებული, მხოლოდ პირდაპირი მითითებისას ამოდის. ხელსაწყოების გამოსავლები იგივე შაბლონს მიჰყვება — სრული გამოსავალი მომდევნო ხელზე, დაიჯესტი ხელის შემდეგ, სამი ხელის შემდეგ კი — „ხელსაწყო X გამოძახდა T მომენტში Y-ის ფორმის შედეგით”.
ეს ის ნაწილია, რომელსაც გუნდების უმეტესობა ხტება, სანამ აგენტის ერთი გაშვება ოცდაათ ცენტს არ დაუჯდება და ცხრამოცდაათ წამს არ წაართმევს.
მენტალური მოდელი: კონტექსტი როგორც აწყობის არტეფაქტი
აი, ცვლილება, რომელიც ცვლის იმას, თუ როგორ ფიქრობენ ამაზე უფროსი ინჟინრები.
შეწყვიტეთ პრომპტზე როგორც სტრიქონზე ფიქრი, რომელსაც წერთ. დაიწყეთ კონტექსტზე ფიქრი, როგორც აწყობის არტეფაქტზე, რომელსაც თქვენი რანტაიმი ყოველ ხელზე აწარმოებს მრავალი წყაროდან:
[მომხმარებლის შეტანა]
[დიალოგის შეჯამება] ──┐
[ამოღებული დოკუმენტები] │
[ხელსაწყოების სქემები] ├──► context assembler ──► მოდელი
[სისტემური წესები] │
[ამოცანის მდგომარეობა] │
[ხელსაწყოს ახალი გამოსავლები] ─┘Context assembler ის პროგრამული უზრუნველყოფაა, რომელიც თქვენ გეკუთვნით. მას აქვს შესასვლელები, ტრანსფორმაციები, ქეშირება, დაკვირვადობა და ტესტები. ეს თქვენი AI-ფიჩის ყველაზე მნიშვნელოვანი კომპონენტია, და გუნდების უმეტესობაში მისთვის ფორმალურად პასუხისმგებელი არავინ არის.
პრომპტი ბოლო ერთი პროცენტია მილსადენისა, რომელიც ოთხმოცდაცხრამეტი პროცენტი სისტემური ინჟინერიაა.
როცა ამას ასე დაინახავთ, დანარჩენი თავისთავად დადგება ადგილზე. თქვენ ვერსიონავთ ასემბლერს. წერთ მისთვის evals-ს. პროფილავთ ტოკენების გამოსავალს. წერთ ინტეგრაციულ ტესტებს, რომლებიც კონკრეტულ კონტექსტის ფორმებს იჭერენ. ინსტრუმენტავთ ყოველ ფენას, რომ როცა ხარისხი დეგრადირდება, ჩანდეს, რომელი ფენა შეიცვალა. არაფერი ეგზოტიკური — ჩვეულებრივი ინჟინერია, გამოყენებული იმ ფენაზე, რომელზეც prompt engineers-ი იდგა და ვერ ამჩნევდა.
ხუთი წესი, რომელიც პროდუქშენში ვისწავლე
დანომრილია, რადგან გამოვიმუშავე და არ გამოვიყვანე.
1. კონტექსტის ფანჯარას მოექეცით როგორც მეხსიერების იერარქიას. Hot — ის, რაც ფანჯარაშია ახლა. Warm — შეჯამებული და ხელმისაწვდომი. Cold — დაარქივებული. გადაიტანეთ იარუსებს შორის შეგნებულად — რელევანტურობის, ასაკის და ღირებულების მიხედვით — და არა შემთხვევით. კონტექსტის ბაგების უმეტესობა იარუსების მართვის ბაგებია გადაცმული.
2. ტოკენები გაზომეთ ისე, როგორც ლატენტობას ზომავთ. ტოკენები ახლა მზიდი წარმადობის მეტრიკაა. ყოველ ფიჩას უნდა ჰქონდეს ტოკენ-ბიუჯეტი ხელზე, სესიაზე, მომხმარებელ-დღეზე. ამის დაკვირვადობის გარეშე ღირებულება და ლატენტობა მონოტონურად მაღლა ცოცავს, და ამის შესახებ ფინანსებიდან ისმენთ, არა ინჟინერიიდან.
3. არასოდეს ენდოთ მოდელს საკუთარი მდგომარეობის მართვა. მოდელები თავდაჯერებულად გეტყვიან, რომ ახსოვთ ის, რაც არ ახსოვთ, და ჩუმად დაკარგავენ თხუთმეტი ხელის წინ მიცემულ შეზღუდვებს. მდგომარეობის მართვა თქვენი საქმეა. მოდელი ასრულებს; ის აღრიცხვას არ აწარმოებს.
4. გამოყავით დაგეგმვის კონტექსტი შესრულების კონტექსტისგან. დამგეგმავი ხედავს მიზანს და ხელსაწყოების ნაკრებს. შემსრულებელი ხედავს მიმდინარე ქვემიზანს და რელევანტურ ჭრილს. სინთეზატორი ხედავს კვალს და გამოსავლებს. ამ სამის ერთ ფანჯარაში არევა ხარისხის რეგრესიის ყველაზე გავრცელებული წყაროა, რომელიც აგენტურ სისტემებში მინახავს.
5. Evals — მილსადენზე, არა პრომპტზე. თუ თქვენი ევალუაციური აღკაზმვა მხოლოდ პრომპტის ფორმულირებებს A/B-ტესტავს, ბოლო ერთ პროცენტს ოპტიმიზავთ. ააწყვეთ evals, რომელიც ცვლის ამოღების recall-ს, შეჯამების სიზუსტეს, ხელსაწყოს გამოსავლის ფორმას და ისტორიის სიღრმეს. ხარისხის რეალური დისპერსია სწორედ აქ ცხოვრობს.
სად ჯერ კიდევ აქვს მნიშვნელობა prompt engineering-ს
გულწრფელი ნიუანსი, რადგან საწინააღმდეგო ფრეიმი ფრეიმია, არა მთელი სიმართლე.
პრომპტის დონის ფორმულირება ჯერ კიდევ დომინირებს შემთხვევებში:
- ერთხელის კლასიფიკაცია და ექსტრაქცია. მოკლე, ხელსაწყოების გარეშე, ისტორიის გარეშე, ძიების გარეშე. ფორმულირება ცვლადია. ამ შემთხვევას მოექეცით როგორც კერძო შემთხვევას, რომელიც ის არის.
- სტრუქტურირებული გამოსავალი მკაცრი სქემებით. Function-call მარშრუტიზაცია, JSON-mode coercion, სქემის გატარება. აქ სიტყვები ამოძრავებენ ნემს ისე, როგორც კონტექსტი ვერ ამოძრავებს.
- ტონი, პერსონა და უარის ქცევა. ტონი ძირითადად პრომპტის საქმეა. უარები — პრომპტ+სისტემის საქმე. პერსონა თითქმის სრულად პრომპტის ფორმაა.
მაგრამ ნებისმიერი აგენტური, ნებისმიერი ძიება-დაყრდნობილი, ნებისმიერი მრავალნაბიჯიანი, ნებისმიერი ხელებზე მდგომარეობის გადამცემი — კონტექსტ-ინჟინერია იმარჯვებს. და 2026-ში ეს იმის უმეტეს ნაწილს ფარავს, თუ რას ჰგავს რეალურად პროდუქშენ-AI.
რას ნიშნავს ეს თქვენი კარიერისთვის 2026-ში
თუ თქვენ ხართ მიდლ-ინჟინერი, რომელიც AI-ფიჩებს აშენებს და გინდათ იცოდეთ, რაში ჩადოთ შემდეგ — აი მოკლე ვერსია.
უფროსი AI-ინჟინრის სამუშაოს აღწერა 2026-ში „prompt engineer” კი არ არის. ის „context engineer”-ია. უნარები, რომლებიც გროვდება: retrieval დიზაინი, ევალუაციური აღკაზმვები, ტოკენ-ეკონომიკის დაკვირვადობა, აგენტური ორკესტრაცია, ხელსაწყოს გამოძახებებისთვის სქემის დიზაინი, შეჯამების სტრატეგია და დისციპლინა, კონტექსტის ფანჯრის კონტროლირებად გარემოდ მოპყრობისა, და არა სურვილების სიად.
უნარები, რომლებიც ჩუმად კარგავენ ფასს: ჭკვიანი პრომპტ-შელოცვები, prompt-შაბლონების ბიბლიოთეკები პროდუქტებად, „prompt patterns” ფრეიმვორკები და ვარაუდი, რომ უკეთესი ფორმულირება გადაარჩენს ცუდად ააწყობილ მილსადენს. არცერთი ამათგანი არ არის უსარგებლო. უბრალოდ ყველა ისინი გაცილებით ნაკლები გახდა, ვიდრე ორი წლის წინ იყო.
80/20, თუ მეტს არაფერს წაიკითხავთ: აიღეთ ერთი პროდუქშენ-AI-ფიჩი, რომელსაც აწარმოებთ. დახაზეთ მისი კონტექსტური მილსადენი დაფაზე ბოლომდე — ყოველი წყარო, ყოველი ტრანსფორმაცია, ყოველი იარუსი. ინსტრუმენტავთ ყოველი ფენის ტოკენ-ღირებულებას. შემდეგ ააწყვეთ ხუთ-შემთხვევიანი eval-კომპლექტი, რომელიც ერთ ფენას ცვლის ერთდროულად. ერთ კვირაში აღმოაჩენთ, რომ ის, რასაც პრომპტის პრობლემად მიიჩნევდით, retrieval-ის პრობლემა იყო, ან მდგომარეობის მართვის, ან მარშრუტიზაციის. ეს აღმოჩენაა მთელი უნარი.
უფრო ღრმა აზრი
გადასვლა prompt engineering-დან context engineering-ზე იგივე გადასვლაა, რომელიც მოხდა, როცა „ვებ-პროგრამირება” გახდა „სისტემური დიზაინი”, და „SQL-ის წერა” გახდა „დატა-ინჟინერია”. საინტერესო სამუშაო ზედაპირიდან — სიტყვებიდან, მოთხოვნებიდან, სტრიქონებიდან — გადავიდა ქვემოთ მდებარე მილსადენში.
ამ დისციპლინის design-time კომპანიონია spec-driven development — როგორ აწარმოებენ გუნდები სინამდვილეში იმ შესასვლელებს, რომლებიც ამ კონტექსტურ მილსადენებს ამოძრავებენ. ეს მომდევნო პოსტია.
თუ უფრო ღრმად გინდათ, ქვემოთ მოცემული კურსები მოიცავს დისციპლინის იმ ნაწილებს, რომლებსაც ყველაზე ხშირად ვასწავლი: Prompt Engineering & AI Workflow Automation პრომპტ-დონის ფუნდამენტისთვის, Building LLM-Powered Apps: RAG & Agents retrieval-ისა და მრავალნაბიჯიანი ორკესტრაციისთვის, Building with Claude API: Production AI Apps რანტაიმ-მხარისთვის, და Building Agents with the Claude Agent SDK — აგენტის სრული ზედაპირი, სადაც ამ სტატიის ყველა პრობლემა ერთდროულად იჩენს თავს.
