Как отключить reasoning у локального DeepSeek-R1 и не сойти с ума

Третий пост из серии про грабли локальных LLM. Первый — про микрочанки, отравляющие RAG. Второй — про embedding модель, которая не знает русский. Сейчас — про reasoning, который жрёт ресурсы и не выключается.

Проблема

DeepSeek-R1-Distill-Qwen-32B — reasoning модель. На каждый запрос она сначала «думает» в блоке <think>...</think>, потом отвечает. Выглядит так:

<think>
Хорошо, мне нужно помочь пользователю распределить задачи
для проекта создания цифрового двойника для молочной фермы.
Я новичок в этом, поэтому постараюсь разобраться шаг за шагом.

Сначала, мне нужно понять, что такое цифровой двойник...
</think>

Разработка цифрового двойника для молочной фермы — это сложный проект...

Блок <think> может быть длиннее самого ответа. Это токены, это время, это VRAM. Для задач где рассуждения не нужны — чистый оверхед.

Наивное решение — не работает

Первая идея: убрать <think> из ответа регуляркой постфактум.

response_text = re.sub(r'<think>.*?</think>', '', response_text, flags=re.DOTALL).strip()

Проблема: модель всё равно генерирует рассуждения. Вы просто прячете их от пользователя, но GPU уже потратил время и токены.

Решение от сообщества

Пустой блок <think>\n\n</think> в конце промпта. Модель видит, что фаза рассуждений уже «завершена», и сразу переходит к ответу.

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
text = text + "<think>\n\n</think>\n\n"

Попробовал — не работает. Reasoning остаётся.

Ловушка с токенизатором

Смотрю в лог что реально уходит модели:

...ть задачи?<｜Assistant｜><think><think>

</think>

Два <think>. Токенизатор DeepSeek при add_generation_prompt=True уже добавляет <think> в конец промпта автоматически. Мой код добавляет второй. Модель видит незакрытый первый тег и начинает думать.

Причём <｜Assistant｜> — это не обычные символы |, а полноширинные юникодные ｜. Специальные токены DeepSeek. Если искать обычный | в строке — не найдёте.

Правильное решение

Проверять, что уже есть в промпте, и действовать по ситуации:

def prepare_prompt_no_thinking(messages, tokenizer):
    text = tokenizer.apply_chat_template(
        messages, 
        tokenize=False, 
        add_generation_prompt=True
    )
    
    if "<think>\n\n</think>" in text:
        pass  # Уже закрыт
    elif "<think>" in text and "</think>" not in text:
        text = text + "\n\n</think>\n\n"  # Закрываем открытый
    else:
        text = text + "<think>\n\n</think>\n\n"  # Добавляем пустой
    
    return text

Три ветки — потому что разные версии токенизатора ведут себя по-разному. Кто-то добавляет <think>, кто-то нет.

Результат

Без тегов:

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

С правильными тегами:

Разработка цифрового двойника для молочной фермы — это сложный проект,
который требует участия специалистов из разных областей.
Вот примерное распределение задач:

Модель сразу отвечает по делу, без вступительных рассуждений. Экономия токенов и времени — в зависимости от запроса от 30% до 60%.

Вывод

Если используете DeepSeek-R1-Distill локально и reasoning вам не нужен — не режьте его регуляркой постфактум. Закройте <think> тег до генерации. Но обязательно проверяйте, что токенизатор уже добавил — иначе получите дубль и потратите час на дебаг того, что должно было занять минуту.

Идеальная база знаний, а RAG возвращает мусор — проблема не там, где кажется

Продолжение предыдущего поста про микрочанки, где 3 мусорных документа отравили весь RAG. Тогда проблема была в данных. Сейчас — данные идеальные, а поиск всё равно не работает.

Контекст

Строю локальную мультиагентную систему. Собрал базу знаний: 85 архитектурных блоков, 160 чанков в ChromaDB, реальный опыт — не синтетика. Embedding модель — стандартная all-MiniLM-L6-v2. Документы на русском с вкраплениями английских терминов (DPO, LoRA, VRAM — как у всех).

Симптом

Спрашиваю: "DPO патч для OOM" — в базе есть целый блок про это. RAG возвращает документ про права доступа к Project Context. Вообще мимо.

Спрашиваю: "positive feedback loop" — в базе есть блок №57 ровно с таким названием. RAG его не находит, dist=0.746.

Диагностика

Подозрение — embedding модель не понимает русский текст. Проверяю: один и тот же смысл, три формулировки.

queries = [
    ("positive feedback loop", "английский"),
    ("петля положительной обратной связи", "русский"),
    ("цикл доверие данные результат", "русский контекст"),
]

