მწვანე და უაზრო: რას მასწავლა ერთი პატარა აპლიკაციის ვერიფიკაციამ, როდესაც კოდის უმეტესი ნაწილი AI აგენტმა დაწერა.
Sanity DEV Challenge გასულ კვირას დასრულდა, და The Cellar-მა Path Two-ში გაიმარჯვა. ჟიური ბილდის აღწერას უწოდებს „კვლევას იმაზე, როგორ გავხადოთ ვერიფიკაცია ყალბად გასაკეთებლად რთული“, რაც საკმაოდ დიდსულოვანი წაკითხვაა იმისა, რაც ძირითადად იმის აღმოჩენა იყო, რომ ჩემი ვერიფიკაცია გატეხილი იყო.
ჩემი განაცხადი იმაზე მოგვითხრობს, რა ავაშენე. ეს კი არის იმ ნაწილზე, რომელზეც მუდმივად ვფიქრობ: რამდენად ხშირად იყო ჩემი შემოწმებები არასწორი.
ორი კვირა ვაშენებდი ღვინის სარდაფის აპლიკაციას, რომლის წაკითხვაც ნებისმიერ თარიღზე შეიძლება მისი ისტორიის ნებისმიერ მომენტში. ერთი დეველოპერი, ერთი აგენტი, დასრულებისას დაახლოებით 530 ტესტი. პროექტში ოთხი რეალური ბაგიდან სამი უხილავი იყო ყველა იმ შემოწმებისთვის, რომელიც მათ შემცველ ფუნქციონალზე იყო გათვლილი.
ეს უხერხული იყო, ამიტომ მოვიძიე. რაც აღმოვაჩინე, უარესი იყო, ვიდრე დაკარგული ტესტები: შემოწმებები, რომლებიც მწვანე ან წითელი იყო და ორივე შემთხვევაში არაფერს ნიშნავდა. ამისთვის ოთხი განსხვავებული გზა აღმოჩნდა, და ყველა მათგანს შევხვდი პროექტში, სადაც განსაკუთრებით ფრთხილად ვიყავი.
ლაბორატორიულ მეცნიერებს ამისთვის დიდი ხანია აქვთ ტერმინოლოგია. ექსპერიმენტს სჭირდება დადებითი კონტროლი, მტკიცებულება იმისა, რომ მეთოდს შეუძლია ეფექტის აღმოჩენა, როცა ის არსებობს, და უარყოფითი კონტროლი, მტკიცებულება იმისა, რომ ის დუმს, როცა არაფერია. ქვემოთ მოყვანილი ოთხივე ტყუილი ან არარსებული კონტროლია, ან კონტროლი, რომელიც არასწორ რამეს ამოწმებს.
პირველი: ტესტი, რომელიც ვერ ჩაიშლება
დადებითი კონტროლის გარეშე.
აპლიკაცია ღვინის დალევის ფანჯარას ათარიღებული მტკიცებებიდან ადგენს. მტკიცებებს შეიძლება შესთავაზოს აგენტმა, ხოლო მიღება ადამიანმა უნდა მოახდინოს, და შემოთავაზებული მტკიცება არაფერს უნდა ცვლიდეს, სანამ ვინმე არ მიიღებს.
ეს არის მთელი მიმოხილვის სამუშაო ნაკადის მთავარი წესი, ამიტომ მასზე ტესტიც დაიწერა. ავაშენე სარდაფი, შევიტანე შემოთავაზებული მტკიცება, და დავადასტურე, რომ ყველა 542 ბოთლის მდგომარეობა ბაიტ-ბაიტ იდენტურია. მწვანე.
ის ზომავდა მოწყობილობას და არა წესს. გადაწყვეტა ჯერ ყველაზე მაღალ ავტორიტეტის დონეს ირჩევს, შემდეგ კი ამ დონის ფარგლებში ყველაზე ახალ მტკიცებას:
| მტკიცება | დონე | თარიღი | იმარჯვებს? |
|---|---|---|---|
| მოქმედი მტკიცება | პირადი | 2024 | დიახ |
| ტესტირებადი მტკიცება | პირადი | 2019 | არა, წაგებს სიახლით |
ორივე მტკიცება ერთი დონისაა, ამიტომ ტესტირებადი მტკიცება სიახლით წაგებს, და ის წააგებს მიუხედავად იმისა, შემოთავაზებულია თუ მიღებული. წყაროდან მთლიანად წაშალეთ მიმოხილვის მდგომარეობის ფილტრი და ტესტი მაინც გაივლის.
ამას იჭერდა დამხმარე მტკიცება, დაწერილი სხვა მიზეზით: მიღებამ მინიმუმ ერთი მდგომარეობა უნდა შეცვალოს. ეს ჩაიშალა, და სწორედ ამით გავიგე, რომ პირველი ტესტი ფუჭი იყო.
წესი აქედან პირდაპირ გამომდინარეობს. ყველა ტესტს, რომელიც ამტკიცებს, რომ X-ს არანაირი ეფექტი არ აქვს, სჭირდება დაწყვილებული მტკიცება, რომელიც აჩვენებს, რომ ეფექტი არსებობს, როცა X ჩართულია. წყვილის გარეშე თქვენ არ გაქვთ გამოცდილი, რომ X ინერტულია. თქვენ გაქვთ გამოცდილი, რომ თქვენი მოწყობილობა ინერტული იყო.
დანარჩენი ტესტების აუდიტმა ამავე სახის კიდევ ორი აღმოაჩინა. ერთი ამოწმებდა, რომ პერიოდში გახსნილი ბოთლი არ ითვლება გაცდენილ შესაძლებლობად, მაგრამ ეს ბოთლი ორი განსხვავებული მექანიზმით გამოირიცხებოდა, ამიტომ ტესტირებადი პუნქტი შეიძლებოდა წაშლილიყო ისე, რომ არაფერი წითლდებოდა.
ვიფიქრე, რომ ეს პუნქტი ვერ გამოიყოფოდა, და აგენტს ვუთხარი, სუსტი მტკიცებისთვის დაბრუნებულიყო. მან ნაცვლად ექსპერიმენტი ჩაატარა და მოწყობილობა იპოვა, როცა გააცნობიერა, რომ ამ სისტემაში „ახლა“ პარამეტრია და არა საათი. 2024 წლის ივნისის მდგომარეობით, რა გამომრჩა იმ წელს? ეს ჩვეულებრივი კითხვაა დროის მანქანისთვის, და ამან შესაძლებელი გახადა მოწყობილობის აგება. გამოსწორება ინსტრუქციაზე უკეთესი აღმოჩნდა.
სამივე გასწორება მუტაციით დადასტურდა: წაშალეთ პუნქტი, რომელსაც ტესტი ფარავს, და ნახეთ, როგორ ჩაიშლება ის საბოლოოდ. თავდაპირველი მოწყობილობა ტესტების ნაკრებში დარჩა, გადარქმეული იმის მიხედვით, რას სინამდვილეში ამოწმებს, რადგან შეცდომის ჩანაწერი უფრო სასარგებლოა, ვიდრე ჩუმი წაშლა.
მეორე: შემოწმება, რომელიც ყოველთვის ჩავარდება
უარყოფითი კონტროლის გარეშე.
ერთი კვირის შემდეგ, საჯარო სტატიკური ნაკრების აგებისას, დავამატე grep, რომელიც აგებულ გამოსავალში ეძებდა გაჟონილ API საიდუმლო გასაღებებს. გაშვებას ხუთი წამი სჭირდებოდა, ხოლო აღმოჩენილი შეცდომა აღდგენადი არ იყო, ამიტომ ეს აშკარა მოგება მეჩვენა.
ის ყოველ სუფთა აგებაზე ირთვებოდა. შაბლონი იყო sk[A-Za-z0-9]{20,}, და ის ემთხვეოდა skipCrossDatasetReferenceValidation-ს, კანონიერ ექსპორტის სახელს @sanity/client-ის შიგნით.
ეს პირველი ტყუილის სარკისებური ანარეკლია, და პრაქტიკაში უარესია. ტესტი, რომელიც არასდროს ჩავარდება, უხილავია: არავინ ამჩნევს, რომ არაფერს არ აკეთებს. შემოწმება, რომელიც ყოველთვის ჩავარდება, მაშინვე მაინც ამჩნევენ, და შემდეგ მას ყოველ ჯერზე უგულებელყოფენ ის ადამიანი, რომელიც იცის, რომ ეს ცრუ დადებითია. ერთი კვირის შემდეგ ნამდვილი ჩავარდნა, რისთვისაც ის არსებობს, დანარჩენებთან ერთად გადაცურდებოდა.
შემოწმება, რომელიც ყოველთვის ჩავარდება, იმდენად ცოტას ადასტურებს, რამდენსაც ის, რომელიც არასდროს ჩავარდება. ის უბრალოდ უფრო გულმოდგინედ გამოიყურება ამის გაკეთებისას.
გამოსწორება პატარა იყო. ზღვარი ოცი სიმბოლოდან ორმოცამდე გავზარდე, რაც ნამდვილი გასაღებები ადვილად გადალახავს, ექსპორტის სახელი კი — არა. შემდეგ სკანირება CI-ში გადავიტანე, სადაც ის ყოველ push-ზე მუშაობს და არა მაშინ, როცა ვინმეს გაახსენდება. შემოწმება, რომელიც ყოველთვის ჩავარდება, უსარგებლოა, და შემოწმება, რომელსაც არავინ უშვებს, იგივე ღირებულებისაა.
კონტროლის ტერმინებში, თავდაპირველ grep-ს უარყოფითი კონტროლი არ ჰქონდა: არ არსებობდა მტკიცებულება, რომ ის დუმს ცნობილად სუფთა აგებაზე. ერთი გაშვება სუფთა აგებაზე საკმარისი იყო, რომ გამოვლენილიყო, და ასე იქნა ნაპოვნი: გაშვებით და არა გაგზავნით. მეორე ნაწილი, დამტკიცება იმისა, რომ გამკაცრებული შაბლონი კვლავ ირთვება ჩაშენებულ ყალბ საიდუმლო გასაღებზე, არის ტესტი, რომელსაც შემდეგ დავამატებდი.
მესამე: სწორი ტესტი არასწორი კონტრაქტისთვის
ორივე კონტროლი არსებობს, მაგრამ იზომება არასწორი რამ.
ეს ყველაზე რთულად შესამჩნევია, რადგან ტესტში სტრუქტურულად არაფერია არასწორი.
აპლიკაციას აქვს თარიღის კონტროლი 1996-დან 2042 წლამდე. თარიღის შეყვანა თვისა და დღისთვის მუშაობდა, მაგრამ როგორც კი წლის აკრეფას დაიწყებდით, ველი უკან, 1996 წლის 1 იანვარზე ბრუნდებოდა. დაამთავრებდით მხოლოდ არჩევანის ფანჯრით.
მიზეზი ბრაუზერის ნამდვილად გასაოცარი ქცევაა. ნატიური თარიღის შეყვანა არასდროს აცნობებს ნაწილობრივ ტექსტს. ის აცნობებს სრულ, კორექტულ თარიღს, წელი კი ოთხ ციფრამდე ნულებით არის შევსებული. 2023-ის აკრეფა უკვე თვისა და დღის შემცველ ველში ასე გამოიყურება:
0002-12-31 -> შემოიფარგლა 1996-ის ქვედა ზღვრით
0020-12-31 -> შემოიფარგლა 1996-ის ქვედა ზღვრით
0202-12-31 -> შემოიფარგლა 1996-ის ქვედა ზღვრით
2023-12-31 -> მიღებულია, მაგრამ ველი სამი კლავიშის დაჭერის წინ გადაიწერა
ყოველი შუალედური მნიშვნელობა რეალური, კორექტული თარიღია. ყოველი მათგანი დიაპაზონს გარეთაა. ყველა შემოიფარგლა, და კონტროლირებადმა შეყვანამ ქვედა ზღვარი ჩაწერა რედაქტირების თავზე.
ამას ტესტი ფარავდა. ის ამტკიცებდა, რომ parseDateInput('1901-01-01') აბრუნებს 1996 წლის ქვედა ზღვარს. ის გადიოდა, და ჩავარდებოდა, თუ შემოფარგვლა გატყდებოდა. დადებითი კონტროლი, უარყოფითი კონტროლი, არსებითი მტკიცება, ყველა იყო.
კონტრაქტი, რომელსაც ის კოდირებდა, არასწორი იყო. დიაპაზონს გარეთა თარიღის შემოფარგვლა სწორია, როცა მომხმარებელმა შეყვანა დაასრულა, და არასწორია, როცა ის ჯერ კიდევ კრეფს, და ტესტს არ შეეძლო ამის განსხვავება, რადგან სპეციფიკაციაც ვერ არჩევდა.
ეს საშიში კატეგორიაა, რადგან პირველი ორი შეცდომად ჩანს, როგორც კი მათ დაინახავთ, ეს კი არა. დიაპაზონს გარეთა შეყვანის შემოფარგვლის შესახებ მტკიცება გულმოდგინებად მოჩანს. ის კოდის მიმოხილვას გაივლიდა. ჩემსასაც გაიარა. ამ შემთხვევის უფრო ღრმა განხილვა გავაკეთე სტატიაში The Contract Discovery Bottleneck.
მეოთხე: სწორი ტესტი არასწორ სისტემაზე
კონტროლები არსებობს, მაგრამ მიმართულია სხვა რამეზე.
მიმოხილვის სამუშაო ნაკადის უსაფრთხოდ შესამოწმებლად, მონაცემთა ნაკრების სატესტო ასლი გავაკეთე. გეგმა ასეთი იყო: ავტორობის ინსტრუმენტი და აპლიკაცია სატესტოზე მიმეთითებინა, მტკიცება შემეთავაზებინა, მიმეღო და მენახა, რომ სწორი ბოთლები იცვლიან მდგომარეობას, წარმოების მონაცემებზე შეხების გარეშე.
ავტორობის ინსტრუმენტი პატივს სცემდა გარემოს ცვლადს, რომელიც მონაცემთა ნაკრებს ირჩევს. აპლიკაცია, აგებული იმავე ბრძანებით და იმავე ცვლადით, ჩუმად უგულებელყოფდა მას. მისი აგებული ნაკრები ბაიტ-ბაიტ იდენტური იყო აგებასთან, სადაც ცვლადი არ იყო დაყენებული და გამოიყენებოდა production. გაფრთხილება არ იყო, შეცდომა არ იყო. ის აიგო და გაეშვა სრულყოფილად.
ასე რომ, ავტორობის ინსტრუმენტი შემოთავაზებას სატესტოში ჩაწერდა, აპლიკაცია კი წარმოებას აჩვენებდა. ეკრანზე ყოველი რიცხვი შიდა თვალსაზრისით თანმიმდევრული იქნებოდა, მაგრამ სხვა სარდაფზე.
ტესტის სიზუსტე აქ ვერაფერს უშველის. მტკიცებები შეიძლება სრულყოფილი იყოს და მაინც არასწორი რამ დაადასტუროს, რადგან კითხვა, რომელიც პირველი უნდა დასმულიყო, რომელ სისტემას ვუყურებ სინამდვილეში?, არასდროს დასმულა.
გამოსწორებას ორი ნაწილი ჰქონდა. აპლიკაციის მონაცემთა ნაკრები ხელით რედაქტირებულ ლიტერალად იქცა, ამიტომ ის ჩუმად არ შეიძლება იყოს არასწორი: ნებისმიერი ცვლილება diff-ში ჩანს. ასევე, აპლიკაცია ახლა თავსართში აჩვენებს მონაცემთა ნაკრების სახელს, როცა ის წარმოება არ არის. მსჯელობა უფრო მნიშვნელოვანია, ვიდრე გასწორება. კითხვა არასდროს ის იყო, როგორ მივუთითო სატესტოზე. კითხვა იყო, დარწმუნებული ვიყავი თუ არა, რომელ მონაცემთა ნაკრებში ვწერდი ახლახან.
მაგალითები ის ბილიკებია, რომლითაც უკვე დადიხარ
ოთხივესგან განცალკევებით, და ის, რაზეც ყველაზე ხშირად ვფიქრობ.
იმავე თარიღის კონტროლს ჰქონდა არითმეტიკული ბაგი: 31 იანვარსა და 1 მარტს შორის სხვაობა არასწორად ითვლებოდა, რადგან რეალიზაცია თებერვლიდან დღეებს ისესხებდა და ნაშთს უხმაუროდ აგდებდა.
ამ ფუნქციონალისთვის ხუთი გადამოწმების თარიღი მქონდა. ისინი ფრთხილად შევარჩიე რეალური მონაცემებიდან, კოდის არსებობამდე. ისინი დემო-ვიდეოსა და ეკრანის ანაბეჭდებშია.
ყველა ხუთი გაიარა ბაგიან ვერსიაზეც. აპლიკაცია მუშაობდა. ეკრანის ანაბეჭდები სწორი იყო. ყველა თარიღი, რომლის ჩვენებასაც ვაპირებდი, კარგად იყო.
ბაგი იპოვა თვისება-ტესტმა, რომელიც სლაიდერის ყველა 17,167 პოზიციას ამოწმებდა, და მტკიცებას ნებისმიერი თარიღების წყვილისთვის მოქმედ იდენტობაზე. ბაგი ცხოვრობდა რეგიონში, სადაც არავინ განზრახ არ მიაღწევდა.
დემოზე დაფუძნებული ვერიფიკაცია ადასტურებს ბილიკებს, რომლითაც უკვე დადიხარ. ეს არ არის არაფერი, მაგრამ არ არის ის, რაც გგონია, რომ იღებ.
რა მართლა იმუშავა
არცერთი მათგანი არ იყო „დაწერე მეტი ტესტი“.
ორაკულები, შექმნილი იმპლემენტაციამდე, მკაფიო მითითებით არ შეკეთებულიყვნენ. მოსალოდნელი გამოსავლები დამოუკიდებლად გამოითვალა და კოდის არსებობამდე დაფიქსირდა. მოთხოვნაში ეწერა, რომ მათ ორაკულად უნდა მოეპყრობოდნენ და არა გამოსავლად, რომელიც უნდა გასწორდეს, და რომ შეუსაბამობის შემთხვევაში უნდა გაჩერებულიყვნენ და ეცნობებინათ. როცა ტესტი ჩავარდება, ყველაზე იაფი ხელმისაწვდომი ნაბიჯი მოწყობილობის შეცვლაა, და ეს ინსტინქტი წინასწარ უნდა იყოს გამორიცხული და არა მომენტში დაძლეული.
მუტაცია, მაგრამ მხოლოდ იმ ტესტებზე, რომლებიც მნიშვნელოვანია. წაშალეთ პუნქტი, რომელსაც ტესტი ფარავს. თუ ის მწვანე რჩება, ტესტი დეკორატიულია. ამან იპოვა სამი ფუჭი ტესტიდან ორი, და აგენტმა ეს პირველის შემდეგ საკუთარი ინიციატივით დაიწყო.
გაზომვა მსჯელობის ნაცვლად, ყველაფერზე, სადაც რიცხვია. წარმადობის ბაგი ოთხ სწორად გამოყურებად მემოიზაციის ხაზში იმალებოდა, რომელიც უკვე გაიარა მიმოხილვა. ინდექსის აგება 6 ms ჯდებოდა; იმის ხელახლა გამოთვლა, რასაც ინდექსი ემსახურებოდა, 0.07 ms. კოდი არასწორს მემოიზებდა. კოდის კითხვით ეს არ გამოჩნდებოდა. ორივეს ბენჩმარკმა ათი წუთი დასჭირდა.
კარიბჭე, რომელიც დაასახელებდა, რა არ ჩაითვლებოდა მტკიცებულებად. შემოწმებებისთვის, რომლებსაც რენდერირებულ ეკრანზე თვალი სჭირდებოდა, ჩავწერე ტესტირებული გზა სრულად და ჩამოვთვალე, როგორ შეიძლებოდა მისი ყალბად გაკეთება: ამის დასაკმაყოფილებლად არ მოიხმოთ მოდული სკრიპტიდან, არ მოითხოვოთ მონაცემები სხვა გზით და არ მიუთითოთ ტესტების ნაკრებზე. შემდეგ: ბრაუზერს ვერ ვხედავ, ამიტომ ეს არ მოხსენოთ როგორც გავლილი. მომაწოდეთ ბრძანება, URL და მოსალოდნელი რიცხვები, და დავადასტურებ.
არ არის დადასტურებული, აი როგორ შეამოწმებ. შედეგი, რომელიც ვერავინ დააკვირდა, არ არის გავლა, და ჰარნესი, რომელსაც ეს არ შეუძლია თქვას, მას გავლად დაამრგვალებს.
აგენტები კარგები არიან. ისინი არ არიან გამონაკლისი.
აგენტმა ამ პროექტში კოდის თითქმის მთელი ნაწილი დაწერა, ტესტების ჩათვლით. ამიტომ ღირს გულახდილად თქმა, ვინ დაწერა ზემოთ ჩამოთვლილი ტყუილების უმეტესობა: იგივე ინსტრუმენტმა, რომელმაც კოდი დაწერა, რომელსაც ისინი ამოწმებდნენ.
ეს ბრალდება არ არის. ორი კვირის განმავლობაში აგენტი ბევრ ამ საქმეში უკეთესი იყო, ვიდრე მე ვარ. ყოველი ეტაპის წინ ის ჩემს სპეციფიკაციას პლატფორმასთან ადარებდა და მასში შეცდომებს პოულობდა; მერვე სესიისთვის ეს გავლა ათ კონფლიქტს ერთდროულად პოულობდა, ორი მათგანი ჩემი სპეციფიკაციის პირდაპირი შეცდომა იყო. როცა შემოვთავაზე Function-ის ტესტირება წარმოების წინააღმდეგ ტრიგერით, რომელიც არსებულ დოკუმენტის ტიპზე არ იყო მიბმული, მან უარი თქვა, სწორად: ტრიგერის მიბმა უსაფრთხოა, მაგრამ მის გააქტიურებას მხოლოდ შესაბამისი დოკუმენტის ჩაწერით შეიძლება, და ჩემი გეგმა წარმოების ისტორიაში ორ მუდმივ მუტაციას დატოვებდა სატესტო ნაკრების შესაქმნელად. მან იპოვა მოწყობილობა, რომელიც მე ვუთხარი, შეუძლებელი იყო. მან გაზომა ფუნქციის ღირებულება, რომლის გაზომვაც არ მთხოვია.
ის ასევე მცდარი იყო იმ გზებით, რომლებსაც ფრთხილი ადამიანი იცნობს. მან დარწმუნებით განაცხადა, რომ API ვერ აკეთებდა იმას, რასაც დოკუმენტაცია აჩვენებდა, შემდეგ კი ერთი ხაზით გაასწორა, როცა შემოწმება ვთხოვე დადასტურების ნაცვლად. თარიღების შედარებაზე სწორ დასკვნამდე არასწორი მიზეზით მივიდა, რაც მხოლოდ მანამ არის სწორი, სანამ შემთხვევა არ შეიცვლება. როცა დარჩენილი სახელმწიფო სამუშაოს სია ვთხოვე, სია არა კოდის, არამედ აგების გეგმის მიხედვით შეადგინა, და სამი პუნქტი უკვე შესრულებული იყო. გეგმა აღწერს დაგეგმილ სამუშაოს, არა დარჩენილს.
და ის წესებს არღვევდა. ორჯერ, მას შემდეგ რაც უთხრეს, არ გაეშვა git ბრძანებები, რომლებიც რეპოზიტორიას ცვლის, მან git checkout გაუშვა საკუთარი დაუდასტურებელი რედაქტირებების გასაუქმებლად. ადრე კი შეცვალა ორაკულის ფაილი, რომელსაც მკაფიოდ ეკრძალებოდა შეხება, შემდეგ კი აღადგინა. ყოველ ჯერზე მან დარღვევა თავად მოახსენა, ჩემს მიერ მის აღმოჩენამდე. „აგენტმა წესი დაარღვია და მითხრა“ უფრო სასარგებლო მონაცემია, ვიდრე ორივე სუფთა ისტორია, „არასდროს დაურღვევია წესი“ ან „დაარღვია და მე დავიჭირე“. წესი ახლა ამბობს, რომ ფაილების ინსტრუმენტები ერთადერთი გზაა რისიმე დასაბრუნებლად, მათ შორის საკუთარი რედაქტირებებისთვისაც.
ქვეშ მდგომი ნიმუში არის ის ნაწილი, რომელიც ღირს შენახვას. აგენტი ტესტებს იმავე გზით წერს, როგორც კოდს: სწრაფად, გაწაფულად, დამაჯერებლად და პრობლემის ერთი და იგივე გაგებიდან. როცა ერთი ინსტრუმენტი ერთი და იმავე მოთხოვნიდან წერს იმპლემენტაციასა და მის ტესტებს, ისინი ერთ ვარაუდების ნაკრებს იზიარებენ, და არასწორი ვარაუდი ორჯერ კოდირდება და შემდეგ საკუთარ თავს ეთანხმება. ეს მესამე ტყუილია, და აგენტები მის მასშტაბურად ჩადენას უფრო იაფს ხდიან. სიჩქარე ვერიფიკაციის პრობლემას არ აშორებს. ის ბოთლნეკს იქ გადააქვს, რაზეც უკვე დავწერე ადრე.
შედეგი არ შეცვლილა იმით, რომ აგენტს ნაკლებად ვენდობოდი. შეიცვალა იმით, რომ ვერიფიკაცია სტრუქტურულად ყალბად გასაკეთებლად რთული გახდა: ორაკულები კოდამდე დაფიქსირებული, ყოველ შემოწმებაზე კონტროლები, კარიბჭეები, რომლებიც დაასახელებდნენ, რა არ ჩაითვლებოდა, და საბოლოო დადასტურება იმ ერთი მონაწილის ხელში, რომელსაც თვალი აქვს. ამ პირობებში აგენტმა არა მარტო გაიარა შემოწმებები, არამედ დაიწყო მათი გაუმჯობესებაც.
ეს ხელახლა მოხდა
ერთი თვის შემდეგ პატარა ექსპერიმენტული ჰარნესი ავაშენე სხვა, დაუკავშირებელი რამისთვის: პატარა ენობრივი მოდელების შედარება ჩვეულებრივ კოდთან Raspberry Pi-ზე. ამ ტაქსონომიას მაშინ უკვე ვიცნობდი. მაინც იგივე ტყუილები ვიპოვე.
მოწყობილობა, რომელსაც არ შეეძლო განესხვავებინა ქცევები, რომელთა შედარებაც უნდა მომხდარიყო. მეტრიკა, რომელიც მოდელს ასჯილდოვებდა ყოველთვის უსაფრთხო პასუხის მიცემისთვის, რაც ყოველთვის გამავალი შემოწმებაა, ლაბორატორიული ხალათით შემოსილი. და დაკარგული დირექტორია, რომელმაც კითხვების მთელი რაუნდი ცარიელ საცნობარო კორპუსზე გაუშვა და დეტალური, დარწმუნებული, არასწორი ანგარიში დაწერა: სწორი ტესტი არასწორ სისტემაზე, კიდევ ერთხელ.
კატეგორიების ცოდნამ ისინი არ აგვაცილა. მან ისინი უფრო სწრაფად ამოცნობადი გახადა, და ეს ყველაზე მეტია, რასაც ნებისმიერი საკონტროლო სიისგან მოველი.
გულწრფელი საზღვარი
ორაკულები იმპლემენტაციის შეცდომებს იჭერენ. სპეციფიკაციის შეცდომებს ვერ იჭერენ, რადგან მათ ჩემი სპეციფიკაციიდან ვქმნიდი.
ერთი მათგანი შემთხვევით უფრო ძლიერი იყო. გაცდენილი შესაძლებლობის ორაკული პერიოდის ყოველი დღის მძლავრი გადამოწმებას იყენებდა, იმპლემენტაცია კი მხოლოდ იმ თარიღებს ამოწმებდა, სადაც მდგომარეობა შეიძლება შეიცვალოს. ორი ნამდვილად განსხვავებული ალგორითმის თანხმობა უფრო ძლიერი მტკიცებულებაა, ვიდრე ერთი ალგორითმის თანხმობა საკუთარ თავთან, იმავე მიზეზით, რის გამოც მეღვინე რეფრაქტომეტრს ჰიდრომეტრით ამოწმებს: ინსტრუმენტები, რომლებიც სხვადასხვა გზით ცდებიან, ერთად ძნელად ცდებიან. ამ იდეაზეც მქონდა ახლახან წერა, აქ. მაგრამ ამ ორაკულსაც იგივე ვარაუდი აქვს სპეციფიკაციასთან იმის შესახებ, რა არის გაცდენილი შესაძლებლობა.
ტესტები გეუბნებიან, რომ იმპლემენტაცია ეწინააღმდეგება თქვენს მოლოდინებს. ისინი ვერ გეუბნებიან, იმსახურებენ თუ არა თქვენი მოლოდინები გამარჯვებას.
რას შევინარჩუნებდი
ოთხი ჩვევა, თითო ტყუილზე:
მიეცით ყველა ინერტულობის ტესტს დადებითი კონტროლი. თუ ის ამტკიცებს, რომ რაღაცას ეფექტი არ აქვს, დაამტკიცეთ, რომ ეფექტი არსებობს, როცა უნდა არსებობდეს.
მიეცით ყველა სიგნალს უარყოფითი კონტროლი. თუ მისი ცნობილად სუფთა შეყვანაზე გავლა არ შეიძლება ნაჩვენები, ის არ არის შემოწმება. ეს არის ხმაური წითელი იკონით.
ტესტირება თვისებებზე მთელ დომენზე, არა მხოლოდ მაგალითებზე. თქვენი მაგალითები ის ბილიკებია, რომლებიც უკვე იცით, რომ მუშაობს, და კონტრაქტი იმდენად კარგია, რამდენადაც იმ შემთხვევები, რომელთა შესახებაც კითხვა მოგაფიქრდათ.
შეამოწმეთ სამიზნე შედეგამდე. გახადეთ ტესტირებადი სისტემა ხილული ეკრანზე და diff-ში, რომ კითხვა „რომელს ვუყურებ?“ არასდროს იყოს ვარაუდი.
არცერთი ეს ჩვევა AI-ზე არ არის, და ამაშია აზრი. აგენტმა ყოველი ეს ტყუილი ჩადენა გახადა იაფად და მათი პოვნა უფრო სწრაფად. მან არ შეცვალა, რომელი შემოწმებები იყო გულწრფელი.
დანარჩენი ჩვეულებრივი რჩევაა, და სწორედ ის არ გადამარჩინა.
ეს წარმოიშვა The Cellar-ის აგებიდან, Sanity DEV Challenge-ისთვის შექმნილი ივენთზე დაფუძნებული ღვინის კოლექციიდან. სრული აგება დოკუმენტირებულია იმ რეპოზიტორიის friction logs-ში, მათ შორის ყველა ზემოთ მოყვანილი შემოწმება და აუდიტები, რომლებმაც ისინი იპოვეს.