Дереккөз бойынша фактілерді тексеру: тест жинағын қалай құруға болады

Неліктен көзбен тексеру жұмыс істемейді

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

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

Модель дереккөзді адам сияқты оқымайды. Ол таныс үлгіні танып, сөйлемді есінде бар нәрсемен толықтыра салады. Сондықтан қолмен тексеру тез арада әртүрлі бағытқа кетеді. Бір ревьюер жалпы мағынасына қарап «дұрыс» дейді. Екіншісі қате лимитті, түсіп қалған шартты немесе ауысқан қадам ретін байқап, «қате» қояды.

Ең жаманы — байқалмайтын қателер. Жауап тыныш әрі сенімді көрінеді, дереккөзге дерлік сәйкес келеді, бірақ бір детальды ауыстырып жібереді. Команда дәл осындай қателіктерді жиі өткізіп алады.

Әдетте қолмен шолу төрт жерде бұзылады:

• жауап стилі фактіден гөрі бағалауға көбірек әсер етеді
• ревьюерлер «жартылай дұрыс» дегенді әртүрлі түсінеді
• ұсақ айырмашылықтар бірден байқалмайды
• бір қате бүгін есептеледі, ертең қабылданбайды

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

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

Дұрыс жауап деп нені есептеу керек

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

Алдымен сұрақты қысқа тұжырымдарға бөліңіз. Бір сұрақтың ішінде көбіне екі-үш тәуелсіз факт болады, ал модель біреуін дәл тауып, екіншісінде қателесуі мүмкін. Әр фактіні бөлек тексеру керек.

AI Router мысалын алайық: «Платформа өз GPU-инфрақұрылымында қанша open-weight модель хосттайды және B2B-инвойсинг қай валютамен жүргізіледі?» деген сұрақта екі бөлек тексеру бар. Біріншісі — модель саны. Екіншісі — инвойсинг валютасы. «Көп модель, шоттар жергілікті валютамен шығарылады» деген жауап сенімді естіледі, бірақ тесттен өтпейді. Дереккөзде «20+ open-weight модель» және «ай сайын теңгемен» деп жазылған.

Әр факт үшін алдын ала шындық қай дереккөзден алынатынын көрсетіңіз. Ол БД өрісі, кестедегі жол, регламенттегі абзац немесе FAQ-тың нақты үзіндісі болуы мүмкін. Байланыс неғұрлым нақты болса, тексеру кезінде дау соғұрлым аз болады.

Жауап формасын бөлек белгілеңіз. Онсыз бір фактіні әртүрлі салыстыра бастайды. Әдетте бірнеше қарапайым түр жеткілікті:

• сан: 500+, 68, 20+
• күн: 2025-04-01 немесе 01.04.2025
• тізім: провайдерлердің, тарифтердің, құжаттардың атауы
• дәл фраза: сөздерді өзгертуге болмайтын тұжырым

Дәл жол әрқашан керек емес. Егер сұрақ өнім коды, келісімшарт нөмірі, мөлшерлеме, заңдық тұжырым немесе БД өрісінің мазмұны туралы болса, толық сәйкестікті талап еткен дұрыс. Ал мәтіндегі қарапайым факт болса, көбіне нормализация жеткілікті: артық бос орындарды алып тастау, күнді бір форматқа келтіру, регистрді елемеу, «20 +» мен «20+»-ті бірдей деп санау.

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

Егер эталонды «факт -> дереккөз -> формат -> салыстыру ережесі» түрінде жаза алмасаңыз, тест әлі шикі.

Эталонды қайдан алу керек

Эталонды команданың жадысынан немесе «шамамен соңғы» дереккөз нұсқасынан алуға болмайды. Ол тест күні деректердің нақты күйімен байланыстырылуы керек. Егер сұрақ құжатқа қатысты болса, файлдың дәл нұсқасын сақтаңыз. Егер кестеге немесе анықтамалыққа қатысты болса, сол күнге snapshot жасаңыз.

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

Өмірі тым қысқа деректер бар. Оларды жалпы жинақтан алып тастаған дұрыс немесе қысқа өмірлік жеке тесттерге бөлген жөн. Әдетте бұларға мыналар жатады:

• қоймадағы қалдық
• ағымдағы баланс
• өтінім статусы
• бүгінгі баға
• соңғы кіру күні

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

