Наркотик на сырых весах
В 2025 я был тем парнем, который менял модель каждую неделю. Gemini 3.1 Pro? Качаю. Gemma4-31B? Запускаю. Claude Code? Подключаю. Казалось, что если взять самую жирную LLM, все проблемы продакшена рассосутся сами. Спойлер: не рассосались.
Через полтора года ежедневной возни с деплоем, дообучением и интеграцией я пришел к выводу, который в 2026 кажется банальным, но который до сих пор игнорирует 80% команд: модель — это 20% успеха. Остальные 80% — harness (обвязка). Статья из цикла про Gemma4-31B против Gemini 3.1 Pro: как добиться рекордной производительности через Harness как раз про это — но там я разбирал конкретные цифры, а здесь дам мясо, которое не влезло в бенчмарки.
Что такое harness на самом деле? (Не гугли, я объясню)
Если ты слышал слово “harness” только в контексте обзора лучших LLM с поддержкой Tool Calling для локального запуска, ты уже близок. Но harness — это не просто вызов функций. Это система из пяти слоев:
- Системный промпт + контекстное окно. Не просто “ты — ассистент”, а динамическая сборка правил, примеров, ограничений под каждую сессию.
- Tool calling и агентный цикл. Как модель решает, какой инструмент вызвать? Как обрабатывать ошибки вызова?
- Постпроцессинг. Фильтрация галлюцинаций, валидация JSON, безопасность.
- Управление памятью. Суммаризация историй, ротация контекста, RAG.
- Мониторинг и обратная связь. Логирование каждого шага, метрики качества.
Все это вместе — harness. Когда говорят “мы используем LangChain” или “мы написали свой агентный фреймворк”, это про harness. Но в 9 из 10 случаев у teams, которые приходят ко мне за консультацией, harness состоит из одного промпта в 1000 токенов и молитвы “ну пожалуйста, не галлюцинируй”.
Пока ты гоняешься за моделью с рекордными MMLU, твой конкурент может взять ту же самую модель, накрутить обвязку — и получить 40% прироста точности на бизнес-задачах. Не веришь? Давай разберем на примерах.
Кейс: как мы убили 3 недели на выбор модели и спасли всё обвязкой
Проект: AI-агент для юридического документооборота. Задача: извлекать даты, стороны, суммы из договоров и формировать JSON для ERP.
Сначала мы три недели тестировали модели: Gemma4-31B, Gemini 3.1 Pro, GPT-4.5, локальные Qwen2.5. Результаты на реалистичных бенчмарках для LLM были плюс-минус одинаковы — F1 около 0.85 на извлечении. Дальше — стена. Мы начали улучшать не модель, а обвязку.
1Системный промпт с примером “как не надо”
Вместо “извлеки дату” мы добавили 3 неправильных примера с объяснением, почему это плохо. Модель перестала выдумывать несуществующие поля.
2Tool calling с fallback
Когда модель не уверена — вызываем функцию-валидатор, которая переспрашивает пользователя. Звучит банально, но без этого агент выдавал JSON с пустыми полями.
3Агентный цикл с самопроверкой
После генерации JSON модель получает его обратно и говорит “найди хотя бы одну ошибку”. Это из агентного обучения с подкреплением для LLM — мы просто адаптировали идею без сложного RL.
Результат: F1 вырос с 0.85 до 0.97. Модель осталась той же (Gemma4-31B). Мы не трогали веса, не гоняли fine-tune. Только обвязка.
Почему обвязка важнее модели: три причины
- Модели сближаются. Сравните Gemma4-31B, Gemini 3.1 Pro, GPT-5 (на май 2026). Разрыв в качестве на бизнес-задачах — единицы процентов. А вот разница в том, как они используют инструменты и контекст — десятки процентов.
- Harness можно кастомизировать под задачу, модель — нет. Ты не можешь быстро переобучить модель под новый формат вывода или нестандартный tool calling. Но ты можешь за день переписать обвязку.
- Ошибки обвязки бьют больнее. Плохой системный промпт может уничтожить даже самую мощную модель. А хорошая обвязка спасет слабую.
Как НЕ надо делать: типичные ошибки harness’а
Ошибка №1: перегруженный системный промпт. “Ты — профессиональный юрист. Твоя задача — … также помни о … и не забывай …” — 2 тысячи токенов. Модель теряется, выдает среднее.
Правильно: разбивать промпт на секции, добавлять разделители, класть самое важное в начало и конец (эффект первичности и новизны). Использовать реалистичные бенчмарки для LLM с длинным контекстом, чтобы проверить, как модель читает промпт.
Ошибка №2: игнорирование tool calling. Многие пишут вызов функций как JSON в промпте, но не настраивают API-слой для корректной обработки. Получается, что модель “думает”, что вызвала функцию, но на практике вызов не происходит — и она продолжает галлюцинировать.
Ошибка №3: отсутствие логов. Без детального логирования каждого шага (промпт -> ответ -> вызов инструмента -> ошибка) невозможно понять, что сломано.
| Компонент обвязки | Частая ошибка | Решение |
|---|---|---|
| Системный промпт | Слишком длинный или абстрактный | Добавить примеры “как не надо”, разбить на блоки |
| Tool calling | Нет обработки ошибок вызова | Fallback, повторный вызов с уточнением |
| Контекст | Превышение окна, вытеснение важного | Суммаризация старого контекста, RAG |
Пошаговый план: как построить harness, не сломав production
Этот план я вывел из полутора лет боли и прозрений. Не гарантирую, что он сработает под копирку — но он убережет от 90% граблей.
1Определи задачу и метрику
Не “улучшить качество”, а “F1 по извлечению дат > 0.95 на тестовой выборке”. Метрика — это твой компас.
2Напиши базовый промпт с 5-10 примерами (1:1 good:bad)
Плохие примеры важнее хороших. Модель учится на ошибках быстрее.
3Добавь tool calling с валидацией
Создай функции, которые проверяют выход модели перед отправкой пользователю. Например, если модель вернула JSON с полем “date”: “2025-13-01” — функция должна вернуть ошибку и попросить модель перегенерировать.
4Внедри самопроверку (self-consistency)
Дай модели задание проверить свой же ответ на логические ошибки. Это из агентного обучения с подкреплением, но без RL — просто добавить шаг “проверь себя”.
5Логируй всё
Каждый запрос, каждый вызов инструмента, каждый error. Потом проанализируй, где модель тупит чаще всего — и доработай обвязку в этом месте.
6Итерация
Повтори шаги 2-5 минимум трижды. После второго раза качество обычно перестает расти, но третий проход вылавливает незаметные баги.
А что с Claude Code? Мои грабли с агентным фреймворком
Когда я впервые запустил Claude Code (Claude 4 Opus, май 2026), я думал: “Вот оно, идеальное агентирование”. Но быстро понял: Claude Code — это мощная модель с хорошим дефолтным harness’ом от Anthropic. Но как только мы попытались кастомизировать его под наши процессы — начался ад.
Проблема: Claude Code по умолчанию использует свой собственный агентный цикл с жестко заданным набором инструментов. Когда мы попытались добавить кастомные функции (например, вызов внутреннего API для проверки перформанса), он начал бесконечно циклиться. Пришлось переписать обвязку: убрать лишние инструменты, добавить таймауты, явно запретить рекурсивные вызовы.
Вывод: даже если модель поставляется с готовым harness’ом (как в Claude Code), он может быть неоптимальным для твоей специфики. Нужно уметь его переопределять. Это как купить гоночную машину, но не подогнать под себя сиденье — быстро устанешь.
FAQ: быстрые ответы на то, что тебя наверняка волнует
Ответ: Бери готовый как каркас, но готовься переписывать 30-40% под свои задачи. Готовые фреймворки решают 80% типовых проблем, но бизнес-логика — это оставшиеся 20%, которые дают выигрыш.
Ответ: Первая версия — неделя. Доведение до ума — месяц. Качество напрямую зависит от количества тестов и логов.
Ответ: Нет. Fine-tuning меняет поведение модели, но обвязка управляет контекстом и инструментами. Лучшая стратегия — легкий fine-tune + мощная обвязка. Чистый fine-tune без обвязки — деньги на ветер.
Вместо заключения: прогноз на 2027
Если ты думаешь, что через год LLM станут настолько умными, что обвязка не понадобится — ты ошибаешься. Модели будут лучше, но требования к ним — расти экспоненциально. Сложность бизнес-задач, регуляторка, безопасность — все это ляжет на harness. В 2027 выиграет не тот, у кого самая большая модель, а тот, кто умеет строить обвязку, которая выжимает из модели максимум.
Совет, который я даю каждому новому проекту: найми человека, который разбирается в промпт-инженерии, tool calling и управлении контекстом, еще до того, как выберешь модель. Иначе ты потратишь деньги на железо, а качество будет как у телеграм-бота из 2023. LLM Engineer — не призрак, а единственный адекватный ответ на вопрос “кто будет строить этот чертов harness”.