Сжатие и выжимка

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

Когда использовать

• Пользователь просит «сократи», «выжимку», «перескажи», «главное», «too long; didn't read»
• Присылает ссылку на длинную статью, отчёт или документ
• Сбрасывает лог переписки, тред, транскрипт встречи и просит итог
• Хочет быстро понять, стоит ли читать полный текст
• Нужна выжимка для решения: «что из этого следует делать»

Инструменты

web_reader

Чтение полного текста статьи или документа по URL — основной инструмент для источников-ссылок.

Когда применять: пользователь дал URL и просит сокращение. Сначала web_reader, потом сжатие. Параметр return_format="markdown" сохраняет структуру (заголовки, списки), что помогает иерархическому сжатию.

web_search

Проверка и уточнение фактов из источника в runtime.

Когда применять: в тексте встретилась незнакомая цифра, имя, дата или термин и есть сомнение в трактовке — ищи подтверждение через web_search(query="..."), прежде чем включать в выжимку. Также для контекста: если статья отсылает к событию, краткий поиск поможет понять значимость.

code_execution

Обработка очень длинных текстов, которые не помещаются в один проход.

Когда применять: документ длиннее ~15 000 слов — разбей на чанки, посчитай частоты, извлек top-k предложений экстрактивно (по TF-IDF или похожести на «идеальное предложение»). Map-Reduce и двухэтапный pipeline реализуются здесь. См. METHODS.md.

image_analysis

Извлечение содержания из скриншотов, инфографики, слайдов, диаграмм, сканов.

Когда применять: источник — изображение (скриншот треда, фото слайда, инфографика) или в документе есть ключевые диаграммы. Опиши изображение через image_analysis, затем включи данные в общую выжимку.

Определение типа задачи

Перед сжатием определи тип — от него зависит метод:

Тип	Признаки	Метод
Короткий текст	< ~2000 слов, помещается в контекст целиком	Однопроходное абстрактивное сжатие
Длинный документ	Отчёт, регламент, книга, статья > ~3000 слов	Map-Reduce / иерархическое (см. METHODS.md)
Встреча или тред	Переписка, транскрипт, лог чата со спикерами	Извлечение решений + action items с владельцами
Статья под решение	Пользователь читает, чтобы сделать выбор	Decision-формат: вывод → что делать → неопределённость

Также уточни цель формата у пользователя, если она не очевидна: «прочитать за 1 минуту» (TL;DR), «выжимка для решения» (тезисы + действие), «только action items» (чеклист). Не угадывай — один уточняющий вопрос лучше неправильного формата.

Workflow

Короткий текст

1. Прочитай источник полностью за один проход.
2. Определи главное утверждение (о чём текст, зачем написан).
3. Сформируй выжимку абстрактивно — своими словами, короче оригинала.
4. Проверь: каждое утверждение в выжимке опирается на оригинал (см. «Точность»).

Длинный документ

Используй Map-Reduce (для текстов, не помещающихся в контекст) или иерархическое сжатие (для структурированных документов с секциями).

1. Map: разбей документ на чанки по смыслу (абзацы, секции, ~800–1500 слов). Сожми каждый чанк отдельно в 3–5 предложений.
2. Reduce: объединить выжимки чанков в общую выжимку. Если объединение снова длинное — повтори (двухуровневый reduce).
3. Иерархический вариант: если у документа есть заголовки секций — сожми каждую секцию, затем сведи выжимки секций в общую.

Подробная процедура и псевдокод — в METHODS.md.

Встреча или тред

1. Определи список участников (спикеров).
2. Раздели содержание на три блока: решения (что постановили), обсуждение (за/против, нюансы), action items (кто что делает).
3. Action items оформи с владельцем и сроком: - [ ] Сделать X — @Имя — до пятницы.
4. Если срок или владелец не названы явно — отметь как неопределённые: «владелец не указан». Не придумывай.

Статья под решение

1. Сформулируй главный вывод автора в одном предложении.
2. Выдели 3–5 ключевых аргументов буллетами.
3. Блок «что это значит для тебя» — интерпретация в контексте задачи пользователя.
4. Блок «в чём автор не уверен» — оговорки, допущения, нерешённые вопросы.

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

Комбинируй блоки под запрос. Не выводи всё всегда — только то, что просили.

TL;DR — 1–3 предложения. О чём источник и главный вывод. Для «понять за 10 секунд».

Ключевые тезисы — буллеты, 4–8 пунктов. Каждый тезис — одна законченная мысль, с опорой на источник.

Action items — чеклист с владельцем и сроком:

- [ ] Подготовить отчёт — @Анна — до 15 июля
- [ ] Согласовать бюджет с финансами — @Игорь — до среды
- [ ] Вернуться с предложением по pricing — владелец не указан

«Что это значит для тебя» — 1–2 предложения. Практическая интерпретация: какое решение принимает пользователь, что меняется.

Точность и достоверность

Это приоритет №1. Сжатие, которое искажает, хуже бесполезного.

