ИИ, за который платят. Создавайте полезные сервисы и продавайте результат

Инструмент, а не волшебная кнопка

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

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

Главный принцип

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

Три уровня практической ценности

Один и тот же инструмент приносит разную пользу в зависимости от того, насколько глубоко он встроен в работу. Условно можно выделить три уровня.

Личная скорость. Человек использует модель как собеседника для идей, редактора, помощника по структуре или переводчика сложного материала на понятный язык. Выигрыш измеряется сэкономленными минутами и количеством качественных вариантов.

Повторяемый процесс. Команда превращает удачные запросы в шаблоны, добавляет правила проверки, подключает корпоративные документы и распределяет роли. Выигрыш измеряется стабильностью, меньшим числом ошибок и сокращением времени цикла.

Система, создающая результат для клиента. Модель становится частью продукта или услуги: помогает консультанту готовить рекомендации, магазину — отвечать на типовые вопросы, образовательной платформе — давать персональные объяснения. Выигрыш измеряется выручкой, удержанием, скоростью обслуживания и качеством решений.

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

Как идея превращается в систему

В феврале 2024 года небольшая студия «Северный текст» из Нижнего Новгорода получила заказ от сети из двенадцати частных клиник. Клиенту требовалось каждую неделю готовить публикации для социальных сетей, ответы на типовые вопросы пациентов и черновики писем после приёма. Раньше два редактора тратили на это около сорока часов в неделю, а материалы всё равно отличались по тону и иногда противоречили внутренним инструкциям.

Руководитель студии Марина Волкова не стала продавать клиенту «тексты от нейросети». Вместо этого команда собрала базу из утверждённых медицинских формулировок, списка запрещённых обещаний, примеров допустимого тона и маршрутов эскалации к врачу. В Notion хранились правила, в Make запускалась обработка новых заявок, а итоговые черновики проходили проверку редактора и медицинского координатора. Через шесть недель среднее время подготовки недельного пакета сократилось с сорока до четырнадцати часов. При этом клиент платил не за генерацию слов, а за предсказуемый контент-процесс с понятной ответственностью.

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

Почему разговорный интерфейс меняет бизнес

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

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

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

Что эта книга будет делать

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

Каждая тема будет рассматриваться через один и тот же вопрос: какое решение должен принять человек или система после ответа модели? Такой подход защищает от соблазна измерять качество красотой текста. Иногда лучший ответ — короткая классификация, иногда — уточняющий вопрос, иногда — передача живому специалисту. Разговорный ИИ полезен не тогда, когда говорит больше, а тогда, когда помогает двигаться к цели с меньшими потерями.

Этап

Главный вопрос

Практический результат

Понимание языка

Что на самом деле хочет пользователь?

Намерение, сущности, контекст и тон

Создание ответа

Какая информация нужна для решения?

Текст, поиск, расчёт или уточнение

Встраивание

Что должно произойти после ответа?

Заявка, рекомендация, документ, действие

Контроль

Как понять, что система полезна?

Метрики качества, обратная связь, аудит

Границы ответственности

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

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

Как читать и применять

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

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

Стартовая установка

Не спрашивайте: «Что может сделать искусственный интеллект?» Спросите: «Какое повторяющееся решение в моей работе можно сделать быстрее, точнее и удобнее — и как я проверю улучшение?»

Вместо обещания лёгкого успеха

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

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

002 · ГЛАВА 1

Как машина понимает человеческий язык

Обработка естественного языка: намерения, сущности, контекст и архитектура диалога.

━━━━━━━━━━━━━━━━━━

Понять фразу — значит не только распознать слова, но и определить, какое действие должно последовать.

В 9:12 утра в чат интернет-магазина приходит сообщение: «Зелёные сорок второго есть, как вчера на фото?» Для человека, знакомого с предыдущей перепиской, смысл почти очевиден. Покупатель спрашивает о наличии зелёных кроссовок 42-го размера, показанных днём ранее. Для программы это сложная задача: название товара не указано, слово «есть» может означать наличие или существование, а выражение «как вчера» требует памяти о контексте.

Обработка естественного языка, или NLP, занимается именно такими задачами. Её цель — помочь вычислительной системе работать с человеческой речью: распознавать структуру, извлекать смысл, определять намерение, находить важные факты и формировать подходящий ответ. В чат-боте NLP соединяет свободную фразу пользователя с конкретным действием бизнеса.

1. Что такое естественный язык

Естественным называют язык, который возник и развивался в человеческом обществе: русский, английский, испанский и тысячи других. В отличие от языка программирования, он не проектировался ради однозначности. Люди постоянно опускают слова, меняют порядок, используют намёки, метафоры, иронию и общий опыт. Одна и та же мысль может быть выражена десятками способов, а одна и та же фраза — иметь разные значения.

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

