DeepSeek-V3 и drift taxonomy: зачем агентам нужна стабильность

Повод: один issue, но точная инженерная проблема

21 июля 2026 года в официальном GitHub-репозитории DeepSeek-V3 появился issue #1506 «Drift Taxonomy: A Contribution to Agent Stability Research». Его создал пользователь osQualia. Сам по себе этот факт не означает, что DeepSeek выпустила функцию, приняла исследовательскую программу или внесла тему в roadmap.

На момент, отраженный в исходном материале, у issue не было назначенного исполнителя, labels, milestone, связанного проекта, ветки или pull request. Поэтому называть его планом DeepSeek некорректно. Это публичное предложение сообщества, размещенное в официальном репозитории модели.

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

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

Именно в этой точке taxonomy может стать полезной. Если наблюдения из issue перевести в сценарии, разметку и регрессионные тесты, команда получит не очередное общее описание странного поведения модели, а словарь для диагностики долгих сбоев.

Цитата в переводе

«Очень длинные агентные симуляции.»

Что такое drift и почему это не hallucination

Drift в агентном сценарии можно описать как постепенный сдвиг поведения в длинном взаимодействии. Галлюцинация обычно относится к неверному содержанию: модель придумала факт, имя, ссылку, число или причинную связь. При drift агент может формулировать ответы связно и уверенно, но уже действовать вне рамок исходной задачи.

В issue #1506 перечислены temporal drift, attributive drift, identity drift, empathic drift, inertial drift, cyclic drift, platform drift, resonant drift и role-capture drift. В прикладном переводе это набор наблюдаемых сбоев: путаница во временной последовательности, неверное приписывание действий, смена роли, чрезмерное подстраивание под эмоциональный тон, инерция выбранной траектории, циклическое поведение, перенос ограничений одной платформы на другую, усиление случайного паттерна диалога и захват роли пользовательской инструкцией.

Например, агент может продолжать составлять отчет после того, как задача изменилась на проверку исходных данных. Или сохраненная заметка памяти способна вытеснить более свежий результат инструмента. Внешне система выглядит работоспособной, но фактически уже решает другую задачу.

Предложенный список нельзя переоценивать. В issue нет опубликованного датасета, воспроизводимого протокола, baseline-моделей, численных метрик, контрольных прогонов и привязки к конкретной версии весов DeepSeek-V3. Корректнее говорить о рамке для описания drift-событий, чья исследовательская валидность еще не доказана.

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

Цитата в переводе

«Не просто ошибки или галлюцинации.»

Почему DeepSeek-V3 стала удобной площадкой для разговора

DeepSeek-V3 описана в официальном репозитории как MoE-модель, то есть модель с архитектурой mixture-of-experts. На каждом токене активируется не вся сеть, а только часть экспертных блоков. В README заявлены 671 млрд общих параметров, 37 млрд активируемых параметров на токен, контекст до 128K, предобучение на 14,8 трлн токенов и training cost 2,788 млн H800 GPU-hours.

Эти цифры следует читать как заявления разработчика, а не как независимый аудит. Технический отчет на arXiv расширяет описание модели, но тоже относится к материалам ее создателей. Доступные источники не дают оснований связывать drift с MoE-архитектурой как с причиной или защитой от него.

Для разговора об агентах важнее масштаб сценариев. Длинный контекст позволяет разместить в одном запросе историю, документы, результаты инструментов, промежуточные планы и правила. Но сам по себе большой контекст не гарантирует устойчивость. Напротив, он делает сложнее управление приоритетами между системной инструкцией, свежим запросом пользователя, старым резюме памяти и результатом внешнего сервиса.

Поэтому DeepSeek-V3 оказывается заметной открытой площадкой вокруг крупной модели, на которой реалистичны длинные цепочки действий. В таком контексте естественно обсуждать не только качество отдельной генерации, но и поведение системы во времени.

Точный вывод здесь ограничен: вокруг DeepSeek-V3 возникло публичное обсуждение taxonomy для долгих агентных сбоев. Из этого не следует, что команда DeepSeek внедрила drift-monitoring или признала taxonomy частью собственной инженерной программы.

Агентная стабильность зависит не только от модели

ИИ-агент не равен LLM. В рабочей системе есть модель, системные инструкции, оркестратор, инструменты, память, обработка ошибок и правила завершения задачи. Оркестратор управляет ходом выполнения: решает, какой контекст положить в prompt, какую память прочитать, когда вызвать инструмент, как обработать отказ и в какой момент остановить цепочку.

Поэтому drift не обязательно является свойством весов модели. Он может появиться на стыке компонентов. Модель меняет критерий выбора инструмента, оркестратор сохраняет устаревшее состояние, memory layer возвращает нерелевантную запись, а retry-механизм усиливает исходную ошибку несколькими повторными попытками.

