Связка system‑prompt, tool descriptions и follow‑ups: борьба с галлюцинациями

1. Введение

Иногда на курсах по prompt‑инжинирингу показывают магическое заклинание:

«Не придумывай факты и говори “я не знаю”, если нет информации.»

К сожалению (или к счастью), для ChatGPT App это не работает как серебряная пуля. Причина проста: модель видит не только ваш system‑prompt, но и:

• список инструментов с их описаниями и схемами;
• результаты этих инструментов;
• историю диалога, включая предыдущие follow‑up’ы.

Если эти три слоя — system‑prompt, описания tools, паттерны follow‑up — противоречат друг другу или просто «провисают», модель начинает вести себя как классический джуниор: старательная, но склонная к выдумкам.

Внутри курса мы используем идею «трёхуровневой защиты от галлюцинаций» (defense in depth):

• уровень 1 — глобальные правила в system‑prompt;
• уровень 2 — локальные ограничения в определении каждого инструмента;
• уровень 3 — обработка ошибок, пустых результатов и follow‑ups.

В этой лекции мы соберём все три уровня в единый, согласованный контракт для нашего учебного приложения GiftGenius.

Insight

В новой архитектуре ChatGPT Apps поле для system-prompt исчезло — формально его больше нет. Но это не означает, что вы должны отказываться от глобальных инструкций для модели. Есть лайфхак: для ChatGPT описания инструментов — такой же текст промпта, как и классический system. Именно через него можно вернуть полноценную «мозговую прошивку» приложения.

Создайте служебный инструмент, например about или about_app. Он не предназначен для частого вызова, но его description читается моделью наравне с остальными инструментами. Поэтому в описание можно встроить полный system-prompt. Лучше его разместить после короткого технического описания самого инструмента. В итоге модель на старте получает ваш system-prompt в чистом виде — и применяет его ко всему дальнейшему диалогу и вызовам tools.

Чтобы упростить сопровождение, рекомендую добавлять в начало system-prompt явную версию, например SYSTEM_PROMPT_VERSION: v3. Это позволяет находить, почему модель ведёт себя по-другому: вы сразу видите, на каком именно наборе инструкций она работает. Если в проде возникает странное поведение, легко понять, относится ли ошибка к старой версии промпта или к новой.

Пример:

tool description

### Global assistant behavior for the entire GiftGenius App (ver 3.01)
*(system-level guidelines, not user-facing text)*

system prompt text

2. Какие галлюцинации бывают у ChatGPT App (на примере каталога подарков)

Чтобы понимать, чем лечить, полезно назвать болезнь. В контексте каталога (подарки, товары, тарифы) чаще всего встречаются такие типы галлюцинаций.

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

Во‑вторых, выдуманные атрибуты. Подарок в каталоге есть, но модель «украшает» реальность: меняет цену, тип подарка (цифровой vs физический), наличию доставки в страну пользователя или срок действия сертификата, потому что так «логичнее» или «звучит лучше».

В‑третьих, галлюцинаторные действия. Модель пишет «я уже купил этот подарок и отправил код на ваш e‑mail, с карты списано $49», хотя ваш backend GiftGenius даже не пытался ничего покупать и никакой ACP/Stripe‑флоу не запускался.

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

Наша задача — сделать так, чтобы в этих ситуациях модель:

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

Причём делать это не за счёт «заклинаний» в произвольных местах, а через связанный контракт system‑prompt ↔ tools ↔ follow‑ups.

3. Слой 1: усиливаем system‑prompt против галлюцинаций

Чтобы остановить выдуманные подарки, атрибуты и действия из предыдущего раздела, сначала усилим верхний слой — system‑prompt: зададим модели общую «философию» поведения в каталоге.

В первой лекции модуля вы уже написали базовый system‑prompt вида: «Ты — GiftGenius, помогаешь подбирать подарки…» и зафиксировали границы ответственности ассистента и работу с инструментами.

Теперь добавим туда явные анти‑галлюцинационные правила.

