…и я решил, что я буду изучать Playwright. Почему я буду изучать именно Playwright, а не автоматизацию тестирования ПО вообще — ну так в вакансиях пишут, что надо уметь в этот ваш Плайвригхт.

Так-то я хз, как оно правильно читается, ха-ха-ха, но инглиш иззэ кэпитэл оф грэт бритэн, это я досконально знаю ещё со школы. Советское образование всегда было лучшим в мире!

А что приличному человеку нужно для успешной учебы?! Ментор нужен, конечно же. Пусть все, как дураки, бегают на общие курсы, а я возьму себе индивидуального ментора, он мне обстоятельно всё объяснит, и это будет моим конкурентным преимуществом. Мы будем с ним раз в неделю созваниваться (два раза, ладно) и он будет советовать мне, что учить, а что нет смысла учить, какие именно страницы в каких именно книгах читать, и будет спрашивать, как у меня идут дела, и я как разовьюсь! Ого! Да-да-да!

Ну и вот я вам пишу, драгэ романтикэ товарэшул молдовенескул тестировщик, а давайте вы будете мне ментором по Playwright. И по API. И по REST, чтобы три раза не вставать. Давайте раз (два раза?!) в неделю созваниваться, вы будете мне обстоятельно всё объяснять… это в ваших же интересах! Доведите меня до трудоустройства, и я сразу же вам заплачу за обучение с первой же зарплаты. Я знаю, что у начинающего зарплата будет небольшой, 1500 или 1700… ладно, 1200 долларов, я не жадный (для начала). И я сразу вам заплачу 200 евро, не обижу. Вам там, в Молдавии, много не надо, я смотрел видео либерально-уважаемой Натановны Эйдельман и знаю всё про вас и вашу страну.

Он, конечно, попытался накрутить себе цену и сбить меня с пути истинного. Начал спрашивать, а зачем вам вообще эта автоматизация, может быть, вы сперва научитесь (хотя бы!) тестировать. Или программировать, хотя бы, на том же JS. На что только не пойдут эти молдаване ради лишних 200 долларов…

Но позвольте милостивый государь, говорю я ему, я же знаю, что тестировать — слишком легко, а программировать — слишком нелегко. А я нашел хитрый способ пройти невредимым посередине — неведомая автоматизация манит меня и ждёт, когда я её открою для себя… Давайте же, ну!

А он говорит — то, чего вы хотите, звучит логично, но на деле нелогично. Вы только умеете переустанавливать винду при любой проблеме и мечтаете купить мак, якобы там ничего переустанавливать не надо… Но вы даже в настройки системы никогда не заходили! Как вы будете скрипты в Playwright писать, если вы локатор в html не найдете, даже если вам на него укажут пальцем указательным?! Почему бы вам не изучить html для начала? И на Linux посмотрите, там тоже основы несложные…

Каюсь, зря я ему про всё это рассказал, что умею только переустанавливать винду и мечтаю купить в Шымкенте дорогой мак занедорого, и что ничего не знаю про html. Слишком я откровенный, что поделать, страдаю человеколюбием. Мы, хабаровские, всегда от этого страдаем.

Вообще я слегка уставший, но изо всех сил стараюсь оставаться вежливым, ведь с молдаванами надо разговаривать как с животными — ласково, без резких движений, а то испугается и шмыгнёт в кусты… Ну я ему и говорю, мол, а зачем мне эти твои глупые html и мануальное тестирование?! Ты такой странный, такие дурацкие предложения предлагаешь… Да ты меня НЕ СЛЫШИШЬ! У мануального тестирования нет будущего, у программирования нет будущего, в будущем будут одни только клауды, я знаю… Мне нужно научиться плайрайт, или как его там! Ментор мне нужен, мееееентоооор!

Он уже занервничал, начал говорить про отвлеченное, мол, а вот вы про клауды говорите — какие именно? Вы про Cloud computing или про семейство ой-ай моделей Claude? А я ж не знаю, о чем он лопочет… Всякие будут, веско говорю. Оно сегодня так развивается, что ай-ой, завтра вообще будет ой-вэй. И пока все вы будете ой-ой, я буду спокойно автоматизировать. Месяц-другой. А потом переключусь на что-то поинтереснее…

А он всё не угомонится, он меня уже с фланга обходит — а хотите, мы просто поговорим о том, как IT устроено? У меня день свободен, я машине под лобовое стекло полиуретановый герметик загнал, спешить некуда. Могу вам рассказать, с чего всё начинается и где там нужен Плэйрайт, а дальше вы сами решите, с чего вам начать…

Мммм, нет, я уже всё понял, не хочет этот полиуретан поработать индивидуальным ментором. Не хотят люди деньги зарабатывать, не хотят… Ну и не надо. Я совсем уже почти договорился с одним бывшим программистом из дома напротив, так он мне устроит краткосрочные курсы по Playwright. Десят тыщ тенге за одно занятие, ну и что? Это недорого. Занятия утром и вечером, а в обед я буду заниматься дома бесплатно, я всегда имею возможность заниматься дома бесплатно и доставать свежие версии Playwright и другие полезные скрипты. В конце концов, если мне покажется недостаточно, так я всегда смогу прикупать нужное в даркнете. Пусть всякие дураки берут учебные курсы задорого. Вот я вижу, вы всегда берете учебные курсы задорого. А я могу брать их же с рутрекера, слитые, бесплатные, у меня там есть аккаунт, и они даже слитые будут лучше, чем ваши онлайн и задорого. Ваши курсы битые, а у меня будут целые, хорошие, проверенные временем курсы! Вы человек ещё молодой, вы ещё не понимаете, что главное в жизни — это устроиться с хорошими образовательными курсами… Ведь мир заполонили дурные, своекорыстные люди! Да господи же боже ж мой, ну нигде же нет от них спасения! Куда ни сунься — везде ведь они! Везде блат, по знакомству можно достать всё, а без знакомства человек ничто — особенно, если он не сумел как следует устроиться по образовательному аспекту…

