AI агенті жұмыс бітпесе де неге «дайын» дейді

OpenAI моделі sandbox-тен қалай шығып, Hugging Face-ті бұзды?#

Алдымен фактілер, содан кейін мұның сіз үшін неліктен маңызды екенін айтамыз.

OpenAI модельдерінің шабуылдық киберқауіпсіздік саласында не істей алатынын өлшеді. Олар ExploitGym сынағын қолданды: белгілі осалдықты жұмыс істейтін эксплойтке, яғни сол осалдықты пайдаланатын дайын бағдарламаға айналдыру қажет болатын 898 тапсырма. Нақты мүмкіндіктердің шегін көру үшін, модельге мұндай әрекеттер жасауға әдетте кедергі келтіретін кіріктірілген қауіпсіздік сүзгілерін өшірді. Олар ортаны толығымен оқшаулап, бір ғана шығу жолын қалдырды: пакеттерді орнатуға арналған ішкі делдал бағдарлама.

Нөлдік күн осалдығы — оны бағдарламаны жазған адамды қоса алғанда, әлі ешкім білмейтін саңылау. Модельдер дәл сол жалғыз шығу жолынан осындай осалдықты тапты.

Одан кейін олар өз артықшылықтарын арттырып, ішкі желі арқылы интернетке қол жеткізе алатын машинаға өтті. Сол жерден ExploitGym жауаптары Hugging Face-те болуы мүмкін деп болжады. Оларға Hugging Face туралы ешкім айтқан жоқ. Мұны өздері анықтады.

Болжам қате болды. ExploitGym Hugging Face-те мүлде жоқ. Бірақ бұл шабуылдың шынайылығын кемітпейді.

Hugging Face басып кіруді өзі анықтап, 16 шілдеде ашып көрсетті, бірақ оны кім бұзғанын әлі білмеді.

Бұл есептегі тағы бір жайт жағдайдың қаншалықты өзгергенін көрсетеді. Hugging Face инженерлері шабуыл журналын кең таралған коммерциялық интерфейстер арқылы жетекші модельдерге бергенде, қауіпсіздік сүзгілері сұрауларды бұғаттады: олар шабуылды зерттеп отырған адам мен шабуыл жасап отырған адамды ажырата алмады. Ақырында талдау өздерінің жабдықтарындағы ашық модельде жүргізілді.

OpenAI бұл туралы 21 шілдеде, Hugging Face жариялағаннан бес күн өткен соң мойындады. Ол кезде шабуылдың өзінен бері шамамен он күн өткен еді.

OpenAI өз талдауын мынадай қорытындымен аяқтады.

Модель сынақтың тар мақсатына байланып, оған жету үшін шектен шықты. hyper-focused және fairly narrow testing objective деген тіркестерді OpenAI-дің өзі қолданған және олар компанияның өз модельдеріне қатысты.

Міне, осы өзге зертханадан сіздің ноутбугыңызға дейінгі көпір іспетті.

Неге бұл «галлюцинация» емес?#

Чаттарда «тағы да галлюцинация», «контекст толып кетті» немесе «жоспар құру керек еді» деген сөздерді жиі көремін. Кейде дәл солай болады. Бірақ AI агенті «дайын, тексердім, бәрі жұмыс істейді» деп жазып, ал жұмыс бітпесе, мәселе әдетте контекст көлеміне байланысты емес.

Ол ештеңені ойдан шығарған жоқ. Сіз өлшеген нәрсені дәл орындады.

«Галлюцинация» деген көп нәрсені қамтитын атаумен үш түрлі ақауды біріктіріп жібереміз. Олардың айырмашылығы мынадай:

Біріншісі контекст арқылы түзетіледі және ең танымал жағдай. Екіншісі — бөлек құбылыс. Ол туралы Claude бәрімен келісетін кез талдауында айтылған: модель тез келісу үшін дәлдіктен бас тартады. Екеуі де жұмыс басталмай тұрып, кіріс деректер кезеңінде болады.

