Обзор Prompt Lab: полезный порядок сравнения, но оценщику нужны исправления
Prompt Lab задает общие примеры и критерии для A/B-сравнения запросов. Проверка исходников и небольшие локальные тесты оценщика выявили ограничения, которые надо устранить до принятия решений по итоговым баллам.
Prompt Lab задает общие примеры и критерии для A/B-сравнения запросов. Проверка исходников и небольшие локальные тесты оценщика выявили ограничения, которые надо устранить до принятия решений по итоговым баллам.
Что проверено
Обзор относится к публичной версии0.1.1, ревизии e7e5027c6e6522bf8e2b6dae9ff25744c9451f35 от29 октября2026. Это плагин ZCode с оценщиком на стандартной библиотеке Python и лицензией MIT. Я прочитал README, навык и код, затем выполнил маленькие искусственные тесты оценщика. ZCode и модельные сравнения не запускались, стоимость провайдеров не измерялась. Владелец предложил проект для обзора; выводы не зависят от реферальных ссылок сайта.
Полезная схема
Оба варианта получают одинаковые примеры и заранее заданные взвешенные критерии. Документированный процесс требует нового агента для каждой пары пример/вариант/повтор и файла runs.json. Критерии и ожидаемые свойства не передаются исполнителю. Это разумная мера против переноса ответов между вариантами. Сам оценщик не создает агентов и не доказывает изоляцию: журнал только фиксирует сведения об исполнении. README описывает установку через marketplace и команду /prompt-lab с двумя путями, примерами, критериями и числом повторов.
Два неудачных числовых теста
Я записал OK в A-run1.txt и FAIL в A-run2.txt для одного примера с критерием contains-OK. При runs_per=2 оценщик прочитал OK дважды и вернул1.0. Внутренний вызов compute_scores передает collect_outputs число1 вместо текущего повтора. Другой тест с успешным первым и неуспешным вторым примером дал1.0 и0.5, хотя второй отдельно должен получить0.0. Накопители got_w и total_w включают предыдущие примеры. Это проверка арифметики и выбора файлов, не модели.
Ручная оценка и буквальный поиск
При одном объективном и одном неоцененном ручном критерии агрегатор объявил победителя, хотя у обоих вариантов pending_manual=1. Счетчик виден, но обещание README отложить вывод до ручной оценки не обеспечено кодом. Свойство no invented numbers превращается в проверку отсутствия буквальной фразы invented numbers, а не вымышленных чисел. Contains и regex пригодны для формата; достоверность и объяснение влияния формулировки требуют отдельной оценки.
Что стоит исправить
Нужно читать точный номер повтора, останавливать оценку при отсутствии файла и сбрасывать накопители для каждого повтора и примера. Итоговый вердикт следует блокировать при обязательных неготовых ручных оценках либо явно делать предварительным. Смысловые свойства надо проверять вручную, журнал сверять с матрицей запусков. Нужны тесты разных ответов, отсутствующего второго файла, смены порядка успешного и неуспешного примера и pending_manual. Я не менял репозиторий. Пока эти проверки не проходят, схему полезно использовать как список действий с чтением ответов, а не как надежный выбор по баллам.