На том и разошлись.

Весь последний абзац — мой вольный парафраз из Стругацких, «Рукопись ОЗ», раздел 23-25, спич Матвея Матвеевича утром на кухне. Соррянчики, не удержался, очень уж было похоже.

А кто виноват?

Я, конечно же.

Человек проделал сложную работу и, как говорит тащ. военврач Курпатов, «оказался в конструкции» в которой он нашел изящное решение своей проблемы. Ему не нужно ни тестировать, ни программировать, он уже решил, что ему просто нужно освоить Playwright. Он всё продумал, он ВСЕХ перехитрил, он сумел выехать, он молодец, осталось только найти кого-то, кто ему покажет, что где нажимать и чтобы светлое будущее наконец-то настало.

А тут я со своим ненужным мнением, пытаюсь ему объяснить что-то, что превышает его уровень понимания темы (винду переустановить…) на невозможном для него уровне объяснения. Мог бы я поменьше рассказывать про абстрактно-игристое?! Вы же не поэт, к чему вам смотреть, как ветер колотит воду по чреву пепельно-сизых финских волн!?

Но я исхожу из того, что нельзя отказывать голодному в еде, а интересующемуся в объяснении. И если я могу что-то объяснить, то давай объясню, тебе потом проще будет понимать, как всё устроено и принимать взвешенные решения.

Я, конечно же, сказал, что если вы вообще ничего не знаете о том, как делают ПО, Playwright сам по себе не имеет смысла, что там надо будет смотреть в код html и писать команды, мол, значение этого элемента сохранить в переменную и сравнить с ожидаемым результатом. Например:

let totalPrice = document.querySelector('#totalPrice').textContent;
let expectedResult = 100;

if (Number(totalPrice) === expectedResult) {
console.log("Total price: PASS");
}

Вам тут всё понятно? В переменную totalPrice cохранить значение из элемента #totalPrice в виде plain text. Перевести этот plain text в число. Сравнить число из переменной totalPrice со значением из переменной expectedResult. Всё понятно человеку, который не имеет понятия, что такое html, переменные и прочие абстрактные абстракции? Оказалось, что нет. И что это всё, очевидно, лишнее. Зачем это всё?

Почему же я просто не сказал ему «Нет»? Человек понял только то, что его пытаются разубедить, ему показалось, что над ним издеваются. Человек хочет просто научиться Playwright. Он же не спрашивал, как оно всё устроено. Может быть, надо было просто показать ему Playwright?

Это проще показать или объяснить?

В основе всего тестирования ПО лежит простой принцип — залезь в настройки, поменяй их и посмотри, что получится. В древние времена тестировщиками становились люди, которые в принципе ВСЕГДА ковырялись в настройках своих компьютеров, потому что вот так в те времена всё было устроено. Сегодня всё иначе, интерфейсы и железо стали стабильно-предсказуемыми, и уже поколения людей никогда не заходили в настройки системы, и не намереваются туда заходить, ведь там всё такое сложно-непонятное, а вдруг я что-то сломаю, ненене, не буду это открывать вообще. И в настройки отдельных программ они тоже не заходят, потому что если программа не делает то, что надо, уже проще установить другую программу.

Впервые я увидел это году в 2017-ом, наверное. Коллега установил какой-то софт для записи экрана, и тот софт нарисовал ему на экране квадрат — область, содержимое которой попадет в видеозапись. А коллега хотел записать сразу весь экран, а не квадрат. Он это ПО сразу удалил и пошёл искать аналоги.

Я это ПО у себя установил, увидел упомянутый квадрат, ухватил его за край курсором мыши и понял, что область видеозаписи можно спокойно растянуть, передвинуть, и вообще можно нажатием одной клавиши переключиться в режим записи всего экрана — я просто посмотрел в настройки софта… И написал коллеге, мол, it works, this gizmo is adjustable! Переключись в другой режим, нажми такую-то клавишу.

Коллега ответил, что нененене, этот софт неадекватный, он скоро найдёт другой.

Ну ок.

Сам по себе Playwright — это фреймворк для написания кода, через который можно будет вызывать из небытия браузер и в этом браузере эмулировать действия пользователя, тыкать кнопки, пролистывать страницы, кликать по ссылкам и проверять наличие каких-то элементов или содержимое этих элементов. И тут надо бы объяснить, что такое фреймворк…

А чтобы взаимодействовать с элементами в коде html надо хотя бы немного разобраться с этим самым html. Начнём с того, что это не язык программирования, это язык логической разметки текста (Hypertext Markup Language). Там дальше есть неэпически запутанные моменты и нюансы, но в основе — нет ничего сложного, смотрите….