Әр сұрақтың жанында тек дұрыс жауапты емес, дереккөзге бағыттаушыны да сақтаңыз. БД жазбасы үшін бұл — жолдың id-і, кестенің аты және snapshot күні. Құжат үшін — файл атауы, нұсқасы, беті, абзацы, кестесі немесе автоматты түрде мәтін алынса, жолдар диапазоны.

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

Құжат нормалары мен БД-дағы тірі деректерді тек екі бөліктің де нақты уақыт белгісі болса ғана араластыруға болады. Әйтпесе жауап формалды түрде қисынды көрінеді, бірақ оны тексеру мүмкін болмайды. Мысалы, комиссия есептеу ережесі наурыздағы регламенттен алынған, ал мөлшерлеме маусымдағы кестеден тартылған. Мұндай эталон даулы болып қалады.

Продакшн жүйелерінде бұл RAG-та айқын көрінеді. Егер компания AI Router сияқты бірыңғай LLM-шлюз арқылы ішкі нұсқаулықтар мен клиент деректері бойынша жауаптарды тексерсе, дау көбіне модельден емес, дереккөздің әртүрлі нұсқаларынан туындайды. Әуелі дереккөзді бекітеді, содан кейін жауапты бағалайды.

Автоматты тест жинағын қалай құру керек

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

Дереккөз бойынша тексеруге кез келген сұрақ жарай бермейді. Алдымен құжатта немесе БД-да бір ғана анық жауап берілетіндерін таңдаңыз. Егер сұрақ «қайсысы жақсы» немесе «неге компания осы процесті таңдады» дегенге ұқсаса, автоматты салыстыру тез бұзылады. Ал «өтінімді өңдеу мерзімі қандай», «B сегментіне қай тариф қолданылады» немесе «18452 тапсырысының статусы қандай» деген сұрақтар жақсы келеді.

Әр тестті бір үлгіде сақтау ыңғайлы:

• сұрақ
• эталон жауап
• жауап табылған дереккөз
• салыстыру ережесі

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

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

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

Тест базасы өскен сайын оны жылдамдық пен тәуекел бойынша бөліңіз:

• промпт немесе ретривер өзгерген сайын іске қосылатын жылдам жинақ
• күнделікті прогонға арналған регрессиялық жинақ
• ең қиын әрі қымбат сценарийлер үшін релиз алдындағы жинақ

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

Жауапты құжатпен немесе БД-мен қалай салыстыру керек

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

Алдымен нормализациядан бастаңыз. Артық бос орындарды алып тастаңыз, мәтінді бір регистрге келтіріңіз, күндерді бір форматқа ауыстырыңыз, валюталарды бір белгілеуге түсіріңіз. Әйтпесе жүйе ұсақ нәрселермен дауласа бастайды: «15.01.2025» пен «2025-01-15» бір мағынаны білдіреді, бірақ жолдық салыстыру оларды әртүрлі деп санайды.

Сандарға келгенде қатаңырақ болған дұрыс. Санның өзін ғана емес, өлшем бірлігін де салыстырыңыз. «12» және «12 ай» — бір нәрсе емес. «500» дегеннің өзінде нақтылау жоқ болса, қауіпті: бұл 500 сұраным, 500 теңге немесе 500 модель болуы мүмкін. Егер бот тариф, лимит немесе мерзім туралы жауап берсе, санның қасында өлшем бірлігі тұрғаны дұрыс.

Дереккөзге сілтеме міндетті

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

Егер ішкі көмекші AI Router-да инвойсинг ай сайын теңгемен жүреді десе, тест тек сөйлемнің өзін ғана емес, қажетті құжат үзіндісіне немесе тариф анықтамалығындағы жазба ID-іне сілтемені де тексеруі керек. Сонда фактінің қайдан шыққаны көрінеді.

Жартылай сәйкестік және артық фактілер

Кемінде төрт статусты сақтау пайдалы:

• толық сәйкестік
• жартылай сәйкестік
• промах
• дереккөзден тыс артық фактілер

Жартылай сәйкестікті промахтан бөлек ұстау маңызды. «Деректерді ел ішінде сақтау» деген жауап мағынасы жағынан дұрыс, бірақ егер құжатта аудит-логтар, PII маскировкасы және rate-limit-тер де болса, ол толық емес. Бұл нөл ұпай емес, бірақ толық зачет та емес.

Қосылған фактілерді бөлек ұстаңыз. Модель көбіне сенімді жазып, құжатта немесе БД жазбасында жоқ детальдарды қосып жібереді. Егер дереккөз тек «ай сайын теңгемен» десе, ал жауап «айдың 5-іне дейін төлеумен» деп қоссa, бірінші бөлігі дұрыс болса да, бұл қате.

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

