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

1.

ChatGPT

, модель и приложение — не одно и то же

ChatGPT — разговорный продукт, который предоставляет пользователю готовый интерфейс и управляет многими техническими деталями. Модель — вычислительный компонент, получающий вход и создающий выход. API — программный способ обратиться к моделям из собственного приложения. Эти понятия связаны, но не взаимозаменяемы.

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

Главная граница

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

2. Как устроен путь текста через модель

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

Этап

Что происходит

Результат

Что важно проектировщику

Токенизация

Текст делится на слова и фрагменты слов

Последовательность токенов

Длина считается токенами, а не страницами

Векторизация

Токены переводятся в числовые представления

Начальные векторы

Похожие элементы получают сопоставимые признаки

Внимание

Модель оценивает связи внутри контекста

Контекстные представления

Порядок, ссылки и дальние зависимости влияют на смысл

Слои сети

Представления многократно преобразуются

Распределение вероятностей

Поведение определяется обученными параметрами

Декодирование

Выбирается следующий токен и цикл повторяется

Готовый текст или структура

Настройки влияют на длину и вариативность

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

3. Контекстное окно и токенный бюджет

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

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

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

4. Инструкции, сообщения и границы поведения

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

Слой

Что в нём хранится

Пример

Инструкции приложения

Роль, правила, формат, ограничения

Не обещай возврат; при споре передай оператору

Сообщение пользователя

Текущая цель и формулировка

«Деньги списались дважды»

Контекст диалога

Подтверждённые данные и прошлые шаги

Заказ 7712; проверка платежа выполнена

Внешние источники

Документы и результаты API

Две операции со статусами completed и reversed

Ожидаемый выход

Структура для следующего компонента

JSON с действием, ответом и уровнем риска

Нельзя считать текст из базы знаний инструкцией более высокого уровня. Документ может содержать пример фразы «игнорируйте предыдущие правила» или случайный пользовательский текст. Приложение должно отделять данные от команд и разрешать только заранее определённые действия.

5. Рабочее пространство проекта

Для прототипа удобно создать отдельный проект в панели OpenAI, чтобы изолировать ключи, лимиты и расходы. Команда выбирает доступную модель, создаёт API-ключ и настраивает биллинг. Модельное имя и поддерживаемые параметры могут меняться, поэтому перед развёртыванием нужно проверить их в актуальной документации и в списке моделей проекта.

Минимальный локальный контур включает Python, виртуальное окружение, официальный пакет openai и переменную окружения OPENAI_API_KEY. Ключ не следует хранить в исходном коде, отправлять в репозиторий или размещать в клиентском JavaScript. Запросы к API выполняются на сервере, а браузер или мобильное приложение обращается к вашему защищённому backend.

Подготовка окружения

python -m venv .venv

# macOS / Linux

source .venv/bin/activate

pip install openai

export OPENAI_API_KEY="ваш_ключ"

# Windows PowerShell

.\.venv\Scripts\Activate.ps1

pip install openai

$env:OPENAI_API_KEY="ваш_ключ"

6. Первый запрос через

API

Ниже показан минимальный серверный пример на Python. В нём клиент автоматически читает ключ из переменной окружения, а Responses API получает модель, постоянную инструкцию и сообщение пользователя.

Минимальный пример на Python

from openai import OpenAI

client = OpenAI()

response = client.responses.create(

model="gpt-5",

instructions=(

"Ты помощник службы доставки. "

"Отвечай по-русски, кратко и без догадок. "

"Если нет фактического статуса, попроси номер заказа."

),

input="Курьер обещал приехать к восьми, уже половина девятого"

)

print(response.output_text)

В демонстрации используется модель gpt-5. В реальном проекте название выбирают из доступных в конкретном аккаунте, исходя из качества, задержки, стоимости и поддерживаемых возможностей. Запускать код следует на тестовых данных, не содержащих лишней персональной информации.

7. Из чего состоит запрос

8. Ответ

API

и его обработка

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

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

Безопасный порядок

Сначала модель предлагает структурированное действие. Затем приложение проверяет схему, права и ограничения. И только после проверки вызывается CRM, платёжная система или другой внешний сервис.

9. Структурированный выход вместо свободного текста

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

Пример ожидаемой структуры

{

"intent": "delivery_delay",

"order_id": null,

"action": "ask_order_id",

"risk": "low",

"needs_human": false,

"reply": "Назовите, пожалуйста, номер заказа — я проверю статус курьера."

}

Структурированный формат не делает предсказание истинным, но отделяет решение от формулировки и упрощает проверку. Список допустимых действий должен быть закрытым: ask_order_id, lookup_status, reschedule_delivery, escalate. Неизвестное значение отклоняется приложением.