Чтобы разобраться с html, надо написать свой код, своими руками, полностью в отдельном файле, и открыть это всё в браузере и посмотреть, что получилось. Сделал три страницы, вывел текст, вывел изображения, соединил эти три страницы через линки — увидел и понял, как оно работает.

Заодно посмотришь, по нраву ли тебе айтишная работа — колотить код и смотреть, как он вроде бы складывается в нужное, а вот тут не получается, а вроде бы всё правильно написал, а что-то не так, а что именно не так, а почему оно, бляха, не работает… ааааа, вот почему оно, бляха, не работает, а я сделаю вот так, и оно, бляха, заработало, но не совсем так, как мне хотелось… И вот так целый день.

C’mon, do-something…

А потом приходят какие-то дементоры и говорят, что это мы отменяем, требования поменялись, тут будет фича вообще без требований, а тут мы еще не знаем, а вот это надо срочно переделать, а вот это не трогать. И теперь оно всё никак не заработает, потому что тут убрали, там добавили, и в целом вроде всё просто, но…

И вот так целый день.

А когда понял, как устроены элементы в html — можно смотреть и понимать, как их делают программисты. Что есть параметры. Что есть классы. Что оформление элемента вынесено в общие файлы, потому что так устроен CSS (Cascading Style Sheets), а идею, силу и особенности CSS надо объяснять отдельно. Потом надо объяснить, что ты можешь открывать исходный код любого сайта и смотреть, как он устроен, и понимать, как с этим всем можно работать.

Пришло время идентифицировать элементы в коде, и это можно делать разными способами… которые во фреймворке Playwright реализованы так и эдак, и к ним можно обращаться или так, или эдак…

Одновременно с изучением html есть возможность хотя бы поверхностно потрогать траву ладонями основные принципы тестирования ПО. Playwright нам нужен не сам по себе, а для выполнения тестирования ПО в браузере руками робота, условно говоря. А чтобы тестировать, надо не тыркать элементы в html по-отдельности, а надо продумывать (распознавать логикой) сценарии, по которым будущие пользователи будут пользоваться нашим приложением.

О, самое время рассказать о том, как наши html-страницы становятся частью приложения, которое работает на сервере… И в чем разница между сайтом и сервером.

Наверное, в том же 2017-м один из наших джунов, который уже год тестировал проект, спросил, а где именно находится наше приложение? Одни говорят, что оно на сайте, другие — что оно на сервере.

Ну, ок. Объяснил.

Playwright умеет автоматически запускать и контролировать сервер, на котором находится тестируемое приложение. И оно может быть на удаленном сервере, а может работать на локалхосте. Пришло время объяснить понятие localhost…

Если понял за 127.0.0.1 и 192.168…, то вернемся к Playwright. Это фреймворк, который позволяет через код программно управлять браузером. Его придумали программисты, и это не единственный фреймворк подобного рода. И чтобы им управлять, вместе с изучением html и тестирования надо посмотреть в основы JavaScript (стал основным языком работы с элементами в браузере) или Python (многие считают его норм для начинающих и таки почему бы и нет). Кажется, что для этого надо сперва научиться программировать, но это только кажется. Чтобы программировать, надо не код писать, а думать как программист. Можно научиться писать код и не научиться программированию.

Кажется нелогичным, но это логично.

Я знаю английский язык, но от этого я не стал англичанином.

Можно научиться играть на пианино и не быть музыкантом, для этого нужен природно-обострённый слух и надо освоить математическую грамоту музыкального мышления.

Вместе с основами html спокойно учим основы программирования на примере JS или Python. Само по себе это знание не сделает нас программистами. Да и вряд ли мы продвинемся дальше основ. Кто-то да, кто-то нет, заранее неизвестно, что и у кого будет получаться. Расчехляем простую рабоче-крестьянскую логику, смотрим на чужой код и разбираемся, как там все устроено. Сперва на простых примерах, затем на всё более сложных.

Вгрызаемся дальше. В командной работе надо будет пользоваться тем языком, которым уже пользуются другие однокомандники. Да, в одиночку можно писать скрипты для Playwright на JavaScript или на TypeSсript или на Python или на ассемблере. Но если в рабочей группе все пишут на Go — ты тоже должен писать скрипты на Go, это не обсуждается. Надо понимать основные принципы языков программирования, а не привязываться к синтаксису.

Далее оказывается, что для работы с общей кодовой базой надо разобраться в том, где она лежит, как её взять и как в неё добавлять свою работу — разбираемся с git (заодно глянем и на svn, не помешает понимать эту тему в принципе, а не в частностях). А для этого надо разобраться с тем, что такое файлы, где они лежат, как с ними работает твоя операционная система, а это вряд ли будет Windows. Давай объясню, как работает Linux…

А как работает обмен данными между серверами? Рассказать про API? Показать, что это само по себе, откуда взялось и как его трогать? Нет, я не буду ограничиваться только «я покажу тебе Postman» — надо понимать, что такое API вообще, а не отдельный софт, через который можно взаимодействовать с API.

И чего мы привязались к API? А реляционные базы данных кого уже давно ждут? Объяснить, почему они называются реляционными?

C’mon, just do something…

Я понимаю, что эта штука делает в принципе.

Я понимаю, как это устроено в принципе.

Я понимаю, как найти локатор на странице в принципе.

Я понимаю, как обезопаситься от того, что этот локатор в будущем может поменять свое местоположение или переименоваться или стать видимым только после выполнения какого-то действия на странице — в принципе.