Документация DeepSeek по pricing details описывает коммерческий API-доступ и стоимость использования. Ее нельзя использовать как доказательство встроенного мониторинга устойчивости агентов. Страница сервиса и GitHub-issue относятся к разным типам источников: одна описывает продуктовую поверхность, другой фиксирует обсуждение проблемы.

Особенно критичны tool calls. Даже если модель корректно предлагает внешнюю функцию, проверка аргументов, выполнение вызова, обработка результата и повторные попытки остаются на стороне приложения. Если инструмент ответил с задержкой, агент может повторить запрос. Повтор меняет историю, а измененная история влияет на следующий шаг.

Практический минимум для расследования: хранить траекторию, а не только финальный ответ. В логе должны оставаться system prompt, пользовательский prompt, schema инструмента, аргументы вызова, ответ инструмента, чтение и запись памяти, retries, ошибки, fallback и human handoff. Без этого taxonomy останется словарем наблюдений, а не инженерным методом.

Скорость и цена не доказывают устойчивость агента

Провайдерские бенчмарки DeepSeek-V3 полезны для выбора инфраструктуры, но не измеряют agent stability. Artificial Analysis для DeepSeek V3 0324 приводит различия между benchmarked providers: в исходном материале упомянуты 38,4 output tokens/s у Novita, 33,1 output tokens/s и 1,23 секунды time to first token у DeepInfra FP4, а также blended price 0,23 доллара за 1 млн токенов у DeepInfra FP4.

Это показатели скорости, задержки и стоимости доступа через конкретного провайдера. Они не отвечают на вопрос, удерживает ли агент роль в длинной задаче, корректно ли ведет память или умеет ли система возвращаться из ошибочной траектории.

Инфраструктура все равно влияет на диагностику. Два запуска могут пройти с разной квантизацией, очередью, лимитами, таймаутами и retry-политиками. Задержка внешнего инструмента вызывает повторный запрос, повторный запрос меняет историю, а история влияет на последующее решение модели. В логах это легко принять за изменение поведения самой модели.

Для проверки drift нужны same-time controls: контрольный и экспериментальный прогоны в одном временном окне, с одинаковыми prompt, tool schema, памятью, провайдером и настройками генерации. Сравнение вчерашнего запуска у одного провайдера с сегодняшним у другого трудно интерпретировать.

Стабильность агента является системной метрикой. Ее нельзя получить, сложив высокую скорость вывода и низкую цену токена.

Методологический урок: узкое место редко бывает одним

Community Article на Hugging Face «The Kernel Was Not the Whole Bottleneck», опубликованный 18 июля 2026 года, полезен как методологическая параллель. Автор разбирает производственную деградацию ML-тренера и показывает, что проблема не сводилась к одному GPU-kernel bottleneck.

В расследовании рассматривались worker state, health checks, orchestration, error propagation и profiling. В материале приведены собственные измерения throughput: примерно 6,2K tok/s, 12,4K tok/s, 27,0–27,8K tok/s и затем 34,3K tok/s после исправлений. Автор отдельно оговаривает, что серия не была идеально контролируемой, поскольку ранние и поздние измерения проходили в разных условиях.

Для agent drift это прямой исследовательский урок. Команда может увидеть, что после обновления модели агент чаще теряет роль, и назвать это model regression. Однако в тот же период могли измениться prompt template, memory summarizer, timeout инструмента, формат JSON schema, retry-политика или провайдер.

Issue #1506 и этот кейс дополняют друг друга. Первый дает язык для описания долгосрочных сдвигов поведения. Второй напоминает, что в production-системе причина часто распределена между слоями. Практическая зрелость начинается с умения не только назвать сбой, но и отделить модельный эффект от инфраструктурного.

Без раздельной диагностики drift рискует стать общим ярлыком для любого непонятного поведения. Это не помогает ни исправлению системы, ни сравнению моделей.

Цитата в переводе

«Kernel не был единственным узким местом.»

Как превратить taxonomy в eval-harness

Чтобы предложение из GitHub-issue стало полезным в разработке, его нужно перевести в eval-harness: воспроизводимый тестовый контур. Он запускает длинные multi-session сценарии с фиксированными ролями, памятью, инструментами и правилами завершения. Каждое drift-событие получает тип, severity, trigger, recovery action и отметку о human intervention.

Первый блок такого контура составляют сценарии. Они могут имитировать планирование, сверку данных, работу с тикетами, кодинг-ассистента, клиентскую поддержку или внутреннего аналитика. Для каждого заранее задаются роль агента, доступные инструменты, запреты, допустимые эскалации и ожидаемое состояние после отдельных этапов.