for q, lang in queries:
    results = col.query(query_texts=[q], n_results=1, include=["documents", "distances"])
    dist = results['distances'][0][0]
    print(f"[{lang}] dist={dist:.3f} | '{q}'")

[английский]       dist=0.746 | 'positive feedback loop'
[русский]           dist=0.566 | 'петля положительной обратной связи'
[русский контекст]  dist=0.504 | 'цикл доверие данные результат'

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

Почему так

all-MiniLM-L6-v2 обучалась на английских текстах. Она превращает текст в вектор из 384 чисел. Для английского — вектор осмысленный, семантически правильный. Для русского — видит буквы, но не понимает смысл. Вектор получается случайный.

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

А может перевести всё на английский?

Первая мысль — перевести все документы на английский, запросы тоже переводить на лету, а результат обратно на русский. Английские embedding модели объективно лучше отточены, больше данных, больше бенчмарков.

Но для локальной системы с русскими документами это плохой вариант. Технические термины с контекстом теряются при переводе. Появляется двойная задержка — перевод запроса туда, результата обратно. Нужен ещё один сервис (переводчик), а задача — держать всё локально. И главное — ошибки накапливаются: плохой перевод → плохой вектор → плохой результат.

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

Решение

Заменил all-MiniLM-L6-v2 на paraphrase-multilingual-MiniLM-L12-v2. Модель обучена на 50+ языках, включая русский. Понимает смешанный текст типа “DPO обучение на LoRA адаптере” — то, что в локальных ML-проектах встречается на каждом шагу.

Пересоздал все коллекции с новой моделью. Результат:

# Было (all-MiniLM-L6-v2):
# 'positive feedback loop' → dist=0.746, нашёл мусор

# Стало (multilingual):
# 'positive feedback loop' → dist=0.35, нашёл именно блок про Feedback Loop

Поиск заработал сразу. На все запросы — и русские, и английские, и смешанные.

Вывод

Если строите RAG на русском (или любом не-английском) — не берите all-MiniLM-L6-v2 по дефолту. Она стоит первой в каждом туториале, но для нелатинских языков это ловушка. Данные могут быть идеальными, чанкинг правильным, а поиск будет возвращать мусор — потому что “переводчик” не знает ваш язык.

Замена embedding модели на мультиязычную — одна строчка кода и пересоздание коллекций. Пять минут работы, которые сэкономят дни дебага.

# Было
ef = SentenceTransformerEmbeddingFunction(model_name="all-MiniLM-L6-v2")

# Стало
ef = SentenceTransformerEmbeddingFunction(model_name="paraphrase-multilingual-MiniLM-L12-v2")

3 мусорных документа (1.7%) отравили весь мой RAG

Строю локальную мультиагентную систему с RAG на ChromaDB. В какой-то момент модель начала нести чушь — вставлять в ответы куски маркдауна, генерить мусор вместо нормальных ответов.

Симптом

Спрашиваю: «Новый проект: цифровой двойник нефтеперерабатывающего завода. Как декомпозировать?»

В ответе — рандомные огрызки разметки типа "25*\n*Тип: Инфраструктура и системное администрирование*". Модель явно копировала что-то из контекста.

Копаю

Смотрю что RAG возвращает на этот запрос:

results = rag.query(query_texts=[query], n_results=3)
for doc in results['documents'][0]:
    print(f"[{len(doc)} chars]: {doc[:50]}")

[56 chars]: 25*\n*Тип: Инфраструктура и системное администр...
[15 chars]:  и реализация*...
[11 chars]: ров вместе...

Топ-3 — мусор, а не документы.

Причина

При загрузке маркдаун-файлов в ChromaDB чанкер резал по 800 символов механически — посередине заголовков, посередине предложений. В итоге появились микро-огрызки типа "ров вместе" (11 символов), которые стали отдельными документами.

Почему короткие чанки ломают RAG

Короткий текст → странный эмбеддинг. Вектор ни о чём, без смысла. И именно поэтому он оказывается «близок» к любому запросу случайным образом. Мой 11-символьный огрызок стабильно обгонял нормальные 800-символьные документы в similarity search.

Фикс

Нашёл все документы меньше 100 символов:

all_docs = rag.get(include=["documents"])
short = [(i, doc) for i, doc in enumerate(all_docs['documents']) if len(doc) < 100]
print(f"Мусор: {len(short)}")  # 3

Удалил:

ids_to_delete = [all_docs['ids'][i] for i, _ in short]
rag.delete(ids=ids_to_delete)
# Было: 176 docs → Стало: 173 docs

Галлюцинации прекратились сразу.

Вывод

Фильтруйте чанки по минимальной длине до загрузки в векторную БД:

MIN_CHUNK_LENGTH = 100
chunks = [c for c in chunks if len(c) >= MIN_CHUNK_LENGTH]