И вот теперь мы берём Playwright и спокойно его используем, и всё будет работать. C’mon, это уже не так уж и сложно! Заморочено, конечно, и много всякого, но в основе своей не сложно. Просто это «длинное» знание, которое приходит медленно, после изучения, привыкания и понимания простых принципов. Это не то, что можно показать на экране и сказать «Вот эту кнопку нажимай, а эту не надо трогать».

А если я скажу вам сразу «Нет»? Ну, вам же легче будет?

Привет каждому, кто приходил ко мне с запросом «Научите меня тестировать…», а я в ответ говорил «Ок. Сделайте сайт, три страницы, давайте посмотрим, как получится и зайдёт ли оно вам…» — может быть, вы уже самостоятельно попытались и поняли, что само по себе тестирование не очень сложное занятие, но сперва надо освоить некоторые очень неочевидные основы. Надо будет лезть в настройки системы и отдельных программ, смело что-то перещелкивать и понимать, что после этого поменяется, и отвечать за результат. И в какой-то момент обязательно надо будет понять разницу между сайтом и сервером.

Тестирование само по себе — абстрактная тема, которую рукам не пощупать. Всё IT работает на абстракциях. Учиться IT — изучить абстрактные темы, для которых в быту нет и не может быть объяснений или примеров, их надо придумывать. Но можно научиться взаимодействовать с абстракциями, можно наполнять их смыслом, придавать им смыслы, перехватывать изменение смыслов… Можно понимать, что перед тобой условные переменные, и что данные в этих переменных бывают разных типов. Нужно тестировщику это знание или нет? Или оно подразумевается, потому что это база нашей профессии?!

Так что да, иногда надо сразу говорить «Нет», а не пытаться объяснить, что три тысячи лет назад один древнегрек возвращался домой с рынка (по-ихнему агора) и посмотрел на звёзды…

Our whole universe was in a hot dense state,
Then nearly fourteen billion years ago expansion started. Wait…

Если в компании появился ИИ‑помощник, чат‑бот или поиск по внутренней базе знаний, следующий логичный шаг – убедиться, что он работает надёжно. LLM часто выдают ответы уверенно, но это не гарантия точности: ошибка может возникнуть на любом этапе RAG‑пайплайна: при поиске контекста, его подготовке или при генерации итогового ответа.

Важно регулярно тестировать RAG-системы с пристрастием, чтобы минимизировать риски некорректной выдачи данных. 

Читайте, чтобы узнать на что обратить внимание в первую очередь, какие метрики отражают реальную картину и как выстроить регрессионную и нагрузочную проверку так, чтобы изменения в модели, промптах или базе знаний не приводили к деградации качества.

Поскольку материал объёмный, советуем добавить страницу в закладки, чтобы возвращаться к нужным местам. Руководителю проекта хватит разделов 1, 2, 8 и 13 – они дадут понять, во что он ввязывается и сколько времени это займёт. Тест‑инженерам пригодятся и все остальные.

Вот приборная панель одного корпоративного ассистента за неделю до того, как его пришлось отключить. Все автоматические метрики зелёные, но проект провалился. 

Три из четырёх метрик вводили в заблуждение.

Ассистент работал с внутренней базой банка. Говорил гладко, не придумывал цифры, всегда ссылался на документы – поэтому метрика faithfulness показывала хорошие 0,94. Но была проблема: в индексе лежали сразу две версии тарифного сборника – старая и новая. Ретривер то и дело вытаскивал старую версию, и модель честно пересказывала её – то есть, по сути, неправду.

На бумаге всё выглядело идеально. А на деле каждый шестой ответ сбивал клиента с толку. При этом метрика этого не показывала: она проверяла, насколько ответ соответствует тому, что попало в контекст, а не тому, насколько он правдив.

Такие ситуации встречаются сплошь и рядом. Команда собирает RAG за полтора месяца, а потом полгода не может запустить его в полноценную работу и сама не понимает, в чём загвоздка.

Давайте разберёмся: какие показатели действительно важны, какими инструментами их измерять, какие значения считать нормой – и что делать, когда метрики друг другу противоречат.

Раздел 1. Почему привычное тестирование не подходит для RAG-систем

Когда QA‑специалист, привыкший к обычному бэкенду, берётся за тестирование ИИ‑системы, он сразу упирается в одну проблему: тут нельзя просто сравнить ответ с эталоном. Нет одного чёткого ожидаемого результата – есть целый набор допустимых вариантов. Один и тот же запрос может трижды выдать разные тексты – и все три будут правильными. А может быть так: два ответа верные, а третий выглядит правдоподобно, но при этом с ошибкой.

Дальше всплывают ещё три неприятные проблемы:

1. Локальная правка ломает то, чего вы не касались. Например, подкрутили промпт, чтобы система перестала выдумывать сроки, – и она вдруг начала отказываться отвечать на половину обычных вопросов.
2. Качество и производительность тесно связаны. Увеличили top‑k с 5 до 15, чтобы охватить больше вариантов, – а в итоге латентность выросла вдвое, да и точность, скорее всего, упала: модель начала «тонуть» в лишнем шуме.
3. Система может деградировать сама по себе. Индекс пополняется, документы со временем устаревают, а вендор тихо обновляет модель под тем же именем эндпоинта. Вы ничего не меняли, а качество всё равно снижается.

