Автор:

В противовес моей идее о том, что тестирование программного обеспечения должно быть ролью, а не просто задачей, мне иногда говорят, что «настоящий Agile» этого не допускает. Почему? Потому что в Agile «качество — ответственность каждого». Это утверждение иногда подаётся так, будто это моральная истина, не подлежащая обсуждению, или же как моральное достижение, уникальное для аджайлистов, будто предыдущим поколениям разработчиков программного обеспечения никогда не приходило в голову помогать друг другу создавать хорошие вещи.

В любом случае, для меня это не имеет смысла.

Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле.

Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка:

Что такое синтетические данные?

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

Подход зависит от задачи: где-то хватит пяти тысяч строк на фикстурах, где-то нужен конвейер генерации 4 ТБ с проверкой по статистике, планам запросов и приватности. Юридическая сторона при этом определяет стоимость. Маскирование с обратимым ключом остается персональными данными по 152-ФЗ¹. Синтез выводит данные из-под закона, только если доказано, что связь с реальными людьми отсутствует, – с 1 сентября 2026 года это проверяется по национальным стандартам ПНСТ 1064–1066².

Наш ведущий эксперт Олег подготовил цикл из трех материалов, в которых пошагово рассказывает, как построить конвейер, который выдает обезличенные данные в промышленных объемах, и как убедиться, что они не врут. Никакой магии – только метрики, пороги и грабли, на которые он уже наступал. Полезно для руководителей разработки и QA, продакт-менеджеров и всех, кто работает с тестовыми данными.

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

Понедельник, планерка. Тестировщик разводит руками: у меня не воспроизводится, на моих данных все зеленое. Аналитик говорит, что у него выгрузка трехмесячной давности и новых статусов заявки там еще нет. Нагрузочник молчит – у него стенд на 40 ГБ против 6 ТБ прода, и он давно перестал верить собственным графикам. А безопасник в этот момент пишет письмо о том, что дамп боевой базы опять оказался на ноутбуке подрядчика. Если у вас такого никогда не бывало – вы либо совсем маленькие, либо уже очень взрослые. В обоих случаях дальше можно не читать.

Я лет десять кручусь вокруг тестовых сред, и первые года три делал ровно то, что делают все: выгружал из прода двести тысяч строк, менял фамилии на Иванов1, Иванов2 и так далее, и считал, что обезличил. Пока не заметил, что в выгрузке остались номера договоров. А по номеру договора на нашей же публичной форме проверки статуса доставался город и последние четыре цифры телефона. Это был не взлом – это была форма на сайте, которую мы сами и сделали. Мне повезло, что очень быстро именно я нашел ее первым.

С тех пор я отношусь к тестовым данным как к проду: с той же паранойей и тем же уровнем проектирования. Ниже – методология, которой хватает и на регресс из 5 000 строк, и на нагрузочный контур в 4 ТБ.

Пара цифр для контекста, чтобы было понятно: проблема не выдуманная. По опросу «Гарды»³ среди российских компаний специализированные средства маскирования применяют около 3% респондентов, почти половина регулярно переносит в тестовые среды копии продуктивных баз без изменений, а 18,8% держат тестовые базы в том же кластере, что и боевую. При этом с 30 мая 2025 года по 420-ФЗ⁴ утечка данных 1 000–10 000 человек стоит юрлицу от 3 до 5 млн рублей, а повторная – от 1 до 3% годовой выручки, минимум 25 млн. Это уже не риски информационной безопасности, это строчка в P&L.

Какие задачи решает создание тестовых данных и чем они отличаются?

Самая дорогая ошибка здесь скрывается на старте, и стоить она может около 6 месяцев бесполезной работы. Звучит так: давайте сделаем нормальные тестовые данные, но без уточнения, для чего. Я вам расскажу про четыре основных задачи с несовместимыми требованиями, которые могут прятаться за таким расплывчатым запросом. Данные, отличные для регресса, бесполезны для нагрузочного тестирования, а данные, на которых обучается скоринг, не подойдут для демо партнеру. И наоборот. Обязательно прочитайте, чтобы не пойти по ложному направлению с самого начала, так как переделывать будет очень дорого.

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

Мой любимый антипаттерн: команда полгода строит пайплайн на CTGAN, покупает видеокарты, а нужны были пять тысяч строк для регресса, где важно только одно – чтобы у клиента было от нуля до семи карт. Это делается за два дня на фикстурах. Бывает и наоборот, и это дороже: под нагрузочное тестирование берут данные, сделанные для демо. Чем это кончается – обязательно расскажу на примере кейсов в третьей статье цикла. Был случай, когда p99 на стенде отличался от прода в двадцать три раза.

