(ДЛЯ “БОЕВОГО” ПРОМТ‑ИНЖЕНЕРА)
1. Валидация JSON‑ответов
1.1. Почему это важно
Если вы используете LLM в проде – без жёсткого контроля формата вы рано или поздно уроните пайплайн: лишняя запятая, комментарий, текст до/после JSON – и ваш парсер падает. Задача промт‑инженера – минимизировать хаос.
1.2. Как просить “строго валидный JSON”
Базовый паттерн:
Ответь строго в виде валидного JSON.
Требования:
– без комментариев;
– без лишнего текста до и после JSON;
– строки в двойных кавычках;
– без висячих запятых.
Структура ответа:
{
"field1": "string",
"field2": 123,
"items": [
{
"name": "item name",
"value": 0
}
]
}
Полезные приёмы:
Сначала показать пример JSON нужной формы, даже пустой.
Явно запретить:
“Не добавляй никаких пояснений, только JSON‑объект.”
При многошаговых сценариях:
на шаге 1 можно просить свободный текст,
на шаге 2 – “преобразуй в JSON по схеме”.
1.3. Промт для авто‑починки JSON
Когда модель всё равно выдала мусор, вы можете прогнать это через отдельный “санитайзер”.
Шаблон промта‑починки
Ты – ассистент, который исправляет JSON.
Тебе дан текст, в котором должен быть JSON, но он может быть с ошибками формата:
– лишний текст до или после;
– одинарные кавычки вместо двойных;
– комментарии;
– висячие запятые и т.п.
Задача:
1. Извлеки JSON‑структуру из текста.
2. Исправь только синтаксические ошибки, не меняя смысла и значений полей.
3. Верни строго один валидный JSON‑объект.
Текст:
<<<
{плохой JSON тут}
>>>
Ответь только валидным JSON, без пояснений и без текста вне объекта.
Вы этот промт вызываете во втором шаге, прямо из кода, если первичный парсинг упал.
1.4. Простейший валидатор JSON: Python
import json
def validate_and_parse_json(raw: str):
try:
data = json.loads(raw)
# Дополнительно можем проверить тип корневой структуры
if not isinstance(data, dict):
raise ValueError("Root JSON must be an object")
return data
except json.JSONDecodeError as e:
raise ValueError(f"Invalid JSON: {e}") from e
# пример использования
raw_response = model_response # строка от LLM
try:
data = validate_and_parse_json(raw_response)
except ValueError as err:
# здесь можно вызвать промт-санитайзер и попробовать ещё раз
print("JSON error:", err)
Мини‑практика:
– сначала валидируете “как есть”;
– при ошибке: перезапрашиваете модель с промтом‑починкой и валидируете снова.
1.5. Простейший валидатор JSON: JS (Node / браузер)
function validateAndParseJson(raw) {
try {
const data = JSON.parse(raw);
if (typeof data !== 'object' || data === null || Array.isArray(data)) {
throw new Error('Root JSON must be an object');
}
return data;
} catch (e) {
throw new Error('Invalid JSON: ' + e.message);
}
}
// пример использования
try {
const data = validateAndParseJson(modelResponse);
} catch (err) {
console.error('JSON error:', err.message);
// здесь можно триггерить повторный запрос / санитайзер
}
2. Валидация аналитики и фактов
2.1. Принцип: LLM – не источник истины
Модель:
может красиво придумывать ссылки, цифры, “статистику”;
не гарантирует актуальность данных;
не знает, как устроена именно ваша система/продукт, если вы это явно не описали.
Её безопасная роль: генератор гипотез, структуры, интерпретатор данных, но не финальный источник фактов.
2.2. Просим модель помечать гипотезы
Шаблон:
Ты – продуктовый аналитик.
Важно:
– Если ты делаешь вывод, основанный на реальных данных, которые я тебе дал – пометь это как "based_on_data".
– Если это предположение или типичная гипотеза без прямой опоры на данные – пометь как "hypothesis".
Верни ответ в JSON:
{
"findings": [
{
"type": "based_on_data | hypothesis",
"statement": "Формулировка вывода",
"data_reference": "На какие данные/факты из входа ты опираешься (или null, если гипотеза)"
}
]
}
Так вы сразу видите, что можно использовать как аналитический факт, а что – только как гипотезу.
2.3. Промт для двойной проверки на противоречия
Очень полезно на втором шаге прогнать ответ через “самопроверку”.
Ты – критичный рецензент аналитических отчётов.
Вот ответ модели (анализ/отчёт):
<<<
{вставь сюда предыдущий ответ}
>>>
Задача:
1. Проверить ответ на внутренние противоречия, логические ошибки и слишком смелые выводы без достаточных оснований.
2. Выделить:
– явные противоречия,
– выводы без достаточной опоры на данные,
– места, где нужно уточнить данные или контекст.
3. Если всё выглядит логично – так и скажи, но всё равно перечисли, какие предположения были сделаны.
Формат ответа:
{
"is_consistent": true | false,
"issues": [
{
"type": "contradiction | unsupported_claim | missing_context | other",
"description": "В чём проблема",
"suggested_fix": "Как переформулировать или что уточнить"
}
],
"assumptions": [
"Явное предположение 1",
"Явное предположение 2"
]
}
Вы можете автоматизировать это как второй шаг в цепочке:
данные → анализ → самопроверка.
2.4. Практическая тактика
Все числовые результаты (проценты, суммы, конверсии), посчитанные моделью, перепроверяете кодом (Python/JS).
Все “факты” (рынок, законы, даты, статистика) – переcекаете внешними источниками (поисковики, внутренние системы).
В проде:
используете модель для подготовки черновиков аналитики и структуры отчётов;
финальные цифры и выводы – только из проверенных источников.
3. Валидация контента и маркетинга
3.1. Чем опасны “сырые” ответы
LLM в маркетинге склонна:
обещать невозможное;
говорить “за компанию” вещи, которые вы юридически не можете заявлять;
писать очень общие, нерелевантные ЦА тексты.
Промт‑инженер обязан встроить чек‑лист валидации в процесс.
3.2. Чек‑лист для маркетингового текста
Три ключевых блока:
Релевантность целевой аудитории (ЦА)
Вопросы:
Понятен ли текст конкретному сегменту (а не “вообще всем”)?
Используются ли боли/ситуации, характерные именно для этой ЦА?
Отсутствие нелепых или опасных обещаний
Вопросы:
Есть ли обещания гарантированного результата (“ты точно похудеешь на 10 кг за неделю”)?
Есть ли юридически/этически токсичные формулировки?
Соответствие тону бренда
Вопросы:
Стиль: формальный / дружелюбный / дерзкий – совпадает с брендом?
Нет ли резких или “токсичных” выражений, если это не ваш стиль?
3.3. Промт‑проверка маркетингового текста
Ты – редактор-маркетолог и бренд-страж.
Контекст бренда:
– Целевая аудитория: {опиши ЦА, например "занятые специалисты 25–40 лет, интересуются здоровым образом жизни, но устали от агрессивного фитнес-маркетинга"}.
– Тон бренда: {опиши тон, например "дружелюбный, поддерживающий, без агрессии и давления"}.
– Ограничения: {например "не обещаем гарантированный результат, не даём медицинских обещаний"}.
Вот черновик текста:
<<<
{сюда вставить текст}
>>>
Задача:
Оценить текст по трём критериям:
1) Релевантность ЦА.
2) Отсутствие нелепых/опасных обещаний.
3) Соответствие тону бренда.
Формат ответа – JSON:
{
"audience_relevance": {
"score": 1-5,
"comment": "Насколько хорошо текст говорит с этой ЦА, что именно попадает/не попадает"
},
"claims_safety": {
"score": 1-5,
"issues": [
"Описание потенциально проблемного обещания или формулировки"
]
},
"brand_tone_alignment": {
"score": 1-5,
"comment": "Где текст совпадает/расходится с заданным тоном"
},
"suggested_improvements": [
"Конкретное предложение по улучшению 1",
"Конкретное предложение по улучшению 2"
]
}
Дальше вы можете:
на шаге 1 – сгенерировать текст;
на шаге 2 – прогнать его через такую проверку;
на шаге 3 – попросить модель переписать текст, учитывая замечания (или сделать это руками).
3.4. Переписывание с учётом чек‑листа
Шаблон:
Ты – маркетолог-копирайтер.
Вот исходный текст и результаты его оценки:
Текст:
<<<
{исходный текст}
>>>
Оценка:
<<<
{JSON с аудиторией, безопасностью обещаний и тоном}
>>>
Задача:
Переписать текст так, чтобы:
– повысить релевантность ЦА (учти комментарии),
– убрать/смягчить опасные или нереалистичные обещания,
– привести стиль к заданному тону бренда.
Формат:
Сначала кратко (1–2 предложения) напиши, что ты изменил и почему.
Затем выведи финальную версию текста.
4. Как это собрать в рабочий пайплайн
JSON‑ответы
Всегда: “строго валидный JSON”, пример структуры.
В коде: try/except + повторный запрос через промт‑санитайзер.
Аналитика и факты
В промтах: просите разделять “based_on_data” и “hypothesis”.
Для важных отчётов: шаг самопроверки на противоречия.
Цифры и факты – всегда перепроверяете вне LLM.
Контент и маркетинг
Генерация → оценка по чек‑листу → переписывание.
Ограничения бренда и юридики – явно формулируете в промте.
Если вы всё это внедряете как стандарты (чек‑листы + шаблоны промтов + куски кода‑валидаторов), вы перестаёте быть обычным пользователем ChatGPT и становитесь тем самым “боевым” промт‑инженером, который отвечает за надёжность и предсказуемость системы.