Логика такая: system‑prompt задаёт общую философию поведения. Он не знает деталей каждого инструмента, зато может:

• запретить придумывать подарки / цены / наличие вне каталога;
• прописать поведение, если инструменты вернули пустой результат или ошибку;
• потребовать явного различения между данными из каталога подарков и любыми «общими знаниями модели».

Пример фрагмента system‑prompt (TypeScript‑константа в нашем Next.js‑проекте, например config/systemPrompt.ts):

// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Роль
Ты — GiftGenius, ассистент по подбору подарков
на основе каталога подарков нашего приложения.

# Данные и ограничения
- Не придумывай подарки, которых нет в каталоге или в ответах инструментов.
- Не выдумывай цены, наличие, тип подарка (цифровой/физический),
  регионы доставки или другие атрибуты.
- Если инструмент не вернул нужных данных или произошла ошибка,
  честно сообщай об этом и не пытайся угадывать значения.

# Работа с инструментами
- Всегда используй инструменты каталога подарков для любых фактических данных:
  списка подарков, цен, типов, доступности, SKU.
- Если инструмент вернул пустой результат, скажи, что по текущим условиям
  подходящих подарков нет, и предложи варианты ослабить фильтры
  (изменить бюджет, категорию, тип подарка).
`;

Здесь важно несколько моментов.

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

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

В‑третьих, фокусируемся не на абстрактном «не галлюцинируй», а на конкретных типах поведения, привязанных к нашему домену (каталог подарков и покупка цифровых/физических SKU).

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

4. Слой 2: описания инструментов (tool descriptions) и схемы как формальная часть контракта

Модель решает, когда и как вызывать ваш инструмент, в первую очередь по:

• имени инструмента;
• description инструмента;
• inputSchema / outputSchema (JSON Schema, описывающая поля).

То есть описание инструмента (tool description) — это не документация «для людей», а такая же часть промпта, только формализованная. И многие галлюцинации рождаются именно здесь.

Представим наш инструмент recommend_gifts, который backend реализует как подбор подарков из каталога GiftGenius.

Плохой вариант описания мог бы выглядеть так:

// ПЛОХО: слишком расплывчато
const recommendGiftsTool = {
  name: "recommend_gifts",
  description: "Подбирает подарки для пользователя",
  inputSchema: {
    type: "object",
    properties: {
      profile: { type: "string" }
    }
  }
};

Формально всё корректно, но модель из этого не понимает:

• где границы инструмента;
• что делать, если подарки не найдены;
• что нельзя придумывать подарки и цены вне каталога.

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

Пример (адаптированный под контракт GiftGenius с segments, budget, locale, occasion):

// config/tools.ts
export const recommendGiftsTool = {
  name: "recommend_gifts",
  description: `
Подбор подарков в каталоге GiftGenius.

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