Что делать прямо сейчас?

Соберите всех, кто работает с тестовыми данными, и попросите каждого назвать одну метрику, по которой он поймет, что данные плохие. Не общие слова про реалистичность, а конкретно: доля отказов по эквайрингу – 2,8% ± 0,3. Если человек не может назвать такую метрику – значит, у него не требования, а ощущения. А ощущения меняются каждый спринт, работать с ними нельзя.

Что такое синтетические данные и какие уровни реалистичности бывают?

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

Британское статистическое ведомство (ONS)⁵ предложило шкалу из шести уровней – самую вменяемую из тех, что я видел. Подготовил для вас удобную таблицу и добавил от себя столбец «для чего годится»: в оригинале его нет, но так нагляднее и полезнее.

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

Ошибка из практики

Как-то раз мы сделали для нагрузочного стенда пятый уровень – просто потому что могли. Через месяц пришел безопасник и спросил: на каком основании данные пятого уровня лежат в контуре, куда имеют доступ двенадцать подрядчиков? И был прав. Мы потом три недели доказывали, что из этих данных невозможно вытащить реальных людей. А по задаче вполне хватало четвертого уровня и недели работы.

Вывод простой: лишнее качество синтетики не всегда оправдано. Ты берешь на себя лишний риск – и потом за него отвечаешь. 

Маскирование, псевдонимизация и синтез – чем они отличаются с юридической точки зрения?

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

Маскирование с обратимым ключом – это псевдонимизация. Вы заменили фамилию на код, а ключ положили в хранилище. Субъекта вроде не определить – но только пока ключа нет. А он есть. Значит, это по-прежнему персональные данные, тестовый контур остается ИСПДн со всеми требованиями к защите, и штрафы за утечку из него ложатся на вас.

Обезличивание регулируется жестко. С 1 сентября 2025 года действует приказ Роскомнадзора № 140 от 19.06.2025⁶ – он заменил прежний № 996 от 2013 года. Методы в целом те же: идентификаторы, изменение состава и семантики, перемешивание, декомпозиция – плюс добавился новый метод преобразования массива. Но важнее методов требования к самому процессу, а их как раз редко кто читает.

Что требует приказ № 140 и что из этого ломает привычную практику:

• Нельзя хранить обезличенные данные вместе с исходными. Схема, когда в одной базе рядом лежат clients и clients_masked, – вне закона. А так делают почти все.
• Ключ соответствия хранится отдельно и третьим лицам не передается. Подрядчик по нагрузочному тестированию – это третье лицо.
• Локальные акты о методах обезличивания и о применяемых системах не должны быть доступны третьим лицам. То есть описание вашего пайплайна маскирования само по себе – чувствительный документ.
• Ведется учет всех действий. Каждая выгрузка сопровождается журналом.

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

И тут стало проще. Росстандарт выпустил первые стандарты по синтезу данных – их подготовила Ассоциация больших данных. Три документа: ПНСТ 1064-2026 – основные понятия и термины, ПНСТ 1065-2026 – архитектура и методы синтеза, ПНСТ 1066-2026 – оценка качества результатов. Действуют с 1 сентября 2026 года, то есть уже сейчас. Там наконец-то есть то, чего не хватало: как оценить достоверность, как измерить риск восстановления исходных данных, как валидировать, как маркировать и аудитировать.

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

А как с этим обстоят дела за рубежом?

Если нужно обосновать подход для зарубежной части группы, логика везде одна: смотрят не на название метода, а на остаточный риск повторной идентификации. GDPR⁷ (соображение 26) и заключение WP29 05/2014⁸ требуют закрыть три риска – выделение записи, связывание и вывод атрибута. Остался хоть один – это уже не анонимизация. Самый практичный документ – NIST SP 800-188⁹, финальная редакция от сентября 2023. Там же описаны совет по проверке раскрытия и тест мотивированного нарушителя. В HIPAA¹⁰ две дорожки: удалить 18 атрибутов из списка или провести экспертную оценку риска. Российская практика по факту дрейфует ко второй.

Отдельная работа для всех, кому синтетику продают как серебряную пулю: Stadler, Oprisanu, Troncoso, Synthetic Data – Anonymisation Groundhog Day, USENIX Security 2022¹¹. Вывод неудобный: сама по себе синтетика не дает лучшего баланса между приватностью и полезностью, чем классическая анонимизация. Либо теряете полезность, либо защищаете не все записи, а предсказать заранее, где окажетесь, трудно. Отсюда единственный рабочий вывод: не верить, а измерять.