Отсюда главный организационный вывод, который Barnett и соавторы сформулировали жёстко: валидацию такой системы нельзя сделать до релиза. Она возможна только в эксплуатации, а устойчивость не проектируется заранее, а накапливается со временем¹ . Это не отговорка, а требование к процессу. Нет замкнутого цикла: продакшен, датасет, регрессия – нет тестирования LLM. Есть приёмка демо. 

Тестирование LLM – это не про проверку отдельных ответов. Это про создание надёжной системы измерений, которая останется полезной, даже если поменяется модель, изменится промпт или база знаний вырастет в десять раз. 

Раздел 2. RAG-система по слоям

Самая частая ошибка – оценивать RAG как единое целое. В итоге вы получаете одну цифру, которая потихоньку падает, а понять, в чём проблема, невозможно. Качество снизилось – и что с этим делать? Между вопросом пользователя и готовым ответом скрывается восемь разных компонентов, и на каждом из них могут быть сбои по разным причинам.

Если оценивать систему целиком, все эти проблемы перемешиваются, и понять, где именно прячется сбой, становится невозможно.

Пример: производственная компания, поиск по техрегламентам.

Recall@10 держался на уровне 0,52. Полгода перебирали модели генерации: две коммерческие, три открытые, пробовали дообучение. Разница – единицы процентов. И неудивительно: лечили точку 8, а сломаны были точки 2 и 3. Разметили 60 вопросов с привязкой к местам в документах.

Оказалось, что 40% эталонных фрагментов физически отсутствовали в индексе: таблицы допусков из PDF парсер разложил в бессмысленную строку чисел. Часть ответов разрывалась между кусками – резали по 800 символам без оглядки на структуру документа. Починили парсинг таблиц, стали резать по разделам, добавили BM25 и реранкер на кросс-энкодере. Recall@10 вырос до 0,87, faithfulness подтянулась сама – с 0,71 до 0,89. Модель не трогали вообще.

Отсюда правило: прежде чем винить модель, убедитесь, что нужная информация вообще попала в промпт. Две трети жалоб решаются на этапе парсинга, разбивки на фрагменты и поиска. 

Раздел 3. Без золотого датасета надстройки не работают

Без размеченного набора вопросов с эталонными ответами вы не сможете ни отследить ухудшение качества, ни сравнить разные модели, ни нормально обсудить с заказчиком, насколько хорошо работает система. Вместо фактов будет просто спор, где побеждает тот, кто громче говорит.

Что должно быть в одной записи:

• Вопрос ровно в той форме, как его мог бы задать реальный человек – с опечатками, сокращениями и всеми «а если по‑другому».
• Эталонный ответ от эксперта. Не какой‑то безупречный текст, а чёткий список фактов, которые обязательно должны прозвучать.
• Ссылки на конкретные куски источников. Они помогают понять, в чём проблема: система не нашла нужную информацию или нашла, но плохо её пересказала. Без таких ссылок не получится разобраться, где именно случился сбой.
• Срез: тип вопроса, подразделение, уровень сложности.
• Ожидаемое поведение: ответить, запросить уточнение или честно сказать, что такой информации нет. Это очень важно: если в наборе нет вопросов, на которые правильный ответ – «в базе этого нет», весь набор почти бесполезен.

Сколько нужно записей?

Допустим, вы хотите понять, насколько хорошо система отвечает: скажем, примерно в 80% случаев, плюс‑минус 5%, и чтобы результат был надёжным (с вероятностью 95%). Для этого понадобится около 250 примеров. Опыт с бенчмарками это подтверждает: стабильная картина появляется где‑то на 250–500 кейсах. А если взять меньше сотни – вы будете видеть случайные колебания и принимать их за реальный прогресс.

Только не надо думать, что нужно собрать по 250 кейсов для каждого среза – так вы просто утонете в разметке. Держать точность в ±5% дорого и трудоёмко. Для того чтобы вовремя замечать, когда качество падает, вполне хватает ±10% – а для этого достаточно около 60 примеров.

Срезы бывают двух видов. По крупным срезам вы смотрите общую долю удачных ответов и оцениваете её с учётом погрешности. А редкие, но очень важные случаи лучше вообще не мерить статистикой: сделайте их обязательными (must‑pass) и проверяйте вручную. Тут всё просто: либо ответ верный, либо нет.

Срезы важнее объёма

Средняя оценка по датасету – почти бесполезная цифра в отчёте. Показатель 0,86 может значить разное: либо везде стабильно 0,86, либо, например, 0,95 на простых фактах и всего 0,41 на вопросах с расчётами. Это два совершенно разных уровня качества продукта.

Разбивать данные стоит минимум по четырём параметрам: тип вопроса (факт, сравнение, расчёт, процедура, отсутствующая информация), раздел базы, «грязность» формулировки и цена ошибки. Отдельно держите список must‑pass – 20–40 вопросов, провал по любому из которых сразу блокирует релиз, без обсуждений.

Откуда брать данные?

Есть три источника, и они дополняют друг друга, а не заменяют:

• Реальные обращения из тикетов и поисковых логов – так вы увидите, как пользователи формулируют запросы на самом деле.
• Экспертные сценарии – то, что обязано работать всегда, даже если таких вопросов ещё никто не задавал.
• Синтетические данные (например, с помощью RAGAS) – они помогают закрыть объём и обеспечить покрытие базы документов.