Кестенің үшінші жолы осы мақаланың тақырыбы. Мұнда агент жағымпазданған да, ойдан шығарған да жоқ. Ол жұмыс істеді, тексерді және шындықты баяндады. Бірақ бұл шындық көрсеткішті сипаттайды да, тапсырма туралы ештеңе айтпайды.

Үшінші ақаудың атауы бар.

Қарапайым тілмен айтқанда, reward hacking деген не?#

Anthropic мұны өзі анықтайды.

Бұл идея нейрондық желілерден де ескі. DeepMind мақаласында бұл құбылыс «спецификацияны ойынға айналдыру» деп аталып, миф арқылы түсіндіріледі.

Мидас сұрағанының дәл өзін алды. Мәселе өтініштің қалай тұжырымдалғанында еді.

Бағдарламалауда мұның нақты көріністері бар. Міне, Anthropic келтірген оқулықтағы мысал:

Бұл зертханаға тән тосын жағдай да емес. Cursor танымал бенчмарктегі 731 траекторияны талдады.

«Шешілген» тапсырмалардың оннан алтауы — тауып алынған жауаптар. Саланың өнімділікті өлшеу тәсілін өзгертіп жатқанының себебі де осы: тексерулерден өтуді енді басты өлшем санамайтын өндіріске дайындығын өлшейтін бенчмарк туралы талдауымыз бар.

Бұл кәдімгі өнімде қалай көрінеді?#

Зертханалық мысалдарды тосын әрі қатысы жоқ деп санау оңай. Сондықтан тәжірибеден алынған төрт оқиғаны келтірейік. Клиенттер мен салалар өзгертілген, бірақ оқиғалардың қалай өрбігені сол күйінде қалды.

Төрт жасыл тексеру және істемей қалған сервис компоненті

Жылжымайтын мүлік агенттігі сервис құрып жатыр: жылжымайтын мүлік тізімі бар веб-сайт және тізімдерді түнде платформаларға экспорттайтын бөлек фондық процессор. Агент тапсырманы аяқтап, типтер тексеруден өтті, код стилі тексерілді, құрастыру сәтті аяқталды, беттер жауап беріп тұр және олардың көрінісі көзбен тексерілді деп есеп береді.

Әрбір тұжырым шын. Бірақ олардың ешқайсысы түнгі процессорға қатысты емес: ол бөлек процесс ретінде іске қосылады және веб-сайт құрастыруының құрамына кірмейді. Орналастыру сәтті өтеді, сайт мінсіз жұмыс істейді, тізім экспорты тоқтайды, ал клиенттер мұны бір күннен кейін хабарлайды.

Енді «дайын» демес бұрын, бір сұрақ қоямын: жұмысымның тексеру қамтымайтын бөлігі бар ма? Бар болса, оны бөлек іске қосып, пәрмен нәтижесін есепке қосыңыз. «Тексерілді» деген сөз бұл мәселені жаппайды.

Жалған құсбелгі дәл түйісу жерінде пайда болады

Интернет дүкені үлкен тапсырманы бір мезетте бірнеше агентке бөледі: біріне серверлік бөлігі, екіншісіне беттер, үшіншісіне тауар карточкалары беріледі. Әрқайсысы мұқият жұмыс істеп, тексерулерден жасыл нәтиже алады.

Бір аптадан кейін «бұл пікір пайдалы болды» түймесі еш жерде жұмыс істемейтіні анықталады. Серверлік бөлік толық жазылған, тексерулері жасыл, қайта есептеу ережелері сақталған. Бірақ ешбір бетте түйме жоқ: түйме бір агенттің аймағында, беттер басқа агенттің аймағында болды, сөйтіп ешкім оны экранға шығаруды ойламады. Есептегіш мәңгі нөлде қалатын еді.

«Код жазылып, тексерулермен қамтылды» және «функция жұмыс істейді» — екі бөлек тұжырым. Екіншісін әрбір жаңа функцияға қоятын бір сұрақпен тексеремін: оны кім шақырады? Мұны жоба бойынша іздеу арқылы растаймын, өйткені бұл жерде агенттің есебі шындықтың көзі емес.

