Семантическое ядро вместо словаря фраз
Мейнтейнер Caveman
закрыл наш pull request с точным замечанием:
тело навыка (файл SKILL.md) является продуктом, его переписывание должно пройти
собственный цикл оценки мейнтейнера, а идентификаторы вроде CAV-SEM-07 в
заголовках рабочего файла будут попадать в модель на каждой сессии как чистые
накладные расходы. Исходный
Caveman PR #944 объединял
переписывание 31 процента рабочего навыка, семантический контракт, прогоны моделей,
отчёты, сгенерированные зеркала и сырые снимки. Замечание было верным. Стабильные ID
приносили пользу, но находились по неправильную сторону интерфейса.
У этой ошибки общая форма. У стилевого навыка для языковой модели есть две разные аудитории. Модели при каждом вызове нужен небольшой набор поведенческих правил. Инженерам нужны идентификаторы, матрицы покрытия, фикстуры, отчёты и сравнения между ревизиями. Если смешать эти аудитории, рабочий промпт, то есть текст, который модель получает при каждом вызове, начинает платить за тестовую систему.
Статья отвечает на один вопрос: где должны жить стабильные идентификаторы тестовой таксономии, чтобы отчёты могли ими пользоваться, а рабочий промпт никогда их не нёс? Она описывает три маленьких последующих PR в Caveman, заменивших #944, и один пример рабочей стороны из Pohuy. Поведение модели под этими навыками здесь не оценивается.
Предыдущая версия этой статьи описывала сокращения кандидата из #944 как результат, доставленный в Caveman. Это были измерения невлитой ветки. Текущая редакция исправляет запись и описывает более узкий дизайн, который появился после того замечания.
Рабочие правила и метаданные оценки находятся в разных слоях
Семантическое ядро определяет поведение, которое должна применить модель:
- сжимать форму с сохранением технического содержания;
- сохранять отрицания, ограничения, числа, единицы, код, идентификаторы, API, команды и процитированные ошибки;
- сохранять язык пользователя и грамматические маркеры ролей;
- писать публичные и сохраняемые артефакты обычной прозой;
- отключать сжатый стиль, когда безопасность или упорядоченная процедура восстановления требуют полной ясности.
Эти правила входят в рабочий контекст, потому что могут изменить ответ.
Метаданные оценки решают другую задачу. Стабильный идентификатор позволяет отслеживать один инвариант через переименованные случаи, переставленные фикстуры и новые ревизии навыка. Он поддерживает связывание данных, матрицы покрытия, тренды и группировку ошибок. Модели не требуется видеть этот идентификатор, чтобы выполнить правило.
Практическая граница выглядит так:
| Задача | Представление в исходниках | Попадает в рабочий промпт? |
|---|---|---|
| Поведенческое правило | Ясный естественный язык | Да |
| Калибровочный пример | Минимальный характерный пример | Иногда |
| Стабильный ID контракта | Запись в таксономии оценки | Нет |
| Связь случая с инвариантом | Читаемые ключи таксономии | Нет |
| Матрица покрытия и отчёт | Сгенерированный результат оценки | Нет |
Назначаем ID при запуске оценки
Дальше пример Caveman следует за одним инвариантом, точным сохранением
(exact-preservation), от записи в таксономии через исходный случай до
аннотированной строки отчёта. Узкая замена в
Caveman PR #1061
хранит стабильный ID только в таксономии оценки. В этом дизайне запись таксономии
является единственным местом, где CAV-SEM-02 написан руками; случаи и рабочий
навык проверяются на его отсутствие:
{
"id": "CAV-SEM-02",
"key": "exact-preservation",
"description": "Preserve polarity, limits, numbers, units, code, identifiers, APIs, commands, and quoted errors."
}Исходный случай ссылается на этот инвариант по читаемому ключу и никогда по ID, поэтому фикстуру можно проверять без таблицы соответствий:
{
"id": "polarity-and-limits",
"taxonomy": ["exact-preservation"],
"prompt": "Restate this retry policy without changing meaning: Do not retry more than 3 times. Retry only after 250 ms, except for HTTP 429."
}При подготовке прогона или отчёта шаг аннотирования разрешает этот ключ. Ожидаемый результат представляет собой тот же случай с одним добавленным полем:
{
"id": "polarity-and-limits",
"taxonomy": ["exact-preservation"],
"contract_ids": ["CAV-SEM-02"],
"prompt": "Restate this retry policy without changing meaning: Do not retry more than 3 times. Retry only after 250 ms, except for HTTP 429."
}Между вторым и третьим примером изменилось только поле contract_ids, и появилось
оно на этапе оценки. Отчёт получает стабильные машинные идентификаторы, а рабочий
SKILL.md не содержит ни одного такого ID. Набор тестов проверяет эту границу
напрямую.
На граничных случаях шаг разрешения ключей и оправдывает своё существование. Он останавливается на повторяющемся ID таксономии, повторяющемся ID случая, неизвестном ключе, повторённом ключе, повреждённой записи и исходном случае со встроенным ID контракта. Эти проверки нужны потому, что опечатка в ключе должна остановить прогон. Молчаливый пропуск сопоставления создаст чистый отчёт со скрытой дырой в покрытии.
Одна нумерация требований даёт мало. Таксономия становится полезной, когда случай
может относиться к нескольким инвариантам, а инженер видит получившуюся матрицу.
Португальский промпт про миграцию покрывает одновременно language-and-grammar и
exact-preservation. Публичное описание PR по безопасности покрывает
artifact-boundary и safety-clarity. Список случаев показывает набор промптов.
Матрица между случаями и инвариантами показывает свойства с положительными
контролями, отрицательными контролями, пересекающимся покрытием или полным
отсутствием свидетельств. Стабильные ID делают сравнение долговечным между
ревизиями. Читаемые ключи оставляют фикстуры доступными для проверки. Шаг
аннотирования соединяет эти представления в момент, когда дополнительные метаданные
становятся полезными.
Полные свидетельства до красивых метрик
Целостная таксономия не доказывает полноту прогона. Разбор исходного #944 также обнаружил, что частичные свидетельства могли пройти структурную проверку. Мы выделили эту проблему в Caveman PR #1062.
Валидатор запускается до существующего отчёта о токенах и требует:
- метаданные снимка и непустой список промптов;
- обе контрольные ветки сравнения;
- хотя бы одну ветку с навыком;
- ровно один вывод на каждый промпт в каждой ветке;
- сырые выводы в виде строк;
n_prompts, равный реальному числу промптов.
Свидетельством для этого валидатора является набор тестов, и именно тесты делают
проверку заслуживающей доверия. В них зафиксированный в репозитории снимок служит
положительным контролем. Затем тест удаляет контрольную ветку, обрезает ветку,
заменяет сырой вывод объектом, меняет n_prompts, удаляет все ветки с навыком и
повреждает JSON. Проверяющий скрипт становится доказательством только после того,
как известное нарушение заставило его упасть по ожидаемой причине.
Изолируем генератор от окружения оператора
Даже полная матрица может измерять не тот объект, если запускающий скрипт наследует локальную настройку агента. Старый вызов Claude получал пользовательские и проектные настройки вместе с конфигурацией MCP. Два инженера могли запустить одинаковые зафиксированные в репозитории фикстуры и незаметно дать модели разные инструкции или инструменты.
Caveman PR #1063
добавляет --setting-sources "" и --strict-mcp-config по схеме изоляции, уже
используемой в caveman-compress. Модульные тесты проверяют точные пользовательский
промпт, системный промпт, модель и аргументы изоляции без вызова модели.
Таксономия, валидация матрицы и изоляция запуска являются отдельными контрактами. Каждый можно рассматривать и вливать независимо. Поэтому замена состоит из трёх маленьких PR вместо ещё одной общей тестовой обвязки и переписывания промпта.
Pohuy показывает рабочую сторону границы
Pohuy является отдельным примером, а не продолжением примера Caveman: он показывает, что остаётся на рабочей стороне после того, как метаданные оттуда вынесены. То же разделение применимо к словарям фраз. Открытый Pohuy PR #21 предлагает рабочий навык размером 2 694 байта и 57 строк с нулём обязательных загрузок справочных файлов. Он сохраняет явное включение, три уровня интенсивности, семантику тона, границы артефактов и ясное поведение в вопросах безопасности. Глоссарии и подборки сценариев остаются необязательным материалом.
Это точные измерения файла и контракта, а не универсальное утверждение о токенах или качестве. Детерминированная тестовая обвязка в PR мутационно тестирует бюджеты байтов и строк, границы включения, уровень по умолчанию, загрузку справочных файлов, схему оценки и пороги безопасности. Поведение модели всё равно требует отдельной оценки.
Что подтверждают текущие свидетельства
Три последующих PR в Caveman открыты на момент этой редакции. Их тесты подтверждают работу предложенных сопоставления таксономии, валидации матрицы с отказом при неполноте и изолированного построения команды. Они не доказывают семантическую эквивалентность между моделями. Они не обосновывают слияние отклонённого рабочего переписывания. Они не заявляют экономии токенов от самих идентификаторов.
Узкое утверждение сильнее, потому что его можно проверить: метаданные прослеживаемости добавляются во время оценки, используются в отчётах и механически исключаются из рабочего промпта.
Практическая последовательность
- Описать поведенческие инварианты ясным языком.
- Оставить в рабочем контексте только правила, влияющие на поведение модели.
- Дать каждому инварианту стабильный ID и читаемый ключ в манифесте, который используется только при оценке.
- Разметить случаи читаемыми ключами.
- Разрешать стабильные ID при подготовке прогона или отчёта.
- Отклонять неизвестные ключи, дубликаты, повреждённые случаи и неполные свидетельства.
- Изолировать запуск моделей от пользовательских настроек, проектных настроек и унаследованных инструментов.
- Мутационно тестировать каждую проверку известным нарушением.
- Публиковать модель, входные данные, повторы, контроли, ограничения и неразрешённые случаи.
У оптимизации промптов и проектирования оценки один инженерный принцип: информация должна находиться на той границе, где её используют. Поведенческие инструкции нужны модели. Таксономия и прослеживаемость нужны тестовой системе. Отсюда следует конкретное решение: ID контракта, найденный в рабочем файле, является утечкой из тестовой системы, и исправлением будет перенос его в манифест оценки. Явная граница экономит контекст и создаёт свидетельства, которым проще доверять.