Не очеловечивать ИИ-модель: как проектировать систему вокруг ограничений
Самая частая ошибка при работе с большими языковыми моделями звучит почти невинно: "модель поняла", "модель запомнила", "модель сама решит", "модель увидит, что важно". Эти фразы удобны в разговоре, но опасны в проектировании. Они заставляют строить систему так, будто ИИ работает как человек.
Практически полезнее другой язык: модель получает контекст, продолжает текст, вызывает инструменты, опирается на источники, может ошибаться и нуждается в проверке. Тогда становится видно, что вокруг модели нужна архитектура: память, правила, доступы, журналы, фильтры, тесты, источники и человеческая приемка.
В материале Anthropic про эффективных агентов агентные системы описаны через простые паттерны: workflow, routing, tool use, evaluator-optimizer, orchestrator-worker. В гайде OpenAI по агентам похожий слой собирается через инструменты, guardrails и handoffs. Оба подхода полезны тем, что не требуют верить в "разум агента". Они заставляют проектировать контур работы.
Главное:Не спрашивайте, "понимает ли модель". Спрашивайте, какой контекст она получила, какие инструменты может вызвать, где берет факты, как проверяется результат и кто отвечает за финальное решение.
Что ломается при очеловечивании
Когда модель называют "сотрудником", легко забыть, что у нее нет человеческой памяти проекта, опыта ответственности и здравого смысла в бытовом значении. Она может уверенно продолжить неверный контекст, перепутать версии документов, принять фальшивую инструкцию за важную, сослаться на слабый источник или красиво объяснить ошибку.
Это не повод не использовать ИИ. Это повод строить систему честнее. Если нужна память, ее надо проектировать. Если нужны факты, нужны источники. Если есть риск вредной инструкции, нужны фильтры и правила. Если результат важен, нужна приемка.
Как проектировать вокруг ограничений
| Человеческая метафора | Более точная рабочая формулировка | Что проектировать |
|---|---|---|
| модель помнит | модель получила контекст или доступ к памяти | хранилище, срок актуальности, источник |
| модель понимает | модель строит ответ из входных данных | формат входа, примеры, критерии |
| модель сама решит | модель выберет следующий шаг по заданным правилам | policy, handoff, стоп-условия |
| модель проверит | модель может запустить проверку, если ей дали инструмент | тесты, аудит, источники |
| модель безопасна | система снижает риск в известных точках | guardrails, журнал, права доступа |
Начните с карты задачи. Что входит в систему? Текст, файлы, таблицы, переписка, сайт, база знаний, API? Что должно выйти? Ответ, документ, код, решение, публикация, отчет? Где ошибка будет дешевой, а где дорогой?
После этого разделите работу на слои. Модель не должна одновременно быть памятью, источником фактов, судьей качества и исполнителем действий. Один слой хранит данные. Другой дает инструменты. Третий проверяет результат. Четвертый решает, когда нужен человек.
- 1Шаг 1
Вход: какие данные получает модель и кто отвечает за их качество.
- 2Шаг 2
Память: что хранится отдельно, как обновляется и когда устаревает.
- 3Шаг 3
Инструменты: что модель может вызвать, а что только предложить.
- 4Шаг 4
Проверка: какие тесты, источники или ревью подтверждают результат.
- 5Шаг 5
Границы: где система обязана остановиться и передать человеку.
Почему это еще и вопрос безопасности
Если система верит всему, что попало в контекст, ее легко сбить. OWASP в разделе LLM01 Prompt Injection описывает риск, когда вредная инструкция прямо или косвенно заставляет модель вести себя не так, как задумано. Для агентных систем это особенно важно: модель может не только отвечать, но и вызывать инструменты.
Поэтому фраза "агент сам разберется" должна настораживать. Без фильтра источников, ограничений инструментов и журнала действий он может очень быстро сделать уверенное, но неправильное действие.
Мы уже разбирали похожую тему в статье про заземление ИИ-агента источниками и в материале про защиту ИИ-базы от плохих документов. Здесь общий принцип: модель не должна быть единственным местом, где живет доверие.
Рабочая карточка
Когда использовать: при проектировании агента, базы знаний, RAG, внутреннего помощника, редакционной фабрики или автоматизации с инструментами.
Что подать на вход: описание задачи, типы данных, доступные инструменты, рисковые действия, критерии качества и список мест, где нужен человек.
Что сделать по шагам:
- Заменить человеческие метафоры на рабочие функции.
- Отделить память от текущего контекста.
- Отделить источник фактов от текста ответа.
- Описать инструменты и права доступа.
- Добавить проверку результата.
- Задать стоп-условия и handoff человеку.
Как проверить качество: любую важную часть ответа можно объяснить через источник, правило, инструмент или проверку, а не через "модель так решила".
Когда не использовать: если задача разовая, низкорисковая и ответ не будет действием в системе. Тогда достаточно обычного чата и человеческой проверки.
Сильная ИИ-система начинается не с веры в почти-человека внутри модели. Она начинается с трезвого контура: данные, инструменты, правила, проверки и ответственность. Чем меньше магии в описании, тем надежнее работа.