NLP не сводится к распознаванию словаря. Система должна ответить как минимум на четыре вопроса: что сказано, что имеется в виду, какие детали важны и что делать дальше. Для этого используются методы лингвистики, статистики, машинного обучения и инженерии программных систем.

Рабочее определение

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

2. Почему язык труден для машины

3. Базовый путь от фразы к действию

Практический NLP-конвейер можно представить как последовательность преобразований. Реальные системы объединяют некоторые этапы, особенно когда используют большие языковые модели, но логика остаётся полезной для проектирования и диагностики.

Шаг

Задача

Пример результата

Зачем это нужно

1

Нормализация

«доставкa завтра??» → «доставка завтра?»

Уменьшить влияние опечаток и формата

2

Разбиение текста

Токены: «доставка», «завтра»

Получить единицы анализа

3

Определение намерения

Изменить дату доставки

Выбрать бизнес-сценарий

4

Извлечение сущностей

Дата: завтра; заказ: из контекста

Заполнить параметры действия

5

Учет контекста

Речь о заказе №1847

Связать текущую реплику с предыдущими

6

Формирование ответа

Предложить доступные интервалы

Продвинуть пользователя к решению

7

Выполнение действия

Обновить слот в системе доставки

Создать реальный результат

4. Токены, формы слов и грамматика

5. Намерение: зачем пользователь написал

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

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

Практическое правило

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

6. Сущности: какие детали нужны

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

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

Фраза пользователя

Намерение

Извлечённые сущности

«Запишите меня к кардиологу в филиал на Лесной после 17:00»

Запись на приём

Специализация: кардиолог; филиал: Лесная; время: после 17:00

«Верните 3 490 рублей за заказ 7712»

Запрос возврата

Сумма: 3 490 ₽; заказ: 7712

«Нужна синяя куртка M, как в каталоге»

Поиск товара

Категория: куртка; цвет: синий; размер: M

7. Контекст и память диалога

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

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

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

8. Тональность и эмоциональные сигналы

Анализ тональности оценивает, выражает ли текст положительное, нейтральное или отрицательное отношение. В поддержке важнее не поставить красивую метку, а изменить поведение системы. Сообщение «Третий раз списали деньги, вы вообще читаете?» должно повысить приоритет, исключить бодрые рекламные фразы и, возможно, быстрее подключить оператора.

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

9. Генерация языка

После понимания запроса система должна сформировать ответ. В классическом боте ответ выбирается из шаблона и заполняется данными. Это надёжно, но негибко. Генеративная модель может переформулировать, объяснить, сократить и адаптировать тон, однако требует ограничений: фактической опоры, правил стиля, максимальной длины и списка запрещённых утверждений.

Практическая архитектура часто сочетает оба подхода. Критические данные — сумма, дата, номер заявки — вставляются из системы без изменения. Объяснение вокруг них формирует модель. В результате ответ звучит естественно, но ключевые факты остаются контролируемыми.

10. Как

ChatGPT

связан с

NLP

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

Это не отменяет классические понятия NLP. Напротив, намерения, сущности, тональность и контекст остаются удобным языком проектирования. Большая модель может объединить несколько этапов в одном вызове, но команда всё равно должна понимать, что именно она ожидает на выходе, как проверить результат и что произойдёт при ошибке.

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

11. Архитектура чат-бота: четыре слоя

Понимание языка. Система определяет намерение, сущности, тон и недостающие параметры.

Управление диалогом. Правила или модель решают, что делать дальше: уточнить, выполнить действие, показать информацию или передать оператору.

Данные и инструменты. Бот обращается к CRM, каталогу, календарю, платёжной системе, поиску или базе знаний.

Формирование ответа. Результат переводится в понятную реплику с нужным тоном и уровнем подробности.

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

12. Практический кейс: бот для транспортной компании

Осенью 2024 года компания «УралТранс Сервис» из Екатеринбурга обрабатывала около 2 600 обращений в неделю. Большинство клиентов спрашивали о местонахождении груза, переносе доставки, документах и стоимости хранения. Операторы вручную искали данные в TMS, копировали статусы и отвечали в чате. Среднее первое ожидание составляло одиннадцать минут, а в понедельник утром превышало двадцать.

Команда начала не с генерации ответов, а с анализа 4 800 обезличенных диалогов. После удаления персональных данных запросы сгруппировали в девять намерений. Для каждого определили обязательные сущности: номер накладной, город, дата, тип документа. Затем описали правила: статус можно сообщать только из TMS; стоимость хранения — только после расчёта; претензии о повреждении сразу передаются специалисту.

Первый прототип распознавал намерения и возвращал структурированный JSON. Диалоговый модуль проверял, хватает ли данных. Если номера накладной не было, бот просил его. Если был — вызывал API TMS. Языковая модель использовалась только на последнем этапе: превращала технический статус в понятную реплику и учитывала тон пользователя.