3 документа из 176 — это 1.7%. Процент не имеет значения. Если у мусора странный вектор — он всплывёт. Один плохой документ может отравить весь ваш RAG.

Представлен открытый проект Project N.O.M.A.D. — локальная база знаний для выживания с ИИ на борту:

• работает на ИИ Ollama — личный локальный ИИ-ассистент, который подскажет, как починить генератор или оказать первую помощь, не обращаясь к внешним серверам;

• Вся Википедия, медицинские справочники и учебники в офлайне;

• карты и навигация любого региона планеты;

• в теории можно развернуть полноценную станцию выживания с N.O.M.A.D. и запитать её всего от одной солнечной панели.

Представлен мегагайд по ИИ-помощнику Claude Code. В обучающем материале 108 тем, включая введение в Claude, форкфлоу, скилы, шорткаты, субагенты, хуки. Каждая тема — короткая справка, подробная документация со всеми нюансами и статьи от профессионалов.

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

Забираем

20 инструментов кибербезопасности 2025 года для пентестинга, сканирования IP-сетей, анализа трафика:

• Nmap — ультрабаза для анализа сетей

• Wireshark — анализатор сетей Ethernet

• Metasploit — самый популярный инструмент пентестинга

• Burp Suite — сканим веб-приложения на уязвимости

• SQLmap — находит уязвимости SQL-инъекций

• John the Ripper/Hashcat — быстрый кряк паролей

• Aircrack-ng — беспроводные сети и пароли

• Nikto — быстрый сканер веб-сетей

• Suricata — IDS / IPS защита

• OpenVAS — мощная система оценки уязвимостей

• Splunk — аналитик машинных данных

• Maltego — полноценная киберразведка

• Shodan — поисковик серверов

• Kali Linux — операционка хакеров и пентестеров

• Cobalt Strike — имитирует действия мошенников

• BloodHound — размечает направления атак

• BEB6 — пароли WiFi-сети

• XSpider — сканер для любых систем

• CrowdStrike Falcon — комплексная защита

• CrackMapExec — проверка окружения Windows/Active Directory

Опасности Apache POI 📍

Наверняка многие из вас юзают Apache POI. Для тех, кто не знает: это джаванская либа для работы с файлами Microsoft Office и OOXML — всякие Excel, Word и прочее.

А в чём опасность?

При генерации Excel-файла эта библиотека позволяет включить отслеживание ширины данных в колонках и автоподгонку ширины столбцов под содержимое (чтобы данные не скрывались из-за маленькой ширины столбца по умолчанию).

Включается это так:
// Отслеживаем ширину для автосайзинга
sheet.trackAllColumnsForAutoSizing();
// ... генерируем строки Excel-файла
// Автосайзим столбцы
sheet.autoSizeColumn(columnIndex);

Проблема: эта тема крайне ресурсоёмкая на больших объёмах данных. На тесте с 100 строками — всё быстро. На проде с 600К строк — 20 минут превращаются в 4 часа. 4 часа, Карл! Чего оно там делает вообще?!)

У нас такое не раз уезжало в прод и штука эта совсем неприятная я вам скажу:

• Отчёт не собирается вовремя;

• Заказчик негодует;

• Паника, крики — в общем, ну его этот трекинг! 😅

Что делать?

В 99% случаев: достаточно автосайзинга только для заголовков:

// Включаем автосайзинг
sheet.trackAllColumnsForAutoSizing();
// Генерируем заголовки
//...
// Автосайзим колонки
sheet.autoSizeColumn(columnIndex);
// Выключаем трекинг
sheet.untrackAllColumnsForAutoSizing();
//... продолжаем генерацию

В 1% случаев: нужно отавтосайзить 1-2 столбца из сотен. Тогда делаем точечный трекинг:

// Трекинг только нужных колонок
sheet.trackColumnForAutoSizing(columnIndex);
// ... генерация данных
// Автосайзим
sheet.autoSizeColumn(columnIndex);

Ну и можно конечно вручную задавать ширину столбцов, но это не всегда удобно.

P.S. Метод autoSizeColumn() очень тяжёлый. Выдержка из джавадоки:

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

P.S.S. Еще кстати поя умеют не буферизовать весь excel’ник в память при генерации, надеюсь вы все этим пользуетесь ибо обратное дико некармическая тема)) Знаете ж как?

Приходите к телегу, там обсуждаем наши кровавые энтерпрайзы: https://t.me/umenyarabotaet

Представлен локальный ИИ-ассистент DeepSeek Code Companion для разработчиков на базе DeepSeek R1. Для работы с ним не нужен даже API. Пишет код на уровне сеньора. Во время компиляции помогает в отладке и исправлении багов. Даёт рекомендации по архитектуре и масштабированию. На выбор есть две модели: для быстрых ответов и для более сложных задач.