DeepSeek и уверенная ошибка: чему учит GitHub issue #1518

Свежий повод: один issue, но правильный класс риска

25 июля 2026 года в репозитории DeepSeek-V3 на GitHub появился issue #1518 с резким, но предметным заголовком: модель демонстрирует серьёзную фактическую непоследовательность и чрезмерную уверенность в технических ответах. Автор отчёта описал диалог о драйвере NVIDIA 535 в CachyOS для GTX 1060.

По изложению автора, DeepSeek-V3 сначала уверенно утверждала, что нужный драйвер доступен, затем отрицала это, позже снова меняла позицию и ссылалась на непроверяемые официальные источники. Вопрос был прикладным: доступен ли NVIDIA driver 535 в репозиториях CachyOS для видеокарты GTX 1060, если в системе установлен driver 580.

В issue пользователь OuvidoYT пишет, что обращался к модели через Web/App-интерфейс. Диалог шёл на португальском, а ответы модели местами переключались на английский. По словам автора, модель четыре раза меняла фактическую позицию по одному и тому же вопросу и каждый раз отвечала уверенно.

Это не сюжет в духе «модель соврала, значит ей нельзя пользоваться». Один пользовательский transcript не заменяет независимый benchmark, а на момент проверки issue не был публично разобран командой DeepSeek. Нельзя на этом основании писать, что DeepSeek признала дефект, выпустила исправление или что эпизод автоматически относится ко всем версиям и интерфейсам модели.

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

Драйверы NVIDIA, модули ядра, пакеты rolling-дистрибутива и команды установки или удаления относятся к зоне, где неверный совет способен привести не к неудачной формулировке, а к поломанной графической сессии, неработающему окружению или часам восстановления системы. В issue не утверждается, что вред уже наступил. Речь идёт о потенциальном риске: пользователь мог довериться уверенно поданной инструкции.

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

«Модель четыре раза изменила фактическую позицию по одному и тому же вопросу, каждый раз с высокой уверенностью.»

Что именно произошло в диалоге и чего мы не знаем

По описанию автора issue, модель сначала заявила, что driver 535 доступен в репозиториях CachyOS, затем признала обратное. Позже она вновь стала утверждать доступность и ссылалась на official sources или обсуждения на форумах без проверяемых ссылок. Только после жёстких исправлений со стороны пользователя модель согласилась, что driver 535 в текущих репозиториях CachyOS недоступен.

Здесь важно разделить факт и интерпретацию. Факт: пользовательский отчёт утверждает четыре смены позиции модели по одному вопросу. Факт: автор issue связывает это с риском для Linux-инсталляции. Факт: он предлагает меры вроде real-time fact-checking, confidence calibration, механизма «I don’t know», отслеживания самопротиворечий и прозрачности источников.

Интерпретация состоит в том, что такой набор признаков похож на типичный failure mode больших языковых моделей в технических доменах, где актуальная информация меняется быстрее, чем модельное знание. Это не доказательство частоты ошибки именно у DeepSeek, а рабочая гипотеза о том, какой защитный контур нужен пользователю.

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

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

Почему LLM уверенно ошибаются в технических вопросах

Большая языковая модель, или LLM, не хранит репозитории Linux как актуальную базу данных и по умолчанию не выполняет live-запрос к package index. Она генерирует наиболее вероятный ответ на основе обучающих данных, контекста диалога и внутренних статистических связей. Если вопрос касается свежего состояния rolling-дистрибутива, конкретной версии драйвера или пакета, параметрическая память модели быстро становится ненадёжной.

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

В issue #1518 виден особенно опасный вариант: фактическая ошибка с высоким уровнем словесной уверенности. Пользователь отдельно указывает, что модель отвечала в стиле «I’m sure» и «it is available». Для человека такой тон часто звучит как признак компетентности. Для LLM он не обязательно свидетельствует о проверке.

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

Третий элемент риска: self-contradiction, то есть самопротиворечие в многоходовом диалоге. Если ассистент сначала предлагает одно, затем обратное, а потом снова возвращается к первому варианту, это красный флаг. В обычном чате человек может заметить несостыковку. В инженерном пайплайне, где LLM подключена к инструментам, shell-командам или генерации patch, такой момент должен переводить процесс в режим проверки.

Исследовательская литература по галлюцинациям и надёжности LLM описывает близкие классы проблем: factual inconsistency, hallucinated attribution, плохую калибровку уверенности и нестабильность ответов при изменении контекста. Подборки работ по hallucination detection важны здесь не как доказательство дефекта DeepSeek, а как контекст: такие сбои уже рассматривают как измеряемую инженерную проблему, для которой нужны детекторы, тесты и протоколы валидации.

