Точность 4B-модели прыгнула с 60% до 82% из-за дизайна промпта — без изменения весов
Эксперимент показал: одна и та же 4B-модель на задаче классификации Kubernetes-задач выдала точность 60% на плохом промпте и 82% на хорошем. Разница в 22 процентных пункта — только из-за структуры запроса: порядка правил, контекста, количества шагов рассуждений.
Показывает, что промпт-инжиниринг — не хак, а критичная часть production AI-систем. Для разработчиков и бизнеса это шанс получить качество GPT-4 на цене маленькой модели, если правильно выстроить harness.
Что произошло
Инженер TGPSKI опубликовал результаты предварительно зарегистрированного эксперимента на 4B-модели (запускалась на ноутбучной GPU с 6GB памяти). Задача: классифицировать задачи в Kubernetes-репозитории по SIG (Special Interest Group) для триажа.
Веса модели, тестовый корпус из 250 задач, метрика оценки — всё не менялось. Варьировался только дизайн harness (способа подачи промпта): где размещены правила, в каком порядке идёт контекст, сколько шагов рассуждений, что передаётся между раундами.
Результат: худший вариант промпта дал 60% точности, лучший — 82%. Разброс 22 процентных пункта на идентичной модели.
Что сработало, что провалилось
- Явные правила в промпте: +13 п.п. точности
- Задача перед справочным материалом (а не после): +6,5 п.п.
- Один дополнительный шаг рассуждений: −5 п.п. (модель запуталась)
- Очистка контекста между раундами, передача только саммари вместо сырых данных: −12 п.п.
- Хэндофф между этапами через новую сессию: −15 п.п.
Худший harness потратил ресурсы на дополнительный этап и 250 вызовов инструментов — и вернулся к базовой точности голой модели. Переусложнение убило производительность.
Весь код, корпус, метрики, предварительная регистрация эксперимента — в открытом доступе на GitHub.
Автор: Марина Соколова · Источник: reddit.com
Разработчикам. Эксперимент доказывает: промпт-инжиниринг на практике даёт больше прироста точности, чем смена модели. Код открыт, можно воспроизвести на своей задаче, понять, где твой промпт сливает точность. Особенно полезно для работы с маленькими моделями на локальном железе.
Бизнесу. Вместо покупки доступа к GPT-4 или найма дорогих ML-инженеров, можно взять дешёвую 4B-модель и правильно написать промпт — получишь 82% точности там, где раньше было 60%. Экономия на инфраструктуре и API при том же качестве.
Инвесторам. Рынок промпт-инжиниринга и harness-фреймворков недооценён. Результаты показывают, что бизнес будет платить за инструменты, которые автоматически оптимизируют промпты, а не за доступ к более мощным моделям. Ниша B2B SaaS для оптимизации inference.
- SaaS для автоматической оптимизации промптов: A/B-тестирование harness под конкретную задачу клиента, выдача best practices
- Консалтинг по промпт-инжинирингу для enterprise: аудит текущих промптов, рефакторинг, экономия на API-вызовах
- Фреймворк-обёртка для маленьких моделей с предустановленными harness-паттернами для типовых задач (классификация, экстракция, суммаризация)
- Курсы и сертификация по промпт-инжинирингу с фокусом на измеримый ROI — для DevOps, support, HR-систем
- Tooling для pre-registration и воспроизводимости AI-экспериментов — сейчас это делается руками, нужен продукт
- Результаты на узкой задаче (Kubernetes triage) — на других доменах паттерны могут не сработать
- Хайп вокруг промпт-инжиниринга может породить волну курсов-пустышек без реальной методологии
- Оптимальный harness сильно зависит от модели и задачи — универсального рецепта нет, нужна экспертиза
- Бизнес может недооценить важность воспроизводимости и предрегистрации, делать выводы на одном запуске
Это один из тех экспериментов, которые стоят сотни статей про «GPT-5 или Claude?». Парень взял маленькую модель, зафиксировал всё (веса, данные, метрики), варьировал только структуру промпта — и получил разброс в 22 процентных пункта. Это не магия, это инженерия: где правила, в каком порядке контекст, сколько шагов рассуждений. Худший вариант даже с дополнительными вызовами инструментов вернулся к базовой точности — переусложнение убило производительность.
Для бизнеса вывод простой: вместо апгрейда на дорогую модель или покупки API-лимитов, сначала проверьте, как написан ваш промпт. Скорее всего, там лежат десятки процентных пунктов точности. Для разработчиков — это напоминание, что промпт-инжиниринг требует той же строгости, что и обычный код: тесты, воспроизводимость, предрегистрация гипотез. Рынок инструментов для автоматической оптимизации промптов пока пустой — кто сделает удобный SaaS, выиграет.
Комментарии