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

Один принимает решения через цифры, другой — через доверие, третий — через статус. Языковая модель умеет «читать между строк» в тексте — распознавать психотипы, мотивацию и даже то, что человек не сказал. Эта глава научит вас слышать собеседника так, как это делают опытные переговорщики после десятилетий практики.

ПРИНЦИП

Каждый текст — это не только информация. Это слепок мышления автора. Длина предложений, выбор слов, количество оговорок, даже структура абзацев — всё это данные. Исследования в психолингвистике показывают устойчивые связи между стилем письма и личностными чертами: тревожные люди используют больше слов неопределённости («возможно», «наверное»), доминантные — короткие утвердительные предложения, ищущие признания — чаще ссылаются на мнение других.

Современные LLM (особенно GPT-5.4 и Claude Opus 4.7) обучены на гигантских массивах человеческих текстов и неосознанно усвоили эти паттерны. Им не нужен диплом психолога — им нужен правильный промпт.

Главное этическое правило этой главы:

мы не манипулируем, мы адаптируем коммуникацию.

Если описать собеседнику, что именно анализирует ИИ и как это используется, он должен понимать и принимать это.

ИНСТРУМЕНТ: Три уровня анализа

Уровень 1. Психологический портрет по переписке

Базовый сценарий: у вас есть переписка с клиентом, партнёром или сложным коллегой. Вы хотите понять, как с ним эффективно разговаривать.

Пример:

Ты — опытный психолог - эксперт в области коммуникаций. Проанализируй переписку ниже и составь рабочий портрет автора.

ПЕРЕПИСКА:

[вставьте текст]

Проанализируй по блокам:

1. СТИЛЬ КОММУНИКАЦИИ:

- Прямой или косвенный?

- Краткий или развёрнутый?

- Структурированный или эмоциональный?

2. МОТИВАЦИЯ И ЦЕННОСТИ:

- На что ссылается чаще: результат, процесс, отношения, статус, безопасность?

- Что явно волнует (повторяющиеся темы)?

- Какие темы обходит или замалчивает?

3. ТОЧКИ НАПРЯЖЕНИЯ:

- Где появляются оговорки, защитные формулировки, избыточные объяснения?

- Что он пытается контролировать?

4. КАК С НИМ РАБОТАТЬ:

- Оптимальный формат коммуникации (коротко/развёрнуто, цифры/образы, прямо/дипломатично)

- Какие аргументы подействуют?

- Чего избегать в общении?

Формат ответа: короткий рабочий портрет на полстраницы. Это гипотеза, не диагноз.

Уровень 2. Анализ по модели Большой Пятёрки (OCEAN)

Когда нужно больше точности, используем самую научно обоснованную модель личности из существующих.

Пример:

Проанализируй следующий текст по модели Большой Пятёрки (OCEAN).

ТЕКСТ:

[переписка или сообщение]

Для каждой черты: Уровень (Высокий / Средний / Низкий) + лингвистические сигналы + что это значит для коммуникации.

ОТКРЫТОСТЬ ОПЫТУ: ...

ДОБРОСОВЕСТНОСТЬ: ...

ЭКСТРАВЕРСИЯ: ...

ДОБРОЖЕЛАТЕЛЬНОСТЬ: ...

НЕВРОТИЗМ: ...

ИТОГ: доминирующие черты, главный мотиватор и демотиватор, оптимальный стиль общения.

ВАЖНО: это рабочая гипотеза на основе текста, не клинический диагноз.

Было: «Я написал клиенту стандартное КП с цифрами и кейсами, он ответил 'интересно, вернёмся позже'».

Стало: Прогнали его переписку через портрет.

Видим: высокая доброжелательность (избегает открытого «нет»), высокая потребность в определённости, средняя добросовестность. В ответе нет цифр — только тёплый тон, доверие, отсутствие давления. Клиент реально заинтересован, но ему нужно время, чтобы всё обдумать.

Уровень 3. Слова-ключи под психотип

Понимать портрет — половина дела. Вторая половина — знать конкретные слова и конструкции, которые резонируют с этим типом человека.

Пример:

На основе следующего профиля составь словарь коммуникации.

ПРОФИЛЬ:

[из предыдущего анализа]

СЛОВАРЬ:

- Слова и фразы, которые резонируют (15-20)

- Слова и фразы, которые создают трение (10-15)

- Конструкции для подачи идеи (3-5 шаблонов)

- Конструкции для работы с возражением (3-5)

- Чего никогда не делать (5-7 пунктов)

Было:

«Давайте подпишем договор до пятницы, а то цены вырастут».

Стало (для человека с высокой потребностью в определённости):

«Цены зафиксированы в этом предложении. Если решите до пятницы, смета не изменится — и мы запускаемся по плану».

Разница: первый вариант давит страхом. Второй — даёт предсказуемость и контроль.

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

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

Взять последнюю переписку с клиентом или коллегой.

Прогнать её через портрет (Уровень 1).

Сгенерировать словарь ключей (Уровень 3).

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

Отправить и сравнить реакцию со своей обычной.

Если собеседник ответил быстрее, теплее или конкретнее, чем обычно — техника работает.

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

Глава 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), чтобы не пропустить конкретные модели.