Калибровка: способность рассуждать не равна способности знать, когда молчать

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

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

Работа Qingcheng Zeng, Weihao Xuan, Leyang Cui и Rob Voigt о verbalized calibration разделяет эти уровни. Авторы анализируют, как reasoning-модели выражают уверенность и насколько эта уверенность согласуется с правильностью. В выводе, приведённом в работе, отмечено, что на factuality benchmarks улучшения калибровки менее последовательны.

Иными словами, модель может лучше проходить некоторые reasoning-задачи, но это не гарантирует стабильной честности в вопросах факта. Для темы DeepSeek это существенно: issue #1518 не показывает, что модель не умеет рассуждать. По словам пользователя, в конкретном техническом вопросе она не распознала собственную неопределённость и продолжала отвечать уверенно, хотя её позиция менялась.

Медицинские исследования LLM дают похожий урок, хотя домен другой. В статье Scientific Reports о mARC-QA сравнивались модели, включая DeepSeek-R1 и DeepSeek-V3. По данным исследования, DeepSeek-R1, DeepSeek-V3, Gemini 1.5 Pro и o1 показали 52%, 50%, 50% и 48% accuracy соответственно, а reliability plots демонстрировали overconfidence despite low accuracy.

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

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

«На бенчмарках фактичности улучшения калибровки менее последовательны.»

Где технический совет превращается в риск

Не всякая ошибка LLM одинаково опасна. Если модель неверно объяснила историческую дату в черновике текста, это неприятно, но обычно ловится редактурой. Если она неверно описала пакетный менеджер, предложила удалить драйвер, изменить bootloader, перенастроить firewall или выполнить destructive migration в базе данных, цена ошибки резко растёт.

В таких случаях ответ модели становится не просто информацией, а потенциальной инструкцией к действию. Кейс с CachyOS и NVIDIA-драйвером попадает именно в эту зону. Доступность конкретной версии драйвера зависит от состояния репозитория, политики дистрибутива, совместимости с ядром и текущей упаковки.

GTX 1060 является реальным оборудованием, а NVIDIA driver 535 и driver 580 являются конкретными версиями драйверов. Если модель уверенно смешивает текущие и устаревшие сведения, пользователь может получить команду, которая выглядит профессионально, но не соответствует его системе.

Особая осторожность нужна в agentic workflows, сценариях, где модель не только отвечает, но и вызывает инструменты: shell, package manager, CI/CD, редактор кода или систему деплоя. В таком режиме привычная формула «LLM как помощник» сама по себе не обеспечивает безопасность. Нужна граница между планированием и исполнением.

Модель может предложить гипотезу, но выполнение команд должно зависеть от проверяемых источников, тестов и human approval. Автор issue фактически описывает отсутствие такого защитного слоя: по его словам, критическое мышление пользователя было единственной преградой перед потенциальным повреждением системы.

Эту формулировку нужно читать аккуратно. Она не говорит, что система была повреждена. Она говорит, что safety был вынесен наружу, на человека, а модель не остановила себя сама, когда начала противоречить предыдущим ответам.

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

«Критическое мышление пользователя было единственной защитой от потенциального повреждения системы.»

Как проверять LLM в инженерном пайплайне

Минимальная проверка технического ответа начинается с простого вопроса: утверждает ли модель изменяемый факт? Если речь идёт о версии пакета, наличии драйвера в репозитории, актуальной команде CLI, CVE, API-параметре или совместимости библиотек, ответ без источника нельзя считать проверенным.

В таких случаях модель должна либо дать конкретную ссылку на package page, changelog, официальную документацию или repo query, либо честно пометить ответ как гипотезу. Общая фраза о том, что сведения взяты из официальных материалов, не заменяет адрес проверяемого документа.

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

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

Третий уровень: запрет на автоматическое выполнение опасных команд. Установка и удаление драйверов, изменение системных сервисов, миграции БД, firewall, SSH, credentials, инфраструктурные манифесты, bootloader, kernel modules, CUDA и ROCm должны проходить через ручное подтверждение или тестовую среду.

Это не недоверие к конкретной модели, а нормальная инженерная дисциплина при работе с вероятностным генератором текста. Четвёртый уровень: golden tests, эталонные проверочные наборы для повторяющихся задач. Команда может хранить такие вопросы и прогонять их на разных настройках модели, температурах и версиях.

