Ложь пользователя как штатный режим работы

Коротко для руководителя. Про галлюцинации языковых моделей говорят все: модель уверенно выдаёт неправду. Гораздо реже признают вторую половину той же проблемы — недостоверен и сам пользователь. Человек регулярно сообщает агенту неверный бюджет, не те даты, ложные ограничения и подменённую цель, причём почти всегда не со зла. Агент, который слепо доверяет входу, строит безупречное решение на ложных вводных — и ошибается тем увереннее, чем чище его логика. Надёжность достигается не верой в данные клиента, а проектированием под заведомо недостоверный вход. Это меняет требования к системе и к её приёмке.

В разговорах про надёжность диалогового ИИ почти всё внимание уходит на галлюцинации модели: LLM уверенно говорит то, чего нет. Это реальная проблема, но она закрывает собой вторую, не менее важную. У диалога два участника, и недостоверен не только агент. Недостоверен и человек. Он сообщает не те цифры, путает даты, называет ложные ограничения и подменяет цель по ходу — и делает это постоянно, в штатном режиме, а не в виде редкого исключения.

Гипотеза: недостоверный пользовательский ввод — это норма, а не сбой

Стандартная архитектура диалогового агента молчаливо предполагает, что данные от пользователя истинны: сказал бюджет — значит, столько и есть; назвал дату — значит, поедет тогда. Мы утверждаем, что это допущение ложно по умолчанию. Недостоверный ввод — не редкая аномалия, которую можно списать на «трудного клиента», а штатный режим работы любой диалоговой системы с живыми людьми. И, что важно, это зеркало галлюцинаций модели: индустрия научилась проектировать защиту от того, что врёт LLM, но почти не проектирует защиту от того, что врёт человек. Надёжность агента определяется тем, переживает ли он недостоверность с обеих сторон, а не с одной.

Проблема: человек искажает данные постоянно и почти всегда не со зла

Важно сразу убрать моральную окраску. «Ложь» здесь — не про обман и злой умысел; это инженерный термин для недостоверного входа. Человек искажает данные по совершенно понятным причинам, и почти никогда — чтобы навредить.

Он называет заниженный бюджет, потому что торгуется или стесняется реальной суммы. Он говорит «гибкие даты», хотя на самом деле привязан к отпуску, — просто ещё сам не осознал жёсткость. Он заявляет ограничение («только прямой рейс»), которое на проверку оказывается предпочтением, от которого он откажется ради цены. Он формулирует цель («ищу подарок»), а на деле выбирает себе. Он отвечает «да, всё подходит», чтобы быстрее закончить, а не потому, что подходит. Ни в одном из этих случаев нет злого умысла — есть обычная человеческая неточность, торг, самообман и желание не усложнять.

Для агента результат один и тот же независимо от мотива: вход недостоверен. И линейный агент, доверившись ему, выстраивает идеально логичное решение на ложном фундаменте. Чем чище его рассуждение, тем дальше уезжает результат от реальной задачи. Это та же механика, что и уверенная ошибка RAG, который выдаёт правдоподобный ответ на испорченных данных, — только источник искажения не в базе знаний, а в собеседнике.

Почему обычные подходы не работают

Первый привычный подход — валидация фактов: проверить, что бюджет — число, дата — в будущем, поле заполнено. Это ловит опечатки и не ловит главного. Заниженный бюджет проходит любую факт-валидацию: это корректное число, просто неправда. «Гибкие даты» — валидный ответ, просто недостоверный. Формальная проверка полей слепа к тому, что данные внутренне непротиворечивы, но не соответствуют реальной задаче человека.

Второй подход — обучать пользователя «отвечать правильно»: вводить строгие формы, обязательные поля, переспросы «вы уверены?». Это перекладывает инженерную проблему на клиента и не решает её: человек не врёт нарочно, поэтому он так же уверенно подтвердит недостоверный ответ. Жёсткая форма лишь маскирует искажение под валидный ввод — и заодно отпугивает тех, кто ещё не определился. Это тот же хардкод сценария, который ломается о живого человека: мы пытаемся загнать недетерминированный вход в детерминированную рамку.

