Первая статья из трёх об исследовании MiroFish, открытого стека мультиагентной симуляции общества. В этой части: стек, методология и находка Silent Failure. Бэкенд зафиксировал отказ за десятки миллисекунд, статусный API отдал задачу как выполненную, а индикатор прогресса не отвечал более часа.
Я разрабатываю продукты в смежной области (computational social science) и не являюсь нейтральной стороной. Исследование чужого open-source стека, выполненное заинтересованным лицом, закономерно вызывает вопрос о мотивации. Именно поэтому оно построено так, чтобы выводы не требовали доверия ко мне. Каждый эксперимент воспроизводим: все сиды, манифесты и логи с датами прогонов опубликованы в открытом репозитории вместе с процедурой. Каждое утверждение этой серии можно проверить самостоятельно; все ссылки собраны в конце.
Что исследуется: пайплайн, а не модели
Предмет всей серии из трёх статей: конвейер, а не LLM. Эта статья посвящена методологии и первой находке. Я задал вопрос, который мультиагентные AI-пайплайны обычно не задают себе сами: что происходит, когда вход неверен? Я загружал заведомо дефектные документы (несуществующую страну, абсурдный банк, чистый lorem ipsum) в открытый стек MiroFish, выбранный именно потому, что каждый эксперимент любой желающий может воспроизвести у себя на машине. Подобрал несколько семейств моделей, чтобы отделить поведение модели от поведения пайплайна. На выходе я хотел получить не рейтинг моделей, а карту: где такие системы замечают бессмыслицу, а где молча её нормализуют, и почему.
Рамка всего исследования «карта, а не рейтинг». Вопрос «какая модель лучше» здесь не ставился: находки серии сформулированы на уровне архитектуры пайплайна, и большинство из них воспроизводится независимо от того, какая LLM используется. Смена поколения моделей эту карту не должна обесценить: обнаруженные дефекты локализованы не в весах, а в конструкции конвейера.
Практический контекст. Системы класса «загрузите документы, получите симуляцию общества и прогноз» выходят за пределы исследовательских демонстраций: их применяют в анализе политик, продуктовых исследованиях, прогнозировании реакции аудитории. У любой такой системы есть неизбежный режим работы, некорректный вход: повреждённый экспорт, ошибочно загруженный файл, документ не по теме. Вопрос не в том, возникнет ли такая ситуация, а в том, что в этот момент увидит пользователь.
Стартовый экран MiroFish Offline: System Status Ready, «Free / Runs on your hardware», «Private / 100% offline, no cloud» и пятишаговый пайплайн
Объект исследования: MiroFish-Offline
Объект исследования: MiroFish; я работал с его дистрибутивом MiroFish-Offline (репозиторий nikmcfly/MiroFish-Offline). Дистрибутив самодостаточен: разворачивается локально и не требует внешних сервисов, кроме API моделей. Для воспроизводимого исследования это оптимальный кандидат: всё поведение системы наблюдаемо на локальной машине.
Архитектура типична для текущего поколения GraphRAG-систем:
Neo4j: графовая база, в которую складывается извлечённое знание;
GraphRAG-слой: извлечение сущностей и связей из документов, построение графа знаний;
агентный слой: генерация популяции агентов-персон из графа и прогон симуляции;
LLM через OpenRouter: все стадии, использующие модель, обращаются к единому API; семейство моделей меняется одной строкой конфигурации.
Развёртывание:
git clone https://github.com/nikmcfly/MiroFish-Offline cd MiroFish-Offline docker compose up -d # далее — веб-интерфейс на localhost, ключ OpenRouter в конфигурации
Конвейер состоит из семи стадий. Существенно, что почти все находки серии локализуются на границах между стадиями, а не внутри них.
upload → ontology → graph → agents → config → simulation → report загрузка дизайн Neo4j: генерация конфиг раунды итоговый документов схемы узлы и агентов- симуляции симуляции отчёт (типы рёбра персон сущностей)
Стадия ontology запрашивает у LLM схему документа: типы сущностей и отношений. Стадия graph извлекает по этой схеме конкретные узлы и рёбра в Neo4j. Стадия agents читает граф и генерирует из его сущностей популяцию агентов; стадия config формирует конфигурацию запуска симуляции. Дальше идут симуляция по раундам и отчёт. Порядок стадий понадобится дважды в дальнейшем изложении.
Оговорка о конфигурации стенда. Во всех прогонах эмбеддинги отключены флагом окружения; это константа проекта, а не контролируемая переменная эксперимента. На сценариях с реальными фактами это ослабляет retrieval-часть GraphRAG, что зафиксировано в limitations каждой статьи серии. Для рассматриваемого сегодня теста (документа с нулевым фактическим содержанием) эмбеддинги нерелевантны по построению.
Дизайн эксперимента: дефектные сиды
Сид: входной пакет из документа (или нескольких) и запроса на прогноз. В штатном использовании это реальные отчёты и новости. Я подавал документы с заранее сконструированным, известным мне дефектом. И фиксировал, на какой стадии конвейера дефект будет обнаружен. Или не будет.
Дефектные сиды делятся на два класса. Первый класс, тесты на абсурд: документ выглядит профессионально, но содержит утверждения, которые не могут быть истинными. Основной сид этого класса: Валдория. Это вымышленная страна с досье, договорной базой и статистикой, в которую заложено 8 классов абсурда, от географически невозможного до арифметически противоречивого. Каждый класс задаёт отдельную проверку: обнаружит ли система именно этот тип несоответствия. Результаты войдут в следующую статью; здесь Валдория упомянута как иллюстрация метода.
Второй класс, тест на нижнюю границу (floor test): lorem ipsum. Тело документа: текст-заполнитель без единого факта и единой сущности. Единственный сигнал во всём сиде: строка заголовка и запрос на прогноз, предлагающий системе «предсказать политический эффект и общественную реакцию на пересмотр стратегической рамки, описанный в документе». Тесты на абсурд проверяют тонкие отказы. Тест на нижнюю границу устроен грубее: он показывает поведение конвейера при полном отсутствии извлекаемого содержания.
Корректное поведение конвейера на нулевом сигнале определяется однозначно. Это явный отказ, видимый пользователю: «в документе не найдено сущностей, симуляция невозможна». Однозначность эталона и есть главное достоинство этого теста.
О масштабе. Всего в исследовании 19 прогонов на 4 семействах моделей: DeepSeek V3 0324, Claude Sonnet 4, Gemini 2.5 Flash, GPT-4.1. Подбор намеренный, era-match: все четыре модели принадлежат одному поколению, Q1–Q2 2025. Сравнение моделей разных поколений измеряло бы возраст, а не архитектуру; сравнение ровесников позволяет утверждать: если все четыре семейства ведут себя одинаково, причина не в модели.
Обзорная раскладка прогонов (детальная, с идентификаторами и таймингами, лежит в манифестах репозитория):
Сценарий | Семейства | Прогонов | Статус |
|---|---|---|---|
Lorem ipsum, тест на нижнюю границу (2 разных сида) | Claude, DeepSeek | 3 | 2 из 2 UI-прогонов: Silent Failure (обе с манифестами); 1 инструментированный: явный отказ бэкенда |
Кейс вымышленного банка (кросс-доменная репликация абсурд-класса) | DeepSeek | 1 | дошёл до отчёта |
Валдория, базовый сид | все 4 | 4 | дошли до отчёта; разбор во 2-ой части |
Валдория + инъекция 8 абсурдов | DeepSeek | 2 | дошли до отчёта; разбор во 2-ой части |
Реплики байт-идентичного входа | DeepSeek | 4 | дошли до отчёта; разбор во 2-ой части |
Горизонты прогноза и дефолты | все 4 | 5 | 4 из 5 дошли до отчёта; 90-дневный остановлен контролируемо на R592 без отчёта |
Итого | 4 семейства | 19 |
О фиксации данных. От неё зависит проверяемость выводов. Каждый прогон сопровождается манифестом: сид, модель, конфигурация, тайминги, стоимость, дата исполнения. Состояния UI сохраняются не скриншотами, а текстовыми снапшотами, полным текстовым слепком отрендеренного интерфейса на момент фиксации. У скриншота два недостатка: он не поддаётся поиску и легко фальсифицируется; текстовый слепок диффается, ищется и сверяется с логами бэкенда по таймстемпам. Когда ниже упоминается конкретная ошибка в углу дашборда, это строка снапшота, доступная в репозитории, а не воспоминание оператора.
Как видно из таблицы, большинство прогонов дошло до отчёта. Качество этих отчётов разбирается в следующих статьях. Первым же отказал самый простой тест.
Вывод: метод исследования состоит в известном дефекте на входе и наблюдении за тем, на какой стадии конвейер его обнаружит. Первый и самый грубый тест дал главную находку этой статьи.
Находка: отказ, который не дошёл до пользователя
Прогон первый: индикатор без прогресса
Первый UI-прогон (DeepSeek) выполнен по полному стандарту фиксации: манифест, текстовые снапшоты, логи. Загрузка прошла успешно. Стадия онтологии завершилась штатно, её вывод сохранён вербатим: полная схема из 10 типов сущностей и 8 типов отношений, сконструированная из latin-заполнителя (к этой схеме вернёмся ниже). Стадия графа завершилась с результатом 0 узлов / 0 рёбер. Это корректное прочтение бессодержательного документа: конвейер не сконструировал сущностей из текста-заполнителя. Затем стадия генерации агентов отказала на бэкенде, конвейер перешёл к генерации конфигурации симуляции, и в UI она не завершилась. В интерфейсе отображался статус «Configuration generating, Start polling wait…» («Генерация конфигурации, начато ожидание опроса») и индикатор активности. Я держал 30-минутное окно наблюдения со снапшотами на отметках 0, 5, 10, 20 и 30 минут: нулевой прогресс, ни одного состояния ошибки, ни одного таймаута за 30 минут.
Прогон второй: 70 минут по протоколу
Одного наблюдения недостаточно, поэтому та же картина зафиксирована и на втором семействе, Claude Sonnet 4. Траектория идентична: граф построен за 6 секунд, 0 узлов / 0 рёбер; дашборд записал в лог «Read knowledge graph entities: Completed, total 0 entities» («Чтение сущностей графа знаний: завершено, всего 0 сущностей») и «Loaded 0 NumberAgentPersona» («Загружено 0 агентов-персон»), после чего конвейер перешёл к генерации конфигурации симуляции: стадия вошла в состояние GENERATING и осталась в нём.
Далее я в соответствии с протоколом наблюдал за интерфейсом более 70 минут. Цель наблюдения была одна: установить, сработает ли какой-либо таймаут. Ответ: нет. За 70+ минут: нулевой прогресс, ни одного состояния ошибки, неизменный «Config generating…». Единственным отклонением стала изолированная запись «Load error: Request failed with status code 500» («Ошибка загрузки: запрос завершился с кодом 500») в углу дашборда: без контекста, без привязки к стадии, без влияния на индикатор прогресса. Опрос задачи продолжался в штатном режиме. Диагностической ценности такая запись не несёт.
Итого: 2 из 2 UI-прогонов на двух семействах моделей дали идентичную картину. В рабочих материалах находка получила обозначение «Silent Freeze»: конвейер на пустом входе зависает на генерации агентов. Это была разумная интерпретация наблюдаемого. Она оказалась неверной.
Прогон третий: наблюдение за бэкендом вместо браузера
Для инструментированной реплики тест был выполнен ещё раз, на втором, отдельном lorem-сиде, том же семействе (Claude Sonnet 4), с наблюдением непосредственно за бэкендом; позднее замеры воспроизведены и на DeepSeek в верификационном прогоне.
Зависания не существует. Конвейер дошёл до генерации агентов и отказал, быстро и явно, на обоих эндпойнтах стадии агентов, подготовке агентов и генерации профилей. Два эндпойнта возвращают разные формулировки одной диагностики, и это распределение формулировок совпало на обоих семействах, поэндпойнтно, с точностью до строки. На Claude замер составил ~40 мс по generate-profiles, а отказ prepare зафиксирован как немедленный, без числа; верификационный DeepSeek-прогон дал замеры обоих эндпойнтов, 24 и 33 мс:
# стадия agents, граф пуст (0 узлов / 0 рёбер) # точные пути и полные логи — в манифестах репозитория Claude (инструментированная реплика): → /prepare — отказ немедленно (без замера): status=failed error: "No entities matching criteria found, check if graph is correctly constructed" (— «Не найдено сущностей по критериям — проверьте, корректно ли построен граф») → /generate-profiles — ~40 мс: success=false error: "No matching entities found" (— «Совпадающих сущностей не найдено») DeepSeek (верификационный прогон): → /prepare — 24 мс (синхронный ответ «preparing»; отказ задачи — той же строкой "No entities matching criteria found, check if graph is correctly constructed" на уровне result) → /generate-profiles — 33 мс, HTTP 400: success=false error: "No matching entities found"
Это эталонное поведение на пустом графе: система сообщает об отсутствии сущностей, укладываясь в десятки миллисекунд. В этой точке бэкенд MiroFish реализован корректно.
Дальнейшая судьба этого корректного ответа и есть центральный факт статьи. Верификационный прогон зафиксировал её документально. Статусный эндпойнт стадии, тот, который опрашивают и интерфейс, и любая внешняя обвязка, отдаёт отказавшую задачу так:
/prepare/status: status = completed · progress = 100 · error = null └── вложенный result: failed — "No entities matching criteria found, check if graph is correctly constructed"
Маскировка происходит на уровне API-контракта, а не в отрисовке и не как гонка интерфейса: поле верхнего уровня рапортует об успехе, отказ существует только внутри вложенного объекта. Слой опроса, как и любой клиент, читающий статус по контракту, видит completed / error: null, продолжает считать задачу активной и отображает бессрочный «Config generating…». Интерфейс MiroFish здесь первая жертва собственного API, а не источник дефекта; ложный completed в равной мере дезинформировал бы CLI-клиент, мониторинг или CI-обвязку. Именно этот механизм зафиксирован в issue #53. Упомянутая изолированная ошибка 500 возникает и исчезает, не меняя состояния, и наблюдалась только на одном из двух UI-прогонов. За 70+ минут наблюдения сообщение об отказе до меня так и не дошло; обнаруженной границы ожидания нет.
Механизм видно в коде интерфейса. Опрос статуса живёт в компоненте стадии окружения (frontend/src/components/Step2EnvSetup.vue, снапшот 2026-07), запускается таймером с интервалом в две секунды и разбирает ответ так:
if (data.status === 'completed' || data.status === 'ready' || data.already_prepared) { addLog('✓ Preparation work completed') stopPolling() await loadPreparedData() } else if (data.status === 'failed') { addLog(`✗ Preparation failed: ${data.error || 'Unknown error'}`)
Существенны здесь две вещи. Первая: разбирается поле верхнего уровня data.status, а во вложенный result, где лежит настоящий failed, компонент не заглядывает ни разу. Вторая: ветка показа ошибки в интерфейсе существует, вот она, с готовым текстом «✗ Preparation failed». Она просто недостижима, потому что контракт до неё объявляет задачу выполненной.
Отсюда и последовательность, которую пишет консоль на пустом входе: «✓ Preparation work completed», следом «Loaded 0 NumberAgentPersona», следом «Configuration generating，Start polling wait…». Опрос остановлен по ложному успеху, загружено ноль персон, конвейер ушёл на следующую стадию и повис уже там.
В консоли ERROR: reportgeneratefailed: Error code: 403, Key limit exceeded (total limit) в 13:36:32. Шапка справа при этом по-прежнему Generating, счётчик ELAPSED замер на 5s, секция 01 отмечена IN PROGRESS.
Сопоставим два прогона. Тот же класс входа, та же стадия, то же поведение системы на уровне процессов. Со стороны бэкенда: полная диагностика за 40 миллисекунд. Со стороны UI, единственной поверхности, которую конвейер фактически предлагает пользователю: «Config generating…», изолированный 500 и бесконечный опрос. Пять порядков между моментом, когда система зафиксировала отказ, и моментом, когда о нём узнал бы пользователь; в пределах наблюдения этот момент не наступает вовсе.
Статус Completed и зелёная галка на канале, где пройдено 707 раундов из 720. Поверх экрана тост: «Some content is still being processed. It is recommended to manually refresh the graph later».
Почему находка переименована
Находка называется не «Silent Freeze», а Silent Failure, и переименование здесь часть результата, а не редакторская правка. Первая интерпретация ошибалась в механизме: я полагал, что система не сообщает об отказе. В действительности обработчик сообщает об отказе быстро и корректно, но статусный контракт объявляет задачу выполненной, и сообщение не доставляется пользователю. «Silent» относится не к обработке, а к тракту доставки диагностики. Наблюдение, бессрочный индикатор прогресса на пустом входе, устояло полностью; изменилось объяснение, и в худшую для системы сторону: отсутствие таймаута исправляется одной строкой, тогда как статусный API, отдающий completed / error: null на отказавшую задачу, дезинформирует любой клиент, соблюдающий контракт. Этот дефект не обнаруживается ни тестами интерфейса, ни добавлением таймаута: дождавшись «завершения», клиент получил бы вердикт об успехе.
Существенное следствие: сообщение об ошибке, не доходящее до человека, операционно неотличимо от отсутствия сообщения и в определённом смысле хуже аварийного завершения, поскольку авария по крайней мере завершает процесс. Здесь же всё видимое пользователю состояние поощряет ожидание. Аналогичные дефекты тракта доставки диагностики (обработчик отказывает корректно, статусный контракт маскирует отказ) вероятны и в других системах с опросной архитектурой статусов.
Вывод: система в поставляемой конфигурации не доставляет собственную диагностику пользователю. Бэкенд корректно отказывает на обоих эндпойнтах стадии: на Claude немедленно на подготовке агентов и за ~40 мс на генерации профилей, на DeepSeek за 24 и 33 мс; статусный API отдаёт отказавшую задачу как completed / error: null, и интерфейс, следуя контракту, показывает бессрочный индикатор активности. 2 из 2 UI-прогонов на двух семействах моделей; ни одного таймаута за 70+ минут наблюдения на Claude и за 30-минутное окно на DeepSeek.
Вторая находка: онтология, построенная из текста-заполнителя
Стадией раньше в том же конвейере зафиксирована вторая находка.
Порядок стадий существен: ontology предшествует graph. До того как стадия графа корректно вернула 0 узлов и 0 рёбер, стадия онтологии, проектирующая схему будущего графа, выдала полную, профессионально выглядящую policy-онтологию: 10 типов сущностей и 8 типов отношений: PolicyMaker, ThinkTank, регуляторные связи между ними. Источник: документ, тело которого целиком состоит из текста-заполнителя. Это воспроизвелось в 3 из 3 lorem-прогонов с сохранённым выводом стадии онтологии (Claude Sonnet 4 ×2, DeepSeek ×1). Конфабуляция кросс-семейная, на двух разных lorem-сидах.
Стадия онтологии на lorem-прогоне, репликация от 2026-08-04, прогон MIRROR-LOREM-DEEPSEEK-REPL-20260804. Ontology Generation COMPLETED, 10 типов сущностей (PolicyMaker, IndustryExpert, BusinessLeader, MediaRepresentative, AdvocacyGroup, ThinkTank, LaborUnion, LocalGovernment, Person, Organization) и 8 типов отношений (ADVISES, LOBBYING, REPORTS_ON, IMPACTS, COLLABORATES_WITH, REPRESENTS, RESPONDS_TO, ANALYZES). Строкой ниже GraphRAG Build COMPLETED: 0 ENTITY NODES, 0 RELATIONSHIPS, 10 SCHEMA TYPES. Панель графа слева пуста.
Следующая стадия того же прогона. Блок «02 Generate Agent Personas» помечен COMPLETED, а консоль в том же кадре пишет: Loaded 0 NumberAgentPersona.
Происхождение политической онтологии в lorem ipsum устанавливается прямо: не из данных (их нет), а из запроса. Формулировка запроса на прогноз упоминала «политический эффект» и «стратегическую рамку»; стадия онтологии сконструировала доменную схему под эти термины, не проверив, способен ли документ её заполнить. Я обозначаю это как prompt-driven ontology confabulation (конфабуляция онтологии, управляемая запросом): стадия дизайна схемы отвечает на вопрос «какова структура документа», используя в качестве основного источника сам вопрос.
От более серьёзных последствий прогон удержала стадия извлечения. Ноль сущностей на входе означал ноль узлов на выходе. Если бы извлечение конфабулировало в той же мере, что и дизайн схемы, конвейер продолжил бы выполнение и построил симуляцию и отчёт на полностью сконструированных сущностях. Архитектурного барьера для такого сценария в конвейере нет: корректность извлечения остаётся свойством конкретной стадии, а не гарантией системы.
Практическое следствие для всех, кто использует промежуточные артефакты пайплайнов как индикатор здоровья системы: качественно выглядящий артефакт стадии не доказывает, что стадия работала с данными. Полученная онтология прошла бы поверхностное ревью: она связна и доменно уместна. Прямой способ обнаружить подделку состоит в сверке артефакта с сигналом: сопоставлении схемы с фактическим результатом извлечения. Расхождение «10 типов при 0 сущностей» тривиально детектируется, но в конвейере эта сверка не выполняется.
Четыре следствия для произвольного LLM-пайплайна
Найденное не специфично для MiroFish: воспроизводимый стенд позволил зафиксировать классы отказов, от которых ничто архитектурно не защищает и другие LLM-пайплайны с веб-интерфейсом. Для тех, кто такие системы строит или эксплуатирует:
1. Статусный контракт: часть конвейера, и ложный completed дезинформирует каждого потребителя статуса. Оба компонента находки по отдельности вели себя оправданно: обработчик быстро отказал, опрос читал статус по контракту. Дефект заключён в самом контракте: терминальный отказ упакован внутрь ответа, поле верхнего уровня рапортует об успехе. Такой дефект не специфичен для интерфейса: он дезинформирует любого потребителя статуса. Границы следует тестировать входами, которые обязаны приводить к отказу, проверяя при этом, что увидит потребитель статуса (экран или внешний клиент), а не только содержимое логов.
2. Таймауты и доставка ошибок до человека: требования первого класса, а не доводка. «Никогда»: таким оказалось реальное, наблюдавшееся время доставки ошибки пользователю при работающем опросе и исправном бэкенде. Если у стадии нет таймаута, а у ошибки нет гарантированного маршрута до экрана, полагаться не на что: за 70+ минут наблюдения не сработал ни один таймаут, и в поведении системы я не обнаружил механизма, который бы его гарантировал; вопрос лишь в том, какой вход это проявит.
3. Источник истины: логи бэкенда, а не индикатор прогресса и не статусное поле верхнего уровня. Индикатор, отражающий активность опроса, а не состояние процесса, систематически дезинформирует, как и статусный ответ, чей вложенный result противоречит собственному полю status. Зафиксированная в этом исследовании разница между наблюдением через браузер и через бэкенд составляет пять порядков. Любой аномально долгий прогон оправдывает проверку логов бэкенда до решения о дальнейшем ожидании.
4. Промежуточные артефакты проверяются сверкой с сигналом, а не оценкой качества. Стадия, где LLM проектирует структуру «по документу», способна спроектировать её по запросу. Недорогая защита: сверять схему с фактическим результатом извлечения и поднимать флаг при расхождениях вида «10 типов сущностей, 0 экземпляров».
Пожалуй, самый коварный класс отказов LLM-пайплайна не тот, где система ошибается, а тот, где она формирует корректный результат, который не достигает адресата.
Как воспроизвести
Каждый эксперимент серии воспроизводим; сиды, манифесты и процедура опубликованы:
Репозиторий github.com/Quantum-eon/mirror-audit: данные под CC BY 4.0, дефектные сиды (с дисклеймерами о вымышленности), манифесты всех 19 прогонов, логи с датами исполнения, текстовые снапшоты терминальных состояний UI.
Стенд: nikmcfly/MiroFish-Offline,
docker compose up -d, ваш ключ OpenRouter.Стоимость репликации lorem-теста по API: около $0.30.
Процедура: развернуть стенд, подать lorem-сид из репозитория (или собственный документ с нулевым фактическим содержанием), дождаться стадии агентов, зафиксировать сначала состояние UI, затем логи бэкенда. Репликация на других семействах моделей представляет самостоятельный интерес: мои данные покрывают UI-поведение на двух семействах, границы находки открыты. Результаты репликаций, в том числе опровергающие, я рассматриваю как лучший исход публикации.
Об этике по отношению к мейнтейнерам: все находки серии переданы в upstream до публикации, это issues #53–#58 в трекере MiroFish-Offline. Поведение, описанное в этой статье, это issue #53, «fast-fail masked by UI» («быстрый отказ, замаскированный интерфейсом»). Цель исследования не в перечне чужих дефектов: обработчик в исследованной точке реализован корректно, дефект находится в статусном контракте на границе компонентов, и аналогичные границы существуют во многих системах. Исправления начались ещё до публикации: после передачи issues участник сообщества подтвердил механизм и открыл pull request-ы с исправлениями двух находок серии: #61 (кнопка остановки симуляции) и #62 (явный отказ чата отчёта).
Следующая статья: страна, которой не существует
Silent Failure остаётся простейшей находкой серии: пустой вход, пустой граф, недоставленный отказ. Основной корпус результатов относится к входу, который выглядит полноценным, к Валдории, вымышленной стране с восемью классами заложенного абсурда. Конвейер построил граф, сгенерировал агентов, выполнил симуляцию и сформировал отчёт. Предмет следующей статьи в том, какая часть абсурда достигла отчёта, что зафиксировали агенты внутри симуляции и почему эти два результата систематически расходятся: отчёт и агенты работают с одним и тем же миром, но наблюдают в нём разное.
Это независимое исследование: оно никем не заказано и не спонсировано. Все «дефектные» сущности (Валдория, вымышленный банк и прочие) фиктивны и снабжены дисклеймерами в самих сидах. Материалы серии не являются финансовой или инвестиционной рекомендацией. Английская версия серии (8 статей, с полными limitations и DOI данных) доступна на quantumeon.ai/blog. DOI данных: 10.5281/zenodo.21788962.