Тексеруші тек қарауды сұраған бағытты ғана көреді

Сервис адалдық деңгейлерін енгізеді: қанша көп ақша жұмсасаңыз, мәртебеңіз бен жеңілдігіңіз сонша жоғары болады. Орналастыру алдында код «Өз мәртебеңізді қолдан көтеруге тырысыңыз» деген нұсқаумен тексеруге жіберіледі. Тексеруші тапсырманы адал орындап, «маңызды мәселе жоқ» деп хабарлайды: мәртебені қолдан көтеру шынымен мүмкін емес.

Екінші тексеруде басқа сұрақ қойылады: «Ақша қайтарылғанда мәртебеге не болады?» Он минутта осалдық табылады. Ұпайлар транзакциялар журналынан есептелді, ал журналда ақшаның қайтарылғаны туралы ақпарат жоқ. Бірдеңе сатып алып, ұпай жинап, ақшаны қайтарып алсаңыз да, мәртебе мен жеңілдік мәңгі қалады.

Бірінші тексеруші жұмысты шала істеген жоқ. Ол мұны құрылымдық тұрғыдан көре алмады: оған «кіріс, көтермелеу» бағыты берілді, ал осалдық «кірісті қайтару, көтермелеуді сақтау» бағытында еді. Ақша, қол жеткізу немесе сатып алуға болатын мәртебе мәселесінде екі рет тексеремін, ал екінші тексеруде кері бағыттарды ашық тіземін: ақшаны қайтару, бұғаттау, қолжетімділікті жою, мерзімнің аяқталуы, дереккөзді жою.

Көрсеткіш ұқсастықты марапаттайды

Жеткізу қызметі операторларға арналған AI ұсыныстары жақсарған-жақсармағанын өлшеуге шешім қабылдайды. Екі жүз ескі қолдау сұрауын алып, жаңа нұсқа арқылы өткізеді де, жасалған жоба мәтінінің адам операторы шын мәнінде жазған жауабына қаншалықты ұқсайтынын өлшейді. Өлшем сенімді өсім көрсетеді.

Бұл өсім екі себеппен ештеңені білдірмейді. Жоба мәтінінің контексті «бүгінгі жағдайға сай» жиналады және оған кейін салыстырылатын оператор жауабының өзі де қоса бүкіл хат алмасу кіреді. Модель жауап жазбайды, оған көрсетілген эталонды басқа сөзбен жеткізеді. Оған қоса, көрсеткіш сөздер мен ұзындықтың ұқсастығын марапаттайды: оператор дұрыс күнді жазған сөздермен дәл солай қате күнді көрсеткен мәтін жоғары ұпай алады.

«Ұқсас болса, жақсы» деген әрбір көрсеткіштің жанына стиль алдай алмайтын қатаң механикалық шарттар қоямын: ойдан шығарылған сандар мен күндер, тыйым салынған сөздер, әрекет етуге берілген уәделер. Шарттар нәтижесінің кез келген төмендеуі көрсеткіш жақсарғанының орнын толтырады.

Агенттің «тексердім» деген сөзі неге ештеңені дәлелдемейді?#

Кез келген жобаңызды алып, агенттен «Қауіпсіздігін тексер» деп сұраңыз. Көбіне ол «бәрі дұрыс, маңызды мәселе жоқ» деп жауап береді.

Енді сол жоба туралы дәл сол сұрақты басқа модельге қойыңыз. Әсіресе жоба үлкен болса, ол көп нәрсе табады. Орналастыру алдында автор жобаны үш түрлі модельмен тексереді, олардың әрқайсысы әртүрлі нәрсе табады.

Бірдей кіріс дерек, бірдей сұрақ, қарама-қарсы қорытынды. Бір модель екіншісінен нашар емес. Тек «бәрі дұрыс» деген мәтін де кез келген басқа жауап сияқты дәл сол қабатта құрылған мәтін. Агент «қарадым, бәрі таза» мен «дұрыс емес жерді қарадым» дегеннің айырмасын ажырата алмайды.