Третий подход — надеяться на «понимание» модели: умная LLM сама заметит несостыковку. Иногда замечает, но системно полагаться на это нельзя. Модель по умолчанию услужлива и доверчива: она принимает сказанное за истину и старается помочь на этих вводных, потому что обучена быть полезной, а не подозрительной. Без явной инженерной установки на проверку мотивации модель добросовестно усиливает искажение — строит всё более качественный ответ на всё той же ложной основе.

Инженерная модель: валидировать мотивацию, а не только факты

Рабочая модель смещает фокус с проверки фактов на проверку мотивации. Вопрос агента — не «корректны ли данные формально», а «соответствуют ли они реальной задаче человека». Контур держится на трёх вещах.

Первое — относиться к вводу как к гипотезе, а не как к истине. Каждое заявленное ограничение, цифра и цель агент держит как версию, требующую подтверждения поведением, а не как факт. Это меняет внутреннюю модель диалога: агент работает не с «данными клиента», а с картиной его задачи, которую достраивает и уточняет по ходу — это и есть его главный рабочий ресурс.

Второе — выявлять мотив за данными, а не сами данные. Вместо «уточните бюджет» агент мягко проверяет жёсткость ограничения: что критично, а что — предпочтение, от которого человек откажется. Заниженный бюджет всплывает не через допрос о сумме, а через реакцию на варианты чуть выше: если человек смотрит — цифра была торгом, а не пределом. Это дёшево по репликам и вытаскивает реальную рамку задачи, которую факт-валидация в принципе не видит.

Третье — ловить противоречия по ходу, а не на входе. Недостоверность чаще проявляется не в момент ответа, а позже: «гибкие даты» сталкиваются с «надо до 15-го», «только эконом» — с интересом к более дорогому. Агент, который удерживает контекст всего диалога и сверяет новые реплики со старыми, замечает эти расхождения и переспрашивает по существу — а не подшивает противоречие в профиль клиента как два равноправных факта.

Принципиально: эта модель не делает агента подозрительным к человеку. Она делает его устойчивым к нормальной человеческой неточности — ровно так же, как защита от галлюцинаций делает устойчивой саму модель. Недостоверность с обеих сторон — это часть штатного шума диалога, под который и проектируется надёжный агент.

Практический вывод для бизнеса

Признайте недостоверный ввод проектным требованием. Если в постановке задачи агент «получает от пользователя бюджет, даты и цель», постановка уже неверна — она описывает демо, а не прод. Правильная формулировка: агент работает с заведомо недостоверным входом и проверяет мотивацию, а не факты. Это требование, как и защита от галлюцинаций, должно стоять в спецификации, а не появляться постфактум после жалоб.

Что поручить. Заложите в приёмку сценарии с искажённым вводом: заниженный бюджет, ложно-гибкие даты, подменённая цель, поспешное «да». Проверяйте на корпусе реальных диалогов — там видно, как и где люди искажают на самом деле, а не как это воображает разработчик.

Чего не делать. Не лечите проблему ужесточением форм и обязательными полями — это перекладывает инженерный долг на клиента и отпугивает выручку. Не считайте факт-валидацию защитой от недостоверности: корректное по форме и ложное по сути проходит её насквозь. И не путайте устойчивость к неточности с недоверием к человеку — цель не уличить клиента, а довести его до результата на честно понятой задаче.

Применить это к вашему агенту — обсудить с инженером → .

Открытые вопросы

Где граница между проверкой мотивации и навязчивостью — слишком дотошный агент начинает раздражать тех, кто как раз сказал правду, и калибровка этой грани держится на живом трафике, а не на интуиции. Как мерить «агент устойчив к недостоверному вводу» в приёмке — это сложнее факт-проверки и требует судьи по исходу диалога, а не по факту ответа. Насколько глубоко стоит копать мотив в коротком сервисном контакте против длинной продажи — зависит от цены ошибки в конкретном процессе и решается до запуска, а не в проде.

Если ваш агент строит безупречные ответы, которые на практике мимо, — проверьте не модель, а вход: скорее всего, он доверяет данным клиента как истине. Обсудить задачу → — посмотрим, где недостоверный ввод уводит вашего агента от реальной задачи.