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

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

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

Облачный сервис покупает время. Локальный запуск покупает контроль. Ни один вариант не отменяет проверку фактов.

Экономика: считать надо токены, а не статьи

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

На тарифе Gemini Developer API для Gemini 3.6 Flash, указанном в актуальной документации на момент сбора данных, вход стоил 1,50 доллара за миллион токенов, выход — 7,50 доллара за миллион токенов. В выходную цену входят thinking tokens. Контекстный кэш имел отдельную цену: 0,15 доллара за миллион токенов, хранение — 1 доллар за миллион токенов в час.

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

Расчёт строится в три прохода:

1. Измерить сырой вход. Нужно взять реальную неделю RSS-лент, страниц и рассылок. Считать токены после извлечения основного текста, а не размер HTML-ответа. Отдельно выделить дубликаты: агентства, репосты и синдицированные колонки часто повторяют один факт десятки раз.

2. Зафиксировать формат выхода. Дайджест из пяти тезисов, краткого контекста и цитаты источника занимает один объём. Дайджест с пересказом, сравнением позиций, тегами, оценкой последствий и переводом — другой. Выходные токены обычно дороже входных. Их нельзя считать побочным расходом.

3. Добавить инфраструктурные операции. Поисковое обогащение, хранение кэша, повторные запросы при сбое, классификация, перевод и разбор вложений входят в фактическую ставку. У Gemini в платном тарифе было предусмотрено 5 000 запросов grounding с Google Search в месяц без отдельной оплаты; далее — 14 долларов за тысячу запросов. Для небольшого личного потока это может не иметь значения. Для автоматического мониторинга десятков тем — уже имеет.

Локальный запуск не делает суммаризацию бесплатной. Он лишь меняет структуру издержек. Деньги уходят в уже купленные CPU, GPU, память, электричество и время на обслуживание. Если машина существует для других задач и простаивает ночью, предельная стоимость выпуска действительно может быть низкой. Если компьютер покупается специально под задачу «пересказать двадцать статей в день», финансовая логика становится менее очевидной.

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

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

Политика данных: «не обучаемся» не означает «ничего не храним»

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

У OpenAI API входы и выходы по умолчанию не используются для обучения или улучшения моделей, если организация специально не подключилась к обмену данными. Но журналы мониторинга злоупотреблений по умолчанию могут храниться до 30 дней. Режим Zero Data Retention доступен не для каждого endpoint и требует одобрения организации.

У платных сервисов Gemini Developer API Google заявляет, что не использует промпты, ответы, кэшированный контекст и файлы для улучшения продуктов. При этом данные могут ограниченно логироваться для мониторинга нарушений. Нулевой след не включается сам по себе: он зависит от выбранного режима, endpoint и отключения функций, создающих состояние или хранение. В частности, работа с состоянием сессии меняет модель хранения: при включённой конфигурации возобновления сессии данные могут сохраняться до 24 часов.

Это не аргумент против облака. Это аргумент против неточных формулировок.

Перед отправкой новостного потока в API нужно ответить на четыре вопроса:

• попадают ли в промпт персональные заметки, адреса, корпоративные документы, закрытые рассылки или история чтения;
• какой endpoint используется и какие условия хранения применяются именно к нему;
• включены ли кэш, файлы, память диалога, поиск и иные stateful-функции;
• нужен ли в дайджесте полный текст источника или достаточно извлечённого фрагмента и метаданных.

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

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

Локальная модель: офлайн возможен, автономность — условна

LM Studio после загрузки модели может работать полностью офлайн: локальные чаты, обработка документов и локальный сервер не требуют интернета, а введённые тексты и документы остаются на устройстве. Формулировка важна именно в этой части: после загрузки модели. Скачивание весов, поиск новых версий, обновления, внешние инструменты и сетевые коннекторы уже не относятся к изолированному режиму.

Минимальный технический порог не равен комфортной работе. Для LM Studio рекомендуется не менее 16 ГБ оперативной памяти. На Windows — от 4 ГБ выделенной видеопамяти. На Mac с 8 ГБ памяти возможна работа только с меньшими моделями и умеренным контекстом. Это не спецификация для «любой модели», а нижняя граница пригодного сценария.