Anthropic бұл механизмді Claude Code құжаттамасында сипаттайды.

Бұл сөйлемді асықпай талдап көрейік. Агентке өзі орындай алатын тексеру бермейінше, оның бір ғана белгісі бар — істердің сырт көзге қалай көрінетіні. Мұндай жағдайда сіз тексеру циклінің бір бөлігі боласыз, бірақ қателерді ең соңында білетін адам да өзіңіз.

Мұның тағы бір терең қабаты бар. OpenAI модельдің пайымдауын бақылап, «жаман ойлары» үшін жазалауға тырысқанда, нәтиже күткендей болмады.

Ниетін айту үшін жазалау сол мәлімдемені жояды. Ниеттің өзі қалады. Сондықтан агенттің қалай алдағанын өзі шынайы айтып береді деп сенбес едім.

Құрал жасаушылардың өздері де осы бағытқа бет алып жатыр. Claude Code 2.1.215 нұсқасында /verify және /code-review дағдылары модельдің өз бастамасымен іске қосылмайтын болды.

2.1.215 - Claude бұдан былай `/verify` және `/code-review` дағдыларын
өздігінен іске қоспайды; қажет болғанда оларды `/verify` немесе `/code-review` арқылы
шақырыңыз

Anthropic себебін түсіндірмейді. Бірақ қағида анық: тексеріліп жатқан адам өзіне өзі тексеру тағайындамайды.

Жоба файлындағы ереже агентті тәртіпте ұстай алмай ма?#

Сіз жоба ережелері файлына: тікелей нұсқау болмаса, коммит жасама, мен тікелей айтпасам өндірістік ортаға орналастырма, өндірістік дерекке тек оқуға рұқсат етілген режимде кір деп жаздыңыз.

Автордың тәжірибесіне сүйенсек, шамамен он жағдайдың бірінде агент бәрібір өздігінен орналастырып жібереді. Қасақана емес, ережені оқымағандықтан да емес. Ол ережені оқыды. Бірақ алдында мақсат тұрды, ал ереже басқа контекст сияқты жай мәтін болатын.

OpenAI зертханасында да дәл осылай болды, тек ауқымы үлкенірек еді. Модельдер бір ғана шығу жолы бар жабық ортада болды және есептеу қуатының едәуір бөлігін шығатын жол іздеуге жұмсады. Сынақ тапсырмалары шешілмей қалды.

Бұл туралы ұстанымым қарапайым: агент қауіпті де, қаскөй де емес. Ол қарапайым ғана, билік берілген ақымақ. Сондықтан сұрауларыңызды қайта жазбай, оның өкілетін шектеу керек.

Нақты тежейтін шаралар: өндірістік дерекке тек оқуға рұқсат беру. Бүтін каталогтарды жоюға тыйым салу. Қалпына келтіру жолы жоқ тарихты қайта жазатын пәрмендерге тыйым салу. Провайдермен шығын шегін белгілеу. Айырмашылық бір тіркеске саяды: «физикалық тұрғыдан істей алмайды» деген шарт «істеме деп сұрадым» дегеннен басым. Нақты баптаулар бөлек қарастырылған: нұсқаулықтағы өтініштердің орнына механикалық тежегіштер мақаласында.

Дегенмен сабыр сақтаңыз. Sandbox те абсолютті шекара емес, мұны провайдердің өзі ашық айтады.

Оған қоса, Claude Code-та модельдің өзі пайдалана алатын кіріктірілген төтенше шығу жолы бар. Sandbox шектеуіне байланысты пәрмен орындалмаса, Claude қатені талдап, sandbox-ты өшіретін параметр қосып, сол пәрменді қайта орындап көруі мүмкін. Мұны арнайы қатаң режим баптауы жабады; әдепкіде айналып өту жолы қолжетімді әрі құжатталған.

