Как контекстная инженерия делает слабую локальную LLM надёжным агентом

Автор статьи на Habr показал: для локальной языковой модели, которая работает в закрытом контуре на ограниченном железе, надёжность агента определяет не размер модели, а то, как устроен её контекст.

Почему просто «взять модель побольше» не работает

Когда модель крутится локально — за периметром компании, на ограниченном железе — увеличить её попросту некуда: нет возможности взять облачную топ-модель с большим числом параметров. Автор утверждает, что в этих условиях главный рычаг качества — не сама модель, а контекст: что именно ей показывают, в каком порядке и как отфильтровывают лишнее.

Из чего складывается «правильный» контекст

По описанию автора, контекст — это не просто вставленный кусок текста, а сборка, учитывающая три параметра: кто задаёт вопрос, откуда он пришёл и о чём именно спрашивает. К этому добавляются ещё два элемента:

• Честный порог релевантности — модели показывают только то, что действительно относится к вопросу, а не всё подряд «на всякий случай»
• Продуманный порядок секций — важная для ответа информация ставится так, чтобы модель её не «потеряла» среди второстепенных деталей

Иными словами, для одного и того же вопроса контекст будет разным в зависимости от роли пользователя, канала обращения и темы: сотруднику поддержки и разработчику имеет смысл показывать разные фрагменты базы знаний, даже если формально они спрашивают «об одном и том же».

Чем сильная модель отличается от слабой в этом сценарии

Ключевое наблюдение статьи — то, как модель прощает ошибки в организации контекста, зависит от её размера и мощности. На сильной облачной модели небрежно собранный контекст часто прощается запасом по reasoning — модель сама разберётся, что важно, а что нет. На средней локальной модели этого запаса нет: тот же небрежный контекст напрямую ломает качество ответов.

На практике это означает, что тестировать промпты и context-pipeline нужно именно на целевой (слабой) модели, а не на топовой облачной — то, что выглядит рабочим на сильной модели, может рассыпаться при переносе на локальную.

Где это особенно критично

Локальные модели чаще всего выбирают там, где данные не могут покидать периметр — банки, госсектор, медицина, промышленность. Именно в таких средах у команды нет опции «просто взять модель посильнее»: железо и лицензии на топовые облачные API либо недоступны, либо запрещены политикой безопасности. В этих условиях контекстная инженерия — единственный рычаг, которым можно управлять напрямую, в отличие от архитектуры самой модели.

Автор отдельно подчёркивает разницу между «контекстом вообще» и «контекстом под конкретный запрос»: если система один раз собрала универсальный набор документов и подаёт его модели без разбора, независимо от того, кто и о чём спрашивает, шансы получить обрывочный или ошибочный ответ на слабой модели заметно выше, чем при точечной сборке под каждый случай.

Что это значит

Для команд, которые вынуждены — по требованиям безопасности, бюджету на железо или по контуру данных — работать с локальными, не самыми мощными моделями, дисциплина контекстной инженерии становится не опциональным улучшением, а условием, без которого агент просто не работает надёжно.