DeepSeek-V4: миллион токенов, гибридное внимание и агентный поиск

Длинный контекст долго был маркетинговой метрикой. Модели заявляли 128K, 256K, потом и 1M токенов - но на практике окно за 64K либо обходилось в состояние, либо давало «потерю середины» (lost-in-the-middle), когда модель игнорирует информацию из центра контекста.

DeepSeek-V4 - первый релиз, где миллион токенов выглядит не как галочка, а как инженерно осмысленная возможность. Ключевое достижение не в том, что окно большое, а в том, что оно эффективное: в режиме 1M контекста V4-Pro требует только 27% вычислений single-token inference и 10% KV-cache по сравнению с DeepSeek-V3.2. Это не «бесплатно», но это практично.

Для бизнеса это важный сигнал. Если система не умеет отбирать релевантные фрагменты, хранить рабочее состояние и вызывать инструменты в нужный момент, гигантский контекст превращается в дорогой способ носить лишние токены. DeepSeek-V4 интересен именно тем, что показывает: длинный контекст, retrieval и tool-use начинают складываться в одну инженерную систему.

Технический отчёт: DeepSeek-V4.pdf на Hugging Face. Релиз: api-docs.deepseek.com.

Гибридное внимание - не один трюк, а два

CSA и HCA - это не косметические оптимизации, а основа того, почему 1M токенов становится практичным. CSA сжимает KV-историю и выбирает релевантные блоки. HCA работает с ещё более коротким представлением для дальних дистанций. Свежие токены остаются под отдельным sliding window - модель не теряет ближайший контекст.

Результат: 27% single-token inference FLOPs и 10% KV-cache по сравнению с V3.2. Это не «длиннее, но медленнее» - это «длиннее, но всё ещё практично».

mHC и Muon - почему сеть не разваливается

На trillion-scale обычные residual-связи перестают справляться. mHC делает прохождение сигнала через глубокую сеть стабильнее. Без этого обучение 1.6T-параметрической модели просто не сошлось бы.

Muon - отдельный оптимизатор, который DeepSeek использует вместо AdamW для значительной части параметров. Ускоряет сходимость и удерживает обучение в устойчивом режиме.

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

Agentic search: модель сама решает, что искать

В non-think режиме используется Retrieval-Augmented Search - классический retrieval в контекст. В thinking-режиме - agentic search: модель итеративно вызывает search и fetch инструменты, оценивает качество найденного и добирает контекст, если ответа не хватает.

Это принципиально. Хороший агент не должен получать один статичный кусок RAG в prompt. Он должен сам искать, оценивать и уточнять. На реальных задачах запрос редко укладывается в один retrieval-проход: пользователь уточняет вопрос, база знаний неполная, релевантный документ лежит в другом месте. Agentic search делает этот цикл встроенным в модель.

RAG не умер, но порог «зачем RAG» сдвинулся

Раньше выбор был простой: контекст маленький и дорогой → нужен RAG. Сейчас с V4-Flash за $0.14/M токенов можно загрузить 200-страничный документ за несколько центов и задавать вопросы напрямую. Для многих задач это проще, чем строить retrieval pipeline с чанкованием, эмбеддингами и reranker.

Но RAG не исчезает. Он остаётся нужным там, где:

• Объём документов превышает 1M токенов (архивы, многолетняя история).
• Нужен точный retrieval с цитированием конкретных абзацев.
• Требуется гибридный поиск (семантический + ключевые слова) и reranking.
• Важна скорость: retrieval быстрее, чем загрузка всего документа в контекст.

Когда agentic search, а когда статичный RAG

Agentic search выигрывает, когда запрос не укладывается в один retrieval-проход: нужно уточнить, переформулировать, поискать в другом месте. Статичный RAG выигрывает, когда запрос предсказуем и retrieval-пайплайн хорошо отлажен.

Практическое правило: если на задаче retrieval-hit-rate стабильно выше 90% - статичного RAG достаточно. Если ниже - agentic search может дать существенный прирост.

Что мы учитываем при проектировании

Когда мы строим контур для заказчика, мы не начинаем с модели. Мы смотрим на:

• Объём и структуру данных.
• Типовые запросы и их сложность (одношаговые vs multi-hop).
• Требования к latency и стоимости.
• Где данные должны оставаться (on-premise, air-gap, выделенный ДЦ).
• Какие метрики качества критичны: faithfulness, context precision, citation accuracy.

И уже под это выбираем: RAG, agentic search, длинный контекст или их комбинацию. DeepSeek-V4 интересен тем, что даёт все три варианта в одной модели - и Flash-версию, которую реально поднять локально.