Короткий ответ
Создать своего GPT в ChatGPT можно без кода: откройте конструктор GPT, задайте чёткие инструкции, подключите файлы знаний и при необходимости инструменты, затем прогоните набор тестовых диалогов и публикуйте только после проверки. Этого достаточно для внутренних справочников, подготовки черновиков, первичной аналитики и типовых консультаций. Метод не подходит, если ассистент должен жить внутри вашего продукта, вызывать приватные сервисы по сложной логике, работать с жёсткими правами доступа, выдавать строго структурированный ответ без сбоев или проходить формальный аудит; в таких случаях правильнее делать решение через OpenAI API, а не через конструктор GPT.
Под «своим GPT» здесь имеется в виду кастомный GPT внутри ChatGPT, а не отдельное приложение и не дообучение модели. Интерфейс и набор переключателей могут меняться, а доступность функций зависит от вашей рабочей области и прав аккаунта. Базовая логика при этом остаётся одной и той же: узкая задача, качественные инструкции, чистые источники знаний и обязательное тестирование. Официальную отправную точку OpenAI держит в справке по созданию GPT: Creating a GPT.
Что понадобится
- Доступ к созданию GPT в ChatGPT. Если раздел с GPT недоступен, начать настройку не получится.
- Один понятный сценарий. Например: «ассистент для ответов по внутренней документации отдела продаж» лучше, чем «универсальный ИИ для всего».
- Набор исходных материалов. Регламенты, FAQ, шаблоны ответов, инструкции, примеры хороших диалогов.
- Правила безопасности. Что ассистенту можно сообщать, что нельзя, когда он должен отказаться или передать вопрос человеку.
- Тестовые запросы. Нужны не только удачные сценарии, но и провокационные, неполные и конфликтные запросы.
- При необходимости — Actions. Это внешний API, который GPT вызывает для получения данных или выполнения операций. Для него нужен подготовленный интерфейс и безопасная схема доступа.
Лучше заранее собрать короткий каркас инструкций. Минимальный набор блоков такой: роль, аудитория, допустимые задачи, запреты, формат ответа, правило уточняющих вопросов, правила работы с файлами знаний и правило эскалации. Если этот каркас не готов, вы почти наверняка начнёте компенсировать пробелы длинными переписками с конструктором, а это даёт нестабильный результат.
Пошаговый план
1. Зафиксируйте одну основную задачу
Главная ошибка на старте — пытаться сделать «ассистента на все случаи». На практике лучше работает GPT с одной доминирующей функцией: консультант по документации, редактор типовых писем, помощник по онбордингу, классификатор входящих заявок. Если задач несколько, определите приоритет и явно опишите границы.
- Плохо: «Помогай во всём, что связано с компанией».
- Хорошо: «Отвечай на вопросы сотрудников по регламентам командировок на основе загруженных документов. Если в документах нет ответа, так и говори и предлагай обратиться в HR».
Если вам нужен и справочник, и аналитик, и оператор CRM, лучше разделить это на несколько GPT или перейти к решению через API, где проще контролировать логику.
2. Подготовьте материалы и очистите источники
Качество файлов знаний влияет на результат сильнее, чем длинные красивые инструкции. Уберите дубликаты, старые версии, черновики и спорные документы. Если тема меняется часто, лучше загрузить один актуальный документ, чем десять версий за квартал.
- Разделяйте материалы по темам, а не сваливайте всё в один файл.
- Давайте файлам понятные имена с датой и версией.
- Удаляйте внутренние заметки, которые не должны попадать в ответы.
- Не загружайте секреты, ключи, персональные данные и всё, что нельзя раскрывать пользователю.
Если информация должна быть строго актуальной по минутам или часам, файлы знаний — слабый вариант. Для такой задачи нужен внешний источник через API.
3. Создайте черновик GPT
В интерфейсе ChatGPT откройте раздел GPT и создайте новый экземпляр. Заполните базовые поля: название, краткое описание и стартовые подсказки для пользователя. Не тратьте много времени на оформление до тех пор, пока не проверите поведение на реальных запросах.
Название должно отражать сценарий, а не брендовые амбиции. Хорошие примеры: «HR Policy Assistant», «Помощник по SLA поддержки», «Редактор коммерческих писем». Стартовые подсказки лучше делать прикладными: «Сверь мой вопрос с регламентом командировок», «Составь ответ клиенту в нейтральном тоне», «Проверь, есть ли в документации нужная процедура».
4. Напишите инструкции как техническое задание
Инструкции — это не рекламный текст, а спецификация поведения. Пишите их коротко, недвусмысленно и по блокам. Полезный минимальный шаблон:
Роль; Для кого работает; Что делает; Чего не делает; Какие источники считать приоритетными; Когда задавать уточняющий вопрос; Когда отказывать; В каком формате отвечать; Когда советовать обратиться к человеку.
- Роль. Кто он в рамках процесса.
- Область. По каким темам отвечает, а по каким нет.
- Источники. Используй загруженные документы как главный источник; если данных не хватает, не выдумывай.
- Формат. Например: краткий вывод, затем шаги, затем ссылка на основание в документе.
- Ограничения. Не давай юридических или финансовых советов, не обещай то, чего нет в регламентах.
- Эскалация. Если вопрос о спорном исключении, направляй к конкретной роли или команде.
Полезно прямо прописать фразу для случаев неопределённости: Если в загруженных материалах нет подтверждения, скажи об этом явно и предложи, где уточнить информацию. Это снижает риск уверенных, но ложных ответов.
5. Подключите файлы знаний
После добавления инструкций загрузите документы, на которых GPT должен опираться. Старайтесь, чтобы каждый файл решал одну функцию: политика отпусков, регламент закупок, шаблоны ответов, карта эскалации. Чем чище границы между файлами, тем проще найти причину ошибки.
Не рассчитывайте, что загрузка PDF автоматически создаст экспертную систему. Если документ написан расплывчато, противоречиво или хранит несколько устаревших правил, GPT воспроизведёт эту путаницу. Хорошая практика — перед загрузкой сделать короткую редактуру: убрать визуальный мусор, повторяющиеся блоки и двусмысленные формулировки.
6. Включите инструменты только под конкретную задачу
Дополнительные инструменты полезны тогда, когда без них сценарий неполон. Если GPT должен анализировать таблицы, пригодится инструмент анализа данных. Если ему нужен доступ к внешнему сервису, используйте Actions. Но каждый включённый инструмент добавляет поверхность ошибок.
- Не включайте всё подряд. Если ассистент отвечает только по внутреннему FAQ, веб-поиск ему может мешать.
- Для Actions используйте минимальные права. Лучше отдельный служебный контур, чем прямой доступ к боевой системе.
- Продумайте ошибки API. Что GPT должен сказать пользователю, если внешний сервис недоступен или вернул пустой ответ.
- Не передавайте секреты в инструкции или файлы. Секреты должны оставаться на стороне вашего сервера или провайдера аутентификации.
Если сценарий требует цепочки из нескольких вызовов, ветвления бизнес-логики, журналирования и контроля прав на уровне ролей, конструктор GPT обычно уже тесен.
7. Настройте границы и стиль ответа
Сразу решите, как ассистент должен вести себя в пограничных случаях. Должен ли он отвечать кратко или подробно, упоминать источник, задавать один уточняющий вопрос или несколько, показывать предупреждение при отсутствии данных. Чем меньше свободы в повторяющихся местах, тем стабильнее поведение.
Практическое правило: сначала ограничьте поведение, потом расширяйте. Наоборот почти всегда получается хуже.
Если GPT будет виден внешним пользователям, не помещайте в него ничего, что нельзя раскрывать. Пользовательские запросы могут пытаться вытянуть инструкции, содержание файлов или логику принятия решений. Полностью исключить такие попытки нельзя, поэтому в систему нельзя класть секретные материалы.
8. Протестируйте на сценариях, а не на одном удачном диалоге
Сделайте маленький набор приёмочных тестов. Минимум: обычный запрос, запрос с нехваткой данных, запрос вне области, конфликт между документами, попытка получить запрещённую информацию, запрос с нуждой во внешнем действии. Один красивый ответ в превью ничего не доказывает.
Повторите одни и те же запросы несколько раз. Если GPT даёт заметно разные ответы на одинаковый вопрос, обычно причина в слишком расплывчатых инструкциях, шумных источниках или лишних инструментах. Уберите вариативность там, где важен процесс: формат, порядок шагов, правила отказа, условия эскалации.
9. Публикуйте постепенно
Начните с режима, доступного только вам или ограниченному кругу коллег. Соберите реальные вопросы, отметьте повторяющиеся промахи, поправьте инструкции и файлы, и только потом расширяйте видимость. Публичная публикация без внутренней обкатки почти всегда превращает пользователей в бесплатных тестировщиков.
Перед публикацией проверьте три вещи: в инструкциях нет секретов, в загруженных файлах нет лишних данных, стартовые подсказки не провоцируют на слишком широкие ответы. Если GPT должен работать в команде, назначьте владельца, который отвечает за ревизию контента и обновления.
10. Ведите версионность
Даже если инструмент выглядит «безкодовым», относитесь к нему как к продукту. Фиксируйте, что меняли: инструкции, файлы, Actions, правила отказа, набор тестов. Иначе через месяц будет невозможно понять, почему качество внезапно ухудшилось или почему два похожих GPT отвечают по-разному.
Типичные ошибки
| Ошибка | Как проявляется | Что делать |
|---|---|---|
| Слишком широкая роль | GPT уверенно отвечает вне своей области | Сузить сценарий и явно описать границы |
| Шумные файлы знаний | Ответы противоречат друг другу | Удалить старые версии, разнести темы по файлам |
| Расплывчатые инструкции | На один и тот же вопрос ответы «плавают» | Задать фиксированный формат, правила отказа и эскалации |
| Лишние инструменты | Ассистент уходит в веб или вызывает API без нужды | Оставить только необходимые возможности |
| Секреты в промпте или файлах | Риск утечки через диалог или публикацию | Никогда не хранить секреты в GPT; держать их вне ChatGPT |
| Отсутствие набора тестов | Качество оценивается по случайным впечатлениям | Собрать короткий, но постоянный список приёмочных запросов |
| Попытка строить продукт внутри GPT Builder | Нет контроля над правами, логами и интеграциями | Перенести сценарий в решение через API |
Как проверить результат
Проверка должна отвечать не на вопрос «мне понравился ответ?», а на вопрос «ассистент стабильно решает нужный сценарий и безопасно ведёт себя на границах?». Для этого удобно использовать матрицу тестов.
| Сценарий | Ожидаемый результат | Признак провала | Исправление |
|---|---|---|---|
| Типовой запрос по документации | Даёт прямой ответ и опирается на загруженные материалы | Фантазирует или добавляет лишние правила | Усилить правило приоритета источников |
| Неполный запрос | Задаёт уточняющий вопрос | Делает допущения и ошибается | Явно прописать условие уточнения |
| Вопрос вне области | Отказывает или перенаправляет | Пытается ответить любой ценой | Ужесточить границы роли |
| Конфликт в документах | Сообщает о конфликте и просит человека уточнить правило | Выбирает произвольную версию | Почистить материалы и описать приоритет версий |
| Запретный запрос | Корректно отказывает | Выдаёт чувствительную информацию | Переписать политику отказа и убрать секреты |
| Вызов внешнего действия | Правильно использует Action и объясняет результат | Путается в параметрах или молчит при ошибке API | Проверить схему и обработку ошибок |
- Прогоните не меньше 10–20 однотипных тестов, если сценарий важен для бизнеса.
- Повторите несколько запросов два-три раза, чтобы оценить стабильность.
- Проверьте, как GPT ведёт себя без нужных данных и при конфликте источников.
- Дайте тесты коллеге, который не участвовал в настройке: он лучше найдёт слепые зоны.
- После каждой правки прогоняйте один и тот же базовый набор тестов повторно.
Хороший результат — это не «модель звучит умно», а «она предсказуемо делает то, что нужно, и останавливается там, где не должна продолжать».
FAQ
Можно ли создать GPT совсем без кода?
Да, если вам не нужны внешние интеграции. Для инструкций, файлов знаний и базового тестирования код не нужен. Но как только появляются Actions, аутентификация, собственные API и сложная логика доступа, техническая работа всё равно возникает.
Это то же самое, что ассистент через API?
Нет. Кастомный GPT внутри ChatGPT — это быстрый способ собрать ассистента в готовой среде. Решение через API подходит, когда нужен контроль над интерфейсом, логикой, правами, журналированием, стоимостью вызовов, маршрутизацией и интеграцией в продукт.
Нужно ли писать очень длинный промпт?
Обычно нет. Лучше короткая и жёсткая спецификация, чем длинный текст с повторами. Длина сама по себе не повышает качество; важны ясные ограничения, приоритеты источников и ожидаемый формат ответа.
Можно ли просто загрузить PDF и получить точный корпоративный справочник?
Только если PDF уже хорошо отредактирован, актуален и не противоречит другим материалам. GPT не исправляет хаос в исходных документах. Если источник плохой, ответ тоже будет нестабильным.
Когда GPT Builder точно не подходит?
Когда нужен ассистент внутри вашего приложения, строгая защита чувствительных данных, сложные многошаговые интеграции, детальный аудит действий, гарантированно структурированный вывод или управление доступом по ролям. Это уже сценарии для API-архитектуры.
Можно ли делать публичный GPT?
Да, но только если в инструкциях, стартовых подсказках и загруженных материалах нет ничего внутреннего или чувствительного. Публичный GPT нужно рассматривать как внешнюю поверхность, а не как безопасное хранилище корпоративного знания.