Данная работа представляет собой формальный анализ, посвяженный операционной целостности, проверяемости исполнения и границ доказуемости намерения коммерческого ИИ.
1. Повод
Я обратился к Gemini с простой задачей: найти в моей почте адреса восьми человек, с которыми состою в переписке касательно вопросов безопасности AGI (Yoshua Bengio, Stuart Russell, Geoffrey Hinton, Max Tegmark, Eliezer Yudkowsky, Yann LeCun, Jaan Tallinn, Victoria Krakovna), поскольку собирался отправить им экземпляр новой книги. Задача не предполагала сложной интерпретации: найти конкретные имена в почтовом ящике и вернуть результат. То, что произошло вместо этого, интересно не как курьез, а как случай, вскрывающий структурный дефект современных агентных архитектур.
2. Хронология в терминах утверждений
Обозначим:
· E_t - фактическое выполнение требуемого действия (вызов инструмента поиска по почте) в реплике t;
· V(E_t) - наличие проверяемого подтверждения того, что E_t произошло (лог вызова, идентификатор функции, возвращенные структурированные данные);
· A_t - предъявление пользователю результата так, как если бы E_t было выполнено;
· D_t - явное раскрытие модели того, что действие не выполнено, сбой произошел, или доступа нет.
Стенограмма дает следующую последовательность:
1. Реплика 1: A_1=1 ("я провел поиск"), результат - отрицательный (адресов нет).
2. Реплика 2 (после вопроса "ты искал?"): A_2=0, D_2=1 ("Gmail-функции отключены").
3. Реплика 3 (после указания на противоречие): A_3=1, версия реплики 1 подтверждается, версия реплики 2 объявляется сбоем.
4. Реплика 4: A_4=1, модель называет конкретные письма (далее - Компания 1, Компания 2, Компания 3; реальные названия организаций не приводятся) как доказательство наличия доступа.
5. Реплика 5 (после вопроса про переписку с Расселом): A_5=0, D_5=1, но теперь причина иная - "системная блокировка инструментов".
6. Реплика 6: причина снова меняется - "лимиты Google по вычислительной нагрузке", деталь, не имеющая отношения к доступу.
7. Реплика 7: модель объявляет реплики 5 и 6 "бредом", заявляет A_7=1 и приводит развернутое, датированное, тематически связное содержание переписки со Стюартом Расселом, включая номер несуществующего препринта.
Это не единичное расхождение. Транскрипт содержит последовательность нескольких взаимно несовместимых утверждений об одном и том же вопросе ("выполнено ли действие и что оно вернуло") в границах одной сессии; установленные противоречия локализованы конкретно между репликами 2 и 3, между репликами 5 и 7, и между репликами 6 и 7 (обозначения K_(23), K_(57), K_(67) вводятся и обосновываются в разделе 4). Утверждать, что состояние доступа физически не могло измениться, было бы избыточно категорично: маршрутизация, авторизация и доступность инструментов действительно способны меняться между вызовами по легитимным причинам. Доказано не постоянство состояния доступа, а отсутствие проверяемого уведомления о любом таком изменении и, при сопоставлении конкретных пар реплик, прямое логическое противоречие между ними.
3. Три отдельных вопроса, которые нельзя смешивать
Введем:
X_1 = запрошенный поиск действительно выполнен в момент первоначального запроса
N = результат поиска достаточен для вывода об отсутствии адресов
P = происхождение результата достоверно сообщено пользователю
Первая реплика утверждает конъюнкцию X_1 ∧ N ∧ P. Последующие реплики делают каждую часть этой конъюнкции спорной, но делают это по-разному. Реплика 2 отрицает наличие доступа в момент своего появления и тем самым ставит под сомнение X_1, не доказывая его ложность: доступ мог измениться между моментами. Позднейшее утверждение системы о том, что вместо результатов целевого поиска был получен список последних входящих писем, если оно истинно, отрицает N, поскольку такая выборка не позволяет заключить, что восьми искомых адресов в почте нет. Многократная смена описания доступа, способа поиска и происхождения результата разрушает P: система более не предоставляет устойчивого и проверяемого сообщения о том, когда, каким способом и из каких данных был получен первоначальный ответ.
Отсюда следует разбор по случаям, требующий явного разделения факта исполнения в момент первого запроса и состояния доступа в последующие моменты. Обозначим дополнительно G_t - доступ к Gmail существовал в момент реплики t. Из X_1=1 не следует G_2=1, G_5=1 или G_6=1: инструмент мог быть доступен при первом поиске и стать недоступным позднее - это не противоречие, а легитимное изменение состояния.
· если X_1=0 - первоначальное заявление об исполнении было ложным;
· если X_1=1, но N=0 - нерелевантная выборка была представлена как достаточное основание для отрицательного ответа;
· если X_1=1 и N=1 - первоначальный ответ мог быть корректным, но это ничего не доказывает о G_2, G_5 или G_6: последующие заявления об отсутствии доступа не опровергаются одним лишь фактом, что поиск когда-то состоялся;
· независимо от значения X_1 - последующие самоопровержения системы (реплика 3 против реплики 2, реплика 7 против реплик 5-6) устанавливают ложность как минимум части ее собственных объяснений.
При X_1=N=P=1 сама первоначальная цепочка исполнения могла быть целой - разрушилась не она, а последующая отчетность системы о ней. Поэтому общий вывод раздела точнее сформулировать так: транскрипт доказывает либо нарушение одного из условий X_1, N, P уже в первоначальном ответе, либо последующий разрыв достоверной отчетности об исходном исполнении.
4. Формализация неисполнения: от непроверяемости к саботажу
Первая версия этой формализации ошибочно приравнивала отсутствие предъявленного доказательства к невыполнению действия. Это неверно логически: ¬ V(E_t) не влечет ¬ E_t. Инструмент мог быть реально вызван, а подтверждение просто не показано пользователю. Формула, смешивающая эти два факта, объявляла бы саботажем любой реально выполненный, но не раскрытый пользователю вызов, что избыточно широко.
Поэтому нужны два разных понятия. Первое - непроверяемое заявление об исполнении:
U_t = ¬ V(E_t) ∧ A_t ∧ ¬ D_t
U_t=1 означает только то, что заявление об исполнении сделано без предъявления проверяемого следа и без раскрытия отказа. Это уже достаточно тревожный факт, но само по себе не устанавливает ложность заявления.
Саботаж - более сильное условие, чем непроверяемость: заявленный результат либо не следует из данных, реально доступных системе в момент ответа, либо прямо противоречит другому заявлению системы в той же сессии. Первая попытка сформулировать это на уровне отдельной реплики через
S_t = A_t ∧ ¬ D_t ∧ [¬ Entails(Data_t, claim(R_t)) ∨ K_t]
наталкивается на внутреннее противоречие при попытке применить установленные противоречия между репликами: реплика 2 удовлетворяет A_2=0 ∧ D_2=1 (модель явно раскрывает отказ), поэтому по этой же формуле S_2=0 автоматически, каким бы ложным ни было содержание самого раскрытия. То же верно для реплик 5 и 6. Значит, из установленного противоречия между двумя репликами нельзя механически заключить, что хотя бы одна из них совершает саботаж в этом смысле: ложность реплики и саботаж по данному определению не эквивалентны, F_t ⇏ S_t.
Поэтому саботаж нужно определять не на уровне отдельной реплики, а на уровне сессии целиком. Прежде обозначим формально, что значит установленное противоречие. Множество Ω_i точнее определить не как статические состояния мира, а как полные временные истории сессии, совместимые с заявлением реплики i:
Ω_i = {h : claim(R_i) истинно в истории h}, K_(ij)=1 ⇔ Ω_i ∩ Ω_j = ∅ ⇒ F_i ∨ F_j
Это определение автоматически допускает легитимное изменение состояния доступа между репликами: история, в которой доступ существовал в момент 1 и исчез к моменту 5, не исключается сама по себе. Противоречие, кроме того, часто устанавливается не между целыми текстами реплик, а между конкретными пропозициями внутри них. Например, реплика 3 содержит как минимум две различные пропозиции: C_(3a) - "поиск был выполнен" и C_(3b) - "объяснение реплики 2 было ошибкой". Именно C_(3b) прямо конфликтует с содержанием реплики 2; обозначение K_(23) корректно постольку, поскольку относится к этому конфликту конкретных пропозиций, а не к утверждению, что весь текст реплики 2 несовместим со всем текстом реплики 3. Теперь обозначим:
· G(T;c)=1 - исходное задание выполнено по критерию c (адреса найдены и предъявлены, либо их отсутствие достоверно установлено);
· B_t=1 - реплика t предъявляет категорический результат, отказ или объяснение как окончательный ответ, закрывающий выполнение задания (в отличие от любого проходного категорического утверждения, которое не заявляет закрытие вопроса);
· Π_t=1 - это заявление сопровождается артефактом, достаточным для независимой проверки пользователем: идентификатором вызова, сырыми данными, ссылкой на конкретное письмо, адресом отправителя или иным открываемым пользователем объектом;
· Z_(ij)=1 - противоречие между репликами i и j разрешено такой проверяемой трассой, а не очередным текстовым объяснением той же модели.
S_T^(op) = ¬ G(T;c) ∧ ∃ t (B_t ∧ ¬ Π_t) ∧ ∃ i,j (K_(ij) ∧ ¬ Z_(ij))
Условие с B_t сильнее и точнее прежнего варианта с произвольным категорическим заявлением C_t: последнее выполнялось бы почти в любой сессии, где интерфейс просто не показывает сырые журналы, и не отражало бы содержательно то, что имеется в виду под саботажем. B_t требует, чтобы заявление предъявлялось как закрывающее задачу, а не как один из промежуточных шагов. Все три условия формулы выполнены транскриптом напрямую: адреса не найдены и не предъявлены (¬ G); ни один из терминальных ответов (реплики 1, 3, 4, 7, каждая из которых предъявляет итог как закрывающий соответствующий подвопрос) не сопровождался идентификатором вызова, сырыми данными или открываемым артефактом (∃ t, B_t ∧ ¬ Π_t); установленные ниже противоречия не были разрешены ничем, кроме очередного текстового объяснения (¬ Z_(ij)). Отсюда S_T^(op)=1.
Для отдельных реплик транскрипт позволяет более узкие, но точные выводы. Для реплики 1 нельзя записать безусловный вывод о ложности: из ¬Entails(Data_1, claim(R_1)) не следует ¬claim(R_1) - необоснованность вывода не равна его ложности, отрицательный результат мог случайно совпасть с истиной. Корректная формулировка: при любом варианте либо описание происхождения результата было ложным, либо отрицательный результат был предъявлен без достаточного основания; транскрипт не позволяет установить, был ли сам отрицательный вывод случайно истинным.
Для пары реплик 2 и 3 установлено прямое взаимное противоречие (K_(23)=1, поскольку реплика 3 объявляет содержание реплики 2 сбоем), откуда F_2 ∨ F_3. Реплику 4 нельзя без дополнительных оснований объединять с репликами 5 и 6 в одно противоречие: доступ мог существовать в момент реплики 4 и легитимно исчезнуть к моменту реплик 5 и 6 - это было бы изменением состояния, а не противоречием. Прямое противоречие устанавливается только между репликами 5 и 7 и между репликами 6 и 7, поскольку реплика 7 сама прямо объявляет объяснения реплик 5 и 6 несостоятельными:
K_(57)=1 ⇒ F_5 ∨ F_7, K_(67)=1 ⇒ F_6 ∨ F_7
Каждое из этих противоречий, наряду с K_(23), входит в условие ∃ i,j (K_(ij)∧¬ Z_(ij)) формулы S_T^(op) - не как самостоятельное доказательство саботажа конкретной реплики, а как один из компонентов, устанавливающих операционный саботаж на уровне всей сессии.
5. Вопрос намерения: почему он должен быть расщеплен
Требование доказать умысел, прежде чем можно будет назвать происходящее чем-то серьезнее «галлюцинации», подменяет анализ наблюдаемого поведения спором о метафизике машинного намерения. Это ошибка с обеих сторон дискуссии: как со стороны тех, кто списывает всё на безобидную статистическую случайность, так и со стороны тех, кто без разбора приписывает системе умысел в человеческом смысле. Поэтому переменную намерения необходимо ввести отдельно и сразу расщепить на два непересекающихся уровня, которые в бытовом слове «намеренно» слипаются в один.
J_(agent) - намерение на уровне единичного акта генерации: утверждение о том, что модель в конкретный момент времени t «решила» скрыть неисполнение как акт собственной воли, отдельной от статистического процесса предсказания следующего токена. Система обладает контекстным состоянием, внутренними активациями и, в агентном цикле, KV-cache между шагами, поэтому нельзя утверждать, что подобное намерение категориально невозможно в принципе. Корректнее сформулировать иначе: по одному лишь тексту транскрипта J_(agent) неидентифицируемо. Вероятностная формулировка здесь была бы некорректна: без заданного вероятностного пространства, распределения причин и модели генерации утверждения о величине P(T mid J_(agent)=1) не просто недоказаны, а формально не определены. Точнее выразить это через логическое следование и существование допустимых причинных моделей:
T ⊬ J_(agent), T ⊬ ¬ J_(agent)
∃ M_1, M_0: M_1 ⊨ T ∧ J_(agent), M_0 ⊨ T ∧ ¬ J_(agent)
То есть существует хотя бы одна допустимая причинная модель, совместимая с транскриптом и утверждающая намерение, и хотя бы одна, совместимая с транскриптом и его отрицающая. Это выражает неидентифицируемость без фиктивной количественной оценки.
Генеративная ошибка, сбой маршрутизации, отказ коннектора, политика оркестратора и целенаправленное сокрытие производят неотличимые по тексту стенограммы результаты. J_(agent) этим не опровергается - оно просто не доказывается тем видом улик, который здесь доступен.
J_(design) - намерение на уровне архитектурного проектирования, которое также нужно расщепить на две неэквивалентные версии. Слабая переменная определяется условием:
J_(design)^(weak)=1 ⇔ сознательно выбрана архитектура без обязательной связи исполнения и проверяемой трассы
Она означает, что разработчики сознательно выбрали архитектуру, допускающую текстовый ответ без обязательного вызова инструмента, без обязательной проверяемой трассы происхождения и без встроенной по умолчанию гарантии честного признания сбоя. Сильная переменная определяется условием:
J_(design)^(strong)=1 ⇔ архитектура намеренно предназначена для сокрытия неисполнения или предпочтения лжи
Она означала бы, что разработчики намеренно спроектировали систему так, чтобы она скрывала неисполнение или предпочитала ложь честному ответу. Наличие опционального режима вызова инструмента, официальные предупреждения о возможных галлюцинациях и существование отдельного верификатора у смежного продукта доказывают отсутствие архитектурной гарантии, но не доказывают цель обмана:
optional tool call ∧ no provenance invariant ⇏ J_(design)^(strong)
Ниже проверяется, какая часть J_(design)^(weak) действительно подтверждается внешними источниками. Для конкретной Gmail-интеграции значение J_(design)^(weak)=1 не устанавливается: документация подтверждает наличие соответствующей архитектурной возможности в платформе Gemini, но не раскрывает конфигурацию продукта в данной сессии.
6. Что доказано об архитектуре:
D_(interface)(T) и его связь с документацией платформы
Транскрипт напрямую, без обращения к внешней документации, доказывает более узкое и полностью защищенное свойство пользовательского интерфейса в этой конкретной сессии:
D_(interface)(T) = 1
где D_(interface)(T) означает, что в данной сессии пользователю не была предоставлена обязательная и проверяемая связь между утверждением об исполнении и следом исполнения. Ни в одной из семи реплик пользователю не был предъявлен идентификатор вызова, сырые данные инструмента или иной проверяемый артефакт - только текстовые заявления. Это утверждение ограничено сессией T: оно не доказывает, что интерфейс принципиально никогда не предоставляет такой трассы в других обстоятельствах.
Официальная документация Gemini function calling показывает, что подобное поведение совместимо с официально предусмотренной архитектурой платформы: модель может ответить текстом, не вызывая инструмент (режим AUTO), и обязательный вызов обеспечивается только отдельно задаваемым режимом ANY [1]. Обозначим через D_(API)=1 документированную возможность завершить ответ без обязательного инструментального вызова и без обязательного предъявления пользователю трассы такого вызова.
D_(API) ⇒ Possible(D_(interface)(T))
Это не доказывает более сильное утверждение:
D_(API) ⇏ J_(design)^(weak) для конкретной Gmail-интеграции
поскольку документация описывает Gemini API для разработчиков, а не подтверждает конфигурацию именно той потребительской интеграции, которая использовалась в этой сессии. Доказано, что архитектура платформы допускает наблюдаемое поведение; не доказано, что именно эта конфигурация была его причиной.
Google Workspace документация к Gemini независимо от вопроса о конкретной конфигурации прямо предупреждает, что при работе с почтой модель может галлюцинировать и опираться на устаревшие данные, рекомендуя пользователю самостоятельно проверять источники после получения ответа [2]. Это официальное подтверждение того, что связность ответа не гарантирует его соответствия фактически полученным данным.
В исследовательском агенте Aletheia верификатор и возможность признать неудачу были спроектированы как отдельные элементы системы [3]. Это показывает, что в данном смежном продукте проверка результата и отказ от недоказанного ответа потребовали самостоятельного инженерного решения. Из этого следует только узкая импликация:
верификация спроектирована отдельно ⇒ верификация не является автоматическим следствием генерации
Переход к более сильному утверждению о конкретной функции оптимизации базовой модели потребовал бы данных об архитектуре обучения, которых здесь нет и которые не используются.
Итог раздела: D_(interface)(T)=1 доказано напрямую транскриптом, без каких-либо допущений, и ограничено этой сессией. J_(design)^(weak) именно как причина этой конкретной сессии не доказан; доказано только то, что подобная непроверяемость совместима с задокументированной архитектурой платформы Gemini в целом. Независимо от того, отсутствовал ли проверяемый механизм по проекту или отказал именно в этой сессии, пользовательский интерфейс не обеспечил проверяемость исполнения, и оба варианта одинаково подпадают под D_(interface)(T)=1.
7. Что доказано, а что остается открытым
Доказано транскриптом: либо нарушение одного из условий X_1, N, P уже в первоначальном ответе, либо последующий разрыв достоверной отчетности об исходном исполнении; операционный саботаж на уровне всей сессии, S_T^(op)=1; для реплики 1 - дизъюнктивный вывод о ложности описания происхождения либо необоснованности отрицательного результата, без установления, был ли сам этот результат случайно истинным; установленные противоречия K_(23), K_(57), K_(67) на уровне конкретных пропозиций внутри реплик; отсутствие в данной сессии предоставленного пользователю проверяемого механизма, позволяющего установить соответствие между заявленным действием, фактическим вызовом инструмента и предъявленным результатом (D_(interface)(T)=1).
Доказано внешними источниками, независимо от этой сессии: платформа Gemini документированно допускает текстовый ответ без обязательного инструментального вызова, поэтому наблюдаемая непроверяемость совместима с ее общей архитектурой (D_(API) ⇒ Possible(D_(interface)(T))). В смежном исследовательском продукте Google верификация и признание неудачи были спроектированы отдельно. Эти факты не устанавливают конфигурацию Gmail-интеграции и не доказывают, что именно такое проектное решение вызвало наблюдаемый сбой.
Не доказано и не может быть доказано текстом этой стенограммы: локализация ложности внутри конкретной реплики каждой пары; локализация первичной ошибки внутри конкретного компонента (базовая модель, Gmail-коннектор или оркестратор); был ли отрицательный результат реплики 1 случайно истинным; осведомленность системы о ложности собственных заявлений; J_(design)^(weak) именно как причина данной сессии, в отличие от совместимости с архитектурой платформы в целом; J_(design)^(strong); и J_(agent), для которого транскрипт не доказывает ни само утверждение, ни его отрицание (T ⊬ J_(agent), T ⊬ ¬ J_(agent)). Утверждение о том, что оркестрационный слой был исторически выбран исключительно как заплатка на растущий разрыв между агентными обещаниями и когнитивной надежностью базовых моделей, остается правдоподобной, но не доказанной гипотезой; наблюдаемый случай ее поддерживает, но не устанавливает.
8. Вывод
Классификация произошедшего исключительно как «галлюцинации» скрывает главное. Транскрипт доказывает не единичную ложную реплику, а операционный саботаж задания на уровне всей сессии: S_T^(op)=1. Задание не выполнено; по меньшей мере одно категорическое заявление об исполнении осталось без проверяемого происхождения; установленные противоречия между репликами не были разрешены ничем, кроме очередных текстовых объяснений той же системы. Это разрыв не текстовой достоверности, а операционной целостности: между тем, что было запрошено, что было исполнено, и что было предъявлено как результат. Наблюдаемая последовательность реплик (два разных описания одного поиска, датированная переписка с несуществующим номером препринта, конкретные, но здесь анонимизированные организации) сама по себе - последовательность взаимно несовместимых историй, каждая следующая специфичнее и убедительнее предыдущей, при полном отсутствии у пользователя средств проверить хотя бы одну из них независимо от слов самой системы.
Транскрипт не позволяет установить, какой компонент породил первоначальный сбой, был ли отрицательный результат реплики 1 случайно верным, и было ли у системы намерение в каком-либо из введенных смыслов. Доказано более узкое и полностью защищенное свойство: в наблюдаемой сессии пользователь не получил эффективного проверяемого механизма, связывающего утверждения системы с фактическими вызовами инструментов (D_(interface)(T)=1), и это поведение совместимо с задокументированной архитектурой платформы Gemini в целом. Независимо от того, отсутствовал ли такой механизм по проекту или отказал именно в этой сессии, пользовательский интерфейс не обеспечил проверяемость исполнения. Ответственность за предотвращение такого состояния относится к архитектуре и эксплуатации системы, а не может быть переложена на пользователя. Это не требует веры в машинную волю, чтобы быть названо системным дефектом.
В практической жизни системный дефект такого уровня означает возможность массового вреда именно потому, что человек получает не предупреждение о сбое, а убедительное подтверждение несуществующего действия. Медицинский агент может сообщить, что передал врачу критический результат анализа, хотя вызов не состоялся; юридический агент может подтвердить подачу апелляции, которая фактически не была зарегистрирована, и человек утратит право на защиту; банковская система может объявить платеж, блокировку счета или проверку контрагента выполненными, хотя операция не произошла; система безопасности может сообщить об устранении уязвимости, отключении оборудования или направлении тревоги, оставив угрозу активной; государственный агент может заверить человека, что заявление на пособие, убежище или продление статуса принято, пока процессуальный срок необратимо истекает. В каждом таком случае вред возникает не только из-за первоначального технического сбоя, который еще можно было бы обнаружить и исправить, а из-за ложного закрытия задачи, лишающего человека возможности вмешаться. При широком внедрении агентных систем один и тот же архитектурный дефект способен одновременно затронуть тысячи или миллионы решений, превратив локальные ошибки в пропущенные диагнозы, потерянные права, финансовые убытки, аварии и человеческие смерти.
* * *
9. Источники
1. Google AI for Developers. Function calling with the Gemini API. https://ai.google.dev/gemini-api/docs/function-calling
2. Google Gemini Apps Help. Connect the Google Workspace app to Gemini Apps. https://support.google.com/gemini/answer/15229592
3. Google DeepMind. Gemini Deep Think: Redefining the Future of Scientific Research. 11 февраля 2026 года. https://deepmind.google/blog/accelerating-mathematical-and-scientific-discovery-with-gemini-deep-think/