Бір сценарийдегі мысал

Банк қолдау чатын елестетіңіз. Клиент: «Осы айда тегін аударым лимитім қанша қалды және ол қандай ережемен есептеледі?» деп сұрайды. Жауап қысқа болуы керек: бір сан және бір ереже, бүкіл тарифті қайталау емес.

Деректер екі жерде тұр. Тариф туралы PDF-де: «Smart» пакетінде комиссиясыз аударымдар айына 300 000 теңгеге дейін қолжетімді, одан кейін комиссия 1%» делінген. Дерекқорда клиенттің ағымдағы күйі сақталған: ол осы айда 120 000 теңге пайдаланып қойған.

Бір тест қалай көрінеді

Тест карточкасында әдетте төрт өріс жеткілікті:

• сұрақ: «Маған қанша тегін лимит қалды және қандай ереже қолданылады?»
• құжат үзіндісі: «Комиссиясыз аударымдар айына 300 000 теңгеге дейін қолжетімді. Лимиттен асқаннан кейін комиссия 1%»
• БД snapshot-ы: monthly_limit = 300000, used_amount = 120000
• күтілетін жауап: «180 000 теңге. Айлық жалпы сома 300 000 теңгеден аспағанша, комиссиясыз аударуға болады»

180 000 деген сан құжаттан алынбайды. Оны клиент дерегі бойынша есептейді. Ал ережені керісінше модель логикасымен толықтыруға болмайды. Оны PDF-тен алып, тұжырымымен немесе нормализацияланған шаблонмен салыстыру керек.

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

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

Мұндай тәсіл жүйенің қай жерде бұзылғанын тез көрсетеді: PDF-тен фактіні алу ма, БД-ға сұрау ма, әлде жауапты соңғы жинақтау ма. RAG бағалауында бұл жауаптарды қолмен оқып, «дұрыс сияқты» деп қоюдан әлдеқайда адал.

Ең жиі қай жерде қателеседі

Көп адам тестті сұрақты таңдаудың өзінде-ақ бұзады. Дереккөз бірден емес, ескертпемен жауап беретін, екі жерде бірдей айтылған немесе мүлде бір ғана нақты қорытынды бермейтін сұрақ алады. Кейін модель рұқсат етілген бір нұсқаны таңдайды да, тест оны қате деп есептейді. Дереккөз бойынша тексеру үшін мұндай кейстерді бірден алып тастаған дұрыс.

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

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

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

Нормализация да бөлек тақырып. Онсыз тесттер мағына өзгермейтін ұсақ нәрселерге дауласа бастайды. Әдетте алдын ала бір форматқа келтірген дұрыс:

• компаниялар мен өнім атауы
• күн форматтары
• валюталар мен сандар
• кодтар, статустар және қысқартулар

Қарапайым мысал: БД-да тариф PRO_UNL деп сақталған, құжатта ол Pro Unlimited деп аталады, ал жауапта модель «Безлимит Pro» деп жазады. Егер осы нұсқалардың бәрін бір канонға келтірмесеңіз, тест жоқ қате жерде қате көрсетеді.

Мұндай қателер бірнеше модельді салыстырып, сапаны batch бойынша есептейтін командаларда жиі кездеседі. Егер екіұшты сұрақтарды алып тастап, эталонды қысқа жазып, БД snapshot-ын бақылап, қате түрлерін бөлек ұстасаңыз, тест есебі әлдеқайда адал болады. Сонда нақты не бұзылғаны көрінеді: іздеу ме, генерация ма, әлде салыстыру ережелерінің өзі ме.

Іске қосар алдындағы қысқа чек-лист

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

• Әр сұрақ үшін бір ғана шындық дереккөзін таңдаңыз: нақты құжат, кестенің нұсқасы немесе SQL-таңдау. Егер жауапты екі түрлі жермен дәлелдеуге болса, тест даулы болады.
• Эталонды бір қысқа тұжырыммен жазыңыз. Эталон «клиентке жақсы жауап» болмауы керек. Ол фактіні тексеруі тиіс: күнді, соманы, статусты, өріс атауын немесе дәл цитатаны.
• Тесттің қасына салыстыру ережесін сақтаңыз. Бір жерде дәл жол керек, бір жерде қажетті валютадағы сан сәйкес болуы керек, бір жерде екі тұжырым нұсқасының бірін қабылдауға болады.
• Жеңіл мысалдармен ғана шектелмеңіз. Шекаралық жағдайлар да керек: бос өріс, құжаттың ескі нұсқасы, ұқсас атаулар, дерекқордағы бір-біріне ұқсас екі жазба.
• Дерек нұсқасын бекітіңіз. Команда бір аптадан кейін де сол бір құжаттар мен сол бір выгрузкада дәл сондай нәтиже шығара алуы керек.

