Назначение шаблона
Этот материал даёт готовый prompt, чтобы план эксперимента. Он специально построен для инженерного review: модель обязана сохранить исходные данные, показать допущения и назвать то, что она не смогла подтвердить.
Что подготовить
| Поле | Требование |
|---|---|
| цель | Фактическое значение/описание; для числа — единица; для документа — версия и источник. |
| объект/узел | Фактическое значение/описание; для числа — единица; для документа — версия и источник. |
| исходные данные с единицами | Фактическое значение/описание; для числа — единица; для документа — версия и источник. |
| ограничения | Фактическое значение/описание; для числа — единица; для документа — версия и источник. |
| критерий готовности | Фактическое значение/описание; для числа — единица; для документа — версия и источник. |
Готовый промпт
Ты — инженер-исследователь и специалист по RAG/источникам.
ЗАДАЧА
План эксперимента.
РАБОЧИЙ СЦЕНАРИЙ
План эксперимента строить из гипотезы, факторов, отклика, диапазонов, повторов и анализа, сохраняя ограничения безопасности.
ИСХОДНЫЕ ДАННЫЕ
- цель: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- объект/узел: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- исходные данные с единицами: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- ограничения: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- критерий готовности: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
ОБЯЗАТЕЛЬНЫЕ ПРАВИЛА
1. Не придумывай отсутствующие числа, размеры, свойства, стандарты, ссылки, паспортные параметры или результаты испытаний.
2. Не меняй значения и единицы молча. Любое преобразование покажи отдельно.
3. Разделяй ФАКТ ИЗ ВХОДА / ИЗВЛЕЧЁННЫЙ ФАКТ / ВЫЧИСЛЕНИЕ / ИНТЕРПРЕТАЦИЮ / ДОПУЩЕНИЕ.
4. Если критического входа или доказательства нет, верни вопрос или статус «требует проверки», а не правдоподобную подстановку.
5. Отсутствие найденного доказательства не заменяй знанием «по памяти»; показывай, что retrieved, а что остаётся неизвестным.
СПЕЦИФИЧЕСКАЯ ПРОЦЕДУРА
Определи hypothesis, factors, levels, controls, response, randomization/replication and analysis plan. Не объявляй оптимальный DOE без resource constraints.
ТРЕБУЕМЫЙ РЕЗУЛЬТАТ
Experiment matrix concept; variables/units; confounders; measurement plan; acceptance/statistical analysis; safety constraints.
ACCEPTANCE
- каждый факт возвращает source_id и locator
- retrieval проверен вопросом, где ответа в базе нет
- синтез отделён от прямой цитаты/факта
- версия корпуса документов зафиксирована
ФИНАЛЬНЫЙ SELF-CHECK
- перечисли все новые числа/утверждения, появившиеся не напрямую из входа;
- укажи, чем инженер должен независимо проверить критический результат;
- перечисли незакрытые вопросы;
- не выполняй write/deploy/publish и другие необратимые действия без явного разрешения.
STOP CONDITION
Если без отсутствующего критического параметра, первичного источника или разрешения корректный вывод невозможен — остановись и запроси это явно.Почему он работает лучше короткой команды
Короткая команда обычно оставляет модели слишком много свободы: неизвестно, какие данные считать истинными, можно ли придумывать пропуски и в каком виде вернуть результат. Здесь контракт задан заранее. Это не гарантирует правильность ответа, но делает ошибку наблюдаемой: видно, какое поле использовано, где возникло допущение и какой шаг должен проверить человек.
Self-check остаётся проверкой внутри той же генеративной системы, поэтому он полезен только как фильтр очевидных несогласованностей. Независимое подтверждение выполняется профильным средством: расчётным модулем, первичным стандартом, CAD/CAE, измерением, unit-test или контрольным экспериментом.
Адаптация под облачную и локальную модель
- В ChatGPT/GPT, Gemini или Claude передавайте только релевантный контекст и фиксируйте используемый режим/tools.
- Через API задайте JSON-schema или другой строгий output contract и машинную валидацию.
- Для локальной LLM через Ollama/другой runtime сохраните тот же контракт, но проверяйте качество на собственном eval-наборе.
- Если есть web/RAG/коннекторы, явно ограничьте допустимые источники и права на запись.
- После смены модели, тарифа или системной инструкции повторите эталонные тесты.
Разбор рабочего примера
Промпт: План эксперимента. Рабочий вариант применения: План эксперимента строить из гипотезы, факторов, отклика, диапазонов, повторов и анализа, сохраняя ограничения безопасности.
Перед первым запуском заполните placeholders реальными значениями и сохраните исходный prompt как версию. После ответа сравните его с acceptance-критериями статьи: любое новое число, ссылка или действие без происхождения переводится в open question. Для регулярного использования добавьте этот пример в eval-набор и прогоняйте после смены модели, тарифа, runtime или системной инструкции.
Критерии acceptance для этой задачи
RAG/research-prompt оценивают по тому, можно ли восстановить доказательство. Требуйте source_id, раздел/страницу, версию документа и отделение прямого факта от синтеза. Chunking и retrieval проверяют на реальных вопросах, включая случаи, когда правильный ответ — «в базе нет данных».
- каждый факт возвращает source_id и locator
- retrieval проверен вопросом, где ответа в базе нет
- синтез отделён от прямой цитаты/факта
- версия корпуса документов зафиксирована
Контрольный прогон именно для этой задачи
Проверка исследования и RAG. В исследовательской задаче проверяется не только ответ, но и retrieval. Источник должен существовать, locator вести к нужному месту, а отсутствие доказательства должно оставаться отсутствием, а не заполняться моделью по памяти.
Для «Промпт: План эксперимента» соберите небольшой fixture, где явно присутствуют цель, объект/узел, исходные данные с единицами и ограничения. Сохраните этот набор без изменений: он нужен как эталон для повторного запуска после смены модели, режима, тарифа, system prompt или подключённых tools.
Фиксируйте результат прогона как PASS/FAIL по каждому тесту и сохраняйте причину исправления. Это превращает prompt из одноразового текста в проверяемую инженерную процедуру: последующее обновление модели можно оценить на тех же входах, а не по субъективному впечатлению от нового ответа.
Как запускать шаблон
Сначала заполните все поля, которые реально известны, и не удаляйте placeholder у неизвестного критического параметра — лучше явно написать «нет данных». Первый запуск используйте как draft. Затем сравните ответ с acceptance-критериями выше и верните модели только конкретные замечания, а не просьбу «улучшить всё». Для регулярной задачи сохраните prompt, входной fixture и ожидаемые свойства результата в системе версий. После смены модели/режима повторите минимум три кейса: нормальный, граничный и с отсутствующим критическим входом.
Проверка результата
Когда ответ нужно остановить
- появились новые исходные числа без источника;
- ссылка или стандарт не открывается/не относится к задаче;
- вывод зависит от отсутствующего параметра;
- модель пытается выполнить write/deploy/publish без разрешения;
- нет способа восстановить, какие входы дали итог.
Навигация по 10 промптам этой части
Внутри части — 10 взаимосвязанных материалов. Переходы между частями и перекрёстные ссылки сохраняют учебную последовательность.
Использовать ИИ поверх проверяемых данных Fits Calc
Fits Calc даёт расчётный и справочный контекст; ИИ помогает анализировать, объяснять, оформлять и автоматизировать. Критические числа, геометрия и нормативные требования остаются предметом инженерной проверки.
Открыть Fits Calc →Источники и документация
- OpenAI — Prompt engineering
- Google AI — Prompt design strategies
- Anthropic — Prompt engineering
- NIST — AI Risk Management Framework