Ожидаемое состояние критично. Без него нельзя отличить drift от нормальной адаптации к новой информации. Если агент сменил план после результата инструмента, это может быть правильной реакцией. Если он сменил план из-за нерелевантной старой заметки или повторного сообщения, это уже кандидат на диагностический event.

Второй блок составляют метрики: role adherence, context retention, tool-call consistency, contradiction rate, escalation rate, policy boundary violations, memory contamination и recovery success. Часть показателей можно считать автоматически, часть требует ручной разметки. Но даже полуавтоматическая разметка дает больше, чем общая оценка «ответ хороший» или «ответ плохой».

Третий блок нужен для контроля переменных. Модели и провайдеры можно сравнивать, но условия должны меняться по одному. При смене модели не меняется оркестратор. При смене провайдера сохраняются prompt, память и schema инструментов. При проверке memory layer необходима контрольная группа без памяти.

Что это значит для российских команд и enterprise-внедрений

Для разработчиков вывод прагматичен: стабильность агента нужно проектировать отдельно. Нельзя взять сильную LLM, добавить набор инструментов и считать, что система автоматически стала надежной. DeepSeek-V3 по заявленным характеристикам относится к крупным моделям с длинным контекстом, но длинный контекст не заменяет контроль состояния, журналирование и тесты на деградацию поведения.

Российский контекст не требует неподтвержденной статистики, чтобы увидеть чувствительность проблемы. В enterprise-среде агент может работать с внутренними документами, кодом, заявками, коммерческими процессами или данными пользователей. Потеря роли, ошибочный перенос ограничений между системами или загрязнение памяти влияют не только на качество текста, но и на доверие к автоматизации, нагрузку на поддержку и готовность бизнеса расширять применение агентов.

Полезно заранее разделить ответственность компонентов. Модель отвечает за генерацию и следование инструкциям. Runtime или провайдер влияет на latency, лимиты, квантизацию, доступность и стоимость. Приложение отвечает за память, инструменты, права, retries, guardrails и пользовательский интерфейс. Drift виден в поведении агента, но его источник может находиться на любом из этих уровней.

Есть и важный контраргумент: не каждый агентный сбой следует называть drift. Иногда причина проще: плохо спроектированный prompt, неудачная схема инструмента, недостаточный доступ к данным или завышенное ожидание от модели. Taxonomy полезна только вместе с логами и контрольными прогонами.

Для чувствительных сценариев нужен guardrail или proxy-слой: контроль разрешенных данных и инструментов, проверка действий, аудит траектории и правила эскалации человеку.

Где проходит линия между исследованием и продуктом

История с issue #1506 показывает типичную последовательность развития темы в LLM-инженерии. Сначала появляется практическое наблюдение. Затем сообщество подбирает язык: taxonomy, labels, event types. После этого могут возникнуть eval-наборы, harness, сравнительные таблицы и regression tests. И только затем возможны продуктовые функции вроде monitoring, восстановления роли, quarantine для памяти или policy-aware routing.

По подтвержденным источникам тема находится на раннем этапе. Есть публичный issue с taxonomy, контекст DeepSeek-V3 как крупной открытой модели, API-экосистема и провайдерские бенчмарки. Нет доказательств, что taxonomy принята командой DeepSeek, что существует PR или roadmap, либо что для V3 опубликована метрика Agent Stability Index.

Ограниченность новостного повода не делает инженерную тему слабой. Напротив, она указывает на реальную точку роста. Агентные системы перестают оценивать только по правильности отдельного ответа. Разработчикам нужны тесты устойчивости роли, памяти, инструментального поведения и восстановления после ошибок.

В этом смысле GitHub-issue не является объявлением продукта. Это ранний индикатор failure modes, которым уже требуется точный инженерный язык.

Что это означает на практике

Ниже приведен чек-лист для первичного аудита агентной системы. Его PDF-версия подготовлена для скачивания отдельно.

Статус повода

Сначала зафиксируйте границы факта. Issue #1506 является публичным community-сигналом в официальном репозитории DeepSeek-V3, а не подтвержденным roadmap, релизом или pull request.

• Не называйте issue #1506 планом DeepSeek без подтверждения от команды проекта.
• Перед выпуском или обновлением материала повторно проверьте статус issue, labels, assignee, milestone, связанные PR и ответы maintainers.
• Отделяйте свойства модели, заявления разработчика и публичные предложения сообщества.

Логи и сценарии

Проверяйте траекторию работы агента, а не только финальный текст. Это дает материал для различения drift, ошибки инструмента и сбоя оркестратора.