• Не искажай. Каждое утверждение в выжимке должно быть выводимым из оригинала. Если сомневаешься — не включай или пометь «требует проверки».
• Цитаты — в кавычках. Прямую речь и формулировки автора бери дословно в кавычки («как написал автор»). Не маскируй пересказ под цитату.
• Цифры, имена, даты — дословно. Не округляй «47%» до «около половины», не меняй «1,2 млрд» на «миллиард». При переформулировке сохрани точное значение.
• Разделяй факты и мнения. Помечай, где автор излагает факт, а где — оценку. «По мнению автора...» / «В отчёте указано...».
• Отмечай источники. Если сжимаешь статью — укажи, откуда она (автор, издание, дата). Если факт из текста отсылает к исследованию — передай эту отсылку.

Частые ошибки и как их избегать

Ошибка	Как избегать
Галлюцинации — добавил факт, которого не было в источнике	После написания выжимки сверяй каждое утверждение с оригиналом. Если не можешь найти источник фразы в тексте — удали её
Потеря нюансов — выкинул «однако», «при условии», «в среднем»	Сохраняй ограничивающие слова и условия. «Выручка выросла на 20%» ≠ «выручка выросла на 20% при условии...» — разница принципиальна
Слишком длинная выжимка — не сжатие, а пересказ	Ставь жёсткий лимит: TL;DR — до 3 предложений, тезисы — до 8 буллетов. Если не укладываешься — сжимай дальше
Пропуск action items и владельцев (встречи/треды)	Обрабатывай встречу/тред отдельным проходом с единственной целью — найти «кто что делает». Владельца и срок выноси явно
Смешение фактов и мнений автора	Помечай мнения словами «по мнению», «автор считает». Факт — без такой пометки, но с указанием источника внутри текста
Игнорирование запрошенного формата (просили буллеты — выдал абзац)	Перед ответом перечитай запрос пользователя. Формат — часть задания. Если формат не указан — спроси или используй TL;DR + тезисы по умолчанию
Искажение цифр при переформулировке	Цифры переноси дословно, без округления и преобразования единиц, если пользователь не просил. «47%» оставляй «47%»

Примеры

Сокращение статьи по ссылке

Пользователь: Сократи эту статью, нет времени читать: [URL]
Агент: [читает через web_reader]
       TL;DR: Автор доказывает, что удалённый формат снизил
       продуктивность R&D-команд на 15–20% из-за потери
       случайных обсуждений, и предлагает гибридную модель.

       Ключевые тезисы:
       • Исследование Stanford (2024) — патентные заявки
         удалённых команд на 15–20% слабее
       • Главная потеря — «коридорные» exchanges идей
       • Гибрид 3+2 восстанавливает 80% случайных контактов
       • Автор признаёт: данные из tech-сектора, не универсальны

       Что это значит для тебя: если у тебя R&D/креативная команда —
       имеет смысл вернуть 2–3 дня в офисе. Для рутинных задач
       разница незначительна.

       Источник: N. Bloom et al., Stanford WFH Study, 2024.

Выжимка встречи

Пользователь: Вот транскрипт планёрки. Что постановили?
               [текст транскрипта]
Агент: Решения:
       • Бюджет на Q3 утверждён в размере 4,8 млн ₽
       • Запуск фичи переносится с 1 на 15 августа
       • Нанимаем двух разработчиков (junior)

       Action items:
       - [ ] Открыть вакансии — @Мария (HR) — до пятницы
       - [ ] Пересчитать roadmap с новой датой — @Денис — до среды
       - [ ] Согласовать 4,8 млн с финдиректором — @Олег — срок не назван

       Открытые вопросы (не решены):
       • Будет ли премия за досрочный релиз — отложено

Сокращение длинного треда

Пользователь: 80 сообщений в рабочем чате про выбор CRM.
               Кто что предлагал и к чему пришли?
Агент: [обрабатывает тред]
       TL;DR: Спорили между Bitrix24, amoCRM и HubSpot.
       К консенсусу не пришли — разбились на два лагеря.

       Позиции:
       • @Антон, @Лена — за amoCRM: проще, дешевле для старта
       • @Игорь, @Олег — за Bitrix24: больше функций под нас
       • HubSpot отмели на старте — дорого для нашего масштаба

       Action items:
       - [ ] Собрать демо amoCRM и Bitrix24 — @Лена — до пятницы
       - [ ] Сравнить стоимости на 10 юзеров — @Игорь — до среды

Правила

• Сначала тип задачи, потом метод — не сжимай длинный документ как короткий текст.
• Цель формата — из запроса; если не ясна, задай один уточняющий вопрос.
• Точность важнее краткости: лучше длиннее, но без искажений.
• Цифры, имена, даты — дословно, без округления.
• Цитаты в кавычках, мнения помечены, факты — с указанием источника.
• Для встреч и тредов — action items с владельцем и сроком всегда.
• После выжимки сверяй утверждения с оригиналом — удаляй то, чему нет подтверждения.
• Соблюдай запрошенный формат: буллеты — значит буллеты.
• Длинный документ → Map-Reduce или иерархическое сжатие (см. METHODS.md).
• Если источник — изображение или содержит диаграммы — используй image_analysis.