Control unsupported AI answersКак проверять ответы AI

Give each claim an identifiable sourceУ каждого утверждения должно быть основание

OpenAI’s September 5, 2025 analysis explains that scoring only correct answers can reward guessing over acknowledging uncertainty. A practical business question follows: which claims may the assistant actually make? List consequential facts such as price, available stock, return eligibility, payment state and confirmed timing. Assign an acceptable source and applicability conditions to each. A general service description cannot substantiate an answer about a particular order, even when its wording sounds relevant.В разборе OpenAI от 5 сентября 2025 года отмечается, что оценивание только по правильным ответам может поощрять догадки вместо признания неопределённости. Для бизнеса из этого следует практический вопрос: какие утверждения помощнику вообще разрешено делать? Составьте перечень значимых фактов: цена, доступный остаток, условия возврата, состояние оплаты, подтверждённый срок. Для каждого укажите допустимый источник и условия применимости. Ответ о конкретном заказе нельзя подтверждать общим описанием услуги, даже если формулировки похожи.

For an auditable answer, retain the record identifier, policy version, retrieval time and fields used. Distinguish those observations from conclusions drawn from them. A dispatch event, for example, supports that an order entered delivery; it does not by itself establish an arrival date. Check citations too: does the document exist, support the claim and apply to this location, item and period? Several claims within one sentence may require different sources.Для проверяемого ответа сохраняйте идентификатор записи, версию правила, время получения и использованные поля. Отдельно отмечайте выводы, которые система делает из этих данных. Например, отметка об отправке подтверждает передачу заказа в доставку, но сама по себе не устанавливает дату прибытия. Ссылка тоже требует проверки: существует ли документ, содержит ли нужное основание и относится ли оно к этому филиалу, товару и периоду? Несколько фактов в одном предложении могут требовать разных источников.

Source: OpenAI on language model hallucinationsИсточник: OpenAI об ошибках языковых моделей

Distinguish missing data from service failureОтделяйте отсутствие данных от сбоя

Set acceptable evidence age by decision type. An archived service description and a technician’s open appointment slots need different freshness checks. Reading a document now does not mean its contents were updated now. Preserve the distinction between an unavailable source, an empty result and conflicting records. Do not silently reuse the last successful answer as a current fact. Clarifying an order number can resolve ambiguity; retrying can resolve a temporary failure; neither substitutes for missing confirmation.Установите допустимый возраст данных по типу решения. Архивное описание услуги и свободное время мастера требуют разных проверок актуальности. Время чтения документа не равно времени обновления сведений внутри него. Если источник недоступен, вернул пустой результат или противоречит другой записи, сохраните именно этот статус. Не подставляйте старый успешный ответ как текущий факт. Уточнение номера заказа помогает при неоднозначности; повторный запрос помогает при временном сбое; ни одно не заменяет отсутствующее подтверждение.

Uncertainty should help the customer understand the next step. Replace vague reassurance with the known state and the specific missing fact: the order is accepted, but a pickup time has not been recorded. If price depends on an option, ask which option applies. Avoid invented confidence percentages. Declining an unsupported promise still leaves room to communicate verified information. Conversely, the assistant should not request unnecessary details or withhold a straightforward answer already supported by current evidence.Неопределённость должна помогать клиенту понять следующий шаг. Вместо расплывчатого «возможно, всё готово» сообщите, какое состояние известно и чего пока нельзя подтвердить: заказ принят, но срок выдачи ещё не указан. Если стоимость зависит от выбранного варианта, сначала уточните вариант. Не добавляйте произвольный процент уверенности. Отказ от неподтверждённого обещания оставляет возможность сообщить проверенные сведения. При этом помощник не должен просить лишние данные или скрывать простой ответ, уже доступный в актуальном источнике.

Verify actions outside generated textПроверяйте действия вне текста модели

Saying a refund is processed requires an operation result, not an intention to perform it. Before changing a record, check required fields, permissions, permitted state transitions and amount limits in application logic. The model may propose parameters; execution must pass those checks independently of persuasive wording. Customer confirmation and access checks are also separate requirements. Define in advance what evidence permits a completion message without further assumptions.Фраза «возврат оформлен» требует результата операции, а не намерения её выполнить. До изменения записи проверяйте обязательные поля, полномочия, допустимость перехода статуса и ограничения суммы в обычной логике приложения. Модель может предложить параметры; решение об исполнении должно пройти эти проверки независимо от убедительности текста. Подтверждение клиента и проверка доступа также не заменяют друг друга. Для каждого действия заранее определите, какое свидетельство позволит сообщить об успешном завершении без дополнительных предположений.