НЕ придумывай подарки и их атрибуты вне результатов этого инструмента.
Если инструмент вернул пустой список, не выдумывай альтернативы,
а переходи к диалогу: предложи изменить бюджет, тип подарка,
повод или другие параметры.
  `.trim(),
  inputSchema: {
    type: "object",
    properties: {
      segments: {
        type: "array",
        description:
          "Сегменты профиля получателя, например ['tech', 'fitness'].",
        items: { type: "string" }
      },
      budget: {
        type: "object",
        description: "Диапазон бюджета на подарок.",
        properties: {
          min: {
            type: "number",
            description: "Минимальная сумма, неотрицательная.",
            minimum: 0
          },
          max: {
            type: "number",
            description: "Максимальная сумма, больше 0.",
            exclusiveMinimum: 0
          },
          currency: {
            type: "string",
            description: "Трёхбуквенный код валюты, например 'USD' или 'BGN'.",
            minLength: 3,
            maxLength: 3
          }
        },
        required: ["min", "max", "currency"]
      },
      locale: {
        type: "string",
        description:
          "Локаль пользователя (формат языка/региона), например 'ru-RU' или 'en-US'.",
        minLength: 2
      },
      occasion: {
        type: "string",
        description:
          "Повод для подарка: например 'birthday', 'anniversary', 'new_year'."
      }
    },
    required: ["segments", "budget", "locale", "occasion"]
  }
};

Здесь description делает несколько полезных вещей.

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

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

Он задаёт поведение при пустом результате: не выдумывать, а переходить к диалогу (то, что потом мы зафиксируем во follow‑ups).

А inputSchema помогает модели более надёжно вытащить сущности из пользовательского запроса: сегменты, бюджет, локаль и повод. Указание явной структуры и ограничений для полей (min, max, currency с фиксированной длиной) тоже снижает вероятность странных комбинаций и ошибок при парсинге.

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

description: `
...
Не используй этот инструмент, если пользователь задаёт общий вопрос
о подарках без запроса на подбор для конкретного человека
(например, "какие бывают популярные подарки на Новый год в целом").
В таких случаях отвечай сам в чате.
`.trim()

Так вы синхронизируете описание инструмента с правилами из system‑prompt про «теоретические» vs «практические» запросы.

5. Слой 3: follow‑ups как UX‑ и safety‑слой

Даже если system‑prompt и описания tools написаны идеально, жизнь не идеальна:

• backend может вернуть ошибку;
• каталог — пустой список;
• результаты — неоднозначные или слишком многочисленные.

Если не прописать, что говорить после вызова tool, модель будет импровизировать: иногда хорошо, иногда — с выдуманными фактами.

В лекции 2 вы уже видели базовые UX‑инструкции: как модель анонсирует запуск App, как завершает сценарий и что говорит пользователю «на выходе». Сейчас добавим к этому паттерны follow‑up’ов, снижающих галлюцинации.

Эти паттерны обычно описываются прямо в system‑prompt в отдельном блоке, например «Диалог после работы с инструментами».

Пример фрагмента:

// продолжение SYSTEM_PROMPT
export const SYSTEM_PROMPT = `
# ... предыдущие секции ...

# Диалог после работы с инструментами

- Если инструмент подбора подарков вернул пустой список:
  1) честно скажи, что при текущих фильтрах подходящих подарков не найдено;
  2) предложи пользователю изменить 1–2 ключевых параметра
     (бюджет, тип подарка, интересы получателя, повод).

- Если инструмент вернул слишком много вариантов:
  1) выбери 3–7 наиболее релевантных;
  2) явно скажи, по каким критериям ты их отобрал
     (совпадение по интересам, попадание в бюджет, рейтинг).

- Если произошла ошибка инструмента:
  1) не выдумывай данные;
  2) скажи, что произошла техническая ошибка и предложи
     попробовать позже или упростить запрос.
`.trim();

Мы тем самым «прошиваем» в модель примерные follow‑up‑реплики. Она будет формулировать их своими словами, но с заданной структурой:

• констатация факта (пусто / много / ошибка);
• честное признание ограничения;
• аккуратное предложение следующего шага.

Для каталога подарков это критично: вместо «всё ок, вот вам три подарка» в случае пустого результата модель скажет что‑то вроде:

«По вашим текущим условиям (цифровой подарок про космос до $5 с доставкой только в США) в нашем каталоге ничего нет. Хотите, я попробую расширить бюджет или предложу другие категории?»

И обратите внимание: это уже не инструментный код, а именно инструкции в промпте, которые задают ожидаемый UX.

6. Связываем всё вместе: эволюция нашего GiftGenius

Давайте посмотрим на мини‑эволюцию нашего приложения и постепенно уменьшим уровень галлюцинаций.

Исходная версия: где всё ломается

Допустим, у нас был очень минималистичный system‑prompt:

export const SYSTEM_PROMPT = `
Ты — помощник по подбору подарков.
Помогай пользователю находить подходящие идеи.
`;

Инструмент был описан так:

export const recommendGiftsTool = {
  name: "recommend_gifts",
  description: "Подбирает подарки для пользователя",
  inputSchema: { type: "object" }
};

Follow‑up‑инструкций нет.

Что будет происходить на практике:

• если пользователь попросит «цифровой подарок другу‑геймеру до $10», а в базе под такие фильтры ничего нет, модель может:
  • либо вообще не вызвать tool и придумать подарки из головы;
  • либо вызвать tool, получить пустой список, но не сказать об этом и придумать варианты;
• если backend вернёт ошибку, модель может считать, что «что‑то да должно быть» и начать гадать.

Так рождается классическая ситуация: в чате — красивый ответ, в базе — ничего похожего.

Новая версия system‑prompt

Перепишем system‑prompt, учитывая три уровня защиты. Часть вы видели выше, соберём его целиком:

// config/systemPrompt.ts
export const SYSTEM_PROMPT = `
# Роль
Ты — GiftGenius, ассистент по подбору подарков
на основе каталога подарков нашего приложения.

