Orchestra и проверяемая память из встреч
31 октября 2026
Orchestra превращает материалы встреч в структурированное знание с проверяемым происхождением. Главная инженерная задача — сохранить связь между утверждением, точной версией источника и решением о том, можно ли считать это утверждение текущим фактом. Этот кейс основан на статическом сопоставлении требований, ADR и кода на 31 октября 2026 года.
Проблема и границы
Расшифровки сохраняют разговор, но сами по себе плохо отвечают на вопросы о текущих обязательствах, решениях и изменениях. При последовательной обработке встреч ошибочное сопоставление сущности может попасть в контекст следующего шага и закрепиться. Исправление должно сохранять историю того, что извлекла модель и что позже решил человек.
Требования описывают более широкую платформу организационной памяти, решений и автоматизации. Подтверждённая здесь реализация — контур загрузки встреч, файловых артефактов, извлечения и согласования знаний, ручного review, поиска и веб-интерфейса. Реализация всей платформы, корпоративной изоляции арендаторов и независимых продуктовых runtime этим исследованием не подтверждается. Инструменты разработки и управления задачами не входят в описываемый runtime продукта.
Как проходят данные
- Адаптер сервиса транскрибации обнаруживает встречи и ставит загрузку в очередь. Версии расшифровок и производных документов хранятся как файловые артефакты с контрольными суммами; метаданные — в БД.
- Отдельный запуск обработки знаний создаёт источник и его ревизию, делит текст на части и запускает извлечение. Повторная обработка использует идентичность содержимого и конфигурации для переиспользования готовых результатов. Суммаризация имеет отдельный обработчик и сама не запускает извлечение онтологии.
- Модель возвращает находки и цитаты. Сервер проверяет точное вхождение цитаты в конкретной ревизии, вычисляет позиции и отклоняет отсутствующие или неоднозначные якоря. Совпадение цитаты подтверждает её происхождение; семантическая истинность требует дополнительных проверок.
- Реконсиляция разрешает сущности, отношения и временные состояния. Источники проходят её в установленном порядке, с checkpoint и контролем владения работой. Неразрешённые случаи получают отдельные состояния и review.
- Детерминированный materializer строит каноническую проекцию из выбранных результатов и решений. Для факта сохраняется цепочка
CanonicalFact → Assertion → Evidence → SourceRevision. Человеческие исправления имеют отдельное происхождение.
- Материалы встреч и версии источников
- Параллельное извлечение находок
- Проверка точных цитат
- Упорядоченное согласование и review
- Детерминированная каноническая проекция
- Интерфейс и чтение знаний
Подтверждённые компоненты и инфраструктура
| Область | Что подтверждают исходники |
|---|---|
| Приложение | Monorepo на TypeScript; Node.js 24, NestJS API, Next.js и React; общие контракты и Zod. REST-контроллеры сосуществуют с tRPC. |
| Исполнение | Очереди заданий в БД и обработчики внутри API; повторные попытки, восстановление, регулируемая параллельность. Effect runtime интегрирован с Nest DI и завершением приложения. |
| Хранилище | PostgreSQL через Prisma и драйвер pg; файловые артефакты; SQL-модель provenance и канонических фактов; PostgreSQL FTS. |
| Поиск | В контуре кандидатов подключены exact, alias/transliteration, FTS, graph и open-loop каналы. Векторный интерфейс этого контура отложен. Отдельный MCP-поиск встреч считает cosine similarity в приложении. |
| Модели | OpenAI-совместимый транспорт для извлечения и разрешения; фиксируемая конфигурация прогона; опциональная локальная стадия GLiNER с настраиваемым переходом к LLM. |
| Развёртывание | Compose описывает локальный PostgreSQL 18 с pgvector, постоянным томом и healthcheck. Для Python-сервисов GLiNER, нормализации имён и шлюза моделей есть launchd-шаблоны. Состояние запущенных сервисов не проверялось. |
Наличие pgvector в образе БД не доказывает работающий ANN-поиск в продукте. Исходники также не доказывают облачный production deployment, высокую доступность или эксплуатационный SLA.
Семь архитектурных решений
Первые четыре пункта — существующие ADR. Последние три — реконструкция архитектурного смысла спецификаций и кода для этого кейса; это не новые принятые ADR проекта.
ADR-1 — продукты поверх общего ядра
В требованиях принят набор отдельно поставляемых продуктов. Документированные альтернативы: единый продукт и open-core с marketplace. Цена выбранного подхода — межпродуктовые контракты и дисциплина версий. Это целевая архитектура, не доказательство реализации всего набора.
ADR-2 — онтология как версионируемый артефакт
Принят путь через Ontology IR и производные артефакты; хардкод и независимые OWL-файлы отвергнуты из-за дрейфа и ограничений эволюции. Цена — компилятор и управление версиями. В коде подтверждены общий TS-реестр, hash и компиляция extraction prompt; полный Studio и весь заявленный набор генераторов не подтверждены.
ADR-004 — отдельная модель происхождения знаний
Бизнес-сущности отделены от Assertion, Evidence, ревизий и поколений извлечения. Исправление добавляет решение вместо переписывания истории. Документированный компромисс: прослеживаемость и переизвлечение требуют дополнительных таблиц, указателей текущих версий и materializer. Ключевые части подтверждены кодом.
ADR-005 — явные состояния жизненного цикла
Отмена задачи и снятие вопроса выражаются отдельными состояниями; уточняются ограничения отношений. В MVP один флаг обслуживает OWL и политику текущего значения. Разделение этих механизмов явно отложено; это документированное упрощение. Изменения реестра подтверждены кодом.
Реконструкция R1 — параллельное извлечение и упорядоченное согласование
Фаза извлечения допускает независимые задания; после барьера запускается согласование с порядком источников. Интерпретация компромисса: параллелизм ускоряет независимую работу, а последовательный участок ограничивает пропускную способность ради управляемой причинности. Полностью параллельный commit — аналитическая альтернатива, а не найденное решение команды.
Реконструкция R2 — восстановление с checkpoint и fencing
Переходы состояния используют compare-and-swap; запись с lease проверяет владельца, токен и срок действия в самом условии изменения. Интерпретация: надёжность при повторных и устаревших worker оплачивается сложностью состояний и обработки потери lease. Простая блокировка только в памяти — аналитическая альтернатива.
Реконструкция R3 — PostgreSQL и локальный контейнерный контур
Спецификация явно выбирает контейнер вместо нативной установки ради воспроизводимости; код подтверждает PostgreSQL без SQLite fallback. Эксплуатация сервера и миграций сложнее файловой БД — аналитическая оценка цены решения. Заявленные в требованиях поисковые расширения нельзя автоматически считать подключёнными возможностями.
Проверки качества и evaluation
В репозитории есть единая команда проверки policy, lint, типов, инструментированных тестов, coverage, acceptance, сборки и browser e2e. Описаны тесты точных и неоднозначных evidence anchors, повторного якорения, детерминизма materializer, изоляции теневой сборки и потери lease. В рамках этого разбора они не запускались; текущий статус прохождения не заявляется.
Контракты evaluation задают покрытие источников, exact match доказательств, прослеживаемость фактов, отсутствие утечки будущего, детерминизм и идемпотентность. Агрегатор различает провал и отсутствие измерения: критический неизмеренный показатель блокирует положительный вердикт. Часть прежних gold-based метрик удалена из активного списка; есть вычисление recall@k относительно переданных решений о соответствии. Это инструменты оценки, а не опубликованные результаты независимого benchmark.
Что этот кейс позволяет утверждать
Код демонстрирует работу с контрактами LLM, версионированием данных, provenance, согласованием сущностей, восстановлением заданий и проверяемыми инвариантами качества. Эти темы подходят для инженерного портфолио и обсуждения оценки AI-систем.
Не подтверждены измеренные показатели точности и скорости, объём production-нагрузки, полнота реализации требований и индивидуальное авторство решений. Кейс описывает систему и не приписывает одному человеку весь дизайн или код. Персональное описание вклада требует отдельного подтверждения владельцем проекта.