პროდაქშენ AI-ფიჩა, რომელსაც ვფლობ, გუშინ მუშაობდა. დღეს იშლება ყოველ მეოთხე გამოძახებაზე. კოდი არ შესწორებულა. პრომპტი არ შესხებიათ. მოდელი არ გადართულა. Retrieval-ინდექსი არ აშენებულა თავიდან. სისტემაში, დიფფის ნებისმიერი წაკითხვის მიხედვით, არაფერი არ შეცვლილა. და მაინც, პასუხების მეოთხედი არასწორია — წყნარად დაჯერებულად არასწორი, ისე, რომ ვერც ერთი მომხმარებელი ვერ შეატყობინებს ბაგზე. ისინი უბრალოდ შენიშნავენ, რომ პროდუქტი უფრო სულელია, ვიდრე კვირის წინ იყო, და წავლენ.
ასე გამოიყურება ცხოვრება evals-ის გარეშე. და მიზეზი, რის გამოც გუნდების უმეტესობას, რომელიც 2026-ში AI-ს რგავს, ჯერ კიდევ არ აქვს evals, არის ის, რომ დისციპლინა უფრო რთულია, ვიდრე ჟღერს, უფრო ძვირი, ვიდრე გამოიყურება, და არ აძლევს დამაკმაყოფილებელ მწვანე ნიშანს. ეს ასევე ერთადერთი საინჟინრო პრაქტიკაა, რომელიც განასხვავებს გუნდებს, რომლებიც AI-პროდუქტებს რგავენ, გუნდებისგან, რომლებიც AI-დემოებს რგავენ.
ეს არის ტრილოგიის მესამე საყრდენი. Context engineering — ეს ის, რასაც რანტაიმი მოდელის გამოძახების მომენტში აყრის თავს. Spec-driven development — ეს ის, რასაც გუნდი წერს და საიდანაც რანტაიმი მერე იყრის თავს. Evals — ეს ის, თუ როგორ იცით, რომ რომელიმე მუშაობს. მესამე საყრდენის გარეშე პირველი ორი იკეცება — სპეციფიკაცია ხდება რწმენა, კონტექსტი — თეატრი, ხოლო თქვენი „AI-ფიჩა” — საგანი, რომელიც სამჯერ იმუშავა დემოზე.
თეზისი უფრო მკვეთრია, ვიდრე ხალხს მოსახერხებელია. თუ AI-ფიჩებს რგავთ evals-ის გარეშე, თქვენ პროდუქტი არ გაქვთ. გაქვთ დემო მომხმარებლებით.
რატომ არ მუშაობს ტრადიციული ტესტინგი
ყოველი ინჟინერი, რომელიც ამას კითხულობს, ოცდაათი წლის ტესტირების ინტუიცია ერთ მზიდ წანამძღვარზე ააშენა: ტესტირებადი სისტემა დეტერმინირებულია. ერთსა და იმავე შესასვლელზე ის იძლევა ერთსა და იმავე გამოსავალს. იუნიტ-ტესტი არის (input, expected-output) წყვილი, რომელიც კომიტს მიამაგრებ და სამუდამოდ ატარებ.
ეს წანამძღვარი ახლა მცდარია თქვენი კოდბაზის მნიშვნელოვანი ნაწილისთვის.
მოდელის გამოძახება არ არის ფუნქცია. ეს არის ალბათობათა განაწილება გამოსავლებზე, რომლიდანაც ამოღება ხდება. ორი იდენტური გამოძახება იძლევა სხვადასხვა სტრიქონს, ორივე პოტენციურად ვალიდურს. გამოძახება, რომელმაც სწორი პასუხი მართში გასცა, აპრილში შეიძლება მისცეს სხვა სწორი პასუხი — ან არასწორი, — რადგან Anthropic-მა, OpenAI-მ, თქვენმა retrieval-ინდექსმა, თქვენმა სისტემურმა პრომპტმა, ხელსაწყოების აღწერებმა, მოდელის ვერსიამ, თქვენმა max_tokens-მა ან ტემპერატურამ თმის ცალით გადაიწია. მთელი ტესტ-პირამიდის მოდელი — იუნიტ, ინტეგრაცია, e2e, ყველაფერი მწვანე, ვრგავთ — დგას წანამძღვარზე, რომელიც ახლა მხოლოდ ნაწილობრივ ვალიდურია. იუნიტ-ტესტების შრე პირამიდის ფსკერზე ჯერ კიდევ მუშაობს ყველაფრისთვის მოდელის საზღვრის ქვემოთ. ზემოთ პირამიდა გადატრიალდება და უცნაურად იქცევა.
ცდუნებაა გადარევა. „დავაყენებთ ტემპერატურას ნულზე და დავწერთ ასერტებს”. ეს ყიდულობს დაახლოებით სამი კვირის ცრუ თავდაჯერებულობას. temperature=0 არ არის დეტერმინიზმი, ეს არის დაბალი დისპერსია. Tool-გამოძახებების რიგი მაინც ცურავს. Retrieval-მა შეიძლება დააბრუნოს სხვადასხვა chunks ერთსა და იმავე ქვერიზე, რადგან ინდექსში გამოჩნდა ახალი დოკუმენტი. API-ენდპოინტს უკან მდგარი მოდელი შეიძლება განახლდეს გაფრთხილების გარეშე. დეტერმინიზმის ილუზია — ეს ის, რაც ბაგს, როცა ის მოდის, არ აქცევს მოსაკვლევად.
Evals — ეს არის დისციპლინა არადეტერმინირებული სისტემის განზრახ ტესტირებისა სწორი ხელსაწყოებით. ეს არ არის იუნიტ-ტესტები ზედმეტი ნაბიჯებით. ეს არის სხვა ფორმა.
რა არის eval სინამდვილეში
Eval — ეს არის (input, behavior assertion, scoring rubric) სამეული, რომელიც ატარებს მთელ სისტემას — მოდელის გამოძახებას, ხელსაწყოებს, retrieval-ს, ისტორიას, ყველაფერს, — და აფასებს გამოსავალს რუბრიკის წინააღმდეგ, რომელიც ითმენს სისტემის ბუნებრივ დისპერსიას, მაგრამ მაინც იჭერს რეალურ რეგრესიებს.
მომწიფებულ კოდბაზებში გხვდება ოთხი ფორმა, რომლებიც დევანან სპექტრზე „იაფი და მტყუნებადი”-დან „ძვირი და გულწრფელი”-მდე.
| ფორმა | რას აკეთებს | როდის ვიყენებთ | ღირებულება | რას იჭერს |
|---|---|---|---|---|
| სტრიქონის / regex შესაბამისობა | ამოწმებს ლიტერალური პატერნების არსებობას ან არყოფნას გამოსავალში | მაღალი ფასიანი უარყოფები, ფიქსირებული ფორმის გამოსავლები, სტრუქტურული ველების არსებობა | უფასო | კატასტროფული გამოტოვებები, ფორმატის გაფუჭებები |
| სტრუქტურული ველის შემოწმება | აპარსავს გამოსავალს როგორც JSON/XML და ასერტავს კონკრეტულ ველებზე | Tool-გამოძახებების ფორმა, schema-bound გამოსავლები, კლასიფიკაციის ლეიბლები | იაფი | სქემის დრიფტი, ლეიბლის გადატრიალება, წყვეტილი პასუხები |
| LLM-as-judge | მეორე (ჩვეულებრივ უფრო ძლიერი, სხვა ვენდორის) მოდელი აფასებს გამოსავალს რუბრიკის წინააღმდეგ | ღია გამოსავლები, ტონი, სარგებლიანობა, მრავალკრიტერიული ხარისხი | საშუალო ($) | ხარისხის რეგრესიები, წვრილი დრიფტი, პერსონის გაფუჭებები |
| ადამიანის რევიუ | რეალური ადამიანი აფასებს შერჩევას | ეტალონის კალიბრაცია, მსაჯული მოდელის კალიბრაცია, ახალი მტყუნების რეჟიმები | ძვირი ($$$) | ყველაფერი დანარჩენი; იატაკი, რომლის წინააღმდეგ ვაკალიბრებთ დანარჩენ ფორმებს |
შეცდომაა, აირჩიო ერთი და ჩათვალო საკმარისად. სტრიქონის შესაბამისობები თითქმის უფასოა, მაგრამ თითქმის არაფერს ამბობს იმაზე, კარგია თუ არა გამოსავალი — მხოლოდ იმაზე, რომ ის არ არის კატასტროფულად გაფუჭებული. LLM-as-judge იჭერს ნიუანსებს, მაგრამ მემკვიდრეობით იღებს თავისი მოდელის მიკერძოებებსა და მტყუნების რეჟიმებს. ადამიანის რევიუ — ერთადერთი გულწრფელი პასუხია „ეს საერთოდ კარგია?” კითხვაზე, მაგრამ CI-მდე არ მასშტაბირდება. მომწიფებული eval-სიუტები ფენავენ ოთხივეს: იაფი შემოწმებები აყავებთ ყოველ გაშვებას, LLM-მსაჯული აშერჩევს პროცენტს, ადამიანი აკალიბრებს მსაჯულს გადადებული ოქროს ნაკრების წინააღმდეგ კვარტალური სიხშირით.
Evals-ის ოთხი შრე
ხაფანგი, რომელშიც ვუყურებ გუნდს გუნდის მერე, არის აზრი, რომ eval ერთი რამეა. ეს მინიმუმ ოთხია, და თითოეული შრე თავისებურად იშლება, თუ მას გამოტოვებ. ფრეიმი მიზანმიმართულად პარალელურია კონტექსტის ხუთი შრის — მკითხველებს, რომლებმაც ის ფრეიმი ინტერნალიზაცია გაუკეთეს, შეუძლიათ აქაც გამოიყენონ.
Capability evals. აკეთებს თუ არა თვით მოდელი საჭიროს საერთოდ, იზოლაციაში? ეს ის evals-ია, რომელსაც Anthropic-ი და OpenAI-ი ატარებენ, რათა გადაწყვიტონ, შეუძლია თუ არა ახალ მოდელს წინა შეცვალოს. თქვენ მათ არ წერთ. თქვენ მათ მოიხმართ — და ყურადღებას აქცევთ, როცა model card აქვეყნებს ქულებს, რომლებიც მატერიალურად გადაიწია თქვენი გამოყენების შემთხვევასთან ახლოს ბენჩმარკზე. Capability evals ნულოვანი სართულია. თუ მოდელს დავალება თავად არ შეუძლია, ვერავითარი context engineering ვერ გადაარჩენს.
Behavior evals. გათვალისწინებული თქვენი პრომპტი და თქვენი კონტექსტი, აწარმოებს თუ არა მოდელი იმ ფორმას, რომელიც გჭირდებათ? ეს ის შრეა, რომელზეც გუნდების უმეტესობა ჩერდება, და ის ყველაზე იაფია. Behavior evals იჭერს „JSON-ში სწორი ველებია”, „უარყოფა ირთვება, როცა უნდა”, „მოდელი ირჩევს ხელსაწყო A-ს და არა B-ს”. თუ მხოლოდ ერთ შრეს ატარებთ — ეს ატარეთ. მაგრამ behavior evals საკმარისი არ არის — ისინი ვერიფიცირებენ ფორმას, არა არსს.
System evals. იძლევა თუ არა მთელი პაიპლაინი — retrieval, დაგეგმვა, tool-გამოძახებები, ისტორია, შეჯამება, უარყოფა, ყველაფერი — სწორ end-to-end შედეგს რეალისტურ შესასვლელზე? System evals — სადაც რეალური ბაგების უმეტესობა ცხოვრობს. Retrieval-მა დააბრუნა არასწორი chunk. ისტორიის შემჯამებელმა ჩამოაგდო შეზღუდვა. დამგეგმავმა გამოიძახა სწორი ხელსაწყო არასწორი არგუმენტებით. ყოველი კომპონენტის behavior eval-მა გაიარა; end-to-end ქცევამ მიგრა. გუნდების უმეტესობას არასოდეს გაუტარებია system eval. ეს ჩანს.
Regression evals. როცა რაღაც იცვლება — სისტემური პრომპტის რედაქცია, ახალი ხელსაწყო, მოდელის ვერსიის ბამპი, retrieval-ინდექსის გადაშენება, Claude.md-ის ტვიკი — ადრე გასულ მაგალითებს რომელი იშლება ახლა? Regression evals — ეს ის შრეა, რომელიც იჭერს „გავუშვით პრომპტის ცვლილება სამშაბათს და წყნარად გავტეხეთ მომხმარებლის ფლოუების 12%”. Regression evals-ის გარეშე თქვენ არ იცით, რა გატეხეს თქვენმა ცვლილებებმა. გაიგებთ მომხმარებლებისგან. შემდეგ გაიგებთ, რომ ცვლილება, რომელსაც ადანაშაულებთ, არ არის ის, რომელმაც გატეხა, რადგან კვირაში სამი ცვლილება გავიდა. Regression evals — ერთადერთი ყველაზე მაღალი ბერკეტის შრე, რომელიც დასამატებელია, თუ ის არ გაქვთ.
პატერნი: გუნდების უმეტესობა აკეთებს ნაწილობრივ behavior evals-ს, არანაირ system evals-ს და ad-hoc regression-ს. გუნდები, რომლებიც სანდო AI-ფიჩებს რგავენ, ოთხივეს აკეთებენ, თითოეულის ფლობის გასაგები ისტორიით.
Eval-ინჟინერიის ოთხი რთული პრობლემა
განზრახ ვირეკავ context engineering-ის ფრეიმს: დისციპლინა ოთხ პრობლემამდე ვიწროვდება, რომლებიც ყოველ არატრივიალურ AI-ფიჩაზე ამოდის. არც ერთი არ წყდება მეტი eval-შემთხვევით. ოთხივე — სისტემურ-საინჟინრო.
ფარვა: როგორ იცით, რომ თქვენი eval-ნაკრები წარმოადგენს იმას, რასაც მომხმარებლები რეალურად აკეთებენ?
Eval-ნაკრები, რომელიც პირველ დღეს დაწერეთ, ეფუძნება შესასვლელებს, რომლებზეც წარმოიდგინეთ, რომ მომხმარებლები გამოაგზავნიდნენ. შესასვლელები, რომლებსაც ისინი რეალურად აგზავნიან, განსხვავდება გზებით, რომელიც ვერ წინასწარმეტყველეთ — სხვა სიგრძე, სხვა ენები, სხვა ზრდილობა, სხვა მცდელობები სისტემის გასატეხად, სხვა დომენები, რომლებზეც არ გიფიქრიათ. Eval-ნაკრები, რომელიც პროდაქშენ-ტრაფიკს არ ასახავს, დეკორაციაა.
გუნდები, რომლებიც ამას წყვეტენ, eval-ნაკრების კურირებას უყურებენ როგორც გრძელვადიან data-pipeline ამოცანას. გასუფთავებული პროდაქშენ-პრომპტები უწყვეტად აშერჩევა ნაკრებში. კიდურა შემთხვევები, რომლებიც ერთხელ გატყდა, იპინება. ნაკრები იზრდება; ძველი შემთხვევები იჭრება, როცა აღარ წარმოადგენენ; ფარვა იზომება რეალური ტრაფიკის განაწილების წინააღმდეგ. გუნდები, რომლებიც ასე არ აკეთებენ, წერენ ოცი შემთხვევას პირველ დღეს, რგავენ და გაკვირვებულები არიან, როცა სისტემა ოცდამეერთეზე ტყდება.
სტაბილურობა: როგორ გავარჩიოთ რეალური რეგრესია ხმაურისგან?
არადეტერმინირებული სისტემა იძლევა სხვადასხვა პასუხებს ყოველ გაშვებაზე. თქვენი eval-ქულა ცურავს კაპოტის ქვეშ ცვლილებების გარეშეც. ამ ფლუქტუაციის ნაწილი უაზრო დისპერსიაა; ნაწილი — წინა ფრონტი რეალური რეგრესიისა, რომელიც დასაჭერია. ამ ორ რამეს გარჩევა უფრო ძნელია, ვიდრე გამოიყურება.
პასუხი სტატისტიკურია, არა ალგორითმული. გაატარეთ ყოველი eval-შემთხვევა N-ჯერ (5–20, ღირებულების მიხედვით), დაჯამეთ და აიღეთ pass-rate (არა pass/fail) როგორც მეტრიკა. დააყენეთ ზღურბლები დისპერსიის გათვალისწინებით — გადასვლა 95%-დან 92%-ზე ერთ გაშვებაში ხმაურია; მდგრადი გადასვლა 95%-დან 85%-ზე სამ გაშვებაში რეგრესიაა. ეს უფრო ახლოა A/B-ტესტის დისციპლინასთან, ვიდრე იუნიტ-ტესტის დისციპლინასთან. ინჟინრები, რომლებსაც experiment design ადრე არ უკეთებიათ, ამ ნაწილს ყველაზე უხერხულად ხედავენ.
ღირებულება: როგორ გავატაროთ ათასი eval და არ გავკოტრდეთ?
ყოველი eval-გაშვება არის ერთი ან მეტი მოდელის გამოძახება. სერიოზული eval-სიუტი — ვთქვათ, სამასი შემთხვევა, ხუთი ნიმუში თითოეულზე, LLM-as-judge ზემოდან — ეს ათას ხუთასი მოდელის გამოძახებაა გაშვებაზე, პლუს ორ-ორი შემთხვევაზე (ტესტირებადი სისტემა და მსაჯული), სულ სამი ათასი გამოძახება. 2026-ის რეალისტურ ფასებში ეს არატრივიალური ხარჯია CI-ბილდზე. გაატარეთ ყოველ PR-ზე და კვარტალის ბოლომდე მიიღებთ კითხვას ფინანსებისგან.
მომწიფებული გუნდები ფენავენ სიუტს: პატარა smoke-ნაკრები ტარდება ყოველ PR-ზე, სრული სიუტი — ღამე main-ზე, ყველაზე დიდი LLM-მსაჯული ნიმუში — კვირაში ერთხელ. კრიტიკული გზები იღებენ მეტ ნიმუშებს; long-tail შემთხვევები — ნაკლებს. ღირებულება არის ბიუჯეტი, რომელსაც აშკარად მართავ, ისე როგორც CI-წუთებს. გუნდები, რომლებიც არ ფენავენ, ან არაფერს ატარებენ, ან უაზროდ წვავენ ფულს.
დრიფტი: რა ხდება, როცა თქვენი ოქროს პასუხები ძველდება?
პასუხი, რომელიც თებერვალში სწორი იყო, შეიძლება მაისში არასწორი იყოს, რადგან პროდუქტი შეიცვალა, მონაცემები შეიცვალა, პოლიტიკა შეიცვალა ან სამყარო შეიცვალა. „გასული წლის გადასახადის განაკვეთი” აღარ არის სწორი პასუხი. „X კომპანიის CEO” განახლდება გაფრთხილების გარეშე. თქვენი eval-ნაკრები ლპება, თუ მას არ უვლით. და სილპობა უხილავია, სანამ გასული eval სინამდვილეში არ ტესტავს არასწორ ქცევას.
დისციპლინა ორმაგია: სადაც შესაძლებელია — ოქროს პასუხები მიამაგრეთ თარიღსა და წყაროს, და გადახედეთ eval-ნაკრებს გრაფიკით. ეს უკანასკნელი მოსაწყენი ჟღერს; ის მართლა მოსაწყენია. ეს ასევე ერთადერთი გზაა ნაკრების გულწრფელად შესანახად. ჩათვალეთ eval-ნაკრების ვლა მუდმივ საინჟინრო საბიუჯეტო სტრიქონად, არა ერთჯერად ინვესტიციად.
ხუთი წესი, რომელიც პროდაქშენში გამოვიმუშავე
დანომრილია, რადგან გამოვიმუშავე, არ გამოვიყვანე.
1. რეალური პრომპტები, არასოდეს სინთეზირებული. ყველაზე ხშირი შეცდომა, რომელსაც ვხედავ — გუნდები ავსებენ eval-ნაკრებს პრომპტებით, რომელიც თვითონ დაწერეს, იმ ხმაში, რომელშიც წარმოიდგინეს, რომ მომხმარებლები საუბრობენ. რეალური მომხმარებლები ასე არ საუბრობენ. ისინი ბეჭდვისას შეცდომებს უშვებენ. აწებებენ markdown-ს. შემოაქვთ შეუსაბამო კონტექსტი. წინადადებებს შუა აზრზე წყვეტენ. Eval-ნაკრები, წარმოსახვითი შესასვლელებიდან აშენებული, წარმოსახვით სისტემაზე გვიყვება, არა თქვენს რეალურზე. ყოველთვის ჩათესეთ ნაკრები გასუფთავებული პროდაქშენ-ტრაფიკით. ყოველთვის.
2. LLM-as-judge-ს სხვა მოდელი ჭირდება. ცდუნებაა შეაფასო Claude-ის გამოსავალი Claude-ით. უფრო იაფია და პრომპტი ნაცნობია. ეს ასევე უკუ-კავშირია, რომელიც თქვენს სისტემას ეფერება. გამოიყენე სხვა მოდელი, იდეალურად სხვა ვენდორისგან, მსაჯულისთვის — ხოლო ყველაზე მაღალი ფსონის evals-ზე გამოიყენე უფრო ძლიერი მოდელი, ვიდრე შესაფასებელი. ერთი და იგივე ოჯახი, რომელიც თავის თავს აფასებს, ფორმას იჭერს, არა არსს. ჯვარედინ-ვენდორული შეფასება იჭერს ისეთ რამეებს, რომელშიც ოჯახი კოლექტიურად ცუდია.
3. ჩათვალე eval-დრიფტი ბაგად, არა ხმაურად. როცა ადრე გასული eval იწყებს ვარდნას კოდის ცვლილების გარეშე, ზარმაცი რეაქცია — გადააცადო, ნახო, რომ გადის, და გადახვიდე. ზრდასრული რეაქცია — გამოიძიო. რაღაც გადაიწია — API-ის უკან მდგარი მოდელი, თქვენი retrieval-ინდექსი, ზევით მდგარი დამოკიდებულება. „შემდეგ ჯერზე გავიდა” დახურული ტიკეტი არ არის. წყნარად დეგრადირებადი პროდაქშენ AI-ფიჩები თითქმის ყოველთვის ჯერ წყნარი eval-დრიფტისავით გამოიყურება; გუნდი, რომელიც დრიფტს გადევნებას ისწავლა, ინციდენტებს სამი კვირით ადრე იჭერს, ვიდრე გუნდი, რომელიც არა.
4. გაატარე regression evals პრომპტისა და კონტექსტის ცვლილებებზე, არა მხოლოდ მოდელის გადანაცვლებაზე. გუნდების უმეტესობას, რომელსაც რეგრესიული დისციპლინა საერთოდ აქვს, ის მხოლოდ მოდელის ვერსიის ცვლილებისას ატარებს. სისტემური პრომპტის ორ-სიტყვიანი რედაქცია შეიძლება დააგდოს ოცდაათი eval — და დააგდებს. ხელსაწყოთა ყუთში დამატებული ახალი ხელსაწყო შეიძლება გატეხოს tool-routing შესასვლელებზე, რომელსაც ახალ ხელსაწყოსთან არაფერი აქვს საერთო. ხელახლა ორგანიზებული AGENTS.md შეიძლება შეცვალოს ის, თუ როგორ ინტერპრეტირებს მოდელი ყოველ პრომპტს. ჩათვალე ყოველი ცვლილება კონტექსტურ პაიპლაინში რეგრესიის კანდიდატად და დაიცავი ის eval-სიუტით ისე, როგორც კოდს იცავ ტესტებით.
5. Evals ეკუთვნის CI-ს. თუ ისინი არ ბლოკავენ, ისინი დეკორაციაა. ღამის eval-ანგარიში, რომელსაც არავინ კითხულობს, არ არის eval-სიუტი. დაშბორდი წითელი კვადრატებით, რომელიც მაინც ირგვება, არ არის eval-სიუტი. evals-ის მთელი აზრი იმაშია, რომ ისინი ხელს უშლის რეგრესიების პროდაქშენში მოხვედრას — რაც ნიშნავს, რომ მათ უნდა ბლოკონ. დიახ, ეს რთულია. დიახ, დისპერსია ამას უფრო რთულს ხდის. დიახ, ღირებულების კითხვა რეალურია. გადაჭერი ეს პრობლემები იმის ნაცვლად, რომ გადაჭრა „კარიბჭის მოხსნის” პრობლემა. გუნდი, რომელიც არ აღებავს, eval-თეატრს აკეთებს, არა eval-ინჟინერიას.
სად იშლება ეს მაინც
რამეს გვყიდიდი, თუ აქ გავჩერდი. Evals აუცილებელია; ისინი არ არის საკმარისი; და არსებობს რეალური შემთხვევები, სადაც დისციპლინა ნათლად არ გამოიყენება.
- ნამდვილად ღია გამოსავლები. „დაწერე ლექსი დანაკარგზე”. რუბრიკა არ არსებობს. LLM-as-judge-ს შეუძლია ტონისა და შეზღუდვების დაცვის შეფასება, მაგრამ ვერ აფასებს კარგ ლექსს. ასეთი ზედაპირებისთვის evals იჭერს იატაკს (უსაფრთხოება, ფორმატი, სიგრძე), ხოლო ჭერი ადამიანებს ეკუთვნით. სხვაგვარად მოჩვენება — ეს evals-ია, რომელიც საშუალოს აფასებს და გამორჩეულს სჯის.
- მრავალ-ხოდიანი root-cause პრობლემები. შვიდ-ხოდიანი აგენტური გაშვება იშლება მეშვიდე ხოდზე. მიზეზი — მდგომარეობის შეცდომა მეორე ხოდზე. Eval ფიქსირებს ვარდნას მეშვიდეზე, მაგრამ დიფფი გასული და ვარდნადი ტრესის შორის ხუთი ხოდის სიღრმეშია დამარხული. გჭირდებათ trace-level evals — რომელიც აფასებს პაიპლაინს, არა მხოლოდ ფინალურ გამოსავალს — და გუნდების უმეტესობას ხელსაწყოები არ აქვს. გულწრფელი პასუხი 2026-ში — multi-turn evals ხელსაწყოები ჯერ კიდევ მზადდება; მოელოდეთ, რომ ველი იქ ჩადებს ინვესტიციებს შემდეგ.
- ღირებულება ყველაზე დიდ სიუტებზე. სერიოზული AI-პროდუქტის სერიოზული eval-სიუტი შეიძლება ღირდეს CI-გაშვებაზე უფრო ძვირი, ვიდრე დანარჩენი CI ერთად. ცბიერი ხრიკი, რომელიც ამას მოაშორებს, არ არსებობს. ღირებულებას მართავ შრეებით, ნიმუშებით და საბიუჯეტო დისციპლინით — ან ეთანხმები, რომ თქვენი eval-ფარვა შემოსაზღვრულია ხარჯით.
- Eval-ნაკრები როგორც პროდუქტი. თვით eval-ნაკრები ხდება საგანი, რომელსაც ფლობ, ვერსიონირებ, რევიუებ და უვლი. ეს კიდევ ერთი კოდბაზაა, თქვენი კოდბაზის შიგნით დამალული. გუნდები, რომლებიც ამას სერიოზულად არ უყურებენ, ბოლოს ხვდებიან საქაღალდეში დაძველებული ასერტებით, რომელსაც ყველა სიძულვილს გრძნობს გასატარებლად. გუნდები, რომლებიც eval-ნაკრებს first-class არტეფაქტად უყურებენ — ფლობდნენ, რევიუებდნენ, რეფაქტორებდნენ — დაგროვებად უკუგებას იღებენ.
გულწრფელი ჩარჩო: evals განუხილველია 2026-ში ნარგავი AI-პროდუქტებისთვის, და ისინი უფრო რთულია, ვიდრე ჟღერს. გუნდები, რომლებიც დისციპლინას ფლობენ, წინ უსწრებენ გუნდებს, რომლებიც არ ფლობენ, არა იმიტომ, რომ ინჟინრები უკეთესნი არიან, არამედ იმიტომ, რომ ისინი ნამდვილად იციან, რასაც რგავენ.
კარიერული კუთხე: eval-ინჟინერი ახალი როლია
კიბის სამი შრე, სამი სხვადასხვა ფსონი.
ჯუნიორები. AI-გუნდში სასარგებლო გახდომის ყველაზე სწრაფი გზა — შესთავაზე eval-ნაკრების ფლობა. არავის უნდა. სამუშაო უმადურია. ეს ასევე ის ადგილია, სადაც სისტემას ისწავლი, რეალურ მტყუნების რეჟიმებს აღმოაჩენ, და სადაც სენიორი ინჟინრები შეამჩნევენ შენს სამუშაოს, რადგან მათ ბაგებს ადრე იჭერ, ვიდრე მომხმარებლები. ინჟინერი, რომელიც პირველ წელს მოვიდა და რეალური ფიჩისთვის რეალური eval-სიუტი ააშენა, უფრო სასარგებლო სამუშაოს აკეთებს, ვიდრე ინჟინერი გვერდით, რომელმაც ორჯერ მეტი აგენტ-გენერირებული კოდი დარგო. ბერკეტი იკრიფება ისე, როგორც ტესტებთან, მხოლოდ უფრო ძლიერად, რადგან გამოტოვებული რეგრესიის ფასი უფრო მაღალია.
მიდ-ლეველები. კარიერული რისკი რეალურია. თუ ბოლო სამი წელი ხდებოდი უკეთესი AI-ფიჩების წერაში და eval-დისციპლინა გამოტოვე — ინჟინერი უარესი ხარ, ვიდრე გგონია. აღსადგენი ნაბიჯი — აიღე გუნდის ყველაზე ფლეიკი AI-ფიჩა და ფლობდე მის eval-სიუტს end-to-end კვარტალის განმავლობაში. სამი თვის eval-სამუშაოში პროდაქშენ AI-ზე უფრო მეტს ისწავლი, ვიდრე წლის ფიჩ-სამუშაოში. ასევე იქნები გუნდში ერთადერთი ადამიანი, რომელიც „ეს მუშაობს?”-ზე პასუხს გასცემს რაიმეთი ვაიბების გარდა — ხოლო ეს არის კითხვა, რომელიც ისმის ოთახებში, სადაც დაწინაურებები ხდება.
სენიორები და სტაფი. „აჩვენე შენი eval-სიუტი” — ეს არის ახალი „აჩვენე შენი test coverage”. ეს არის კითხვა, რომელსაც ახლა ვსვამ ყოველ AI-საინჟინრო ინტერვიუზე, და პასუხის ხარისხი კანდიდატზე უფრო მეტს მეუბნება, ვიდრე ნებისმიერი სხვა სიგნალი. თქვენს დონეზე სამუშაო არ არის evals-ის წერა — დისციპლინის ფლობაა. დააწესე ბარი იმისთვის, რა იბლოკება. ააშენე ჯვარედინ-ფუნქციური კუნთი human review-ის მარყუჟში დასატოვებლად. დაარწმუნე ფინანსები eval-ხარჯის დასაფინანსებლად. მოლაპარაკდი პროდაქტთან evals-ის pass-rate-ით აღებაზე, არა გაშვების თარიღით. ეს არის პოლიტიკური და არქიტექტურული ამოცანები, ტესტირების ამოცანებად ჩაცმული, და ეს არის ის სამუშაო, რომელშიც სენიორებს უხდიან.
ბაზარს არ მოუხდენია წინსვლა. ინჟინრების რიცხვი, რომელთაც აგენტური სისტემისთვის სერიოზული eval-სიუტის აშენება შეუძლიათ, საკმარისად მცირეა, რომ hiring-მენეჯერები, რომლებთანაც ვსაუბრობ, ამას ერთციფრიანი პროცენტის უნარად აღწერენ. პრემია იწერებს, რაც დისციპლინა გახდება სტანდარტული პრაქტიკა, იმავე გზით, რომლითაც იუნიტ-ტესტირება 2005-დან 2015-მდე იქცა. ფანჯარა, სადაც ეს უნარი იშვიათია, არის დაახლოებით ახლა — თვრამეტი თვე, ორი წელი ჭერი.
უფრო ღრმა აზრი
სპეციფიკაცია — ეს ჭეშმარიტებაა. კონტექსტი — ეს აწყობაა. Evals — ეს დასტურია.
ეს არის სამი სხვადასხვა არტეფაქტი, სამი სხვადასხვა დისციპლინა, სამი სხვადასხვა კუნთის ჯგუფი. 2026-ის მომწიფებული AI-ინჟინერია სამივეს აკეთებს. გუნდები, რომლებთანაც ვმუშაობ და რომელიც მხოლოდ ერთს აკეთებენ, დემოებს რგავენ. გუნდები, რომლებიც ორს აკეთებენ, რგავენ პროდუქტებს, რომლებიც წყნარად დეგრადირდებიან. გუნდები, რომლებიც სამივეს აკეთებენ, რგავენ პროდუქტებს, რომლებიც განაგრძობენ მუშაობას — რაც გამოდის ერთადერთი ფიჩა, რომელიც ინჟინერიის გარეთ ვინმეს შეუძლია გაარჩიოს.
ჩარჩო, რომელიც ყველაზე დიდხანს ვინტერნალიზე, ასეთია: არადეტერმინირებულ სისტემაში ტესტ-სიუტი არის ის, რაც სისტემას რეალურს ხდის. Evals-ის გარეშე თქვენი AI-ფიჩა არის სამი დემოს საშუალო და თქვენი იმედი. Evals-ით ეს არის სისტემა, რომელსაც რეალურად ხვდები. სხვაობა არის სხვაობა ინჟინერსა და ექსკურსიამძღოლს შორის.
თუ უფრო ღრმად გინდათ, ქვემოთ მოცემული კურსები მოიცავს დისციპლინის იმ ნაწილებს, რომლებსაც ყველაზე ხშირად ვასწავლი: Building LLM-Powered Apps: RAG & Agents — system-evals-ის დიზაინი retrieval-სა და აგენტურ პაიპლაინებზე, Building with Claude API: Production AI Apps with the Anthropic SDK — პროდაქშენ-რანტაიმის მხარე, სადაც evals CI-ში ცხოვრობს, Building Agents with the Claude Agent SDK — multi-turn აგენტური evals-ის ხელსაწყოები, და Claude Code Mastery: Agentic Coding for Engineers — ყოველდღიური workflow eval-სიუტისადმი როგორც first-class არტეფაქტისადმი მოპყრობისა სპეციფიკაციასა და კონტექსტურ პაიპლაინთან ერთად.
