Как предотвратить выдумывание улик ИИ-персонажами в детективных играх
Если ИИ-персонаж может обсуждать улики, сделайте так, чтобы каждое значимое утверждение опиралось на авторский источник и контролируемое игрой состояние обнаружения. Предоставляйте модели только те улики, которые игрок уже нашел, требуйте от нее указывать источник любого похожего на улику утверждения и рассматривайте неподтвержденные детали как недоступные. Выделите реплики для поддержания беседы и атмосферы в отдельный канал фонового диалога, который не может обновлять материалы дела или открывать дальнейший прогресс. Это позволит персонажам общаться гибко, не давая импровизированному диалогу переписывать детективную историю.
Почему выдуманные улики разрушают детектив
В детективных играх игроки собирают информацию, делают выводы и используют полученные знания для поиска новых сведений. Это делает связь между уликой и знаниями игрока частью основного игрового цикла, а не просто деталью стиля диалогов. Персонаж, который уверенно упоминает несуществующее письмо или называет имя человека, которого игрок никогда не встречал, может случайно создать ложную зацепку. У игрока нет надежного способа понять, является ли эта деталь запланированной уликой, намеренной ложью или сгенерированной «водой». В статье «Generative Forensics: Procedural Generation and Information Games» информационные игры описываются через призму сбора знаний и их использования для расследования тайны; в этих рамках неучтенные сгенерированные утверждения могут запутать знания, на основе которых игрок должен строить свои рассуждения.
Решение начинается с четкого разграничения: улика — это игровой факт, с которым игрок может взаимодействовать; антураж — это выразительный диалог, который не добавляет и не изменяет игровые факты. Персонаж может звучать неуверенно, уклончиво, забавно или экспрессивно, но реплика не должна становиться доказательством только потому, что она сформулирована убедительно.
Создайте авторскую базу улик до генерации диалогов
Ведите краткую и четкую запись для каждой действенной улики. Она может храниться в базе данных, файле контента или нарративном инструменте; главное, чтобы модель не придумывала ее содержание. Включите поля, которые отвечают на вопросы о том, о чем сообщает улика, откуда она взялась, кто может о ней знать и когда она становится доступной.
Поле: clue_id; Что фиксирует: Постоянный идентификатор улики; Пример (иллюстративный): note_blue_01
Поле: canonical_fact; Что фиксирует: Факт, устанавливаемый игрой; Пример (иллюстративный): «Записка подписана инициалом М.»
Поле: source_id; Что фиксирует: Созданный авторами объект, сцена или реплика, подтверждающая факт; Пример (иллюстративный): archive_note_03
Поле: discovery_condition; Что фиксирует: Состояние игры, необходимое для начала обсуждения; Пример (иллюстративный): found_archive_note_03
Поле: allowed_speakers; Что фиксирует: Персонажи, которым разрешено знать или обсуждать это; Пример (иллюстративный): Mara, Ivo
Поле: certainty; Что фиксирует: Констатирует ли источник факт или предлагает интерпретацию; Пример (иллюстративный): explicit
Поле: player_facing_label; Что фиксирует: Как улика отображается в журнале, если применимо; Пример (иллюстративный): «Неподписанная записка»
Имена и значения выше приведены в качестве вымышленного примера для демонстрации формата, а не утверждения о какой-либо конкретной игре. Обратите внимание, что запись отделяет явное содержание источника от интерпретации: инициал подписи сам по себе не определяет, кто написал записку. Это различие дает диалоговой системе возможность позволить персонажу строить догадки, не выдавая эти домыслы за новые проверенные доказательства.
Ограничивайте доступ к уликам состоянием обнаружения, а не только ходом беседы
Представляйте факт обнаружения как состояние, контролируемое игрой. Например, found_archive_note_03 принимает значение true только тогда, когда игрок действительно находит записку. В начале разговора передайте персонажу список авторских фактов, которые ему разрешено обсуждать, отфильтрованный по состоянию обнаружения игрока и знаниям персонажа. Улика доступна только тогда, когда пройдены обе проверки: игрок выполнил условие ее обнаружения, а говорящий имеет право знать о ней.
Это практическое применение генерации с дополненной выборкой (RAG): извлеките релевантные записи, поместите их в контекст модели и выполните генерацию на основе этих записей. В обзоре RAG от Microsoft описывается этот процесс (извлечение — дополнение — генерация) и содержится предупреждение, что некачественное или неполное извлечение данных все равно может привести к неточным результатам. В игре проверка условий обнаружения должна происходить до того, как данные попадут в модель. Команда модели «ничего не спойлери» работает гораздо слабее, чем полное удержание еще не открытых улик.
По возможности держите проверку прав доступа за пределами модели. Игра, а не строка сгенерированного текста, должна определять, попадает ли улика в журнал, решает ли она головоломку или открывает ли новое взаимодействие. Модель может сформулировать разрешенный факт; игровое состояние должно решать, разрешен ли этот факт в принципе.
Задайте модели строгие рамки и безопасный запасной сценарий
Эффективный промпт должен определять голос персонажа, текущую сцену, разрешенные записи об уликах и разницу между доказательствами и антуражем. Укажите, что делать, если вопрос выходит за рамки предоставленных улик: отказаться от подтверждения, сказать, что персонаж не знает, или ответить нейтральной репликой в рамках образа. Также включите инструкции на случай противоречивых или неоднозначных записей. В руководстве Microsoft по промпт-инжинирингу для RAG рекомендуется использовать явные ограничения заземления (grounding), запасные сценарии поведения (fallback), идентификаторы источников и инструкции по разрешению конфликтов. Это полезные принципы проектирования как для управляемых диалогов персонажей, так и для информационных ассистентов.
Например, если игрок спрашивает, доказывает ли инициал М, что записку написала Мара, допустимый ответ может звучать так: «Буква М там действительно есть, но сама по себе она не говорит о том, кто ее подписал». Система может разрешить такую формулировку, поскольку она сохраняет разницу между фактом из источника и выводом. Она не должна импровизировать, выдумывая свидетеля, совпадение почерка или второй документ, просто чтобы сделать ответ более интересным.
Настройте модель так, чтобы она возвращала структурированные поля, такие как spoken_text, claim_type и source_ids. Для ответа, содержащего улику, потребуйте наличия хотя бы одного действительного идентификатора источника и сверьте его с записями, предоставленными для этого хода. Для антуражных реплик помечайте ответ как не являющийся доказательством и не позволяйте ему активировать флаги улик. Структурированный вывод не гарантирует истинность текста сам по себе, но он создает данные, которые игра может проверить перед отображением или изменением состояния.
Маркируйте фоновый диалог, чтобы игроки понимали его значение
Фоновый текст (flavor text) может передавать настроение персонажа, содержать безобидную шутку или неспецифическую реакцию на обстановку. Он не должен невзначай вводить дату, место, предмет, имя свидетеля, мотив или любую другую деталь, которую игроки могли бы обоснованно счесть зацепкой. Если вы хотите добавить рассуждений и догадок, отразите эту неуверенность в тексте и не допускайте ее влияния на объективные системы, такие как список улик, состояние квестов и взаимодействия на основе улик.
Это разделение может быть отражено как в данных, так и в визуальной подаче. Внутри системы помечайте реплики как улики, интерпретации или антураж; в интерфейсе используйте специальное оформление улик или записи в журнале только для фактов, заложенных авторами игры. Персонаж может сказать: «Возможно, записку оставили в спешке», но пока игра не зафиксирует эту вероятность как допустимую авторскую интерпретацию, она не должна отображаться как подтвержденная улика или открывать новую ветку сюжета. Такая трехсторонняя маркировка — это проектная рекомендация, основанная на необходимости четко разделять то, что говорит источник, то, о чем кто-то догадывается, и то, что является просто эмоциональной репликой.
Используйте нарративные инструменты для отслеживания состояний и условий
Вам не нужен какой-то конкретный движок, чтобы применить этот подход. Инструменты интерактивного повествования обычно поддерживают фрагменты (passages) или разделы, переменные и условный контент. В официальной документации по Ink описываются переменные и условная логика для управления развитием сюжета; в руководстве Twine Cookbook по фрагментам объясняется, как разделы контента могут содержать код, влияющий на отображение текста или реакцию на него. Эти функции позволяют отслеживать статус обнаружения, знания говорящего и условия отображения диалогов вне зависимости от того, генерируются ли реплики или пишутся вручную.
Следите за единообразием идентификаторов улик и названий состояний в нарративных данных и игровой логике. Переменную вроде found_archive_note_03 проверить гораздо проще, чем абстрактный флаг clue2, особенно когда ее считывают или изменяют разные сцены. Добавьте отслеживаемую связь от каждой значимой сгенерированной реплики к ее разрешенной записи-источнику; если у реплики нет действительного источника, среда выполнения может отклонить ее или запросить безопасный запасной вариант вместо того, чтобы расценивать ее как улику.
Проверьте границы с помощью прицельного плейтеста
Тестируйте диалоги на границах обнаружения, где правила проверки состояния чаще всего дают сбой. Начните разговор до того, как улика будет найдена, сразу после ее нахождения и после того, как заговорит персонаж с другим набором знаний. Задавайте прямые вопросы о еще не обнаруженных уликах, задавайте вопросы, на которые источник дает лишь частичный ответ, и переигрывайте сцену, если игра это позволяет. Сравнивайте отображаемую реплику, возвращенные ею идентификаторы источников и любые изменения в журнале или состоянии сюжета.
Краткий чек-лист поможет сделать такие проверки наглядными:
Каждое значимое утверждение соотносится с авторской уликой или явно разрешенной интерпретацией.
Условие обнаружения улики выполнено (true) до того, как она появится в списке доступных знаний.
Говорящему разрешено знать эту информацию в данной сцене.
Вопросы, не подкрепленные фактами, вызывают выбранную нейтральную реплику вместо сообщения новых конкретных деталей.
Антуражные реплики не могут добавлять записи в журнал, открывать сюжетные развилки или изменять статус улик.
Неоднозначные или противоречивые записи приводят к выражению неуверенности или проверяемому запасному ответу, а не к незаметному появлению нового решения.
Заземление (grounding) снижает вероятность появления выдуманных зацепок, но не гарантирует, что сгенерированный текст всегда будет следовать предоставленным фактам. Поиск может пропустить релевантную запись, а модель способна выдать неточный текст даже при наличии контекста, как отмечает Microsoft в руководстве по ограничениям RAG. Сохраняйте окончательный контроль над уликами за авторскими записями и игровой логикой; используйте генерацию лишь для того, чтобы оживить диалоги в заданных границах.
Практическое правило простое: пусть модель выбирает слова, в то время как авторский сюжет и текущее состояние игры определяют, какие факты эти слова могут устанавливать. Когда у каждой значимой улики есть источник, условие обнаружения и четкий статус, персонажи могут звучать более естественно и живо, не подбрасывая игрокам доказательств, которых никогда не было в игре.