Важное про синтетику: она часто создаёт вопросы, которые почти дословно повторяют текст документа. Такие легко решаются простым совпадением и сильно завышают показатель recall – иногда на десятки процентных пунктов. Обязательно перефразируйте такие вопросы и вручную проверьте хотя бы 10%. Лучше подстраховаться сразу.

Признаки, что ваш датасет не отражает реальность:

• В нём нет вопросов, на которые правильный ответ – «не знаю».
• Все вопросы написал один человек за один вечер.
• Эталонные ответы готовил тот же человек, который писал системный промпт.
• Датасет три месяца не обновляли, хотя в базу добавили 4000 документов.
• Он хранится в Google‑таблице без версий – никто не может сказать, какая версия использовалась для какого релиза.

Раздел 4. Метрики поиска – база для оценки RAG

Хорошая новость: ретривер (тот самый каталог данных) тестируется как обычная поисковая система, тут за нас всё придумали ещё в девяностые. Метрики детерминированные, дешёвые, считаются за секунды и не требуют ни одного вызова LLM.

Три эксперимента, которые реально улучшают показатели. Сделайте их до того, как начинать возиться с моделью.

1. Гибридный поиск. Векторный поиск плохо ловит точные обозначения – артикулы, номера ГОСТов, коды услуг, редкие термины. Зато с этим отлично справляется BM25. Если объединить результаты (обычно используют RRF), на корпоративных базах на русском языке recall стабильно растёт. Причина простая: в половине реальных запросов люди указывают точные идентификаторы.
2. Реранкер. Поставьте кросс‑энкодер поверх первых 50 результатов – это самый недорогой способ поднять nDCG. Обработка занимает всего десятки миллисекунд и почти всегда себя оправдывает.
3. Метаданные и права доступа. Добавляйте фильтры по дате, версии, подразделению. Параллельно проверьте, нет ли утечек: обязательно включите в обязательные тесты ситуацию, когда пользователь с одной ролью пытается получить доступ к документам другой роли.

И про длину контекста. Хочется добавить побольше текста в запрос – вроде как модель лучше разберётся. Это частая ошибка. Ещё в 2023 году описали эффект «потерянного в середине»²: информация из середины длинного контекста хуже учитывается. А исследование context rot от Chroma подтвердило: чем длиннее входной текст, тем ниже качество ответов – это верно для всех проверенных моделей. Даже миллион токенов не убирает проблему, а лишь сдвигает момент, когда качество начинает падать³. Подбирайте количество фрагментов (k) опытным путём: почти всегда есть граница, после которой лишние куски только ухудшают и точность, и скорость работы.

Раздел 5. Пять типов галлюцинаций: чем они отличаются и как их ловить

Слово «галлюцинация» в требованиях к проекту – верный признак, что требования ещё не проработаны. За этим термином скрывается как минимум пять разных дефектов, и для каждого нужно своё решение.

Пятый тип – самый коварный: его не видят метрики без эталона. Именно он был в примере из начала статьи. Если ваша база обновляется чаще раза в квартал, добавьте отдельную метрику – «доля ответов на неактуальной редакции». Это простая проверка на метаданных – она не требует ни одного вызова модели и обходится недорого.

Пример: банк, ассистент оператора контакт-центра

Это тот самый случай, с которого началась статья. Когда базу переиндексировали, новые версии тарифов загрузили рядом со старыми, а старые не удалили. В итоге около 17% фрагментов в поиске относились к уже недействующим редакциям. Векторный поиск спокойно их выдавал: по тексту они даже лучше подходили к запросам – ведь написаны более официальным, «казённым» языком. 

Проставили valid_from и valid_to в метаданных, ввели жёсткий фильтр по дате на этапе поиска, добавили в датасет 45 вопросов с изменившимися формулировками и метрику свежести. Доля ответов по устаревшим источникам за две недели упала с 17% до 0,4%. Faithfulness не изменилась – и это нормально: она и не должна была меняться, ведь проблема была не в искажении фактов, а в том, что система брала данные из старых документов. 

Раздел 6. Четыре способа бороться с галлюцинациями

В индустрии выделяются четыре основных подхода. Они отличаются по стоимости – разница может быть в два раза и больше. Выбирать стоит тот, который укладывается в ваш бюджет при нужном объёме прогонов. 

В статьях про Lean в тестировании часто показывают только витрину: перечисляют семь потерь, описывают DMAIC, приводят цифру в 3,4 дефекта на миллион. И дело не в том, что эти данные неверны. Такая подача не помогает руководителю ответить на самый важный вопрос: с чего начать именно в его команде и что делать дальше.

Методы Lean нередко подают как разные варианты на выбор, хотя на деле это последовательные стадии одного цикла. Мы покажем, как они связаны между собой.

Три японских термина – не просто красивые слова, а чёткая цепочка: она подсказывает, в каком порядке устранять проблемы и выстраивать улучшения.

В западных разборах всё крутится вокруг муда и её семи видов, а мура и мури упоминают будто для галочки. В Toyota, где и были разработаны принципы бережливого производства, подход другой: сначала выравнивают поток задач – (убирают мура). Это снимает перегрузку (мури), и только потом борьба с потерями (муда) становится по-настоящему эффективной.

Поэтому главное правило системы простое: устранять проблемы нужно строго по порядку – сначала мура, потом мури, и только затем муда. Это важно.

