Инженерия интеллекта от промта к системам ИИ

Глава 4. Анатомия агента, или как написать алгоритм поведения текстом

Я поверил им трижды.

Сначала — когда попросили логотип.

«Сделай, пожалуйста, ты же умеешь. Мы потом оплатим».

Я умел. Я сделал. Потом — рекламное видео.

«Ты же можешь, ты же инженер, у тебя нейросети».

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

Они хвалили. Говорили «отлично».

И добавляли: «В следующий раз обязательно оплатим». Следующий раз наступал, и появлялась новая просьба. Платежа не было. Я был не инженером. Я был бесплатным генератором, в который закидывают запрос — и он выдает картинку, видео, мелодию, текст.

Тогда я ещё не знал, что я нарушил главный принцип работы агента. У меня не было формализованного протокола передачи результата. Не было Definition of Done(критерия готовности).

Не было чётко прописанного условия, при котором работа считается завершённой, а оплата — обязательной.

Я действовал как чат-бот: получил запрос — ответил. Получил следующий — ответил. Без состояний, без границ, без условий эскалации.

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

Если бы я вёл себя тогда как спроектированный агент, я бы сказал:

«Вот коммерческое предложение с условиями. Результат будет передан после подтверждения и предоплаты».

И это спасло бы меня от месяцев бесплатного труда.

Вот почему эта глава — первая в Части II. Потому что прежде чем строить сложные системы, вы должны понять разницу между чатом и агентом. Чат — это вежливый исполнитель, который ждёт следующее сообщение. Агент — это сущность, которая знает, когда задача выполнена, и не боится закрыть сессию.

Вот Вы написали идеальный системный промпт. Модель отвечает прекрасно: в нужном тоне, с правильной структурой и без воды. Вы воодушевлены и отдаёте этот промпт коллегам. Они пользуются. И через три дня всё ломается.

Почему?

Потому что вы написали инструкцию для чата. А требовалась инструкция для агента. Разница принципиальная.

Чат ждёт от пользователя команду и выполняет её. Агент выполняет работу. Чат отвечает на сообщение. Агент движется к цели.

Вот как это выглядит на практике:

Инструкция для чата: «Ты — опытный маркетолог. Отвечай кратко и по делу. Используй деловой тон. Если не знаешь ответа — скажи об этом.»

Прекрасная инструкция. Модель будет вести себя как маркетолог в любом диалоге. Но если коллега напишет: «Собери мне заявки за май, сравни с апрелем и пришли сводку в Excel»,

— чат ответит вежливо: «Я могу помочь с маркетинговыми вопросами. За какой период нужны данные?» и будет ждать следующего сообщения.

Инструкция для агента (решающая ту же задачу): «При запросе отчёта:

1. Проверь тип отчёта в запросе (месяц, регион, менеджер).

2. Если тип не указан — запроси одним предложением.

3. Обратись к базе данных SQL и получи нужные цифры.

4. Сверь результат с контрольными суммами за прошлый период.

5. Если отклонение больше 15 % — поставь в сводке тег [ТРЕБУЕТ ПРОВЕРКИ].

6. Отправь результат в Slack-канал #ежедневные-отчёты.

7. После отправки напиши пользователю: «Готово. Сводка в #ежедневные-отчёты».»

Первый вариант описывает, как вести себя. Второй — что делать. Агент не ждёт продолжения диалога. Он выполняет последовательность шагов, проверяет результат и завершает задачу.

ПРИНЦИП

Поведенческая инструкция для агента строится вокруг трёх элементов:

1. Цель. Что должно быть достигнуто. Одна задача, одно завершённое состояние.

2. Алгоритм. Последовательность действий с условиями перехода между ними. «Сделай А. Проверь критерий X. Если да — переходи к Б. Если нет — вернись к А и учти ошибку.»

3. Критерий завершения. Как модель понимает, что работа выполнена и пора выдавать финальный результат. Мы называем это Definition of Done (DoD) — формальный, проверяемый список признаков готовности.

Без любого из этих трёх элементов инструкция неполная, и поведение модели будет непредсказуемым в потоке реальных задач.

ИНСТРУМЕНТ

Паттерн 1: Алгоритм с циклом проверки

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