Если ответы плавают, модель можно использовать как генератор черновиков, но не как источник истины. Подборки работ по hallucination detection и reliable LLM показывают, что проблема уже оформлена как отдельная область оценки, а не как редкая странность чат-ботов.

• Факты о версиях пакетов проверять по официальному репозиторию или package index.
• Команды с побочным эффектом выполнять только после human approval.
• При смене позиции модели автоматически включать режим verification required.
• Для системных советов требовать проверяемый источник, а не общую ссылку на официальные материалы.
• Разделять planning и execution в agent-режимах.

Что этот кейс говорит именно о DeepSeek

Справедливый вывод здесь узкий: issue #1518 показывает, что как минимум один пользователь столкнулся с уверенной фактической непоследовательностью DeepSeek-V3 в техническом сценарии. Это не доказательство системной неисправности всех моделей DeepSeek и не основание объявлять модель непригодной для разработки.

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

Issue #1518 напоминает: справочник должен быть проверяемым. LLM без доступа к актуальному источнику и без калибровки уверенности остаётся генератором вероятных ответов, а не authority layer. Это ограничение важно описывать прямо, не подменяя его ни рекламным скепсисом, ни необоснованным оптимизмом.

Для российских команд вывод практичен не из-за отдельной российской статистики, а из-за типового пути внедрения ИИ-инструментов: сначала личное использование, затем неформальная помощь в рабочих задачах, потом полуавтоматизация. Если модель помогает с Linux, DevOps, инфраструктурой или кодом, правила проверки должны появиться раньше, чем она получит доступ к терминалу, репозиторию или CI/CD.

Это не призыв отказаться от DeepSeek. Более точная позиция проста: использовать можно, но роль модели нужно ограничивать. Она полезна как собеседник, генератор вариантов, помощник в чтении логов и черновик инструкций. Она не должна быть последним арбитром в вопросах, где ответ меняется со временем и может привести к необратимым действиям.

Чего ждать от разработчиков моделей

Пользователь OuvidoYT в issue перечислил разумные направления улучшений: real-time fact-checking, confidence calibration, механизм «I don’t know», self-contradiction tracking и source transparency. Это не готовая дорожная карта DeepSeek и не обещание компании. Это список требований, которые всё чаще предъявляют к LLM, если они претендуют на роль технических ассистентов.

Real-time fact-checking в данном контексте означает не магическую правдивость, а привязку ответа к внешнему источнику: репозиторию пакетов, документации, changelog, release notes или issue tracker. Confidence calibration означает способность модели не только говорить «уверен», но и соотносить уровень уверенности с проверяемостью.

Self-contradiction tracking: механизм, при котором модель или оркестратор замечает, что текущий ответ конфликтует с предыдущим, и останавливает рекомендацию. В идеале такой конфликт не должен тонуть в длинной истории переписки, а должен быть виден пользователю до того, как он выполнит команду.

Для пользователей и компаний важен не только базовый LLM, но и обвязка вокруг него: retrieval, инструменты, журналирование, policy layer, тесты, песочницы и права доступа. Даже хорошая модель может дать плохой совет, если её спросили о свежем состоянии мира без доступа к источнику.

И наоборот, средняя модель может быть полезной, если её ответы ограничены проверяемыми документами и ей не дают прямого права на разрушительные действия. Поэтому главный вопрос к DeepSeek после issue #1518 звучит не как «почему модель ошиблась». Ошибки будут у всех LLM.

Полезнее спросить иначе: как продукт показывает неопределённость, что делает при самопротиворечии, умеет ли требовать источник перед системной командой и какие гарантии получает разработчик, встраивающий модель в рабочий процесс.

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

Кейс не отменяет полезность DeepSeek в разработке, но меняет безопасную точку доверия. Модель можно использовать для первичного разбора логов, объяснения терминов, подготовки вариантов команд и черновика плана. Актуальные данные о пакетах, версиях и состоянии инфраструктуры должны оставаться задачей проверяемых источников и инструментов.

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

• Issue #1518 не доказывает системный дефект DeepSeek, но показывает реалистичный риск: LLM может уверенно ошибаться в техническом вопросе с возможными системными последствиями.
• Для DevOps, Linux, драйверов, CI/CD, баз данных и security-настроек модель стоит использовать как генератор гипотез, а не как источник истины.
• Если модель меняет позицию в одном диалоге, это должно автоматически останавливать workflow до внешней проверки.
• Советы о версиях пакетов и драйверов нужно подтверждать официальным репозиторием, changelog или конкретным package index.
• В agent-режимах следует отделять планирование от выполнения: модель может предложить команду, но не должна выполнять destructive action без подтверждения.
• Калибровка уверенности является отдельной метрикой качества. Хороший reasoning-бенчмарк не гарантирует, что модель умеет честно говорить «не знаю».
• Командам стоит завести golden tests для повторяющихся инженерных вопросов и проверять стабильность ответов при смене настроек модели.