Еще две цифры на случай, если кто-то думает, что убрал ФИО и теперь безопасно. Латания Суини¹² еще в девяностых показала: около 87% американцев однозначно определяются по связке индекса, даты рождения и пола. Rocher, Hendrickx и de Montjoye в Nature Communications за 2019 год оценили¹³, что 99,98% американцев можно переопределить по пятнадцати демографическим атрибутам, причем даже на сильно прореженных выборках. Пятнадцать атрибутов есть в любой таблице клиентов.

На чем в итоге сходится большинство зрелых команд: нейросеть отвечает за структуру; правила – за форматы и ключи; каталог патологий – за редкие и проблемные случаи. Про дифференциальную приватность скажу отдельно: она нужна, когда данные уходят наружу, и почти никогда – когда остаются внутри вашего контура. 

Главный вывод первой части

Закон не запрещает работать с тестовыми данными – он запрещает работать с ними небрежно. Граница между псевдонимизацией, обезличиванием и синтезом не техническая, а правовая, и цена ошибки здесь не часы переделки, а оборотные штрафы и репутация. Приказ Роскомнадзора № 140, стандарты Росстандарта по синтезу, требования GDPR и HIPAA – все сходится в одном: документально доказанный остаточный риск повторной идентификации. Не название метода и не уверенность на совещании, а отчет, который можно положить на стол аудитору.

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

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

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

Вопросы и ответы

Недавно знакомый PM попросил рассказать «Что значит отвечать за качество?» в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину.

Начну немного издалека. Последние лет пять тема продуктовых команд очень популярна. Тестировщиков из «колодцев» и подчинения QA лидам и хэдам забирают в команды. Если сначала было матричное управление с функциональным руководством, то последние годы растет тренд на отказ от QA лидов с передачей функции лидам продуктовых команд.

Автор:

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

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

И поскольку мне нравится автоматизировать свои проблемы, я решил упростить это с помощью инструментов, которые пробовал в последнее время. Покажу, как использовал Goose, Playwright MCP и их новое расширение Playwright MCP Bridge для Chrome, чтобы автоматизировать скучную задачу создания множества тикетов во внутренней системе отслеживания задач.

Когда заказчик просит «посмотреть сайт свежим взглядом» и заказывает анализ юзабилити, он часто ожидает услышать про цвета, шрифты или расположение кнопок. Но важно понимать: внешность сайта — это лишь интерфейс (UI). А настоящий юзабилити-аудит (UX) охватывает намного больше факторов и показателей. И его цель – проверить, соответствует ли интерфейс ментальной модели пользователя и решает ли он бизнес-задачи.

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

Решили поделиться интересным кейсом «Лаборатории качества». Мы провели комплексный UX-аудит сайта франшизы федеральной сети салонов для животных и выявили 19 критических ошибок и 29 точек роста. В этой статье мы разберем наш подход пошагово, опираясь на методологию экспертного анализа, чтобы показать, как данные и системный подход помогают находить проблемы, невидимые глазу.

Команда и инструменты

Аудит выполняли наши специалисты с опытом в B2B и юзабилити-анализе. Был использованы такой стек: Яндекс.Метрика (Вебвизор, карты кликов, воронки), инструменты автоматизированного тестирования, чек-листы по эвристикам Нильсена и методы когнитивного walkthrough. Такой микс компетенций и подбор команды позволил найти не только визуальные недочеты, но и скрытые технические и юридические риски.

Шаг 1. Анализ Яндекс.Метрики: от цифр к гипотезам о поведении

Прежде чем смотреть на дизайн, мы изучили данные за последние полгода (02.02.2026 — 02.08.2026). Цифры сами по себе не дают ответов, но они позволяют сформулировать точные гипотезы о том, где и почему пользователи теряются. Картина была противоречивой: трафик рос (+20,7%), но конверсия падала (-0,42%). Доход по целям сократился на 6,93%. Это классический сигнал о том, что качество трафика или соответствие интерфейса ожиданиям аудитории ухудшилось.

Какие гипотезы мы сформировали на основе данных

Гипотеза 1: нерелевантный трафик из платных каналов. Канал Google Ads приносил 3 574 визита (9,4% всего трафика), но конверсия составляла всего 0,03%, а доход — 1 000 рублей. Для сравнения: органический поиск при меньшем объеме в 2,5 раза давал конверсию 9,3% и доход 167 500 рублей.