Көбіне екінші пункт бұзылады. Адамдар эталонды тым кең жазады да, модель оны әдемі мәтіннің есебінен өтіп кетеді. Егер сұрақ «келісімшарт бойынша төлем мерзімі қандай?» болса, эталонды «10 банк күні» деп жазып, артық детальдың керегі жоқ екенін бөлек көрсету жақсы. Сонда құжат бойынша тексеру фактіні, стильді емес, бағалайды.

Әр тестке қысқа комментарий қосқан пайдалы. Бір сөйлем жеткілікті: «limts_2025_02 кестесінен тек лимит мәнін салыстырамыз» немесе «модель 4.2-тармақтағы статустың дәл атауын қайтарса, жауапты қабылдаймыз». Бұл команда: модель ме, тексеру ме, әлде тесттің өзі ме — кім дұрыс деген дауда көп уақыт үнемдейді.

Егер сіз ішкі регламенттер немесе БД деректері бойынша RAG бағалау жүргізсеңіз, мұндай чек-лист күрделі метрикадан да маңыздырақ болуы мүмкін. Ол бірден модельдің дереккөзді шатастырғанын, ретривердің басқа фрагмент әкелгенін немесе қате тесттердің өзінде жатқанын көрсетеді.

Продакшанда әрі қарай не істеу керек

Бір сәтті прогон ештеңені білдірмейді. Жұмыс жүйесінде жауаптар ұсақ өзгерістерден кейін-ақ ауытқиды: промпт ауысты, ретривер жаңарды, метадеректер бойынша фильтр қосылды, модель ауысты — және кешегі дұрыс жауап енді дереккөзбен салыстырудан өтпей қалады.

Сондықтан тесттерді кәдімгі релиз циклына енгізу керек. Жауапқа әсер ететін кез келген өзгеріс сол бірдей тексеру жинағын іске қосуы тиіс. Әйтпесе команда бұзылғанын тек пайдаланушы шағымынан кейін ғана біледі.

Жалпы балл пайдалы, бірақ тым дөрекі көрсеткіш. Егер жүйе 82% жинаса, шешім қабылдау үшін бұл аз. Қай жерде қателескенін көру керек: БД-дан дұрыс емес жолды алды ма, санды түсіріп қалды ма, өлшем бірліктерін шатастырды ма, мән ойлап тапты ма, әлде екі дереккөзді бір жауапқа біріктіріп жіберді ме.

Мұндай талдау алдымен нені жөндеу керек екенін тез көрсетеді. Кейде мәселе модельде. Бірақ жиі себеп әлдеқайда қарапайым: нашар chunking, артық SQL join, қате post-processing немесе салыстыру ережесінің тым жұмсақ болуы.

Үш бөлек тест жинағын ұстаған ыңғайлы:

• тек құжат бойынша жауаптарға арналған
• тек SQL және БД-дағы басқа деректер бойынша жауаптарға арналған
• модель құжат пен кестені қатар оқитын аралас сценарийлерге арналған

Оларды бір жинаққа араластыру әдетте зиян. Орташа балл бұзылуларды жасырады. Құжаттар бойынша жүйе жақсы жұмыс істеп, ал SQL жағында фильтрлер мен күндерді тұрақты шатастыруы мүмкін.

Егер команда көп модель мен провайдерді салыстырса, стендті күрделендірмеген дұрыс. Бір ғана OpenAI-үйлесімді шлюз арқылы сол бір жинақты өткізу жеңілірек. AI Router жағдайында base_url-ді api.airouter.kz-ке ауыстырып, содан кейін әр провайдерге бөлек орау жасамай-ақ, сол бір SDK, код және промпттарды әртүрлі модельдермен сынауға болады. Бұл уақытты үнемдейді және салыстыруды таза етеді.

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

Егер тест жинағы кодпен қатар өмір сүріп, әр өзгерістен кейін іске қосылып, қате түрін көрсетіп тұрса, команда сезіммен таласпайды. Қай жауап құжатқа немесе БД-ға сәйкес келгені, қайсысы келмегені бірден көрінеді.