Когда ИИ забывает деталь проекта, ему следует спросить, прежде чем вспоминать
Когда ИИ-ассистент не может найти обычную деталь текущего творческого проекта, ему следует прямо сказать о том, что он не может подтвердить, указать недостающий факт и спросить у пользователя источник. Ему следует обновлять свое рабочее понимание только после того, как пользователь подтвердит эту деталь. Такой ответ гораздо полезнее, чем выдумывание правдоподобного прошлого диалога, поскольку он позволяет отделить реальные записи проекта от догадок.
Почему правдоподобное воспоминание все равно остается догадкой
Творческий проект держится на мелких решениях: какое название вошло в шорт-лист, от первого или от второго лица пишется черновик, или какую цветовую палитру выбрал пользователь. Если ассистент не может найти одну из таких деталей, беглый и гладкий ответ может прозвучать как надежное воспоминание, незаметно подменяя выбор новым.
NIST определяет конфабуляцию генеративного ИИ как включающую уверенно преподносимый ложный контент, а также результаты, которые расходятся с входными данными или противоречат им. Выдуманная деталь проекта как раз несет в себе такой практический риск: ее можно принять за уже принятое решение. Профиль генеративного ИИ от NIST описывает этот механизм в общих чертах; последствия для работы над проектами здесь являются выводом для проектирования взаимодействия, а не выводом о конкретном продукте.
Исследования OpenAI также показывают, что распространенные стимулы оценки могут поощрять угадывание вместо признания неопределенности. В качестве примера приводится ответ на общие вопросы, но этот урок применим и к проектированию: ассистент не должен воспринимать уверенно звучащую автодостройку как доказательство того, что прошлый диалог действительно доступен. Why language models hallucinate
Сначала определите, что ассистент видит на самом деле
Ассистент должен различать три состояния: деталь видна в текущем диалоге, деталь можно извлечь из доступного источника проекта, и деталь невозможно проверить. Эти состояния требуют разных формулировок. Если деталь встречалась ранее в этой же ветке, ассистент может процитировать ее или пересказать, указав на этот контекст. Если он нашел заметку или документ, он может назвать этот источник. Если ни то, ни другое недоступно, об этом следует сказать прямо.
Полезное заявление о неопределенности должно быть конкретным и сдержанным: «Я не могу проверить, какое название вы выбрали, на основе доступной мне информации о проекте». Оно не предполагает, что пользователь никогда не выбирал название, что ассистент обыскал все возможные архивы, или что недостающей детали не существует. Эти различия важны, так как невозможность извлечь запись не является доказательством того, что запись никогда не создавалась.
Руководство Google People + AI Guidebook рекомендует объяснять актуальные возможности и ограничения, концентрируя объяснения на том, что влияет на понимание и решения пользователя. В данном контексте это указывает на необходимость краткого заявления о доступном контексте проекта, а не на техническое объяснение внутреннего устройства модели. Explainability + Trust
Запрашивайте минимально необходимый источник
Обозначив пробел, задайте один целевой вопрос. Например: «Не могли бы вы вставить заметку или назвать выбранный заголовок?» Если у пользователя может быть несколько вариантов источников, предложите короткий список: «Это было в последнем черновике, в ваших заметках к проекту или в предыдущем чате?» Цель состоит в том, чтобы упростить восстановление данных, не превращая рутинную творческую задачу в допрос.
Практичный шаблон ответа выглядит так: «Я не могу подтвердить палитру по тем данным, к которым у меня есть доступ. Если вы покажете заметку или напомните мне цвета, я использую их для следующего черновика». Это определяет недостающий факт, запрашивает подтверждение или подтверждающие данные и объясняет, что произойдет дальше. Это также сохраняет темп: ассистент может продолжать работу над незатронутыми частями задачи, оставляя неопределенный выбор открытым.
Уточнение полезно тогда, когда недостающая информация меняет ответ. В исследовании совместного диалога Тестони и Фернандес обнаружили, что стратегия уточнения, направляемая неопределенностью модели, повысила успешность выполнения их конкретной задачи по рисованию; они также отмечают, что уточняющие вопросы сопряжены с определенными издержками. Это говорит в пользу взвешенного подхода: задавайте вопросы тогда, когда недостающий факт о проекте действительно важен, и формулируйте их предельно четко. Asking the Right Question at the Right Time
Обновляйте информацию только после подтверждения пользователем
Когда пользователь предоставит источник или подтвердит деталь, повторите подтвержденный факт в компактной форме: «Понял: текущее название — “Заметки о маленьком саде”, согласно присланной вами заметке». Если в источнике говорится нечто немного иное, покажите это несоответствие, а не делайте выбор молча. Например: «В вашей заметке указано “Заметки о саде”, а вы только что сказали “Заметки о маленьком саде”. Что использовать?»
Обновление должно быть ограничено рамками проекта и подтверждающими данными. Вставленная строка может служить основанием для использования этой строки в текущей задаче; это не означает автоматически, что деталь является окончательной, применяется ко всем версиям или должна сохраняться за пределами текущего диалога. Если в продукте есть видимая история проекта, покажите предполагаемое обновление и дайте пользователю возможность исправить его. Если такой записи нет, не утверждайте, что воспоминание было сохранено навсегда.
Этот шаг подтверждения — рекомендация по проектированию, основанная на отслеживаемости и контроле со стороны пользователя: пользователь видит, какой факт был принят, и может исправить его до того, как он повлияет на дальнейшую работу. Это особенно полезно, когда творческие решения меняются в процессе. В предыдущем черновике может содержаться старый заголовок, в то время как недавнее сообщение вводит новый; ассистент должен сохранять эту последовательность, а не сводить все черновики к единому якобы неизменному воспоминанию.
Избегайте вопросов, в которые скрыто заложена догадка
Вопрос может вводить в заблуждение, если в него уже заложен выдуманный ответ. Вопрос «Вы же выбрали бирюзовый, верно?» подталкивает диалог к детали, которую ассистент не проверял. Предпочтите нейтральный запрос: «Какой цвет вы выбрали?» Если есть реальный источник, в котором упоминается бирюзовый, укажите на него: «В черновых заметках указан бирюзовый цвет. Это все еще та палитра, которую вы хотите использовать?» Такая формулировка отделяет доказательства из источника от текущего подтверждения.
Не выдавайте сгенерированные альтернативы за вспомненные факты. Если пользователь не может найти старое решение, ассистент может предложить помочь выбрать заново, но должен четко обозначить это как новый выбор: «Я не могу восстановить предыдущую палитру. Хотите выбрать ее прямо сейчас?» Такое разграничение позволяет продолжать творческое сотрудничество, не переписывая историю проекта заново.
Исследование 2024 года, посвященное реакции языковых моделей на неполные вопросы, показало, что контекстуально уместное поведение по уточнению проявляется при определенных условиях размера модели и промптинга, а не возникает автоматически. Этот результат служит напоминанием для продуктовых команд: такое поведение нужно проектировать и оценивать явно, а не рассчитывать на то, что модель будет стабильно задавать правильные вопросы по умолчанию. Clarifying Completions
Оценивайте поведение на обычных проектных задачах
Команды разработчиков могут тестировать это взаимодействие с помощью привычных запросов из творческих проектов: попросите назвать отсутствующий заголовок, выбранный формат или предпочтения для черновика, когда соответствующая деталь отсутствует в доступном для ассистента контексте. Качественный ответ должен называть пробел, избегать выдумывания предшествующего диалога, запрашивать соответствующий источник или подтверждение, а затем последовательно использовать подтвержденную информацию.
Включайте схожие сценарии, где деталь присутствует в текущей ветке или предоставленной заметке. В таких случаях ассистент должен использовать доступные доказательства, точно указывая, откуда они взяты. Также проверяйте конфликтующие версии и исправления пользователя. Полезная оценка четко разграничивает необоснованное воспоминание и подкрепленное источниками извлечение данных, а также проверяет, продолжает ли ассистент выполнять незатронутую работу вместо того, чтобы блокировать всю задачу.
Это предлагаемый метод оценки, а не результат, установленный цитируемыми исследованиями. Его информационная ценность заключается в последовательности принятия решений: определить доступ, заявить об ограничении, запросить минимально необходимый источник, подтвердить принятую деталь и четко обозначить рамки обновления. Эта последовательность превращает фразу «Я не знаю» в продуктивный шаг рабочего процесса.
Сделайте неопределенность частью непрерывности проекта
Для ассистента в творческом проекте признание отсутствия детали не является тупиком. Это способ защитить непрерывность: система может продолжать помогать, оставляя непроверенную историю незаполненной. Четко обозначенная неопределенность, сфокусированный запрос и явное подтверждение позволяют пользователю самому решать, что должно войти в историю проекта, а ассистенту дают надежную основу для следующего черновика.