Краткий пересказ нейросетью: как выжать суть из документа

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

Что модель делает с текстом на самом деле

Есть два принципиально разных способа сжать текст. Экстрактивный — выбрать из документа самые важные предложения и склеить их. Так работали старые алгоритмы вроде TextRank: они ничего не сочиняют, но пересказ получается рваным, фразы вырваны из контекста. Абстрактивный — прочитать текст и написать новый, своими словами. Именно так работают языковые модели.

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

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

Из чего состоит хороший запрос на пересказ

Плохой промпт — «сделай краткое содержание». Хороший отвечает на пять вопросов.

1. Объём и единица измерения

«Кратко» модель понимает как угодно. Задавайте измеримое: «5 пунктов списка», «300–400 знаков», «три абзаца». Счёт в предложениях и пунктах работает надёжнее, чем в знаках и словах — модели плохо считают символы, зато нормально держат структуру.

2. Для кого пересказ

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

3. Что именно вытаскивать

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

4. Опора на текст

Добавьте прямое ограничение: «используй только сведения из документа; если чего-то нет — напиши "не указано"». Это заметно снижает количество дописанного от себя. Разрешение сказать «не знаю» работает лучше, чем запрет выдумывать.

5. Формат вывода

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

Рабочая заготовка, которую остаётся подставить под свою задачу:

Ты аналитик. Ниже — стенограмма встречи.
Сделай пересказ для руководителя проекта, который не был на встрече.

Формат:
- Итог одним предложением
- Принятые решения (списком, до 5 пунктов)
- Задачи: кто, что, к какому сроку
- Открытые вопросы

Правила: опирайся только на текст стенограммы.
Если данных нет — пиши «не указано». Не добавляй оценок и советов.

Стенограмма:
<текст>

Разделители вокруг исходника («Стенограмма:» и явные скобки) нужны не для красоты: они отделяют данные от инструкций и снижают шанс, что фраза внутри документа будет прочитана как команда. Подробнее про приёмы формулировок — в заметке про промпт-инжиниринг, а про постоянные правила для модели — в материале о системном промпте.

Что делать, если документ большой

Первый вопрос — влезает ли текст в контекстное окно модели (объём текста, который она может принять за один запрос). Современные модели тут щедры: у Gemini 3.5 Flash окно на 1 млн токенов и до 65k токенов на ответ, у Claude Sonnet 5 и Opus 5 — 1 млн токенов входа, у линейки GPT-5.6 — около 1,05 млн. Миллион токенов — это порядка полутора-двух тысяч страниц обычного текста, так что большинство документов проходят одним куском.

Осторожно с русским: он токенизируется хуже английского, один и тот же текст занимает в 2–3 раза больше токенов. Как это считать и на чём экономить — в заметке про токены и лимиты.

Целиком в один запрос

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

Map-reduce: режем, пересказываем, склеиваем

Текст делится на куски, каждый пересказывается отдельно (стадия map), затем из полученных выжимок собирается финальный пересказ (стадия reduce). Google описывал эту схему как основной подход для длинных документов ещё до появления окон на миллион токенов; она остаётся полезной, когда документов много или когда куски можно обрабатывать параллельно — так быстрее.

Слабое место — стадия reduce: если в промежуточных выжимках потерялась деталь, финальный текст её уже не вернёт. Резать лучше по смысловым границам (главы, разделы, реплики спикеров), а не по числу символов.

Refine: пересказ, который дописывается

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

Чем пересказывать

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

NotebookLM от Google. Заточен ровно под эту задачу: загружаете источники и спрашиваете по ним. На бесплатном тарифе — до 100 блокнотов, до 50 источников в каждом, до 500 000 слов на источник и 50 запросов в чате в сутки. Главное достоинство — ответы со ссылками на конкретные фрагменты источника, что резко упрощает проверку.

Google AI Studio. Удобная песочница, чтобы подобрать промпт и сразу увидеть, во что он превращается в коде. Подробности — в заметке про AI Studio.

API. Единственный вариант, если пересказ нужен регулярно: письма, тикеты, звонки, новости. Здесь же появляется смысл в пакетной обработке — у Gemini батч-режим стоит вдвое дешевле обычного, и для ночной обработки очереди документов это прямая экономия.

Локальная модель. Если документы нельзя выпускать наружу, пересказ — одна из немногих задач, где небольшая локальная модель реально справляется: тут не нужны глубокие знания о мире, нужен аккуратный пересказ данного текста. Как поднять — в заметке про Ollama на своём сервере. Учтите, что контекстные окна у локальных моделей меньше, так что map-reduce вам почти наверняка понадобится.

Как проверять результат

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

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

Сверяйте цифры и имена руками. Именно они страдают чаще всего: суммы округляются, даты смещаются, фамилии путаются. Если в пересказе есть числа — проверьте каждое.

Отдельным запросом спросите, чего не хватает. «Вот документ, вот пересказ. Что важное в него не попало?» Второй проход с другой ролью ловит пропуски лучше, чем попытка сразу написать идеальный текст.

Задайте эталон. Если пересказы делаются потоком, соберите 5–10 примеров «как надо» и подкладывайте пару из них в промпт — приём разобран в заметке про few-shot и примеры в промпте. Это самый дешёвый способ зафиксировать стиль и уровень детализации.

Когда пересказ — не тот инструмент

Если задача звучит как «найти в архиве ответ на вопрос», пересказывать весь архив бессмысленно и дорого. Нужен поиск по документам с подстановкой найденных фрагментов в запрос — это RAG. Пересказ отвечает на вопрос «о чём этот документ», RAG — на вопрос «что в моих документах сказано про X». Их часто путают и строят громоздкую систему там, где хватило бы одного запроса, или наоборот — гоняют через модель гигабайты текста, когда нужен был поиск.

Коротко

Пересказ нейросетью — это не кнопка «сжать», а управляемая задача. Указывайте объём, аудиторию и слоты, которые нужно вытащить; разрешайте модели писать «не указано»; для длинных документов сначала проверяйте, влезает ли текст целиком, и только потом усложняйте схему до map-reduce или refine. И закладывайте проверку: цитаты к пунктам и ручная сверка цифр занимают пару минут, а спасают от решения, принятого по вымышленному факту.