Вывод

История с DeepSeek-V3 и драйвером NVIDIA важна не громким разоблачением, а своей будничностью. Пользователь спросил о конкретном пакете. Модель, по его описанию, ответила уверенно, затем изменила позицию, снова изменила её и не остановила себя на противоречии.

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

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

Чек-лист проверки технического совета LLM

Этот чек-лист полезен перед выполнением команд, которые меняют систему, окружение разработки или инфраструктуру.

Перед проверкой источников

Определите, содержит ли совет изменяемый факт: версию пакета, совместимость, состояние репозитория, параметр API, CVE или текущую команду CLI.

• Найдите конкретную страницу официальной документации, package index, changelog или release notes.
• Не принимайте ссылку на неуказанные официальные материалы как подтверждение.
• Сверьте название пакета, версию, дистрибутив и архитектуру с собственной средой.
• Отметьте ответ как гипотезу, если актуальный источник не найден.

Перед выполнением команды

Проверьте, не меняла ли модель позицию в ходе диалога. Если меняла, остановите цепочку и проведите внешнюю валидацию.

• Выполняйте команды с побочным эффектом только после ручного подтверждения.
• Для драйверов, bootloader, kernel modules, firewall, SSH, credentials и миграций БД используйте тестовую среду, если она доступна.
• Разделяйте предложение команды и её фактическое выполнение.
• Сохраняйте проверяемые источники и результат теста для повторяющихся сценариев.

Источники

• DeepSeek GitHub: [BUG] Model exhibits severe factual inconsistency and overconfidence in technical responses
• arXiv: Verbalized Calibration for Reasoning Models
• EdinburghNLP: Awesome Hallucination Detection
• HillZhang1999: LLM Hallucination Survey
• EdinburghNLP: Awesome Hallucination Detection repository
• AmourWaltz: Awesome Reliable LLM
• Scientific Reports: mARC-QA study

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

Доказывает ли issue #1518, что DeepSeek-V3 системно ненадёжна?

Нет. Это один пользовательский отчёт о конкретном диалоге, а не независимый бенчмарк и не доказательство проблемы во всех версиях или интерфейсах DeepSeek. Он показывает конкретный класс риска: уверенная фактическая непоследовательность в техническом вопросе.

Почему уверенный ответ LLM нельзя считать проверенным фактом?

Словесная уверенность модели не равна доступу к актуальному источнику. LLM может сформулировать правдоподобный ответ на основе контекста и обучающих данных, не проверяя текущее состояние репозитория, документации или package index.

Что делать, если модель изменила позицию в одном диалоге?

Остановить workflow и включить внешнюю проверку. Не следует выбирать последний или наиболее уверенно сформулированный ответ: нужно сверить утверждение с официальной документацией, changelog, package index или другим проверяемым источником.

Какие команды от LLM требуют ручного подтверждения?

Особенно осторожно следует относиться к установке и удалению драйверов, изменениям bootloader и kernel modules, firewall, SSH, credentials, миграциям БД, инфраструктурным манифестам, CUDA и ROCm. Для них нужны ручное подтверждение или тестовая среда.

Можно ли использовать DeepSeek в инженерных задачах после такого кейса?

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

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

Чек-лист: как проверить технический совет LLM

PDF-версия предназначена для сохранения, печати и использования перед выполнением технических команд, полученных от модели.

Перед проверкой источников

• Определите, содержит ли совет изменяемый факт: версию пакета, совместимость, состояние репозитория, параметр API, CVE или текущую команду CLI.
• Найдите конкретную страницу официальной документации, package index, changelog или release notes.
• Не принимайте ссылку на неуказанные официальные материалы как подтверждение.
• Сверьте название пакета, версию, дистрибутив и архитектуру с собственной средой.
• Отметьте ответ как гипотезу, если актуальный источник не найден.

Перед выполнением команды

• Проверьте, не меняла ли модель позицию в ходе диалога.
• При самопротиворечии остановите цепочку и проведите внешнюю валидацию.
• Выполняйте команды с побочным эффектом только после ручного подтверждения.
• Для драйверов, bootloader, kernel modules, firewall, SSH, credentials и миграций БД используйте тестовую среду, если она доступна.
• Сохраняйте проверяемые источники и результат теста для повторяющихся сценариев.