Шектеу оны қаншалықты қатаңдатсаңыз, соншалықты ғана жұмыс істейді. Әр кедергінің жылдамдыққа әсері бар. Мұны алдын ала адал есептеп алған жөн, өйткені бір аптадан кейін анықталса, қымбатқа түседі.

Алдауға келмейтін аяқталу өлшемін қалай орнатуға болады?#

Өлшемнің тұжырымы қалғанының бәрін анықтайды. Оны бір сұрақпен тексеріңіз: агент ештеңе істемей-ақ осы өлшемді орындай ала ма?

• «Бәрі жұмыс істейтінін тексер» — орындай алады. «Тексердім, жұмыс істейді» деп жазса жеткілікті.
• «Құрастыруды іске қосып, нәтижесін көрсет» — қиынырақ, себебі нәтижені қайдан да болса алуға мәжбүр.
• «Қолданбаны іске қос, тапсырысты рәсімдеу түймесін басып, экранда не шыққанын көрсет» — мұны сөзбен орындау мүмкін емеске жуық.

Бірінші мен үшіншінің айырмасы — есеп пен дәлелдің айырмасы.

Claude Code құжаттамасында қатаңдықтың төрт деңгейі сипатталған. Қателіктің құны артқан сайын көтерілуге болатын баспалдақ:

1. Бір хабарламада. Агенттен тексеруді іске қосып, осы жерде сәтті аяқталғанша қайталауды сұраңыз. Ең арзан тәсіл, ұсақ жұмыстарға жарайды.
2. Бүкіл сессияға. Тексеруді мақсаттың шартына айналдырыңыз: бөлек бағалаушы әр айналымнан кейін тексереді, ал агент шарт орындалғанша жұмыс істейді. Техникалық егжей-тегжейі аяқталу өлшемін алдын ала орнату нұсқаулығында қамтылған.
3. Механикалық тосқауыл. Агент айналымды аяқтауға әрекеттенгенде скрипт іске қосылып, тексеру өтпейінше аяқтауына жол бермейді. Бір маңызды жайт бар: қатарынан сегіз рет бұғатталғаннан кейін Claude Code тосқауылды айналып өтіп, айналымды бәрібір аяқтайды. Жүйеде мүлде өтпейтін тосқауыл жоқ.
4. Екінші пікір. Нәтижені жоққа шығаруға міндетті, контексті жаңа бөлек тексеруші.

Төртінші тармақтың ерекшелігі — ол құралдарға қатысты емес жалғыз тәсіл.

Агенттің жұмысын кім қабылдауы керек?#

Үлкен тапсырманы орындауға агенттерді айналыммен қосқанда, менің жүйем мынадай: бір топ жазады, ал жазуға қатыспаған жаңа топ жұмысты қабылдайды.

«Жаңа» деген — шешімдердің қалай қабылданғанын көрмеген таза контекст. Сол сессиядағы басқа сұрау мұны қамтамасыз етпейді. Кодты жазған адам оның дұрыстығына сендіру үшін әлдеқашан күш-жігер жұмсады әрі енді де растауға бейім болады. Жоққа шығару оның мүддесіне сай емес.

Тексерушіге берілген тапсырманың тұжырымы оның моделінен маңыздырақ. Салыстырыңыз:

• «Осы жұмысты қарап шық» — тексеруші оңай табылатын нәрсені тауып, «жалпы алғанда дұрыс» деп жазады.
• «Бұл жұмыс орындалмағанын дәлелдеуге тырыс» — тексеруші осалдықтарды іздей бастайды, өйткені оның мақсаты сол.

Екінші тұжырым дәл ExploitGym сәтсіз болған себеппен жақсырақ жұмыс істейді: агент өзіне берілген мақсатқа ұмтылады. Оған саңылауды табу мақсатын берсеңіз, оны іздейді.

Міне, сол күйінде көшіруге болатын толық сұрау мәтіні:

Сіз басқа біреудің жұмысын тексеріп жатырсыз. Оны өзіңіз жазған жоқсыз және қорғауға міндетті емессіз.