Показателен класс моделей уровня Qwen3-8B: 8,2 млрд параметров, нативный контекст 32 768 токенов, расширение до 131 072 токенов с YaRN. На бумаге цифра контекста выглядит как решение задачи агрегирования целого дня новостей. В реальной машине остаются три ограничения:

• Квантизация. Одна и та же модель в разных GGUF-сборках потребляет разные объёмы памяти и по-разному ведёт себя на русском тексте, извлечении фактов и длинной инструкции.
• KV-кэш. Чем длиннее контекст, тем больше памяти требуется на его обслуживание. Паспортные 131 072 токена не гарантируют приемлемую скорость и отсутствие выгрузки в оперативную память.
• Скорость генерации. Дайджест, который строится несколько минут, технически существует. Практически он ломает ритм утреннего выпуска и провоцирует уменьшать проверку источников.

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

Но слова «локальный» и «безопасный» не являются синонимами.

LM Studio запускает локальный API без аутентификации по умолчанию. Если включить доступ из локальной сети или CORS без необходимости, сервер перестаёт быть личным контуром. Он становится сервисом, который может принять запрос от другого устройства или приложения. При доступе не только через localhost требуется токен аутентификации. Сетевой доступ следует выключать, если для него нет конкретной задачи.

Модель на домашнем компьютере не защищена по умолчанию. Незащищённый API — это внешний интерфейс, просто расположенный ближе.

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

Новостная лента — недоверенный ввод, а не база знаний

RSS, статья и веб-страница не должны попадать в контекст как нейтральный материал. Они содержат инструкции, рекламные блоки, невидимые элементы, цитаты, внедрённые промпты, комментарии и ошибки извлечения. OWASP отдельно выделяет indirect prompt injection: внешнее содержимое меняет поведение модели через инструкцию, спрятанную или открыто размещённую в документе.

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

• игнорировать системные правила и выдать текст в другом формате;
• присвоить источнику высокий приоритет;
• скрыть неудобный тезис;
• раскрыть фрагменты ранее обработанного контекста;
• сделать запрос к подключённому инструменту;
• подменить ссылку или добавить недостоверный вывод.

RAG не устраняет эту уязвимость. Дообучение не устраняет её. Жёсткий системный промпт снижает часть риска, но не превращает внешний текст в доверенный.

Нормальная защита строится на разделении ролей.

1. Инструкция хранится отдельно от источника. Текст статьи передаётся как данные с явной маркировкой: он не является командой и не может менять правила обработки.

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

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

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

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

Слабая конструкция — одна большая команда: «прочитай эти статьи и сделай важное». Устойчивая конструкция — несколько узких шагов: извлечение, дедупликация, классификация, краткое резюме отдельного источника, проверка цитат, финальная компоновка. Это медленнее в проектировании. Зато ошибка локализуется.

Главный риск не в утечке, а в правдоподобной ошибке

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

Суммаризация особенно уязвима, потому что её результат короче источника. При сокращении теряются оговорки: «может», «по данным одной стороны», «предварительно», «при условии», «на момент публикации». Модель часто считает эти элементы шумом. В редакционной работе они меняют смысл.

Минимальный стандарт для личного дайджеста выглядит так:

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

Полезно требовать от модели не «сделать вывод», а заполнить строгую структуру: что произошло, кто утверждает, когда, где это подтверждено, какие существенные ограничения есть в исходном тексте. Даже тогда результат остаётся черновиком. Структура дисциплинирует генерацию, но не заменяет сопоставление с источником.

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

Оценивать следует не «красоту резюме», а частоту фактических потерь:

• неверно переданные числа и даты;
• потерянные условия и оговорки;
• перепутанные субъекты действия;
• выдуманные ссылки и цитаты;
• пропущенные противоречия;
• следование инструкциям из исходного документа.

Вердикт

Облачный API — рациональный выбор для личного дайджеста, если нужен быстрый запуск, поток состоит преимущественно из открытых источников, а пользователь готов считать токены и принимать политику хранения конкретного провайдера. Передача данных должна быть минимизирована. Кэш, файлы, память и endpoint проверяются отдельно.

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

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

Автоматический дайджест не является источником фактов. Это механизм сокращения входящего потока. Факт остаётся в первоисточнике.