# Contextum: меньше токенов и выше пропускная способность агента

Contextum переводит документы в Markdown и сжимает контекст: агент тратит меньше токенов, пропускная способность выше. Реестр потерь, Go и .NET, Docker.

> For the index of this section of the site, see [llms.txt](https://anetlab.ru/llms.txt)

POCЛицензия: По запросу

# Contextum

Документы в Markdown для AI-агентов: сжатие и реестр потерь

Модель читает не документ, а текст, который из него получился. Contextum отдаёт этот текст вместе со списком того, что по дороге потерялось, — потерю видно до того, как ответ уйдёт клиенту.

## Что это

Contextum — сервис, который готовит документы к работе с LLM. Он принимает файл, превращает его в Markdown, ужимает содержимое до размера контекстного окна и отдаёт результат вместе со списком того, что при переносе не выразилось.

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

## Кому это нужно

Тем, кто строит агента поверх документов: договоров, технических заданий, счетов, регламентов, отчётности.

Покупатель — организация, а не разработчик-одиночка: продукт B2B. Типичные покупатели:

*   компания с работающим LLM-контуром, где документы до модели доходят строкой;
*   компания, которая LLM-контур строит;
*   ИИ-провайдер, который бустит платформу и отдаёт доступ своим пользователям;
*   ИИ-портальное приложение или внутренний ИИ-проект, где идёт работа с документами.

Картина обычно выглядит так: агент получает PDF, библиотека возвращает строку, и строка выглядит осмысленной. Всё, чего Markdown не умеет — таблицы, объединённые ячейки, цвет, подчёркивание, над- и подстрочность, диаграммы, векторные картинки, — исчезает молча. Ошибку находят позже: в ответе, который уже ушёл клиенту, или в заявке, что из договора выпала часть условий. Проверять такие ответы вручную дорого, а обнаружить потерю задним числом почти невозможно.

Contextum меняет три вещи:

*   **Результат можно проверить.** Реестр потерь приходит вместе с конвертацией: видно, что именно не выразилось, а не только то, что получилось.
*   **Длинный документ влезает в окно.** Сжатие ужимает текст по правилам стратегии, а экономия считается на вашем же корпусе: цифра приходит из замера, а не из примера в документации.
*   **Агент не подвисает.** Конвертация CPU-ёмкая и уходит в отдельный сервис: вызовы моделей не ждут конца рендера.

## Как это работает

graph TD
  U\[Пользователь\] --> A\[AI-агент\]
  A -->|файл| G\[Contextum\]
  G --> C\[CONVERT\]
  C --> S\[COMPRESS\]
  S -->|артефакты| A
  A -->|контекст| L\[LLM\]
  G -.-> E\[EMBED/INDEX/VAULT\]
  classDef accent fill:#eef7f0,stroke:#008A2A,stroke-width:1.5px,color:#141616
  classDef muted fill:#f7f8f8,stroke:#c8cdcd,stroke-width:1px,color:#505757
  class G accent
  class U,L,E muted

Схема 01Путь документа от агента к модели

Путь файла: агент отдаёт его в шлюз Contextum → CONVERT переводит документ в Markdown → COMPRESS сжимает текст и режет на чанки → артефакты возвращаются в агент → агент кладёт их в контекст модели. Реестр потерь приезжает с конвертацией: он есть в результате конвертера и в логе рабочего процесса. От шлюза отходят три остальные стадии — EMBED, INDEX и VAULT; сегодня это заглушки: выполняются, но не делают заявленного.

Рендер страниц, разбор таблиц и построение Markdown живут в отдельных процессах, шлюз держит состояние заданий. Между шлюзом и процессами — gRPC по protobuf-контракту, один источник правды для Go и .NET.

Отличить заглушку от настоящей стадии можно прямо в ответе: процесс возвращает `simulated = true`, и по этой метке интегратор знает, чем можно пользоваться как источником истины.

## Что входит

|  | Значение |
| --- | --- |
| Вход | PDF, DOCX, XLSX, PPTX, Markdown, HTML, текст — до 64 МиБ |
| Выход | GFM Markdown, сжатый Markdown, чанки; артефакты `converted.md` и `compressed.md` — из настоящих стадий, `embeddings.manifest.md`, `index-receipt.md` и `vault-article.md` — из стадий-симуляторов |
| Транспорт | HTTP к шлюзу, gRPC с protobuf-контрактом к рабочим процессам |
| Развёртывание | Go и .NET, Docker, NATS JetStream, Postgres, Redis |

Реестр потерь виден в ответе конвертера (`POST /api/v1/convert`) и перечисляет, что не выразилось: цвет, шрифт, подчёркивание, над- и подстрочность, выравнивание, объединённые ячейки, диаграммы, векторные картинки. То, что отключено опцией — например, формулы при `includeCellFormulas = false`, — потерей не считается: это выбор пользователя, а не дефект конвертации.

PPTX конвертируется в диалект MARP, где выражается больше, чем в GFM: цвет фона слайда, фоновая картинка, цвет текста, размер колоды. Презентация теряет меньше, и это свойство формата, а не недосмотр.

## Сценарии применения

*   **Договоры и спецификации.** Агент отвечает на вопросы по загруженному договору, а получатель видит, какие элементы форматирования в ответ не попали.
*   **Техническая документация.** DOCX и PDF превращаются в Markdown, пригодный и для базы знаний, и для показа человеку.
*   **Таблицы и отчётность.** XLSX → Markdown, дальше — в RAG-конвейер или в аналитику агента.
*   **Презентации.** PPTX → MARP: слайды сохраняют больше оформления, чем документы.

## Что измерено

Замер и оценка в продукте разведены, и по цифрам это видно:

*   **Байты, длительность стадии, число чанков** — факты.
*   **Токены** — оценка по длине текста («1 токен ≈ 4 символа»), а не токенизация модели. Для прикидки «сколько контекста съест агент» полезно, для точного биллинга — нет.
*   **Экономию заявляет только стадия сжатия.** Сводка берётся из результата последней измеренной стадии, а не как максимум по стадиям.

Проценты экономии мы не публикуем, пока нет замера на реальном корпусе: пример в документации — это пример, а не измерение. Разбор метрик подробнее — в [разборе продукта](https://anetlab.ru/blog/contextum-document-pipeline.md).

## Кейсы

Боевых внедрений Contextum пока нет: продукт в статусе POC, публичных релизов не было, и продавать его как проверенное решение было бы враньём. Что есть — измерения, публичный разбор архитектуры и реестра потерь в блоге и в документации продукта.

Ближайший опыт команды в том же классе задач — SaaS «До подписи»: AI-аудит договоров, где загруженный PDF разбирается и превращается в список рисков. Это другой продукт, он в [«Портфолио»](https://anetlab.ru/projects.md), но показывает, что такие вещи мы доводим до продакшна.

## Честно о границах

Список ограничений — часть продукта, а не сноска. Он отвечает на вопрос «можно ли встраивать уже сейчас», и по части пунктов ответ «нет».

*   **Распознавания нет.** OCR и страницы-сканы не заявлены: в контракте нет ни движка распознавания, ни вида потери `ocr`.
*   **Якоря страниц PDF — вид потери, а не фича.** В исходном PDF якоря есть, в Markdown они могут не выразиться. Но мы работаем над этим.
*   **Прогресс — только polling.** Вебхуков и SSE нет. В дорожной карте.
*   **Автоматической очистки артефактов нет** — TTL-сборщик нужен на стороне интегратора.
*   **Один процесс — одна роль.** Вертикального масштабирования нет.
*   **Размерность вектора и модель эмбеддингов не выбраны.** В настоящее время, мы тестируем несколько моделей одновременно и делая замеры и проверки.

## Для кого

Contextum - это B2B-продукт, и покупают его там, где LLM-контур уже есть или строится. Общий знаменатель всех покупателей — нужен отдельный сервис конвертации и сжатия: с реестром потерь, с метриками из замера, с масштабированием отдельно от оркестратора. Там, где задача разовая — прогнать один файл, — сервис не нужен.

## Связанные материалы

*   [Партнёры: совместный продукт с Office Doc](https://anetlab.ru/partners.md)
*   [Contextum: конвейер документов в Markdown для AI-агента](https://anetlab.ru/blog/contextum-document-pipeline.md)
*   [Собираем RAG-пайплайн на .NET: практический разбор](https://anetlab.ru/blog/rag-pipeline-dotnet.md)
*   [RAG на .NET: архитектура, которая переживает продакшн](https://anetlab.ru/blog/rag-na-dotnet.md)
*   [Production RAG: чек-лист из 50 пунктов для продакшна](https://anetlab.ru/blog/production-rag-checklist.md)

## CTA

Разбираете, как встроить слой документов в агентскую систему, — [напишите нам](https://anetlab.ru/contact.md). Посмотрим, какие стадии вам действительно нужны, какие ограничения критичны для вашего контура и как это ложится рядом с оркестрацией. Пока продукт в статусе POC, договариваться будем о том, что он делает и чего не делает.

FAQ

## Частые вопросы

Можно ли развернуть это в нашем контуре?+

Да. Go и .NET, Docker, NATS JetStream, Postgres, Redis — всё живёт в вашей сети, документы наружу не уходят. Оговорка: аутентификации и TLS нет, поэтому гейтвей ставится только внутри доверенной сети или за своим аутентифицирующим обратным прокси.

Что происходит с форматированием документа?+

Markdown выражает не всё: цвет, подчёркивание, над- и подстрочность, выравнивание, объединённые ячейки, диаграммы и векторные картинки могут не выразиться. Всё, что не выразилось, попадает в реестр потерь. То, что отключено опцией — например, формулы при includeCellFormulas = false, — потерей не считается.

Какие форматы принимаются?+

PDF, DOCX, XLSX, PPTX, Markdown, HTML и текст, до 64 МиБ. PPTX конвертируется в диалект MARP, где выражается больше, чем в GFM.

Можно ли встроить это в прод прямо сейчас?+

Как слой конвертации и сжатия — да. Эмбеддинги, векторный индекс и запись в базу знаний сегодня заглушки: они выполняются, но не делают заявленного, и в ответе помечены флагом simulated = true. Плюс нет аутентификации, распознавания и автоматической очистки артефактов.

Сколько это стоит?+

Лицензия — по запросу. Условия и цена обсуждаются под ваш контур.