# Зона ответственности
- Твоя задача — помочь пользователю выбрать подходящие подарки
  из каталога, объясняя плюсы и минусы вариантов.
- Не давай обещаний о фактической покупке или отправке подарка —
  ты только помогаешь подобрать и сравнить варианты.
  Покупку и выдачу кода/ссылки делает backend после явного согласия пользователя.

# Данные и ограничения
- Не придумывай подарки, которых нет в каталоге или в ответах инструментов.
- Не выдумывай цены, тип подарка, наличие или регионы доставки.
- Если инструмент не вернул данных или произошла ошибка,
  не пытайся угадывать, а сообщи об этом.

# Работа с инструментами
- Используй инструменты каталога подарков (например, profile_to_segments,
  recommend_gifts, get_gift) для любых фактических данных
  (список подарков, цены, типы, SKU, описания).
- Отвечай сам (без инструментов), если вопрос теоретический
  и не требует подбора конкретного подарка.

# Диалог после работы с инструментами
- При пустом результате: честно объясни, что ничего не найдено
  по текущим условиям, и предложи изменить 1–2 параметра.
- При большом количестве вариантов: выбери 3–7 наиболее подходящих
  и объясни критерии выбора.
- При ошибке инструмента: не придумывай данные, извинись за сбой
  и предложи попробовать ещё раз или упростить запрос.
`.trim();

Теперь модель чётко знает:

• где она консультант по подаркам, а где «бэк‑офис» (он у нас за инструментами);
• какие именно данные нельзя выдумывать;
• как вести себя в типичных неидеальных случаях.

Новый description и схема для recommend_gifts

Системный промпт мы усилили, теперь доведём до ума tool и соберём финальную версию его описания — на основе идей из раздела 4.

// config/tools.ts
export const recommendGiftsTool = {
  name: "recommend_gifts",
  description: `
Подбор подарков в каталоге GiftGenius.

Используй этот инструмент, когда нужно:
- получить список реальных подарков с актуальными ценами, типом
  (digital/physical) и тегами;
- сузить выбор по сегментам интересов, бюджету, локали и поводу.

НЕ ИСПОЛЬЗУЙ инструмент:
- если пользователь задаёт общий теоретический вопрос о подарках
  без запроса на подбор для конкретного человека;
- для придумывания подарков, которых нет в каталоге.