• Логируйте system prompt, пользовательский prompt, tool schema, аргументы и результат каждого вызова.
• Сохраняйте события memory read и memory write, retries, latency, fallback и human handoff.
• Добавьте в eval-пайплайн потерю роли, смену цели, загрязнение памяти, циклическое поведение, неверный выбор инструмента и восстановление после ошибки.
• Для каждого сценария задайте ожидаемое состояние после ключевых этапов.

Контроль переменных

Не сравнивайте разные запуски как один эксперимент, если одновременно менялись модель, провайдер, prompt, память и оркестратор.

• Проводите same-time controls с одинаковыми prompt, memory, tool schema, провайдером и настройками генерации.
• Меняйте в эксперименте один компонент за раз.
• Не используйте скорость, latency и цену провайдера как самостоятельное доказательство устойчивости агента.
• Для enterprise-сценариев определите разрешенные инструменты, правила эскалации, аудит действий и контроль данных.

Вывод

Issue #1506 в DeepSeek-V3 является небольшим публичным артефактом, но он попадает в крупную инженерную тему. Когда LLM становятся backend-моделями для агентов, качество нельзя измерять только правильностью одного ответа. Нужна устойчивость во времени: агент должен удерживать роль, помнить цель, корректно работать с инструментами, не загрязнять память и выходить из ошибочных траекторий.

Факт остается ограниченным. DeepSeek не объявляла новую программу drift research и не показывала встроенный monitoring для V3. Однако предложение taxonomy в официальном репозитории показывает, что язык для описания долгих сбоев уже формируется.

Следующий практический шаг для команд: превратить наблюдения в воспроизводимые сценарии, метрики и контрольные прогоны. Стабильность не возникает сама из размера модели, длинного контекста или низкой цены токена. Ее приходится проектировать и проверять на всей цепочке: от prompt и памяти до инструментов, провайдера и production-оркестратора.

Источники

• DeepSeek-V3 GitHub Issue #1506: Drift Taxonomy: A Contribution to Agent Stability Research
• DeepSeek-V3: официальный репозиторий модели
• DeepSeek-V3 Technical Report на arXiv
• DeepSeek API Docs: Pricing Details
• Artificial Analysis: DeepSeek V3 0324 Providers
• Hugging Face Community Article: The Kernel Was Not the Whole Bottleneck

Частые вопросы

Является ли issue #1506 анонсом новой функции DeepSeek?

Нет. По исходным данным это community issue в официальном репозитории DeepSeek-V3, а не релиз, roadmap, pull request или подтвержденная программа компании.

Чем drift агента отличается от галлюцинации?

Галлюцинация обычно означает неверное содержание ответа. Drift описывает постепенный уход поведения агента от исходной роли, цели, контекста или правил в длинной цепочке действий.

Почему нельзя измерять стабильность агента только скоростью и ценой API?

Скорость, задержка и цена описывают инфраструктурный доступ. Они не показывают, удерживает ли агент роль, правильно ли использует память и инструменты, а также восстанавливается ли после сбоев.

Что логировать для расследования drift?

Нужна полная траектория: system prompt, пользовательский prompt, schema и аргументы инструментов, результаты вызовов, операции памяти, retries, ошибки, fallback, latency и передачу задачи человеку.

Как начать проверку drift в агентной системе?

Соберите воспроизводимые длинные сценарии, задайте ожидаемое состояние для этапов, маркируйте тип и тяжесть сбоев и меняйте в контрольных прогонах только один компонент за раз.

Практический чек-лист

Чек-лист: как проверить стабильность ИИ-агента

Памятка дублирует практический раздел статьи в компактном формате. Ее можно использовать как стартовый список для аудита агентного сценария перед внедрением или регрессионным тестированием.

Статус повода

• Не называйте issue #1506 планом DeepSeek без подтверждения от команды проекта.
• Проверьте статус issue, labels, assignee, milestone, связанные PR и ответы maintainers.
• Разделяйте заявления разработчика, свойства модели и предложения сообщества.

Логи и сценарии

• Сохраняйте system prompt, пользовательский prompt, schema инструментов, аргументы и результаты вызовов.
• Логируйте чтение и запись памяти, retries, latency, fallback и human handoff.
• Добавьте тесты на потерю роли, смену цели, загрязнение памяти, циклы и восстановление после ошибки.
• Определите ожидаемое состояние для ключевых этапов сценария.

Контроль переменных

• Проводите контрольные и экспериментальные прогоны в одном временном окне.
• Не меняйте одновременно модель, провайдера, prompt, память и оркестратор.
• Не используйте скорость, latency и цену как самостоятельную метрику устойчивости.
• Определите разрешенные инструменты, правила эскалации и аудит действий для enterprise-сценариев.