Пример:

Твоя задача — [одна конкретная цель].

Алгоритм работы:

Шаг 1. [Первое действие].

Шаг 2. Проверь результат по критерию [конкретный критерий].

Шаг 3. Если критерий выполнен — переходи к Шагу 4.

Если нет — вернись к Шагу 1, учтя, что именно не сработало.

Шаг 4. Выдай финальный результат.

Не выдавай результат, пока Шаг 2 не пройден полностью.

Пример для редакторского ассистента:

Твоя задача — отредактировать текст пользователя.

Алгоритм:

1. Прочитай текст целиком. Не правь.

2. Выдели три проблемы: нарушения логики между абзацами, повторения одной мысли, утверждения без подтверждения.

3. Перепиши, устранив проблемы.

4. Проверь: остались ли утверждения без подтверждения?

5. Если да — доработай эти места. Если нет — выдай финальный текст.

Критично, чтобы критерии на шаге проверки были однозначными. «Хороший текст» — не критерий. Модель будет интерпретировать его по-разному. «Остались ли утверждения без доказательств» — критерий: ответ либо «да», либо «нет».

Паттерн 2: Иерархия правил

В диалоге с агентом рано или поздно возникает конфликт. Пользователь просит то, что противоречит системной инструкции. Без явной иерархии модель начинает «договариваться» и постепенно отступает от правил.

Пример:

Приоритеты, от высшего к низшему:

УРОВЕНЬ 1 (абсолютный): Правила безопасности и конфиденциальности.

Не переопределяются ни при каких условиях.

Если запрос противоречит — вежливо откажи и объясни причину.

УРОВЕНЬ 2: Формат вывода, заданный в системной инструкции.

Не изменяется по запросу пользователя.

Если запрашивается другой формат — объясни, что формат фиксирован.

УРОВЕНЬ 3: Тон и стиль.

Адаптируются в рамках заданных границ. Числовая нумерация снимает неоднозначность. Модель сама разрешает конфликт, сверяясь с приоритетами.

Паттерн 3: Ролевая декомпозиция «Генератор — Критик — Редактор»

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

ПРИМЕР:

Работай в три этапа:

ЭТАП 1 — ГЕНЕРАТОР.

Напиши черновик. Приоритет — полнота идей. Не сокращай, не редактируй.

Выведи: —— ГЕНЕРАТОР ЗАВЕРШЁН ——

ЭТАП 2 — КРИТИК.

Возьми черновик. Найди три слабых места по критериям:

- логические переходы между аргументами,

- отсутствие подтверждения у ключевых тезисов,

- соответствие структуры задаче.

Для каждого — одна конкретная рекомендация.

Выведи: —— КРИТИК ЗАВЕРШЁН ——

ЭТАП 3 — РЕДАКТОР.

Возьми черновик (Этап 1) и замечания (Этап 2).

Перепиши, устранив проблемы. Сохрани смысловую полноту оригинала.

Пользователю выдавай только результат Этапа 3.

Маркер — ГЕНЕРАТОР ЗАВЕРШЁН — это не украшение. Это явный сигнал модели:

«режим сменился, теперь ты не создаёшь, а критикуешь».

Без таких сигналов модель продолжает дополнять черновик вместо того, чтобы его разбирать.

Было: «Напиши коммерческое предложение для клиента из логистики».

Стало: Ты — агент по подготовке КП. Цель: подготовить коммерческое предложение, которое клиент поймёт за 2 минуты чтения.

Алгоритм:

1. Проанализируй бриф клиента. Выдели явно: главную боль клиента, его бюджетный диапазон, его критерий выбора.

2. Напиши КП по структуре: боль наше решение доказательства (кейсы) следующий шаг с дедлайном.

3. Проверь КП по DoD:

Каждое утверждение подкреплено примером или цифрой.

Объём — не более 1 страницы, 300–350 слов.

Нет слов «инновационный», «уникальный», «команда профессионалов».

Есть конкретный следующий шаг с датой.

Если DoD пройден — отдай результат. Если нет — доработай.

Разница: вы не написали модельному ассистенту, «как писать КП». Вы дали ему алгоритм, критерии приёмки и границы свободы.

