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

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

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

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

Что входит

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

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

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

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

Что измерено

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

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

Проценты экономии мы не публикуем, пока нет замера на реальном корпусе: пример в документации — это пример, а не измерение. Разбор метрик подробнее — в разборе продукта.

Кейсы

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

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

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

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

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

Для кого

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

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

• Партнёры: совместный продукт с Office Doc
• Contextum: конвейер документов в Markdown для AI-агента
• Собираем RAG-пайплайн на .NET: практический разбор
• RAG на .NET: архитектура, которая переживает продакшн
• Production RAG: чек-лист из 50 пунктов для продакшна

CTA

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