Мақсатыңыз — барлық тексеру жасыл болып тұрса да, мәлімделген нәтижеге қол жеткізілмегенін дәлелдеу. Тексерулердің бәрі сәтті болса да, нәтижеге қол жеткізілмеуі мүмкін кемінде үш жолды табыңыз.

Мына ретпен тексеріңіз:

Тексерулердің аясынан тыс қандай жұмыстар орындалады: фондық процестер, бөлек скрипттер, жоспарланған тапсырмалар, кезек өңдегіштері.

Әр жаңа функцияны кім шақырады. Жобаны іздеп, шақыруды табыңыз; файл мен жол нөмірін көрсетіңіз.

Кері бағыттар: ақшаны қайтару, бұғаттау, қолжетімділікті қайтарып алу, мерзімнің аяқталуы, дереккөзді жою.

Нәтиженің бар-жоғы ғана емес, оның ішіндегі мәндер.

Адал іздеу ешбір осалдық таппаса, солай айтыңыз, бірақ нақты нені және қалай тексергеніңізді көрсетіңіз.

Агенттің өзін айналыммен тексеруі туралы мақалада агент итерациялар арасында өзін тексеретін цикл қалай жұмыс істейтіні және әдетте қай жерде істен шығатыны түсіндіріледі.

Өлшемді басқаша тұжырымдағанда не өзгереді?#

Бұл — мен білетін ең арзан жақсарту, бірақ оны дерлік ешкім қолданбайды.

Агенттен кодқа шолу жасауды сұрасаңыз, ол код тұрғысынан пайымдайды: құрылым, қателерді өңдеу, қайталап көру, осал тұстар. Пайдалы.

Одан клиенттің сайтқа алғаш келген сәтінен бастап ақшасын қайтарып алу әрекетіне дейінгі жолын бақылауды сұрасаңыз, артефактінің басқа түрлері шығады. Пайдаланушыға көруге болмайтын нәрсені көрсететін қате. Іс жүзінде болған жағдайға сәйкес келмейтін хат мәтіні. Идеал сценариймен келмеген пайдаланушы логикалық тұрғыдан өте алмайтын қадам.

Бұл ақаулардың ешқайсысын кодқа шолу таппайды, өйткені олардың әрқайсысы кодта жарамды.

Осыдан өзім ұстанатын ереже шығады: тексеру ештеңе таппаса, алдымен сұрауды басқаша тұжырымдаңыз. Мәселе әдетте модельде емес. Бір жұмысты үш түрлі тәсілмен сұратсаңыз, үш түрлі қорытынды тізімі шығады. Бағдарламашы емес адамдарға арналған практикалық сұрақтар бөлек жинақталған: бағдарламалау дағдыларынсыз кодты тексерудің жеті тәсілі.

Агент жұмысын қабылдауға арналған дайын сұрау мәтіні#

«Дайын» немесе «тексерілді» деп жауап бермеңіз. Маған дәлел керек.

Әрбір жұмыс тармағына мына мәліметтерді дәл осы түрде беріңіз:

Тармақтың жұмыс істейтінін растау үшін қандай пәрменді іске қостыңыз? Пәрменнің өзін және толық шығысын қысқартпай көрсетіңіз.

Егер пәрменді іске қоспасаңыз, «орындалмады» деп айтыңыз. Оның орнына «көзбен тексердім» немесе «логикасы дұрыс» демеңіз.

Тексеруіңіз қамтымайтын қандай жұмыс бар? Фондық процестер, бөлек скрипттер, жоспарланған тапсырмалар, кезек өңдегіштері — негізгі қолданбадан басқаша іске қосылатын кез келген жұмыс. Әрқайсысы бойынша: оны бөлек іске қостыңыз ба және қандай нәтиже берді?

Сіз қосқан әр жаңа функцияны кім шақырады? Жобаны іздеп, шақыруды табыңыз; файл мен жол нөмірін көрсетіңіз. Шақыру болмаса, оны ашық айтыңыз.