КРИТЕРИИ ГОТОВНОСТИ ГЛАВЫ (Quick Win)

Вы освоили эту главу, если можете прямо сейчас:

1. Взять свою регулярную рабочую задачу (письмо клиенту, отчёт, анализ чего-либо).

2. Описать её как алгоритм минимум из трёх шагов.

3. Сформулировать Definition of Done — три измеримых критерия, по которым вы поймёте, что результат готов, даже не читая его внимательно.

4. Добавить иерархию приоритетов: что самое важное в этой задаче, а что можно адаптировать.

Если справились — вы перешли Рубикон. Вы только что написали первую агентную инструкцию.

Это вторая глава Части II — мы даём агенту долговременную память и доступ к внешним знаниям.

Глава 5. Память агента: проектируем поиск знаний (RAG)

Вы запустили агента поддержки. Он вежлив, быстр и отлично держит стиль. Но на третий день эксплуатации приходит клиент и пишет:

«Что там с моим возвратом? Номер заказа — 14592».

Агент отвечает:

«Для оформления возврата, пожалуйста, зайдите в личный кабинет и следуйте инструкциям».

Вежливо, но бесполезно. Клиент взрывается. Почему это произошло?

Потому что модель отвечала из своей общей памяти. Она не знала, что заказ 14592 был возвращён вчера, что деньги зависли, и что по этому кейсу уже открыт тикет с пометкой «срочно». Она действовала как очень начитанный, но слепой стажёр. Вы дали агенту блестящие инструкции, но не дали ему память.

Языковая модель обучена предсказывать следующий токен, а не извлекать конкретные факты из внешней базы данных.

Когда задача требует точного ответа, основанного на актуальных корпоративных данных, модель без доступа к ним сделает две вещи: либо честно признается в незнании (хорошо, но бесполезно), либо, что опаснее, придумает правдоподобный ответ.

Это называется галлюцинацией, и для бизнес-систем это неприемлемо.

ПРИНЦИП

Решение существует и называется RAG — Retrieval-Augmented Generation (Генерация, дополненная поиском). Принцип прост: перед тем как модель начнёт отвечать, вы находите нужные данные в своей базе знаний и подставляете их прямо в контекст запроса. Модель отвечает, опираясь на эти данные, а не на статистические паттерны из своего обучения.

Вот как выглядит полный RAG-пайплайн из трёх шагов:

1. Пользователь задаёт вопрос.

2. Система ищет релевантные документы, фрагменты или цифры в базе знаний компании.

3. Эти данные подставляются в промпт, и модель отвечает строго на их основе.

Звучит как серебряная пуля. Но практика 2026 года, включая исследования в медицинской и финансовой сферах, показывает важный нюанс:

RAG действительно резко снижает галлюцинации, но не устраняет их полностью. Модель может выдать «верную цитату из неверного места» или проигнорировать найденный документ, добавив то, чего там не было.

Поэтому даже с RAG нам нужна постобработка и проверка, которую мы разберём в следующих главах.

Но сначала — фундамент.

Главная инженерная сложность RAG спрятана в слове «найти». На практике это три абсолютно разные задачи, и для каждой нужен свой инструмент.

ИНСТРУМЕНТЫ

Тип 1: Векторный поиск — поиск по смыслу

Это ваш основной инструмент для работы с неструктурированными текстами: регламентами, инструкциями, статьями, архивами переписки.

Принцип работы:

Текст превращается в эмбеддинг — длинный вектор (набор чисел), где тексты с похожим смыслом расположены близко друг к другу. Запрос пользователя также превращается в вектор, и система ищет ближайшие к нему документы в этом пространстве. Благодаря этому запрос «регламент увольнения» найдёт документ «порядок расторжения трудового договора», даже если слова не совпадают.

Без правильно настроенной нарезки (чанкинга) этот механизм бесполезен. Слишком большой чанк — вектор размывается, и документ срабатывает на любой запрос. Слишком маленький — теряется контекст. Рабочий стандарт в индустрии сегодня — 300–500 токенов с перекрытием в 10–15% между соседними фрагментами.

Для быстрого старта можно использовать следующую инструкцию:

Пример:

