Проблема: Промпты не масштабируются
Корпоративные приложения на базе больших языковых моделей (LLM) часто начинаются как прототипы, где логика работы держится исключительно на промптах и контексте. Однако при выходе на продакшн возникают требования к границам источников, маршрутизации сущностей, «контрактам» на ответы и воспроизводимым следам (traces). Авторы статьи из arXiv (2607.08028) предлагают решение: перенос детерминированного поведения из промптов в код, манифесты, схемы и артефакты валидации.
Методология: Harness Engineering
Предложенный подход реконструирует архитектуру LLM-агента так, чтобы:
- Детерминированная логика была зашита в код и валидационные артефакты.
- Замена модели оставалась возможной без потери гарантий.
- Источники данных оставались единственным авторитетом для runtime-ответов.
Эксперимент: 25 компаний и 3 модели
Для проверки гипотез исследователи использовали публичные данные пяти крупных корейских корпоративных групп (25 публичных компаний). Были протестированы три ключевых вопроса, результаты которых сведены в таблицу:
| Критерий оценки | Результат | Значение для бизнеса |
|---|---|---|
| Сохранение контрактов | 100% успешных валидаций | Гарантия соответствия ответов источникам и стандартам |
| Устойчивость к замене модели | 270/270 проходов успешно | Модульность: можно менять LLM без переписывания логики |
| Промпты vs Код | Промпты пропускали ошибки; код блокировал их | Только программная валидация обеспечивает безопасность |
| Сравнение с Guardrails | Harness: 120/120 утилиты; Guardrails: 88/120 | Отсутствие ложных отказов (over-refusal) при сохранении безопасности |
Ключевой вывод: Код важнее промптов
Самое важное открытие исследования: гарантии, обеспечиваемые кодом (code-owned guarantees), невозможно воспроизвести только инструкциями в промпте. При фиксированной модели LLM, но изменении слоя enforcement, промпты позволяли нарушать контракты (например, утечка внутренних трасс или неверный язык рекомендаций). Внешние guardrails-решения блокировали нарушения, но снижали полезность системы до 73% (88 из 120 сценариев). Предложенный же Harness сохранил полную полезность (120/120), полностью блокируя нарушения.
Итог
Методология Harness Engineering предоставляет переиспользуемый инженерный паттерн для превращения исследовательских прототипов в аудируемые приложения с версионированными источниками, контролем и артефактами валидации. Это закрывает критический разрыв между экспериментальной AI-разработкой и надежным корпоративным софтом.
Источник: arXiv cs.AI ↗