Введение: почему «модель плохая» - часто неправильный диагноз
Вы запускаете оценку новой LLM на своей задаче. Точность 60%. Вывод напрашивается сам: «модель не справляется». Но что, если проблема не в модели, а в том, как вы её обвязали?
Один зарегистрированный эксперимент поставил этот вопрос ребром. Взяли замороженную 4B-модель с открытым кодом. Зафиксировали золотой корпус из 250 реальных задач классификации - Kubernetes issue, которые нужно отнести к одной из Special Interest Groups (SIG). Меняли только программную обвязку: промпты, порядок блоков, многошаговые процедуры, управление контекстом. Модель не трогали вообще.
Результат: разброс точности от 60% до 82%. Двадцать два пункта разницы на одной и той же модели и одних и тех же данных. Это означает, что фраза «модель плоха в задаче X» в большинстве случаев должна звучать иначе: «моя обвязка плоха в задаче X».
В этой статье мы детально разбираем, какие конкретные решения в дизайне harness дали максимальный прирост, а какие обвалили точность ниже базового уровня. Код, реестр запусков и матрица результатов открыты - вы можете перепроверить каждый вывод без GPU.
Дизайн эксперимента: что мы тестировали и как измеряли
Постановка предельно чистая. Замороженная 4B-модель, никакого дообучения. Золотой корпус - 250 реальных issue из репозиториев Kubernetes. Задача: прочитав текст issue, назначить её на правильную SIG. Метрика одна - точность классификации.
Менялась только обвязка. Промпты. Порядок подачи информации. Наличие или отсутствие дополнительных шагов рассуждения. Способ передачи контекста между этапами. Управление историей диалога. Всё это - чисто инженерные решения, которые не требуют ни дополнительного обучения, ни смены модели.
Почему Kubernetes SIG triage - удачный полигон для теста обвязки
Задача классификации Kubernetes issue по SIG - не синтетический бенчмарк. В реальном проекте Kubernetes больше 30 Special Interest Groups с пересекающимися зонами ответственности. Issue про сбой в networking может касаться и SIG Network, и SIG Node, если проблема на стыке компонентов. Issue про безопасность контейнера - SIG Security и SIG Node одновременно.
Модель должна прочитать текст, выделить ключевые термины, сопоставить их с описаниями групп и принять решение в условиях неоднозначности. Это типичный сценарий для корпоративных задач: классификация тикетов, маршрутизация обращений, распределение инцидентов по командам. Выводы, полученные на этом полигоне, переносятся на широкий класс реальных бизнес-кейсов.
Важный момент: авторы эксперимента выложили в открытый доступ весь инструментарий. Вы можете взять их код, подставить свою задачу и проверить, работают ли те же паттерны у вас. Это превращает статью из теории в воспроизводимый практический инструмент.
Что сработало: два решения, которые дали суммарно +19.5 пунктов точности
Из всех протестированных вариантов обвязки два изменения показали наибольший прирост. Они не требуют сложной инженерии и применимы практически к любой задаче классификации.
Явные правила в промпте: +13 пунктов за счёт структурирования критериев
Базовый промпт выглядел стандартно: описание задачи, список SIG с краткими описаниями, текст issue. Модель должна была самостоятельно вывести критерии классификации из этой информации. Точность - около 67%.
В улучшенном варианте в промпт добавили явные правила вида: «Если issue содержит упоминание Container Runtime Interface или sandbox - назначай на SIG Node. Если речь про NetworkPolicy, CNI-плагины или service mesh - назначай на SIG Network». Таких правил было несколько десятков, по одному-два на каждую SIG.
Результат: +13 пунктов точности. Модель перестала гадать в пограничных случаях и получила чёткий алгоритм разрешения неоднозначностей. Это снизило когнитивную нагрузку и направило «рассуждение» по детерминированному пути. Практический вывод: не ждите, что модель сама выведет правила из примеров. Пропишите их явно.
Порядок подачи информации: +6.5 пунктов, когда задача идёт перед справочником
Сравнили два варианта структуры промпта. Первый: сначала идёт справочник с описаниями всех SIG, потом текст issue. Второй: сначала текст issue, потом справочник. Разница - 6.5 пунктов в пользу второго варианта.
Механизм связан с работой механизма внимания в трансформерах. Когда модель сначала читает справочник, она распределяет внимание по всем описаниям SIG равномерно, ещё не зная, что именно искать. Когда она сначала видит конкретную issue, в контексте активируются ключевые термины, и последующее чтение справочника становится целенаправленным поиском релевантных признаков.
Этот эффект воспроизводится на разных моделях и задачах. В нашем разборе методологии оценки агентов Databricks мы видели аналогичную картину: порядок блоков в промпте для кодинга влиял на точность сильнее, чем выбор между открытой и проприетарной моделью.
Что сломало точность: три антипаттерна в дизайне обвязки
Не все изменения вели к улучшению. Три популярных инженерных решения дали отрицательный эффект, причём одно из них обрушило точность на 15 пунктов.
Дополнительный виток рассуждений: −5 пунктов из-за избыточной «рефлексии»
Сценарий: модель выдаёт первый ответ, затем её просят перепроверить своё решение, явно проговорить рассуждение и выдать финальный вердикт. Идея кажется логичной - «пусть подумает ещё раз». На практике точность упала на 5 пунктов.
Причина не в том, что модель «передумывает» правильные ответы. Механизм тоньше: второй виток рассуждения вносит шум. Модель начинает искать дополнительные обоснования для уже принятого решения и иногда находит ложные корреляции, которых не было в исходном анализе. В задачах классификации, где важна точность, а не креативность, дополнительная рефлексия чаще вредит, чем помогает.
Этот результат перекликается с выводами из нашего разбора модели catmind-1.2b, где скрытое рассуждение обрушило точность с 75.6% до 24.3%. Дополнительные токены рассуждения не бесплатны - они могут уводить модель в сторону от правильного ответа.
Суммаризация вместо сырых доказательств: −12 пунктов на передаче контекста
Многошаговая архитектура: первый шаг собирает доказательства из текста issue, второй шаг принимает финальное решение. В неудачном варианте между шагами передавалась не полная выжимка доказательств, а их краткая суммаризация. Падение точности - 12 пунктов.
Суммаризация убивает детали. Конкретные упоминания API-объектов, имена контейнеров, специфические термины - всё это теряется при пересказе. Второй шаг получает размытую картину и вынужден классифицировать на основе общих слов, а не точных признаков. Модель на первом шаге может правильно определить, что issue относится к SIG Storage, но в суммаризации напишет «проблема с сохранением данных», и второй шаг уведёт классификацию в SIG Apps.
Правило: между шагами многошагового пайплайна передавайте сырые данные. Любая промежуточная обработка текста - это потеря информации, за которую вы заплатите точностью.
Свежая сессия между этапами: −15 пунктов из-за обнуления контекста
Самый разрушительный антипаттерн. В многошаговом пайплайне между этапами сбрасывали историю диалога - каждый шаг начинался с чистой сессии. Результат: минус 15 пунктов, точность вернулась к уровню простейшего zero-shot промпта.
Это эквивалент амнезии. Модель на втором шаге не видит, какой анализ она провела на первом. Она не знает, какие доказательства собрала, какие альтернативы отбросила. Каждый шаг превращается в независимую попытку решить задачу с нуля, но с ухудшенным промптом - потому что входные данные второго шага часто неполны без контекста первого.
Практический вывод: если ваш пайплайн состоит из нескольких обращений к LLM, сохраняйте историю диалога между ними. Сброс контекста - это гарантированный способ убить точность многошаговой системы.
Парадокс худшей обвязки: как 250 вызовов инструментов вернули точность к уровню голой модели
Самый показательный результат эксперимента - конфигурация, которую назвали «худшей обвязкой». Многошаговый пайплайн с дополнительным этапом, на котором модель делала до 250 вызовов инструментов - например, искала документацию по конкретным SIG, уточняла зоны ответственности, собирала дополнительный контекст.
Итоговая точность: около 60%. Столько же, сколько у простейшего zero-shot промпта, где модель получала только текст issue и список SIG без каких-либо инструкций.
Причины провала:
- Накопление ошибок. Каждый вызов инструмента - это точка отказа. Модель может неправильно сформулировать поисковый запрос, неверно интерпретировать результаты, пропустить релевантную информацию. На 250 вызовах даже единичные ошибки каскадно нарастают.
- Потеря фокуса. Обилие дополнительной информации размывает исходный сигнал. Модель тонет в контексте и начинает классифицировать на основе второстепенных признаков.
- Переусложнение промптов. Каждый этап требовал своих инструкций, и их суммарная сложность превысила способность модели эффективно следовать всем директивам одновременно.
Этот результат критически важен для оценки реальных AI-систем. Когда вы видите бенчмарк, где модель показывает 80% точности, а ваш production-пайплайн на той же модели даёт 60%, проблема почти наверняка не в модели. Проблема в обвязке, которую вы построили вокруг неё.
Методология раздельной оценки модели и обвязки детально разобрана в нашем материале про evaluation awareness: модель может показывать завышенные результаты на тестах, но проваливаться в реальном пайплайне именно из-за разницы в обвязке.
Практические рекомендации: как спроектировать обвязку, которая не убьёт точность
Семь правил, выведенных из эксперимента. Они сформулированы на конкретной задаче классификации, но имеют общий характер и применимы к большинству LLM-пайплайнов.
- Начинайте с простого промпта и измеряйте baseline. Один промпт, одна задача, никаких дополнительных шагов. Зафиксируйте точность. Это ваш эталон, относительно которого вы будете оценивать все последующие изменения.
- Добавляйте явные правила классификации. Не надейтесь, что модель выведет критерии из примеров. Пропишите: «Если видишь X, назначай Y». Каждое такое правило - это устранённая неоднозначность.
- Размещайте задачу перед справочной информацией. Сначала конкретный кейс, потом контекст. Модель должна знать, что искать, до того, как начнёт читать справочник.
- Избегайте дополнительных шагов рассуждения без измеримой необходимости. Каждый лишний виток рефлексии вносит шум. В задачах классификации он чаще вредит.
- Передавайте сырые данные между этапами. Никаких суммаризаций, никаких пересказов. Полный текст доказательств - на вход следующего шага.
- Сохраняйте контекст сессии в многошаговых процессах. Сброс истории диалога между этапами обнуляет накопленный анализ. Для модели это амнезия.
- Тестируйте каждое изменение изолированно. Изменили порядок блоков в промпте - замерьте точность. Добавили правила - снова замерьте. Только так вы поймёте, какой именно фактор дал прирост или падение.
Эти правила не догма. Они - стартовая точка для построения собственной методологии тестирования обвязки. Без систематического подхода вы будете гадать, а не проектировать.
Ограничения и следующие шаги: что мы не знаем и как проверить на своих данных
Эксперимент проведён на одной модели - 4B-модели с открытым кодом. На одной задаче - классификации Kubernetes issue по SIG. Это честные ограничения, и их нужно проговаривать прямо.
Мы не знаем, как эти же паттерны поведут себя на модели размером 70B или 400B. Возможно, большие модели менее чувствительны к порядку блоков в промпте, потому что их механизм внимания эффективнее работает с длинным контекстом. Возможно, на задачах генерации, а не классификации, дополнительный виток рассуждений даст прирост, а не падение. Всё это - гипотезы для проверки.
Авторы эксперимента выложили в открытый доступ код, реестр запусков и матрицу результатов. Вы можете взять их инструментарий, подставить свою задачу и свои данные, и проверить, воспроизводятся ли те же эффекты в вашем домене. Это не требует GPU - модель заморожена, все эксперименты проводились через API.
Методология изолированного тестирования изменений обвязки, описанная в этой статье, универсальна. Даже если конкретные цифры прироста и падения будут другими на вашей задаче, сам подход - менять что-то одно и замерять эффект - остаётся единственным способом не гадать, а знать.
Заключение: обвязка - это часть модели, и её нужно проектировать соответственно
Главный результат эксперимента: точность LLM-системы определяется не только качеством модели. Дизайн обвязки может сдвинуть точность на 22 пункта - от 60% до 82% на одной и той же замороженной модели. Это не теоретический предел, а измеренный факт.
Когда вы в следующий раз увидите бенчмарк с впечатляющими цифрами, задайте себе вопрос: какую обвязку использовали авторы? И когда ваша собственная система покажет результат ниже ожидаемого, не спешите винить модель. Проверьте обвязку. Скорее всего, проблема там.
Открытость кода и данных в этом эксперименте позволяет превратить статью в практический инструмент. Вы можете не просто прочитать выводы, но воспроизвести методологию на своих задачах. Начните с простого промпта, замерьте baseline, а затем методично применяйте правила из этой статьи - и смотрите, как меняется точность.