Статья
Пробуем разобрать конфиденциальный отчёт с помощью пяти ИИ-моделей
Это был не финансовый отчёт и не набор таблиц. Исходником был внутренний исследовательский отчёт на 13 708 знаков, разделённый на 12 смысловых блоков. Руководителю нужен не пересказ документа, а короткая карта барьеров, мотивов и точек недоверия, причём каждый вывод должен подтверждаться точной цитатой. Самое простое решение кажется очевидным: бросить DOCX в Claude или Codex. Но что делать, если так нельзя? Для этого эксперимента передавать исходник внешним сервисам было нежелательно. Это не универсальный запрет. Допустимость облачных моделей зависит от политики компании, договоров и категории данных. В нашем случае документ остался на ноутбуке. Claude и Codex его не читали и не анализировали, но помогали настроить локальный конвейер: подготовить скрипты, схему результата, проверки и сборку выходных файлов. Пять ИИ-моделей запускали на MacBook Air M5 с 32 ГБ памяти. Проверяли не абстрактный интеллект, а рабочую задачу: получить материал для принятия решения, доказать каждый вывод исходным текстом и не выпустить данные за пределы выбранного контура.
01
Что именно нужно было получить
Исследование отвечало на практические вопросы: замечают ли клиенты нужный раздел продукта, на каком шаге бросают оформление, как выбирают поставщика, почему доверяют или не доверяют предложению и какие каналы привлечения приводят к покупке. Из этого нужно было сделать не «краткое содержание», а аналитическую записку.
Каждая модель должна была выделить от пяти до девяти самостоятельных выводов, собрать их в четыре, пять или шесть тем и приложить к каждому выводу точную цитату из DOCX. Отдельно модель должна была сохранить оговорки исследования и не превращать наблюдения ограниченного исследования в утверждения обо всех клиентах.
- 01Прочитать DOCX13 708 знаков и 12 смысловых блоков
- 02Выделить темыБарьеры, доверие, выбор и каналы привлечения
- 03Собрать выводыОт пяти до девяти неповторяющихся наблюдений
- 04Проверить доказательстваУ каждого вывода есть дословная цитата из источника
Итог нужен не ради сокращения текста, а ради решения, которое можно проверить по первоисточнику.
02 — Спойлер
Тема рабочая, но не в формате чата
Да, конфиденциальный отчёт можно разбирать локально. Лучший прогон дал пять смысловых разделов и восемь выводов. Все восемь подтверждающих цитат дословно нашлись в исходном документе. На аналитическую часть ушло чуть больше восьми минут.
Но рабочим оказался не ответ в чате, а весь конвейер. Модель возвращает строгую структуру. Код проверяет схему и каждую цитату. Из проверенных данных собирается HTML-отчёт, который открывается в обычном браузере: вверху краткий итог, ниже темы, выводы и точные доказательства.
JSON нужен не читателю, а следующему шагу автоматизации. Это машинная структура с темами, выводами и ссылками на цитаты. React нужен только тогда, когда тот же проверенный материал надо встроить во внутренний портал или панель с карточками, навигацией и графиками. Обезличенная текстовая копия относится к отдельному тесту защитного контура. Это не четыре версии одного и того же прогона.
HTML в браузере
Проверенный HTML-отчёт
Краткий итог
Действие откладывают, когда условия нельзя быстро сравнить.
React во внутреннем портале
Интерактивное представление
Панель исследования
Карточка показывает тему, статус проверки и ссылку на исходный фрагмент.
Обезличенные мокапы показывают устройство результата, а не содержание исходного отчёта. JSON и HTML получены в основном прогоне. React и обезличивание проверялись отдельно.
03
Как был устроен эксперимент
Исходником был DOCX на 13 708 знаков. Он содержал законченный исследовательский отчёт из 12 смысловых блоков с текстом, данными и числовыми показателями. Название компании, продукта и содержание исследования мы не публикуем.
Каждая модель получила один и тот же текст и одинаковый контракт: выделить от пяти до девяти выводов, сгруппировать их в четыре, пять или шесть разделов и приложить к каждому выводу точную цитату из источника.
Тест шёл на MacBook Air M5 с 32 ГБ общей памяти. Температуру генерации установили на ноль, параметр seed зафиксировали на 42. Для каждого условия сделали один детерминированный прогон. Поэтому цифры следует воспринимать как ориентир, а не как статистически устойчивый результат.
- DOCX
- формат внутреннего отчёта
- 12
- смысловых блоков в исследовании
- 13 708
- знаков в документе
- 5
- ИИ-моделей в сравнении
MacBook Air M5, 32 ГБ памяти. Исходный документ не покидал локальный контур.
04
Какие модели запускали
Четыре модели работали через Ollama 0.30.11. Muse Glimmer запускалась через LM Studio 0.4.16. MLX-модели в финальное сравнение не вошли: Qwen 3 14B остановилась на обработке запроса при текущей нагрузке памяти, а Devstral 2507 не перезапускали на новом документе. GPT-OSS 20B через LM Studio тоже остановилась на обработке запроса и оценки не получила.
Ниже указан размер квантованных весов или пакета модели, а не пиковое потребление оперативной памяти. Во время генерации к весам добавляются контекст, кэш и служебные данные, поэтому фактическая нагрузка выше.
В Ollama использовали Q4_K_M, для Qwen 3.5 вариант Q4_K. Muse Glimmer работала в формате k-quant GGUF.
05
У моделей получились разные профили
Один отчёт показывает только часть картины. Поэтому паутинка ниже собрана по более широкому полевому тесту на восьми типах задач. В неё вошли работа с кодом, анализ документа, точность цитат, сборка React-интерфейса, агентные действия и предложение схемы обезличивания.
Универсального победителя не получилось. Muse Glimmer лучше остальных разобрала отчёт и сохранила доказательную основу, но уступила в агентных задачах. Qwen 3 4B оказалась заметно быстрее и после одного рабочего примера собрала корректный React-материал. Devstral, Gemma и Qwen 3.5 сильнее выглядели в агентных сценариях, чем в работе с точными цитатами.
Особенно хорошо видно влияние контекста. Один качественный пример заметно улучшил результат React-прогона у двух моделей. То есть выбирать надо не только модель, но и способ постановки задачи.
Диаграмма отрендерена Pele, движком диаграмм Markdown-редактора Mark.
Шкала от 0 до 5. Каждую модель в каждом сценарии запускали один раз, поэтому цифры показывают направление, а не точный рейтинг.
06
Лучшую аналитику дала самая большая модель
Лучший результат по качеству аналитической записки показала Muse Glimmer 30B. Она получила 4,6 балла из 5. Небольшая Qwen 3 4B заняла второе место с результатом 4,05. Devstral Small 2 и Gemma 4 набрали по 3,65. Qwen 3.5 Abliterated получила 3,15.
Сам по себе этот график ещё не выбирает победителя. Разница между первым и вторым местом заметна, но вместе с качеством надо смотреть на доказательства и время. Именно там картина становится интереснее.
Оценивались полнота резюме, отсутствие повторов, структура, осторожность выводов и читаемость.
07
Точные цитаты изменили результат
Muse Glimmer оказалась единственной моделью, которая прошла строгую проверку доказательств. Все восемь её цитат нашлись в документе дословно. У Qwen 3 4B проверку прошли пять цитат из восьми. У Devstral Small 2 только пять из девяти. У Gemma 4 четыре из семи. У Qwen 3.5 Abliterated две из семи.
В обычном интерфейсе эти ошибки легко пропустить. Цитата выглядит правдоподобно, соответствует теме и часто отличается от оригинала всего несколькими словами. Но это уже не цитата. Если такой материал уходит руководителю или клиенту, красивый пересказ начинает изображать доказательство.
Баллы рассчитаны по доле заявленных цитат, которые дословно нашлись в исходном документе.
08
Почему восемь минут на отчёт вполне нормально
Muse Glimmer подготовила лучший документ за 8 мин 7 сек. Devstral Small 2 закончила почти за девять минут. Qwen 3 4B справилась за 1 мин 29 сек и заняла второе место по качеству резюме.
Для одного содержательного отчёта восемь или девять минут не выглядят долгим ожиданием. На выходе уже есть структурированный черновик, но это не значит, что модель заменила аналитика. Человеку всё равно нужно проверить смысл выводов, ограничения выборки и итоговые рекомендации.
Скорость начинает влиять на выбор, когда документов десятки или сотни либо когда ответ нужен в интерактивном режиме. Тогда разница почти в пять с половиной раз превращается в пропускную способность. Для отдельного важного отчёта качество и точность доказательств важнее.
Один прогон на одной машине. Время показывает порядок величины, а не гарантированную производительность.
09 — Бонус
Можно ли обезличить отчёт и отдать его Claude или Codex
А что если отчёт обезличить, отдать Claude или Codex, а после обработки локально вернуть исходные значения? Иногда так можно, если это допускают политика компании, договоры и категория данных. Поэтому мы отдельно проверили, могут ли с обезличиванием помочь локальные модели.
Сначала мы проверили модель без дополнительной защиты. Она должна была найти чувствительные фрагменты и заменить их обратимыми метками. На синтетическом документе было 15 защищённых фрагментов. Ни одна модель сама по себе не прошла условие нулевой утечки.
Это ожидаемый результат. Формулировка «найди все чувствительные данные» не превращает вероятностную модель в межсетевой экран. Она почти всё находит, но для утечки достаточно одного пропуска.
Поэтому в реальной проверке мы сознательно сузили защитный контур до чисел, диапазонов и процентов. Модель предлагала замены, а обычный код повторно искал эти типы значений, добавлял пропущенные и только после этого разрешал дальнейшую обработку. Соответствие между метками и исходными значениями оставалось в локальном хранилище.
Эта проверка не доказывает, что тем же способом можно автоматически обезличить имена, номера документов и другие персональные данные. Для них нужны отдельные правила и отдельные тесты.
- 01Локальный разборМодель предлагает замены для чисел, диапазонов и процентов
- 02Детерминированная проверкаКод повторно ищет эти значения и добавляет пропущенные
- 03Обезличенный материалДальше проходит только текст без оставшихся цифр
- 04Локальное восстановлениеИсходные значения возвращаются по локальной таблице соответствий
В этом опыте детерминированный контур проверял только числа, диапазоны и проценты.
10
На реальном документе обе модели пропустили одно число
Для дополнительной проверки мы попросили Qwen 3 4B и Muse Glimmer найти семь уникальных числовых значений в реальном конфиденциальном документе. Обе модели корректно нашли шесть из семи. В каждом ответе также был один ошибочный элемент. Это не идеальный результат, хотя найденные корректные значения были воспроизведены с точностью 100 процентов.
Детерминированная проверка добавила пропущенное значение. После этого в обезличенном тексте не осталось цифр, а локальное восстановление точно вернуло все использованные значения.
Самая сильная модель не справилась с задачей самостоятельно. Самая маленькая показала тот же результат. Надёжность появилась не из размера модели, а из архитектуры процесса.
Жёсткого вывода здесь нет. Такая схема не защищает от утечки на 100 процентов и ничего не гарантирует: модель может пропустить фрагмент, а проверка кодом охватывает только те типы данных, под которые её написали. Частичное обезличивание может быть одним из этапов, но решение о передаче документа во внешний сервис нельзя принимать по этому тесту. Его определяют политика компании, договорные ограничения и проверка конкретных категорий данных.
- 7
- уникальных значений в исходнике
- 6
- нашла каждая из двух моделей
- 1
- добавила проверка обычным кодом
- 0
- цифровых утечек после проверки
После локального восстановления все использованные значения вернулись на свои места.
11
Какую схему мы выбрали бы для работы
Если нужен лучший черновик важного аналитического отчёта на этой машине, мы бы начали с Muse Glimmer. Восемь минут для такой задачи вполне нормальны. Если документов много, а результат всё равно проходит автоматическую и человеческую проверку, Qwen 3 4B выглядит практичнее.
Devstral Small 2 показала себя сильнее в агентных сценариях, чем в анализе документов, где важна точность доказательств. Gemma 4 и Qwen 3.5 Abliterated тоже могут быть полезны в своих ролях, но этот тест не дал причины выбирать их для аналитики конфиденциальных отчётов.
Ни одной из моделей мы не отдали бы право самостоятельно выпускать выводы или решать, что данные уже безопасны. Модель готовит черновик. Код проверяет формальные границы. Человек принимает содержательное решение.
12
Вывод
Локальный запуск решает вопрос о том, где физически обрабатывается документ. Он не гарантирует качество и не даёт автоматической гарантии конфиденциальности.
В нашем тесте большая модель сделала лучший аналитический материал. Маленькая модель оказалась в несколько раз быстрее и достаточно хороша для ограниченной роли. Обе пропустили одно чувствительное число. Поэтому рабочий выбор выглядит не как название одной модели, а как связка из локального запуска, точных цитат, программных проверок и понятного человеческого контроля.
Тот же принцип, когда данные остаются в вашем контуре, лежит в основе наших проектов с распознаванием речи и текста на изображениях: от расшифровки встреч до OCR скриншотов на локальной модели.
- РечьЛокальный голосовой ассистентДиктовка и заметки встреч на ноутбуке; голос не покидает устройство.
- РечьБаза знаний из чатов и встречТранскрипция с разделением спикеров; решения и задачи извлекаются и связываются с источником.
- OCRЛокальная vision-модель для агентовАнализ скриншотов и OCR на локальной модели для агентов разработки и поддержки.
- СтатьяРасшифровка совещаний без облака: Whisper и разделение спикеровКак устроить локальную расшифровку встреч: Whisper large-v3, pyannote для спикеров, узнавание знакомых голосов и разбор решений с привязкой к таймкоду.