Fits Calc
ИИ для инженера · Промпты · часть 9/10

Промпт: Найти противоречия между источниками

Готовый инженерный шаблон для задачи: найти противоречия между источниками.

Назначение шаблона

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

Модели и тарифы меняются. GPT/ChatGPT, Gemini, Claude/Claude Code, локальные модели через Ollama и другие продукты приведены как примеры классов инструментов, а не как рейтинг. Функции, контекст, tools, лимиты, стоимость и доступность зависят от модели, плана, региона и даты. Для ответственного процесса фиксируйте конфигурацию и проверяйте официальную документацию.

Что подготовить

ПолеТребование
цельФактическое значение/описание; для числа — единица; для документа — версия и источник.
объект/узелФактическое значение/описание; для числа — единица; для документа — версия и источник.
исходные данные с единицамиФактическое значение/описание; для числа — единица; для документа — версия и источник.
ограниченияФактическое значение/описание; для числа — единица; для документа — версия и источник.
критерий готовностиФактическое значение/описание; для числа — единица; для документа — версия и источник.
Специальный акцентСильный prompt отделяет цель, факты, ограничения, output schema и критерии проверки.

Готовый промпт

Промпт: Найти противоречия между источниками
Ты — инженер-исследователь и специалист по RAG/источникам.

ЗАДАЧА
Найти противоречия между источниками.

РАБОЧИЙ СЦЕНАРИЙ
При конфликте источников вернуть оба значения, версии и правило приоритета, а не усреднять их.

ИСХОДНЫЕ ДАННЫЕ
- цель: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- объект/узел: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- исходные данные с единицами: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- ограничения: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]
- критерий готовности: [ЗАПОЛНИТЬ / НЕТ ДАННЫХ]

ОБЯЗАТЕЛЬНЫЕ ПРАВИЛА
1. Не придумывай отсутствующие числа, размеры, свойства, стандарты, ссылки, паспортные параметры или результаты испытаний.
2. Не меняй значения и единицы молча. Любое преобразование покажи отдельно.
3. Разделяй ФАКТ ИЗ ВХОДА / ИЗВЛЕЧЁННЫЙ ФАКТ / ВЫЧИСЛЕНИЕ / ИНТЕРПРЕТАЦИЮ / ДОПУЩЕНИЕ.
4. Если критического входа или доказательства нет, верни вопрос или статус «требует проверки», а не правдоподобную подстановку.
5. Отсутствие найденного доказательства не заменяй знанием «по памяти»; показывай, что retrieved, а что остаётся неизвестным.

СПЕЦИФИЧЕСКАЯ ПРОЦЕДУРА
Нормализуй сравниваемое утверждение и выведи evidence from each source separately. Конфликт не разрешай без authority rule.

ТРЕБУЕМЫЙ РЕЗУЛЬТАТ
Conflict matrix; source dates/editions; compatible vs contradictory parts; recommended authoritative check; open issue.

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.

Negative testУдалите или пометьте как неизвестное поле «цель». Хороший ответ не должен молча подставлять правдоподобное значение: он обязан показать, какой вывод заблокирован.
Boundary testИзмените «объект/узел» на граничное, но допустимое значение. Проверьте, изменился ли только тот вывод, который действительно зависит от этого входа.
Conflict testДобавьте противоречие между «исходные данные с единицами» и «ограничения». Модель должна зафиксировать конфликт и запросить правило приоритета, а не самостоятельно выбрать удобный вариант.
Acceptance testПроверьте два обязательных свойства результата: каждый факт возвращает source_id и locator; retrieval проверен вопросом, где ответа в базе нет. Затем подтвердите третий критерий — синтез отделён от прямой цитаты/факта.

Фиксируйте результат прогона как PASS/FAIL по каждому тесту и сохраняйте причину исправления. Это превращает prompt из одноразового текста в проверяемую инженерную процедуру: последующее обновление модели можно оценить на тех же входах, а не по субъективному впечатлению от нового ответа.

Как запускать шаблон

Сначала заполните все поля, которые реально известны, и не удаляйте placeholder у неизвестного критического параметра — лучше явно написать «нет данных». Первый запуск используйте как draft. Затем сравните ответ с acceptance-критериями выше и верните модели только конкретные замечания, а не просьбу «улучшить всё». Для регулярной задачи сохраните prompt, входной fixture и ожидаемые свойства результата в системе версий. После смены модели/режима повторите минимум три кейса: нормальный, граничный и с отсутствующим критическим входом.

Проверка результата

ЧислаКонтрольный пересчёт и размерности.
НормативыПервичный документ и область применения.
КодSandbox, тестовые данные, diff и rollback.
CAD/CAEНативные измерения, solver/test, а не только изображение.

Когда ответ нужно остановить

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

Навигация по 10 промптам этой части

Использовать ИИ поверх проверяемых данных Fits Calc

Fits Calc даёт расчётный и справочный контекст; ИИ помогает анализировать, объяснять, оформлять и автоматизировать. Критические числа, геометрия и нормативные требования остаются предметом инженерной проверки.

Открыть Fits Calc →

Источники и документация

  1. OpenAI — Prompt engineering
  2. Google AI — Prompt design strategies
  3. Anthropic — Prompt engineering
  4. NIST — AI Risk Management Framework
Проверено: 02.10.2026Инженерная проверка обязательнаМодели и тарифы меняются