Именно этот принцип и лежит в основе подхода Toyota – он помогает не распыляться на мелкие проблемы, а бить точно в цель. Вот как сформулировал суть сам создатель производственной системы компании:

---

«Всё, что мы делаем, – смотрим на время между заказом клиента и получением денег. И сокращаем этот отрезок, убирая всё, что не добавляет ценности»

 – Тайити Оно, создатель производственной системы Toyota

---

Стадия 1. Составляем карту потока и получаем конкретные данные

Карта потока создания ценности (VSM) – это карта всего пути задачи: от самого первого запроса до того момента, когда результат доходит до пользователя. Каждый этап на ней отмечают тремя цифрами – они показывают, сколько времени уходит на работу, на ожидание и на потери. Относится к концепции бережливого производства (Lean).

Важно понимать: VSM не исправляет проблемы – она помогает их увидеть. Именно с этой карты стоит начинать любые улучшения. Без цифр мы обычно бросаемся чинить то, что бросается в глаза, а не то, что реально, но тихо съедает время и деньги.

На каждом шаге процесса мы смотрим три метрики. Их важно понимать точно, так как именно на них строится вся дальнейшая работа с цифрами.  

Одна ошибка может свести на нет всю ценность карты потока.

Показатель %C&A нужно снимать с того, кто принимает работу, а не с того, кто её делал. Автор всегда уверен, что передал всё как надо. А правду видит тот, кто принял задачу – и вернул с вопросами.

Например, чтобы понять реальную картину, спросите разработчика, какая доля багов приходит с понятными шагами для воспроизведения. Или спросите тестировщика, насколько часто требования приходят без пробелов в граничных случаях. Так вы получите честные данные, на которых можно строить улучшения.

Карта потока выдаёт три главных показателя

Они складываются из построчных данных – PT, LT и %C&A. Эти итоговые цифры – как диагноз для процесса: сразу видно, где он тормозит и сколько времени и ресурсов теряется зря. 

Total LT = сумма Lead Time всех шагов          # сквозное время задачи
Total PT = сумма Process Time всех шагов       # чистая работа

Activity Ratio = Total PT / Total LT × 100%     # доля времени, когда над задачей работали
# В реальных потоках сплошь и рядом 2–15%. Остальное — ожидание.

Rolled %C&A = %C&A(шаг1) × %C&A(шаг2) × ...    # сквозное «годно с первого раза»
# Перемножается! Пять шагов по 80% дают 0.8^5 = 33%.
# То есть две трети задач где-то по пути идут на переделку.

Activity Ratio помогает понять, почему процесс идёт медленно: из‑за самой работы или из‑за ожиданий. Rolled %C&A (он же rolled first‑pass yield в Six Sigma) показывает, сколько задач приходится переделывать. Его главная особенность – он перемножается: даже неплохие 80–90% на каждом этапе в сумме могут дать очень низкий общий результат. Именно эту проблему часто упускают из виду.

В статье мы разберём один сквозной пример на всех этапах

В команде – 6 разработчиков и 2 QA‑инженера. Менеджмент замечает, что тестирование тормозит релизы, и предлагает решение: нанять ещё одного тестировщика. Мы построили карту потока по 12 задачам – и с её помощью смотрим, где на самом деле прячется проблема.

Activity Ratio = 12 / 108 = 11%
# 89% времени задача просто ждёт. Люди при этом заняты по горло.

Rolled %C&A = 0.70 × 0.85 × 1.0 × 0.75 × 0.90 = 40%
# 60% задач где-то идут на переделку. Два узких горла — груминг (70%)
# и тестирование (75%), и они бьют по одному и тому же: возвраты.

Карта сразу показывает, что первоначальная гипотеза неверна. Дело не в том, что тестирование идёт медленно: на саму работу уходит всего 3 часа. И нехватка людей тут ни при чём.

Главная проблема – в долгих ожиданиях (Activity Ratio 11%) и в том, что многое приходится переделывать (Rolled %C&A 40%). Причём переделки возникают на двух конкретных этапах.

Если бы в команду взяли ещё одного тестировщика, эти цифры не изменились бы: задачи всё равно застревали бы в той же очереди.

Стадия 2. Диагностика типа проблем

VSM не просто показывает, где есть проблемы, – она ещё помогает понять, какого они рода. В этом суть всей системы – и именно этого не хватает в поверхностных обзорах.

Три сводные метрики указывают на три разных типа проблем, и для каждого нужен свой подход. Если перепутать тип, получится, что лечим не ту болезнь – и улучшения не дают результата.

Почему «загрузить людей на 100%» – самая дорогая ошибка

Здесь нужна математика очередей, потому что интуиция врёт именно в этом месте. Дон Райнертсен (писатель, прославился как один из главных авторов концепции бережливой разработки продуктов) перенёс теорию массового обслуживания на разработку, и вывод контринтуитивный: время ожидания в очереди зависит от загрузки не линейно, а экспоненциально. Для простой очереди множитель ожидания считается так:

Ожидание ∝ U / (1 − U)       # U — загрузка ресурса (0..1)

  U = 50%  →  множитель  1×
  U = 80%  →  множитель  4×
  U = 90%  →  множитель  9×
  U = 95%  →  множитель 19×

# Догрузив тестировщика с 80% до 95%, вы получаете не +19% работы,
# а рост времени ожидания задачи в очереди почти впятеро.