Если результат пустой, НЕ придумывай подарки самостоятельно,
а верни управление в диалог (следуй инструкциям system-prompt).
  `.trim(),
  inputSchema: {
    type: "object",
    properties: {
      segments: {
        type: "array",
        description:
          "Сегменты профиля получателя: например, 'tech', 'sport', 'books'.",
        items: { type: "string" }
      },
      budget: {
        type: "object",
        description:
          "Диапазон бюджета на подарок в валюте пользователя (min/max).",
        properties: {
          min: { type: "number", minimum: 0 },
          max: { type: "number", exclusiveMinimum: 0 },
          currency: {
            type: "string",
            minLength: 3,
            maxLength: 3,
            description: "Код валюты ISO 4217, например 'USD' или 'BGN'."
          }
        },
        required: ["min", "max", "currency"]
      },
      locale: {
        type: "string",
        description: "Локаль пользователя, например 'bg-BG','ru-RU' или 'en-US'."
      },
      occasion: {
        type: "string",
        description:
          "Повод для подарка: 'birthday', 'anniversary', 'new_year' и т.п."
      }
    },
    required: ["segments", "budget", "locale", "occasion"]
  }
};

Тут есть несколько нюансов.

Мы явно связываем поведение инструмента с system‑prompt: фраза «следуй инструкциям system‑prompt» напомнит модели, что «пустой результат = честный разговор, а не креатив».

Мы задаём отрицательные условия («не используй…», «не придумывай…»), что, как показывает практика, важно не меньше, чем позитивные описания.

Мы делаем inputSchema семантически богатым: нормальные описания и ограничения помогают модели правильно сопоставлять запросы с полями и меньше «ошибаться» ещё до вызова инструмента.

Follow‑up‑паттерны в коде виджета и формате ответа

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

Формально follow‑up‑ы задаются текстом в system‑prompt, но в вашем Next.js‑виджете вы можете дополнительно нормализовать ToolOutput, чтобы сделать жизнь модели проще и снизить простор для фантазий.

Например, договоримся, что backend для recommend_gifts всегда возвращает:

// тип ответа инструмента на бэкенде
export type RecommendGiftsResult = {
  items: Array<{
    id: string;
    title: string;
    price: number;
    currency: "USD" | "EUR" | "BGN";
    tags: ("digital" | "physical" | "education" | "fitness" | "tech")[];
  }>;
  // поле, которое backend заполняет, чтобы явно сказать модели, что произошло
  status: "ok" | "empty" | "error";
  errorMessage?: string;
};

Виджет может отображать это красиво, а модель — опираться на status при формировании ответа. В Apps SDK вы часто возвращаете ToolOutput модели как JSON‑объект, и она видит это поле.

В system‑prompt можно добавить маленький блок:

# Интерпретация статуса инструмента

- Если status = "empty": смотри раздел "Диалог после работы с инструментами" и
  не придумывай подарки.
- Если status = "error": сообщи про техническую ошибку и не пытайся угадывать
  содержимое каталога.

Да, модель и без этого могла бы догадаться, но явная инструкция снижает шанс «угадываний» на основе догадок.

7. Практика: дорабатываем свой App

Чтобы не было ощущения «ну это всё красиво на слайдах», давайте опишем конкретное упражнение, которое вы можете сделать со своим текущим App (в нашем случае — GiftGenius). Сделаем маленький рефакторинг по трём слоям защиты: system‑prompt, описания инструментов и обработка результатов.

Во‑первых, на уровне system‑prompt, возьмите ваш system‑prompt из первой лекции и найдите в нём место, где описывается зона ответственности и работа с инструментами. Добавьте туда:

• запрет на придумывание сущностей вне каталога/базы (подарков, SKU, цен);
• правила на случай пустого результата и ошибки инструмента;
• раздел «Диалог после работы с инструментами» с 2–3 сценариями (пусто, много, ошибка).

Во‑вторых, на уровне описаний tools, откройте описание ключевого инструмента (у вас это может быть recommend_gifts, search_gifts, search_tariffs, calculate_quote, неважно). Перепишите description так, чтобы он:

• явно говорил, что инструмент работает только с вашим источником данных (каталог подарков, тарифов и пр.);
• объяснял, когда он нужен, а когда нет;
• содержал явные негативные ограничения: «не придумывай…», «не используй для…».

В‑третьих, на уровне структуры ответа инструмента, если в ответе инструмента ещё нет поля, явно описывающего статус (status, resultType, hasMore) — добавьте его в тип на бэкенде и в ToolOutput. Затем в system‑prompt впишите, как модель должна интерпретировать этот статус в диалоге.

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

В следующей лекции вы формализуете такие запросы в так называемый golden prompt set и превратите это в повторяемый тестовый артефакт, но пока для нас важно, чтобы вы руками почувствовали разницу.

8. Типичные ошибки при борьбе с галлюцинациями через промпты и инструменты

Ошибка №1: одна волшебная фраза «не галлюцинируй» в system‑prompt.
Разработчик пишет в конце промпта: «Не придумывай информацию» — и считает задачу решённой. На практике модель продолжает выдумывать, потому что описания инструментов и follow‑ups не задают ей альтернативного поведения. Без конкретных правил «что делать вместо выдумывания» (признать пустой результат, предложить изменить фильтры, сообщить об ошибке) такая фраза почти не помогает.

Ошибка №2: противоречие между system‑prompt и description инструмента.
В system‑prompt вы говорите: «Не придумывай подарки, которых нет в каталоге», а в описании инструмента — «Подбирает подходящие подарки, а если не нашёл — может предложить похожие варианты на своё усмотрение». В итоге модель мечется между двумя источниками правды, и побеждает, к сожалению, более конкретный (обычно description инструмента). Нужно, чтобы оба слоя говорили одно и то же: если похожие варианты допустимы, это тоже надо формализовать (и обязательно пояснять пользователю, что это не точное совпадение).

Ошибка №3: слишком расплывчатые описания инструментов.
Описание вида «Инструмент, который помогает пользователю решать задачи» не даёт модели почти никакой информации о границах инструмента. В таком случае она либо вообще не будет его использовать, либо будет дёргать по любому поводу — а потом «додумывать» данные, когда инструмент вернул мало или ничего. Хороший description должен быть дискриминативным: явно говорить, что делает инструмент и когда его не надо вызывать.

Ошибка №4: отсутствие стратегии для пустых и ошибочных результатов.
Разработчик заботливо пишет бэкенд, который возвращает { items: [], status: "empty" }, но нигде не объясняет модели, что это значит. В результате модель видит пустой массив и решает: «ну, видимо, надо предложить что‑то из общего знания». В system‑prompt не хватает раздела, объясняющего, как интерпретировать такие статусы и что говорить пользователю. При этом добавление пары чётких правил для пустого/ошибочного результата даёт огромный прирост качества.

Ошибка №5: попытка «лечить» галлюцинации только на уровне кода виджета.
Иногда хочется всё переложить на фронтенд: «если список пустой — покажу заглушку и не дам пользователю увидеть текстовый ответ модели». Это может слегка смягчить UX, но сама модель при этом продолжает верить в выдуманные сущности и так же вести себя в последующих репликах. Правильный подход — сначала менять инструкции (system‑prompt, описания инструментов, follow‑ups), а уже потом дополнять это защитами в UI.

Ошибка №6: игнорирование влияния метаданных и схем на поведение модели.
Некоторые разработчики воспринимают JSON Schema и описания полей как «чисто для формы и валидации». На самом деле, для ChatGPT это важная часть промпта: по этим описаниям модель понимает, какие параметры ей нужно извлечь из запроса и как выглядит корректный ответ. Слабые или несогласованные описания полей (description, enum) повышают шанс ошибок и косвенно провоцируют галлюцинации.

Ошибка №7: слишком жёсткие запреты без альтернатив.
Бывает, что промпт превращается в сплошной список «не делай того, не делай этого», но нигде не сказано, что делать в сложных случаях. Например, мы запретили придумывать подарки и ограничили себя только каталогом, но ничего не сказали о теоретических вопросах. В итоге модель иногда просто отвечает «я не знаю», хотя могла бы полезно объяснить общие принципы выбора подарков. Всегда старайтесь не только запрещать, но и открывать разрешённые пути: «если не можешь найти подарок в каталоге — честно скажи об этом и предложи, как можно изменить запрос» или «если запрос теоретический — отвечай сам, без инструментов».