• Вывод: либо реклама настроена неверно, либо посадочная страница не соответствует ожиданиям аудитории из этого источника. Сайт «обманывает» ожидания кликнувших по объявлению, что подтверждается высоким показателем отказов (23,7%) и снижением времени на сайте на 10,55%. Примечание: В рамках данного аудита фокус был на основном проблемном канале, но рекомендация по аудиту распространяется на все платные источники.

Гипотеза 2: первый экран не удерживает B2B-аудиторию. 44,8% пользователей уходили после просмотра одной страницы. При этом те, кто смотрел 2-3 страницы, имели конверсию 2%, а доскроллившие до отзывов и цифр — 8,9%. Эти пользователи приносили 66,1% всего дохода.

• Вывод: проблема не в продукте, а в подаче. Пользователи, которые преодолевают первый барьер и погружаются в факты, конвертируются отлично. Значит, нужно убрать барьеры на старте и дать им повод скроллить дальше.

Гипотеза 3: основной инструмент лидогенерации работает против пользователя. Квиз был главным инструментом захвата лидов (26 700 просмотров, 4 837 запусков). Однако конверсия внутри него составила всего 3,5% (169 заявок). 80% пользователей открывали квиз, но не нажимали кнопку «Пройти». Еще 48% бросали заполнение формы контактов в самом конце.

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

Гипотеза 4: аудитория ищет бизнес-информацию, а получает развлечения. Ядро целевой аудитории — женщины 35-54 лет с долгосрочными интересами в финансах, бизнесе, красоте и здоровье. Они приходят за цифрами, сроками и гарантиями, так как должны понимать, во что им предлагают вкладывать инвестиции.

• Вывод: наблюдается полное несоответствие ментальной модели B2B-инвестора с B2C-развлечениями на сайте. Развлекательный контент создает когнитивный диссонанс и снижает доверие к бренду как к надежному партнеру для бизнеса.

Итог этапа: проблема не в отсутствии трафика, а в несоответствии интерфейса потребностям аудитории и технических барьерах. Мы перешли от ощущения «что-то не так» к конкретным, измеримым гипотезам для проверки.

Шаг 2. Экспертный анализ по эвристикам Нильсена: поиск ошибок и точек роста

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

Нарушение принципа «Соответствие системы реальному миру» (ошибка)

Сайт продавал сложную услугу для бизнеса (B2B), но вел себя как развлекательный портал для конечных потребителей (B2C).

Ключевые баги:

• выдуманные персонажи-животные занимали 30% контента;
• кнопка с шуточным текстом вместо открытия формы скроллила страницу наверх. Пользователь терял позицию и раздражался;
• слайдер с примерами работ дублировал контент с сайта салонов и не нес ценности для инвестора.

Нарушение принципа «Предотвращение ошибок» (ошибка)

Формы захвата работали против пользователя, создавая ложное ощущение корректности.

Ключевые баги:

• валидация полей показывала зеленые галочки при вводе невалидного телефона («+7 (2») и email («test»). Ошибка появлялась только после нажатия «Отправить»;
• при клике на выбор конкретного формата услуги в форме заявки всегда выбирался базовый вариант. Менеджеры получали некорректные лиды.

Нарушение принципа «Видимость состояния системы» (ошибка)

Пользователь не понимал, что происходит после его действий.

Ключевые баги:

• после прохождения интерактивного теста ссылка на бонус вела в пустую папку облачного хранилища. Пользователь тратил время, оставлял контакты, но не получал обещанное. Это полностью обесценивало инструмент;
• все ссылки на «Политику конфиденциальности» вели на страницу 404 с креативной иллюстрацией. Для юридического документа это недопустимо.

Точки роста (улучшения)

Параллельно с поиском ошибок мы фиксировали возможности для усиления:

• добавить детальное описание паушального взноса и роялти (сейчас пользователь видит сумму, но не понимает состав);
• расширить FAQ с 3 до 8-10 вопросов для снятия возражений;
• оптимизировать блоки с персонажами: сократить количество шагов или изменить действие кнопок;
• удалить или переработать блок «Тип бизнеса» (абстрактная концепция, AI-изображения).

Шаг 3. Когнитивный разбор сценариев: путь предпринимателя vs B2C-подход

Мы смоделировали поведение типичного партнера (женщина 40 лет, ищет инвестиции, интересуется финансами) и сравнили его с тем, что предлагает сайт. Здесь мы анализировали когнитивную нагрузку: где возникает перегрузка, путаница или сомнения.

Ожидание пользователя (Ментальная модель): «Я хочу увидеть сроки окупаемости, размер взносов, роялти и скачать финансовую модель, чтобы показать партнеру. Я хочу понять риски и шаги».

Реальность на сайте (Когнитивный диссонанс)

• Отсутствует информация о сроках запуска (только общая фраза «от 6 месяцев»). Нагрузка:пользователю приходится гадать или спрашивать менеджера.
• Нет детализации взносов и роялти. Нагрузка: недоверие («скрывают условия»).
• Блок «Цели на будущее» с sticky-эффектом зависал при скролле, заставляя ждать смены слайдов. Нагрузка: потеря контроля над просмотром, утомление.
• Блок «Новости и СМИ» занимал 20% длины страницы, отвлекая от целевых действий. Нагрузка: визуальный шум, сложность поиска сути.

Результат когнитивного разбора: сайт создает избыточную когнитивную нагрузку. Пользователь вынужден фильтровать развлекательный шум, чтобы найти бизнес-информацию. Это повышает тревожность и снижает доверие.

Шаг 4. Технический аудит и комплаенс: где скрыты юридические риски

Юзабилити - это не только удобство, но и безопасность. Мы выявили критические проблемы соответствия законодательству, которые грозили финансовыми и репутационными рисками для бизнеса.

Нарушение 152-ФЗ: 

• Отсутствовал отдельный документ «Согласие на обработку персональных данных». В чекбоксах форм была только ссылка на Политику конфиденциальности. Штраф: 60 000–100 000 ₽;
• Cookie-баннер имел только кнопку «Принять». Отсутствовала возможность отклонить или настроить категории cookie. Штраф: до 300 000 ₽.
• Отсутствие механизма отзыва согласия: в футере не было ссылки или формы для отзыва согласия на обработку ПДн.

Также мы обнаружили несоответствие юридической информации: на разных страницах экосистемы компании указывались разные названия юрлица, отсутствовали ИНН/ОГРН и юридический адрес. Это подрывает доверие и создает риски при проверках.

Шаг 5. Сравнительный анализ с конкурентами

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

Вывод: отсутствие базовых элементов доверия (договор, финмодель, прозрачные условия) напрямую влияет на bottom line. Бизнес теряет деньги не потому, что продукт плохой, а потому что интерфейс не дает пользователю чувства безопасности, необходимого для принятия решения о крупной инвестиции. Внедрение этих элементов — это не «украшательство», а прямая работа над увеличением выручки.

Шаг 6. Приоритизация и план действий

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

Топ-4 задачи (Critical):

1. Исправить битые ссылки и унифицировать юридическую информацию (Политика конфиденциальности, презентация после теста, реквизиты во всех разделах). Восстановить доверие и устранить юридические риски.
2. Оптимизировать основной инструмент лидогенерации. Изменить первый экран (показать выгоду), упростить форму контактов, добавить мотивационные триггеры. Цель: рост конверсии с 3,5% до 8-10%.
3. Добавить навигацию. Фиксированное меню с якорями + кнопка «Наверх». Решить проблему 44,8% отказов и потери ориентации на длинном лендинге.
4. Добавить недостающий B2B-контент. Сроки запуска, детализация взносов, скачиваемая финансовая модель, расширенный FAQ. Закрыть потребности аудитории 35-54 лет.

Проработанный UX позволяет добиться предсказуемого пользовательского поведения

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

Как только мы убираем красивые картинки с излишним интертейментом с B2B-сайта, и добавляем сухие, но необходимые данные (сроки, документы, финансовые модели), то площадка начинает работать на свою целевую аудиторию и приносить бизнесу достойный результат.

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

Это лучшее подтверждение того, что качественный UX-аудит — это не просто список правок, а дорожная карта для роста бизнеса. Помните: Пользователю не нужно, чтобы было красиво. Ему нужно, чтобы было понятно, безопасно и полезно. Всё остальное — просто декорации. А чтобы отличить декорации от работающего инструмента, нужны данные, документы и системный подход.

А что, если ваш сайт уже теряет заявки из‑за сырого юзабилити? Напишите нам, и мы покажем скрытые проблемы: от когнитивной нагрузки до нарушений 152‑ФЗ. Запишитесь на бесплатную консультацию – разберём 2–3 ключевых сценария и дадим список гипотез для проверки.

…и я решил, что я буду изучать 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, а причина проблемы неочевидна.

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