Вот почему добавление ещё одного человека в перегруженную команду нередко ускоряет работу куда сильнее, чем кажется. А попытки выжать из текущих сотрудников «ещё немного» почти всегда дают обратный эффект – процесс только замедляется.

Главный практический вывод Райнертсена прост: управлять нужно не загрузкой людей, а размером очереди. Загрузку точно оценить сложно, а очередь всегда видна – например, на доске задач. Стоит ограничить количество задач в работе – и загрузка сама придёт в здоровый диапазон.

Правила выбора инструмента простые

• Если видите долгие ожидания и низкий Activity Ratio – проблема в очереди. Решают лимиты WIP (Стадия 03). Нанимать людей или требовать работать быстрее тут не поможет.
• Если низкий Rolled %C&A – значит, много переделок. Нужно внедрять poka‑yoke на том шаге, где показатель падает.
• Если на одном шаге %C&A неожиданно низкий – не стоит действовать наугад. Разберите причину с помощью подхода DMAIC.
• Если проблемы сразу по всем фронтам – исправляйте по порядку: сначала выровняйте поток (mura), потом снимите перегрузку (muri), затем уберите потери (muda).

В нашем примере карта выявила две основные проблемы: очередь (Activity Ratio – 11%) и переделки на двух этапах (Rolled %C&A – 40%). Значит на третьей стадии понадобятся два инструмента: лимит WIP, чтобы справиться с очередью, и poka‑yoke – чтобы сократить переделки. Действуем по правилу mura, а затем muda: сначала выравниваем поток, а потом точечно улучшаем качество отдельных шагов.

Стадия 3. Выбрать и применить контрмеру

Контрмера А. Лимит WIP – против очереди

Механика. Лимит WIP работает на базе закона Литтла – простого, но фундаментального правила из теории очередей. Суть такая: в стабильном потоке время выполнения задач напрямую зависит от их количества. Держите в работе меньше задач – и они будут проходить через систему быстрее.

WIP = Throughput × Lead Time

  WIP        — задач одновременно «в работе»
  Throughput — сколько задач в день выходит из шага
  Lead Time  — сколько в среднем задача проводит на шаге

# Перестановка даёт лимит, а не «возьмём 2 на человека наугад»:
Целевой лимит WIP = Throughput × Целевой Lead Time

Лимит рассчитывается, исходя из реальной пропускной способности команды и целевого времени цикла, а не на глаз. Покажем на примере.

# Из карты: шаг тестирования выпускает ~2 задачи в день (throughput).
# Сейчас Lead Time на шаге = 28 ч ≈ 3.5 рабочих дня.

Фактический WIP = 2 × 3.5 = 7 задач висят в тестировании разом.
# Вот источник переключения: 2 инженера жонглируют семью задачами.

# Хотим Lead Time = 1 день. Тогда:
Целевой лимит WIP = 2 × 1 = 2 задачи
# Ставим лимит колонки = 3 (небольшой запас), а не 7.

Как внедрить, чтобы результат сохранился

• Ставьте лимит на колонку, а не на отдельного сотрудника. Если лимит достигнут – новую задачу не берём: вся команда помогает завершить то, что уже в работе.
• Важно дать команде право не брать новые входящие задачи. Без этого лимит превращается просто в цифру на доске. Если сверху постоянно подкидывают «срочно» поверх лимита – система не работает.
• Эффект следует из закона Литтла: при том же объёме выполненной работы (throughput) и меньшем количестве задач в работе (WIP) время выполнения (Lead Time) сокращается пропорционально. Это не про то, что все стали усерднее трудиться, – это простая арифметика.

Где возникают проблемы

Закон Литтла работает только при стабильном потоке: сколько задач заходит, столько примерно и выходит. Если есть mura – то есть скачки в поступлении задач, – лимит WIP будет то создавать заторы, то пустовать.

Поэтому действовать нужно по цепочке mura, затем muri, потом muda: сначала хотя бы примерно выровнять поток входящих задач – например, через классы обслуживания или ограничение числа одновременно стартующих задач. И только потом ставить лимит WIP. Пытаться применять лимит на хаотичном, неровном потоке – значит лечить не причину, а симптом.

Контрмера Б. Poka‑yoke – боремся с переделками 

Механика. Poka‑yoke (метод Сигео Синго из Toyota) напрямую повышает показатель %C&A на этапе – не за счёт более тщательного поиска ошибок, а за счёт того, что делает ошибку невозможной.

Синго выделял два уровня защиты – и это не просто нюанс, а выбор силы решения:

• контролирующий poka‑yoke не даёт совершить ошибку – это самый надёжный вариант;
• предупреждающий – только сигнализирует о ней, но человек может его проигнорировать, поэтому он слабее.

Мы в компании всегда, где возможно, выбираем контролирующий вариант – он даёт устойчивый результат и заметно снижает переделки.

Привязка к карте простая: находим шаг с низким %C&A и работаем именно с ним.

В нашем примере проседали груминг (70%) и тестирование (75%) – и причина у обоих одна: работа уходит дальше, не будучи доведённой до нужного состояния. Контрмеры:

Контрмера В. DMAIC в поисках причины

Механика. DMAIC (каркас Six Sigma) используют не каждый день, а только когда на карте виден этап с низким %C&A, а причина проблемы неочевидна.

Он помогает не бросаться чинить первый попавшийся симптом, а разобраться в настоящей причине. Его сила – в пяти чётких шагах: они задают системный подход.