After execution, match the service response to the intended operation and retain its identifier. A timeout leaves the result unknown: the action may have completed even though its response was lost. Check state before retrying or use the integration’s supported duplicate protection. Absence of an error message is insufficient proof of success. Test a wrong identifier, insufficient permissions, stale state and a repeated request. These are implementation and acceptance requirements for the particular integration.После выполнения сопоставьте ответ сервиса с нужной операцией и сохраните её идентификатор. Тайм-аут означает неизвестный результат: действие могло завершиться, хотя ответ потерялся. Перед повтором проверьте состояние или используйте предусмотренный механизм защиты от дублирования. Не объявляйте успех по отсутствию ошибки в тексте. В тесте отдельно проверьте неверный идентификатор, недостаточные права, устаревший статус и повторный запрос. Это требования к реализации и приёмке конкретной интеграции, а не утверждение, что любая система уже их выполняет.

Separate errors from warranted abstentionРазличайте ошибку и обоснованный отказ

For each test, specify the request, evidence available to the assistant and expected behavior. Distinguish a supported correct answer, an incorrect or unsupported claim, warranted abstention and unnecessary abstention despite sufficient evidence. Review against what the system could know when asked. A lucky guess matching reality does not demonstrate compliance with the source requirement. Track false action confirmations and invalid citations separately, because a combined score can conceal consequential defects.Для каждого теста задайте входной запрос, доступные помощнику сведения и ожидаемое поведение. Разделяйте подтверждённый правильный ответ, ошибочное или неподтверждённое утверждение, обоснованный отказ и лишний отказ при достаточных данных. Тестировщик должен оценивать ответ по тому, что система могла знать в момент запроса. Случайная догадка, совпавшая с реальностью, не доказывает соблюдение правил источника. Отдельно фиксируйте ложное сообщение об исполнении действия и неверную ссылку: общий балл может скрыть такие опасные дефекты.

In a hypothetical set of 20 cases, suppose there are 12 supported answers, 4 warranted abstentions, 2 unsupported answers and 2 unnecessary abstentions. The unsupported-answer case rate is 2 / 20 × 100 = 10%; this is not a claim-level error rate across every sentence. Warranted abstentions should not count as errors, and unnecessary ones should not count as successes. Set acceptance limits beforehand according to consequences. A false payment confirmation may block release despite a good aggregate result.Учебный пример: из 20 случаев получены 12 подтверждённых ответов, 4 обоснованных отказа, 2 неподтверждённых ответа и 2 лишних отказа. Доля случаев с неподтверждённым ответом составляет 2 / 20 × 100 = 10%; это не доля ошибочных утверждений внутри всех предложений. Обоснованные отказы не следует смешивать с ошибками, а лишние — считать успехом. Порог приёмки задайте заранее с учётом последствий. Ложное подтверждение платежа может остановить выпуск даже при хорошем среднем результате остальных проверок.

Repeat evaluations after changesПовторяйте проверки после изменений

OpenAI’s evaluation guidance recommends task-specific tests, human review alongside metrics and repeated evaluation when systems change. Include ordinary questions, missing information, conflicting policies and attempts to pressure the assistant into an unsupported promise. Record expected behavior before comparing alternatives. Keep a separate test set that is not used to tune instructions. This reduces the chance that a rewrite appears better simply because the developer repeatedly checked the same familiar examples.Рекомендации OpenAI по оцениванию предлагают тесты под конкретную задачу, сочетание показателей с человеческой проверкой и повторное оценивание при изменениях. Для своего процесса включите обычные вопросы, отсутствующие сведения, конфликтующие правила и попытки склонить помощника к неподтверждённому обещанию. Зафиксируйте ожидаемые результаты до сравнения вариантов. Храните отдельный проверочный набор, который не используется для подгонки инструкций. Так новая формулировка не будет выглядеть улучшением только потому, что разработчик постоянно проверял одни и те же знакомые примеры.

Rerun the set after changes to the model, instructions, retrieval, permissions or service response format. Record versions and repeat disputed scenarios; a single successful answer cannot establish consistency. Add real failures after removing unnecessary personal data. The process owner should see what changed, which abstentions were justified and which defects remain open. Passing checks still leaves residual risk. Expand usage only after the responsible owner accepts those limits.Повторяйте набор после смены модели, инструкции, поиска, правил доступа или формата ответа сервиса. Записывайте версии и проверяйте несколько запусков спорных сценариев: единичный удачный ответ недостаточен для вывода о стабильности. Новые реальные ошибки добавляйте в набор после удаления ненужных персональных данных. Владелец процесса должен видеть, что изменилось, какие отказы оправданы и какие дефекты ещё открыты. Даже пройденные проверки оставляют остаточный риск; расширяйте область использования только после принятия этих ограничений ответственным за процесс.

Source: OpenAI evaluation best practicesИсточник: рекомендации OpenAI по оцениванию

Quick answersКороткие ответы