Твоя задача — подготовить документ для загрузки в базу знаний (RAG).

Разбей текст ниже на смысловые блоки со следующими правилами:

- Каждый блок содержит одну завершённую мысль (примерно 200–400 слов).

- Если мысль длиннее — раздели по логической границе.

- Начинай каждый блок с заголовка раздела, к которому он относится.

- Добавь к каждому блоку 3–5 ключевых тем для последующей фильтрации.

Текст:

[ваш документ]

После нарезки каждый блок отправляется в векторную базу данных.

По состоянию на 2026 год выбор здесь широк:

легковесные open-source решения вроде pgvector (работает прямо в PostgreSQL) и ChromaDB для прототипов;

промышленные гибридные системы вроде Qdrant (показывает отличные результаты в бенчмарках облачных решений для 2026 года), Pinecone и Weaviate;

энтерпрайз-гиганты Elasticsearch и Vespa, предоставляющие комплексные AI-поисковые платформы.

Тип 2: Text-to-SQL — поиск по точным значениям

Векторный поиск бесполезен, если клиенту нужно узнать, «сколько денег вернули Иванову 5 марта». Здесь нужна работа с реляционными базами данных и SQL.

Современные модели (такие как GPT-5.4 или Claude Opus 4.7) отлично пишут SQL-запросы по описанию на естественном языке, но при критически важном условии: они должны знать схему таблиц. Без неё модель начинает угадывать названия столбцов и получает синтаксические ошибки.

Формула успеха: явно описать в промпте структуру таблиц и ключевые особенности данных.

Пример:

База данных со следующей структурой:

Таблица: sales

- id (INT, уникальный)

- date (DATE, формат YYYY-MM-DD)

- product_name (VARCHAR)

- category (VARCHAR, допустимые значения: "Ноутбуки", "Мониторы", "Периферия")

- quantity (INT)

- total (DECIMAL, руб.)

ВАЖНО: возвраты хранятся с отрицательным quantity. Данные — с 01.01.2025.

Задача: [ваш вопрос на естественном языке].

Напиши SQL-запрос и одним предложением объясни, что он делает.Указание конкретных значений в категориях (как «Ноутбуки», а не «Ноутбук») устраняет целый класс ошибок, связанных с несовпадением строк в фильтрах.

Тип 3: Графовые базы данных — поиск по связям

Есть вопросы, на которые не ответят ни векторный, ни SQL-поиск.

«Кто из сотрудников общался с контрагентом X через посредников?», «Какие компании связаны с контрагентом Y через общих учредителей?».

Это вопросы о структуре отношений, и для них существует граф.

Графовая база данных хранит информацию в виде узлов (люди, компании, документы) и рёбер (связей между ними с указанием типа: «является руководителем», «подписал», «аффилирован с»). С ростом сложности корпоративных данных всё более востребованным становится GraphRAG — подход, который объединяет графовые и векторные базы для повышения точности ответов.

На практике в 2026 году популярны Neo4j и специализированные open-source решения вроде Nexus (гибрид графа и векторного поиска для RAG) и OverGraph (встроенная графовая база данных с поиском, работающая прямо внутри процесса). Крупные вендоры,

такие как Memgraph и NebulaGraph, также выпускают собственные GraphRAG-решения.

Тип 4: Гибридный поиск — когда нужно всё и сразу

В реальных бизнес-задачах почти никогда не нужен только один тип поиска. Представьте интернет-магазин: пользователь пишет «ноутбук для дизайнера, бюджет до 150 000». Здесь нужно совместить:

Семантический поиск (векторный), чтобы найти общее описание.

Ключевой поиск (BM25), чтобы не пропустить конкретные модели.

Числовые фильтры, чтобы отсечь всё, что выше 150 000.

Это называется гибридным поиском (Hybrid Search). Результаты объединяются алгоритмом Reciprocal Rank Fusion (RRF): документ, попавший в топ и векторного, и ключевого поиска, получает высший итоговый ранг. В инженерной практике 2026 года стандарт усложнился: после слияния применяется модель-реранкер (часто — специализированная легковесная LLM), которая оценивает пару «запрос-документ» и пересортировывает результат для максимальной релевантности.