[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"guide-how-to-build-an-evaluation-set-that-does-not-go-stale::ru":3,"guide-related-how-to-build-an-evaluation-set-that-does-not-go-stale::ru":17},{"slug":4,"title":5,"excerpt":6,"body":7,"meta_title":5,"meta_description":8,"keywords":9,"category":15,"published_at":16,"updated_at":16},"how-to-build-an-evaluation-set-that-does-not-go-stale","Как собрать оценочный набор, который не устареет","Большинство оценочных наборов собирают один раз, из того, что было легко достать, и они тихо перестают представлять работу. Как собрать набор из уже имеющихся отказов, подпитывать его из продакшена, защищать от системы, которую он измеряет, и понимать, когда он исчерпан.","\u003Ch2>О чём это и о чём нет\u003C\u002Fh2>\n\u003Cp>У большинства команд, измеряющих функцию на основе искусственного интеллекта, где-то есть набор тестовых случаев. Его собрали за неделю, из того, что было легко достать, руками человека, который с тех пор ушёл в другой проект, и он по-прежнему выдаёт число при каждом прогоне конвейера. Это число считают фактом о качестве. Обычно это факт о наборе, который перестал описывать продукт некоторое время назад.\u003C\u002Fp>\n\u003Cp>Это не текст о том, как проводить оценку, когда у вас нет команды данных: механику и дешёвый вариант подсчёта разбирает материал о том, как оценивать качество вывода без команды данных. И не о том, как судить агента на многошаговой задаче, — этим занят материал о том, как понять, работает ли агент на самом деле. Здесь речь о самом материале: откуда берутся случаи, что держит их представительными и как понять, что набор исчерпан.\u003C\u002Fp>\n\u003Ch2>Начинайте с отказов, которые у вас уже есть\u003C\u002Fh2>\n\u003Cp>Худший способ собрать набор — сесть в комнате и придумать примеры. Придуманные случаи хорошо сформулированы, однозначны и вежливы; они измеряют версию задачи, которую никто не присылает. Лучшее сырьё — уже собранные отказы: обращения в поддержку по этой функции, ответы, на которые жаловались, случаи, которые инженер бросил в канал со словом посмотрите, всё, что человек исправлял вручную.\u003C\u002Fp>\n\u003Cp>Возьмите их первыми и прочитайте, прежде чем что-то решать. Сотня настоящих отказов научит вас тому, что нужно набору, лучше любого планирования, а формулировки, которые вы запишете по ходу чтения, станут первым наброском категорий, по которым вы потом будете считать.\u003C\u002Fp>\n\u003Ch2>Решите про группы раньше, чем про размер\u003C\u002Fh2>\n\u003Cp>Вопрос никогда не в том, сколько случаев; вопрос в том, каких видов и сколько каждого. Выберите группы, о которых вы захотели бы принимать отдельное решение, — сегмент, язык, тип документа, длина запроса, сложность, только что найденные категории отказов — и возьмите каждой столько, чтобы её оценка что-то значила сама по себе.\u003C\u002Fp>\n\u003Cp>Это намеренно завышает долю редких и дорогих случаев относительно трафика, что верно для поиска проблем и неверно для описания типичной работы. Поэтому записывайте состав рядом с набором, а когда нужна цифра, представляющая живое поведение, возвращайте группам их настоящие доли. Самая частая ошибка отчётности в этой области — привести невзвешенное среднее набора, который собирали трудным.\u003C\u002Fp>\n\u003Ch2>Запишите, что значит верно, и проверьте саму запись\u003C\u002Fh2>\n\u003Cp>Прежде чем что-либо размечать, напишите инструкции: что считается хорошим ответом, как поступать со случаями между категориями и что делать, когда правильный ответ действительно неясен. Затем дайте выборку двум людям независимо и сравните. Там, где они разошлись, не хватает правила, а не аккуратности; и исправление идёт в инструкцию, а не в разговор.\u003C\u002Fp>\n\u003Cp>Неоднозначные строки сохраняйте, а не продавливайте. Случай, который двое внимательных читателей видят по-разному, — самая содержательная строка у вас на руках, и пометить его спорным честнее, чем заморозить один из двух ответов как истину.\u003C\u002Fp>\n\u003Ch2>Держите лёгкий пол и трудную вершину\u003C\u002Fh2>\n\u003Cp>Набору нужны обе половины, и они делают разную работу. Лёгкие случаи — это регрессионный пол: именно они ловят релиз, сломавший что-то базовое, и их ценность как раз в том, что они должны проходить всегда. Трудные случаи — там, где видно улучшение и где два кандидата отличаются друг от друга.\u003C\u002Fp>\n\u003Cp>Отчитывайтесь по ним раздельно. В общей куче лёгкое большинство доминирует в среднем, и настоящий выигрыш на трудном материале растворяется в числе, которое почти не двигается. Это же и ранний признак того, что набор упёрся в потолок: проходит всё, разброс схлопнулся, а помесячные различия — шум.\u003C\u002Fp>\n\u003Ch2>Подпитывайте его из продакшена по расписанию\u003C\u002Fh2>\n\u003Cp>Быстрее всего пробел создают ваши собственные релизы. Любая новая возможность начинает жизнь вовсе без случаев, поэтому её первые недели измеряет материал, собранный до неё, и оценка остаётся успокаивающей, пока риск наиболее высок. Лекарство — не проект, а распорядок: с фиксированной частотой берите выборку недавних настоящих входов, добавляйте те, эквивалента которых в наборе нет, и размечайте их.\u003C\u002Fp>\n\u003Cp>Тот же распорядок — место, куда добавляются отказы, найденные с прошлого раза. Жалоба, ставшая постоянным случаем, — это жалоба, которая не может тихо повториться.\u003C\u002Fp>\n\u003Ch2>Защитите его от системы, которую он измеряет\u003C\u002Fh2>\n\u003Cp>Держите материал там, откуда система читать не может. Это значит не вставлять его случаи в подсказки как примеры, не позволять коллекции, из которой система извлекает, обновляться выгрузкой, содержащей его, и проверять пересечение машинно всякий раз, когда собираются обучающие или справочные данные.\u003C\u002Fp>\n\u003Cp>Примите и то, что набор, по которому вы много раз итерировались, частично израсходован, как бы вы ни осторожничали: подкручивать, пока оценка не устроит, — значит подгоняться под набор, а не измеряться по нему. Отложите долю, в которую заглядывают редко, чтобы всегда оставался материал, под который систему никогда не целили.\u003C\u002Fp>\n\u003Ch2>Знайте, когда он исчерпан\u003C\u002Fh2>\n\u003Cp>Стоит следить за тремя сигналами. Проходит всё, и разброс схлопнулся. Свежий срез трафика содержит категории, примеров которых в наборе нет. Или инструкции правили так часто, что старые строки размечены по правилам, которые больше не действуют. Любой из них означает, что набор описывает задачу, которую продукт уже прошёл.\u003C\u002Fp>\n\u003Cp>Выводить материал из обращения нормально, и это должно быть рутиной, а не драмой: сохраните версию, отметьте, что изменилось, и не сравнивайте оценки через эту границу, не сказав, что набор под ними поменялся.\u003C\u002Fp>\n\u003Ch2>Как выглядит поддерживаемый набор\u003C\u002Fh2>\n\u003Cp>Небольшим. Несколько сотен случаев, сгруппированных, с записанным рядом составом, короткий документ с инструкциями, который правили не один раз, отметка о том, какие строки были спорными и почему, и дата последнего добавления материала из продакшена. Чьё-то имя напротив и повторяющийся час в календаре.\u003C\u002Fp>\n\u003Cp>Это вся практика, и она достаточно невзрачна, чтобы обычно не быть ничьей работой. Причина отдать её кому-то в том, что каждое решение ниже по течению — помогло ли изменение, готова ли функция, лучше ли модель поставщика той, что у вас есть, — ровно настолько хорошо, насколько хорош этот материал, а набор, который никто не поддерживает, портится в сторону, которая всегда выглядит как успех.\u003C\u002Fp>","Соберите оценочный набор из реальных отказов, стратифицируйте его, подпитывайте из продакшена, защитите от утечки и выводите, когда он перестал различать.",[10,11,12,13,14],"оценочный набор","качество ИИ","тестовые данные","оценка модели","эталонные ответы","how-to","2026-09-09T03:30:02+00:00",[18,23,27,31,36,41],{"slug":19,"title":20,"excerpt":21,"updated_at":22},"ai-tool-pricing-models-seat-vs-usage-vs-credits","Модели ценообразования AI-инструментов: за место, за использование и по кредитам","Три распространённых способа тарификации AI-инструментов — за место, за использование и по кредитам — и как понять, какой из них окажется дешевле именно для того, как работает ваша команда.","2026-08-05T14:32:26+00:00",{"slug":24,"title":25,"excerpt":26,"updated_at":22},"how-ai-image-generators-differ-diffusion-vs-the-rest","Чем различаются ИИ-генераторы изображений: диффузия и всё остальное, простыми словами","Нетехническое объяснение того, как работают ИИ-генераторы изображений, почему диффузионный подход стал доминирующим и каких практических различий стоит ждать от разных инструментов.",{"slug":28,"title":29,"excerpt":30,"updated_at":22},"how-to-automate-your-workflow-without-code","Как автоматизировать процесс без кода","Практическая последовательность для автоматизаций, которые выживают: выбрать подходящий процесс, описать его до того, как открывать инструмент, и предусмотреть сбои, ломающие большинство первых попыток.",{"slug":32,"title":33,"excerpt":34,"updated_at":35},"how-to-build-a-chatbot-without-coding","Как собрать чат-бота без программирования","Практический путь к работающему чат-боту на no-code инструментах: определить границы, подключить свой контент, обработать вопросы без ответа и понять реальную стоимость.","2026-08-05T14:32:27+00:00",{"slug":37,"title":38,"excerpt":39,"updated_at":40},"how-to-change-a-prompt-without-breaking-production","Как менять промпт, не ломая прод","Промпты правят в текстовом поле и выкатывают за секунды — поэтому они ломают вещи тихо: ни компилятора, ни стектрейса, ни очевидного момента сбоя. Дайте им релизную дисциплину кода.","2026-08-24T03:30:02+00:00",{"slug":42,"title":43,"excerpt":44,"updated_at":22},"how-to-choose-an-ai-writing-assistant","Как выбрать ИИ-ассистента для письма","Практическая схема выбора инструмента ИИ для письма — как соотнести его с той работой, которую вы реально пишете, проверить возможности редактирования и не попасть на инструменты, выдающие уверенный, но обезличенный текст."]