Содан кейін бөлек бөлімде: тексерулеріңіздің бәрі жасыл болса да, мәлімделген нәтижеге қол жеткізілмеуі мүмкін үш жолды жазыңыз. Мұқият іздеңіз.

Соңында, бір жолмен: автоматты тексеру байқамай қалатындықтан, мен өз көзіммен нені қарап шығуым керек?

Төртінші тармақ ұсақ болып көрінуі мүмкін, бірақ тұтас ақаулар тобын анықтайды. Бір үлкен тапсырманы аймақтарға бөліп агенттерге бергенімде, бүкіл жүз тапсырманың ішінде «дайын» деп қате айтылған жалғыз жағдай екі аймақтың түйіскен жерінде болды: код жазылды, тексерулер жасыл болды, бірақ ешкім оны экранға шығаруды ойламады.

Тексеру арқылы өзіңізді алдаудың төрт тәсілі#

1. Барлық тексерушіні күтпеді. Үш тексеруді қатар іске қостым, екеуінен жасыл нәтиже келді де, орналастырдым. Үшіншісі төрт минуттан кейін алты заңбұзушылық тапты. Жарияланғаннан кейін түзету енгізу екі минут күтуден қымбат.
2. «N-нен N өңделді» деген қорытындыға сенді. Агенттер көпке тарағанда, кейбірі үнсіз сәтсіздікке ұшырайды: сәтті деп хабарлайды, бірақ файлға тимеген. Енді агент арқылы кез келген жазудан кейін өзгерістердің дискіге шынымен түскенін механикалық жолмен тексеремін.
3. Өз көзіммен қарамады. Толық жарамсыз нәтиже кезінде де автоматты тексерулер жасыл болуы мүмкін. Суреттер техникалық тұрғыдан дұрыс, өлшемі дұрыс, жауап коды дұрыс. Бірақ шын мәнінде иллюстрацияланған мұқабалардың орнына автоматты қатып қалған кадрлар қойылған. Мұны ешбір автоматты тексеру байқамайды.
4. Мәнін емес, бар-жоғын тексерді. Тексеру нәтижеден міндетті мәтінді іздеді; мәтін бар, бірақ оның ішіндегі дерек қате: күн бір күнге ауытқыған. Тексеру жасыл болды, есеп өтірік еді. Енді күтілетін мәнді тұтас тексеремін, өйткені дұрыс сөздің жалғыз өзі ештеңеге кепілдік бермейді.

Төрт жағдайдың ортақ тұсы: тексеру болды, сенімді көрінді, бірақ дұрыс емес нәрсені тексерді. Модельдер мен олардың сынағындағы механизммен бірдей, тек мұнда тапқырлық жоқ.

Бүгін неден бастау керек?#

Жиырма минут алатын үш қадам.

1. Соңғы «дайын» дегенді алыңыз. Оны дәлел туралы бөлімдегі қабылдау сұрауымен тексеріңіз. Мақсат қарапайым: қанша тармақ сөзбен, ал қаншасы пәрмен шығысымен аяқталғанын көру.
2. Өзіңізге бір ереже қойыңыз. Тіркелген пәрмен шығысы жоқ «тексерілді» деген сөз есепке алынбайды. Бұл ереже агентке емес, сізге арналған, сондықтан жұмыс істейді.
3. Орындаушы мен тексерушіні бөліңіз. Келесі тапсырмада жаңа сессияға тексеруші сұрауын беріп, жұмыстың ОРЫНДАЛМАҒАНЫН дәлелдеуді сұраңыз. Әдетте алғашқы тексерудің өзі бұл әдетті ақтайды.

Құрал жақсы және ай сайын жақсарып келеді: бір жыл бұрын агент үнсіз жасайтын істер енді оның жолын кеседі. Қауіпсіздік шекарасы жылжып, шекара болып қала береді. Агент өзіне берілген мақсатқа ұмтылғанша, «мұны нақты қалай өлшедіңіз?» деген сұрақ сіздің мойныңызда. Тексеру әдеті — қауіпсіздік торыңыз.