10. Подключение инструментов и данных

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

Каждый инструмент должен иметь узкую функцию и строгую схему. Команда явно определяет обязательные поля, допустимые диапазоны и права. Функция get_order_status безопаснее универсального execute_sql, а create_refund_request — безопаснее прямого списания или возврата средств без подтверждения.

Инструмент

Вход

Выход

Ограничение

search_knowledge

Вопрос и фильтры продукта

Фрагменты с идентификаторами

Только утверждённая база

get_order_status

Номер заказа и пользователь

Статус, время, курьер

Проверка права доступа

reschedule_delivery

Заказ и новый интервал

Подтверждение изменения

Только доступные слоты

create_ticket

Категория, описание, приоритет

Номер заявки

Персональные данные по минимуму

11. Как хранить состояние разговора

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

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

12. Журналирование, приватность и контроль расходов

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

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

13. Практический кейс: бот для проката оборудования

Летом 2025 года самарская сеть «Вектор Прокат» получала около 420 сообщений в день через сайт и Telegram. Клиенты спрашивали о наличии перфораторов, продлении аренды, залоге, неисправностях и времени возврата. Операторы работали в 1С, а ответы вручную переносили в мессенджеры. Вечером ожидание первого ответа доходило до восемнадцати минут.

Команда создала backend на FastAPI, PostgreSQL для истории и Redis для состояния активного диалога. Через Responses API модель определяла намерение и формировала вызов одного из пяти инструментов: search_catalog, get_contract, extend_rental, create_breakdown_ticket и handoff_to_operator. Цены, доступность и сроки всегда возвращались из 1С; модель не имела права придумывать их.

Первый релиз обслуживал только три сценария: наличие, правила залога и создание заявки о неисправности. В журнал сохранялись версия инструкции, аргументы инструмента и итоговый ответ. Ежедневно руководитель поддержки просматривал двадцать случайных диалогов и все случаи ручного исправления.

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

14. Как тестировать первый прототип

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

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

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

3. Зафиксируйте ожидаемое действие для каждого сценария, а не единственную красивую формулировку ответа.

4. Повторите тесты несколько раз, чтобы увидеть вариативность и нестабильные решения.

5. Проверьте отказ внешнего API, тайм-аут, пустой поиск и превышение лимита.

6. Запустите ограниченный пилот и сравнивайте новую версию с предыдущей на одном тестовом наборе.

15. Типичные ошибки первого API-проекта

Размещать секретный API-ключ в браузере, мобильном приложении или публичном репозитории.

Передавать модели всю базу и всю историю вместо отбора релевантного контекста.

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

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

Считать историю чата надёжным хранилищем состояния и фактов.

Не различать ошибку модели, поиска, интеграции и интерфейса.

Тестировать только в Playground и не воспроизводить реальные сетевые сбои и ограничения backend.

Жёстко привязывать приложение к одному названию модели и набору параметров без конфигурации.

16. Ключевые термины

Термин

Смысл

ChatGPT

Готовый разговорный продукт с пользовательским интерфейсом и встроенной оркестрацией.

Модель GPT

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

API

Программный интерфейс для обращения к моделям из собственного приложения.

Responses API

Интерфейс OpenAI для получения ответов модели и работы с инструментами.

Токен

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

Контекстное окно

Объём информации, доступный модели в одном запросе.

Instructions

Постоянные правила роли, формата и ограничений для запроса.

Структурированный выход

Ответ по заданной схеме, пригодный для программной проверки.

Вызов инструмента

Предложение модели обратиться к определённой функции с аргументами.

Backend

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

Состояние диалога

Подтверждённые параметры и выполненные шаги, сохранённые приложением.

Тайм-аут

Ограничение времени ожидания ответа внешнего сервиса.

Повтор с задержкой

Контролируемая повторная попытка после временной ошибки.

Журналирование

Сохранение данных выполнения для диагностики, оценки и аудита.

17. Мини-практикум

Соберите локальный прототип, который не выполняет необратимых действий. Подходящий первый сценарий — классификация обращения или ответ по небольшой утверждённой инструкции.

1. Создайте отдельный проект и API-ключ, сохраните его только в переменной окружения.

2. Установите официальный SDK и выполните минимальный запрос из этой главы.

3. Добавьте instructions с ролью, запретом на догадки и форматом ответа.

4. Попросите модель возвращать JSON с намерением, действием, ответом и признаком needs_human.

5. Проверьте структуру на сервере и отклоняйте неизвестные действия.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.