Kenes AI

Из совещания в протокол: кто делает, что и к какому сроку

Русский · Қазақша · Смешанная речь

HackAlem AI · команда 01husky

Для жюри · Демо Видео · Возможности · Попробовать · Разработчикам и ИИ

Секретарь проверяет поручения по исходным репликам, уточняет ответственных и утверждает протокол. Исполнители получают задачи, руководитель видит сроки и статус работы.

Демо Видео

https://github.com/user-attachments/assets/8aec9702-6772-4f75-bc86-cb9ea3ab2fc2

Смотреть на Google Drive · Скачать MP4 · 44 с · 1080p.

_{Обзор сценария: от записи совещания до проверки протокола и контроля поручений.}

Для жюри

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

Возможности

_{Интерфейс показан на демонстрационных данных. Модели в этих записях не запускаются; готовность компонентов описана в разделе «Что готово».}

От записи встречи до выполненного поручения. Демонстрации охватывают 13 пунктов функциональных требований, а также выбор источника записи, саммари и контроль сроков.

Запись · Языки · Проверка · Документы · Исполнение · Данные и голос

01. Добавьте запись совещания

Файл, микрофон или бот во встрече

При создании совещания выберите источник: готовый файл, запись с микрофона или ссылку на Meet, Zoom, Teams. В ролике показан выбор режима. Для подключения бота нужен допуск организатора; ограничения платформ перечислены в разделе «Что готово».

Загрузка и этапы обработки

Загрузите аудио и проследите путь до транскрипта. В этой записи стадии и готовый текст возвращает деморежим.

02. Проверьте смысл на обоих языках

Русский

Нажмите цитату в поручении Динары: в транскрипте подсветится исходная реплика. Рядом видны исполнитель и дата.

Қазақша

Поручение Айбека связано с казахской репликой. Формулировку срока «ертеңге дейін» можно сверить с календарной датой.

Переключение языка внутри фразы

Откройте реплики с отметкой RU + KZ и проверьте контекст целиком. Языковые примеры в этих GIF взяты из готового демотранскрипта; по ним нельзя оценивать точность распознавания.

03. Проверьте черновик перед утверждением

Поручение, ответственный и календарный срок

Сверьте задачу с цитатой, проверьте исполнителя и откройте календарь. «До пятницы» требует конкретной даты. Локальная модель формирует черновик поручений для проверки секретарём. В этой записи использован заранее подготовленный пример.

Кто говорил и кто отвечает

Назначьте Тимура для несопоставленного спикера. Автор реплики и исполнитель поручения могут быть разными людьми, поэтому их можно проверить отдельно.

Саммари совещания

Откройте краткое содержание и отредактируйте формулировку перед выпуском протокола. В деморежиме исходное саммари подготовлено заранее.

Утверждение секретарём

Уточните ответственного, подтвердите протокол и проверьте уведомления. Ролик объединяет эти действия в один сценарий.

04. Передайте результат участникам

PDF и DOCX на нужном языке

Выберите язык документа и формат выгрузки. В записи используются демонстрационные файлы; образец PDF и DOCX отдельно сформированы рабочим backend-экспортом из примера про склад.

Передача в СЭД

Отправьте утверждённый протокол и получите регистрационный номер. В демонстрации используется имитация СЭД. Для внедрения потребуется адаптер системы документооборота организации.

05. Следите за выполнением

Статусы и доска поручений

Отфильтруйте задачи в работе, отметьте завершённую и перейдите на доску. Счётчики отражают изменение статуса.

Срочность и направление

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

Уведомления с поручениями

После утверждения откройте уведомление и перейдите к задачам. В записи показаны уведомления внутри приложения на демоданных.

Ближайшие сроки и просрочка

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

06. Управляйте данными и участниками

Голосовой эталон участника

Откройте карточку участника и запишите эталон. API и интерфейс записи готовы; распознавание личности по тембру ещё не подключено. В GIF используется тестовый микрофон.

Локальные модели и удаление аудио

Посмотрите сведения о моделях и удалите исходное аудио, сохранив транскрипт. Ролик показывает управление записью; условия закрытого контура и текущие ограничения описаны в разделе «On-premise и приватность».

Режим записи и ограничения каждого ролика · Статичные экраны и тёмная тема

Попробовать за минуту

Интерфейс запускается без backend и ML-моделей. Нужны Node.js 20+ и pnpm:

cd frontend
pnpm install
pnpm mock

Откройте http://localhost:3000. Вход: [email protected], пароль любой. Данные хранятся в браузере; ?reset-mocks в адресе сбрасывает их к исходному состоянию.

Запуск полного стека описан в разделе «Запуск».

Развитие после хакатона

Первый пилот: секретарь и одна команда в организации с двуязычными совещаниями. На согласованных записях нужно проверить точность поручений и сроков, число ручных исправлений и время подготовки протокола. Измеренных показателей экономии времени пока нет.

Разделение API, очереди и ML-библиотеки даёт основу для этих изменений. Масштабирование ещё требует нагрузочных проверок. Для новых организаций понадобятся отдельная проверка изоляции данных и настройка интеграций.

Вопросы о продукте

Что подтверждают эти демонстрации? Видеоролик объясняет сценарий продукта, записи интерфейса показывают действия пользователя на демонстрационных данных. Реальный локальный пайплайн формирует транскрипт, метки спикеров, черновики поручений и саммари. Сервер сохраняет результат, правки и утверждение, формирует документы.

В чём преимущество такого подхода? Секретарь проверяет поручение рядом с исходной цитатой, различает автора реплики и исполнителя, уточняет календарный срок. После утверждения работа продолжается в списке задач и на доске. Специализацию на RU/KK и локальной обработке нужно подтвердить пилотом; сравнительного исследования конкурентов пока нет.

Можно ли доверять поручению без проверки? Черновик проверяет секретарь до утверждения. Цитата и ссылка на реплику помогают обнаружить неверное имя или срок. Локальная модель уже формирует черновики, но может пропускать поручения или создавать смысловые дубликаты. Проверку секретарём сохраняем до утверждения.

Что нужно для внедрения? Оценить качество извлечения на записях организации, проверить полный on-premise запуск, подключить СЭД организации и провести пилот на её записях. Требования к гостевому входу бота зависят от платформы и допуска организатора.

Пример протокола

Смоделированное совещание, 23 сентября 2026 года. Команда обсуждает бюджет и запуск склада. В одной реплике участники переключаются между русским и казахским:

[00:14] Серик: «Айбек, подготовь обновлённую смету по складу до пятницы. Керек болса, Данамен бірге отырыңдар.»

[00:22] Айбек: «Жақсы, пятницаға дейін жасаймын. Данамен бүгін кездесемін.»

Секретарь получает черновик с поручениями. Относительные сроки («до пятницы», «бүгін») пересчитаны в даты от дня встречи:

Каждое поручение хранит цитату и номер реплики, поэтому его можно сверить с исходным контекстом. После подтверждения секретарь скачивает протокол, а ответственные получают уведомления. В PDF входят саммари, таблица поручений и приложение с репликами по спикерам.

Происхождение примера. Данные взяты из детерминированной фикстуры pipeline.fake, участники вымышлены. DOCX/PDF сформированы рабочим сервисом экспорта backend. Пример показывает формат протокола и связь данных; качество моделей на нём не измерялось. Как пересобрать образец.

Что готово

Реальный пайплайн возвращает транскрипт, метки speaker1, speaker2, поручения-черновики и саммари. Явная передача слова или самопредставление может связать голос с именем (источник llm, не голосовой эталон). Неоднозначные имена остаются для ручной привязки; порядок списка участников не используется. Коррекция коротких сдвигов границы спикера уменьшает разрывы внутри предложения, но не гарантирует точность диаризации. Извлечение может пропускать поручения или оставлять смысловые дубликаты.

Для разработчиков и ИИ-агентов

Архитектура · Стек · Запуск · API · Приватность · Тесты · Структура репозитория · Сценарий защиты

Начните с текущего статуса и спецификации контрактов. Инструкции модулей: frontend, backend, pipeline, bots.

Записи интерфейса. Режим pnpm mock, встроенные демонстрационные данные; backend и модели в записи не запускались. Версия приложения и методика записи, метаданные отдельных сценариев.

Архитектура

flowchart LR
    subgraph Источники
        W[Браузер<br/>файл · микрофон]
        B[Бот Playwright<br/>Meet · Zoom · Teams]
    end
    W -->|REST / WebSocket| API
    B -->|POST /meetings/id/audio<br/>токен одной встречи| API
    API[FastAPI api<br/>auth · meetings · tasks<br/>participants · export] -->|Celery / Redis| WK
    API <--> DB[(PostgreSQL)]
    subgraph WK[worker: pipeline.process]
        direction TB
        S1[Whisper STT] --> S2[Диаризация] --> S3[Маскирование<br/>ИИН / телефонов] --> S4[Поручения + саммари<br/>Qwen3:8b · Ollama]
    end
    WK -->|MeetingResult| DB
    BEAT[beat: check_deadlines<br/>каждый час] --> DB
    API --> EXP[DOCX / PDF · СЭД]

Все модели работают внутри контура: faster-whisper, sherpa-onnx и Ollama. Веса скачиваются заранее отдельным шагом, без аудио и текста.

Поток данных: запись → data/audio/<id>/audio.wav (ffmpeg, 16 kHz mono) → Celery process_meeting → pipeline.process() возвращает MeetingResult (контракт) → сегменты, карта спикеров, черновики поручений и саммари сохраняются в БД → секретарь проверяет → «Подтвердить протокол» → уведомления ответственным, экспорт DOCX/PDF, отправка в СЭД → beat следит за сроками.

Границы модулей:

• pipeline/: библиотека без веб-сервера и БД. Функция process(audio_path, meeting_date, participants, directions, output_language, progress) -> MeetingResult. PIPELINE_FAKE=1 подменяет её детерминированной заглушкой, поэтому backend и frontend работают без ML-моделей.
• backend/: FastAPI + Celery. Хранение, API, экспорт, уведомления, СЭД. Пайплайн вызывается как библиотека.
• frontend/: Next.js, обращается только к REST API.
• bots/: отдельный процесс в изолированном контейнере. Загружает запись с временным токеном конкретной встречи.

Стек

Запуск

Docker Compose

Нужен Docker с Compose v2. LLM по умолчанию: qwen3:8b; локальный запуск проверен на Mac с 16 ГБ RAM. Подготовка весов, приватность и ограничения описаны в локальной LLM.

cp .env.example .env        # затем замените SECRET_KEY случайным значением
docker compose up -d --build

При старте сервис api применяет миграции и загружает справочники и демо-участников. Сервисы worker и beat ждут его healthcheck.

• Swagger: http://localhost:8000/docs
• Просмотр таблиц БД: http://localhost:8000/admin
• Вход: [email protected] / admin123
• Frontend запускается отдельно: cd frontend && pnpm install && pnpm dev, затем http://localhost:3000

По умолчанию Compose работает с PIPELINE_FAKE=1: результат детерминированный, ML-модели не нужны. Образ worker с ML-зависимостями и томом весов пока не собран. Настоящее распознавание проверено при локальном запуске без Docker.

Для подготовки LLM внутри контейнера: docker compose exec ollama ollama pull qwen3:8b. Веса скачиваются заранее; обработка не обращается к облачным моделям.

Локально с настоящим Whisper (macOS)

Проверенная инструкция: docs/local-development.md. Скрипт поднимает отдельные PostgreSQL и Redis, генерирует пароли и запускает API с Celery. Модели диаризации описаны в docs/local-diarization.md.

brew install postgresql@16 redis ffmpeg uv
uv sync --project backend --extra stt
backend/.venv/bin/python scripts/local_dev.py setup

Реальный пайплайн также требует запущенную Ollama с подготовленной Qwen3:8b: инструкция локальной LLM. Без модели обработка возвращает явную ошибку.

createuser -P protocol        # пароль protocol
createdb -O protocol protocol
createdb -O protocol protocol_test

cp .env.example .env
# в .env замените хосты на localhost:
#   DATABASE_URL=postgresql+psycopg://protocol:protocol@localhost:5432/protocol
#   REDIS_URL=redis://localhost:6379/0
#   OLLAMA_URL=http://localhost:11434
#   удалите DATA_DIR и OUTBOX_DIR (будут использованы значения внутри backend/)
cd backend
uv sync
uv run alembic upgrade head
uv run python -m app.seed
uv run uvicorn app.main:app --reload --port 8000

cd backend && uv run celery -A app.tasks.celery_app:celery_app worker --loglevel=info

cd backend && uv run celery -A app.tasks.celery_app:celery_app beat --loglevel=info

cd pipeline
uv sync --extra stt
PIPELINE_FAKE=0 uv run python -m pipeline.cli /path/to/meeting.m4a --date 2026-09-23

Сценарий демо

Четыре минуты на защиту. Сюжет: поручение Айбеку о смете проходит путь от исходной фразы до протокола и уведомления.

API=http://localhost:8000/api/v1
curl -s $API/health

# тестовое аудио: любой файл или сгенерированный тон
ffmpeg -y -f lavfi -i "sine=frequency=440:duration=5" -ac 1 -ar 16000 sample.wav

# логин, cookie в файл
curl -s -c c.txt -X POST $API/auth/login -H 'Content-Type: application/json' \
  -d '{"email":"[email protected]","password":"[скрыто]"}'

# участники и направления из seed
curl -s -b c.txt $API/participants | python3 -m json.tool | head -30
curl -s -b c.txt $API/directions

# голосовой эталон первому участнику
PID=$(curl -s -b c.txt $API/participants | python3 -c 'import json,sys; print(json.load(sys.stdin)[0]["id"])')
curl -s -b c.txt -X POST $API/participants/$PID/voiceprint -F "[email protected]"

# совещание из файла (PIPELINE_FAKE=1 обрабатывает мгновенно, иначе смотрите status/progress_pct)
MID=$(curl -s -b c.txt -X POST $API/meetings \
  -F title="Оперативное совещание" -F meeting_date=2026-09-23 \
  -F participant_ids=$PID -F "[email protected]" | python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])')
curl -s -b c.txt $API/meetings/$MID | python3 -m json.tool

# поправить спикера, подтвердить протокол
curl -s -b c.txt -X PUT $API/meetings/$MID/speakers -H 'Content-Type: application/json' \
  -d "[{\"speaker\":\"SPEAKER_00\",\"participant_id\":$PID}]"
curl -s -b c.txt -X POST $API/meetings/$MID/confirm

# экспорт и СЭД
curl -s -b c.txt "$API/meetings/$MID/export?format=docx&lang=ru" -o protocol.docx
curl -s -b c.txt "$API/meetings/$MID/export?format=pdf&lang=kk" -o protocol.pdf
curl -s -b c.txt -X POST $API/meetings/$MID/sed

# дашборд и статусы
curl -s -b c.txt "$API/tasks?status=confirmed"
curl -s -b c.txt $API/tasks/stats
TID=$(curl -s -b c.txt "$API/tasks?meeting_id=$MID" | python3 -c 'import json,sys; print(json.load(sys.stdin)[0]["id"])')
curl -s -b c.txt -X PATCH $API/tasks/$TID -H 'Content-Type: application/json' -d '{"status":"in_progress"}'

# уведомления
curl -s -b c.txt $API/notifications
curl -s -b c.txt $API/notifications/unread-count

# live-запись: создать совещание, затем браузер шлёт бинарные чанки в ws://localhost:8000/api/v1/meetings/{id}/live
curl -s -b c.txt -X POST $API/meetings/live -H 'Content-Type: application/json' \
  -d "{\"title\":\"Live\",\"meeting_date\":\"2026-09-23\",\"participant_ids\":[$PID]}"

# бот (нужны bot-worker, разрешённый гостевой вход и допуск организатора)
curl -s -b c.txt -X POST $API/meetings/bot -H 'Content-Type: application/json' \
  -d "{\"title\":\"Meet\",\"meeting_date\":\"2026-09-23\",\"platform\":\"meet\",\"url\":\"https://meet.google.com/abc-defg-hij\",\"participant_ids\":[$PID]}"

API

Префикс /api/v1, интерактивная схема на http://localhost:8000/docs. Аутентификация: JWT в httpOnly cookie access_token. Роли user и admin. Совещание может создать любой вошедший пользователь; редактируют создатель и администратор, участники видят. Ответственный меняет статус своего поручения.

Гости. Секретарь может добавить участника по имени и email до его регистрации. Поручения назначаются на участника. Когда человек регистрируется с тем же email, участник и его поручения привязываются к аккаунту автоматически.

Жизненный цикл поручения: draft (после пайплайна) → confirmed (протокол утверждён) → in_progress → done. Если срок прошёл, beat ставит overdue; из него поручение переводится в in_progress или done.

On-premise и приватность

По условиям кейса аудио и текст нельзя передавать во внешние облачные API. Это ограничение соблюдается и при разработке, и на демо.

• Локальные модели по умолчанию. .env.example задаёт STT_BACKEND=local, LLM_PROVIDER=ollama, HF_HUB_OFFLINE=1. Пайплайн не обращается к облачным провайдерам. Веса скачиваются отдельным шагом без аудио и текста.
• Без внешних запросов из интерфейса. Шрифты собираются вместе с приложением, аналитики и CDN нет.
• Минимум персональных данных. Телефоны и ИИН маскируются до сохранения транскрипта. DELETE /meetings/{id}/audio удаляет запись после обработки, транскрипт и поручения сохраняются.
• Изолированный бот. Бот получает токен только для загрузки записи одной встречи, с ограниченным сроком действия. Chromium работает без root в отдельном контейнере. Приватные сетевые адреса и переходы за пределы домена платформы заблокированы.
• Секреты хранятся в .env, который исключён из git. Перед развёртыванием задаётся случайный SECRET_KEY.

Материалы в docs/demo/ содержат вымышленные имена и смоделированный разговор. Реальные записи в репозиторий не входят.

Тесты

GitHub Actions в репозитории хакатона отключены. Проверка перед каждым PR выполняется локально:

./scripts/check.sh                # ruff, pytest backend / pipeline / bots, HTTP smoke
./scripts/check.sh --compose      # плюс весь стек docker compose: тесты и smoke в контейнерах
./scripts/check.sh --compose-only # только стек docker compose, PostgreSQL на хосте не нужен

cd pipeline && uv run pytest          # контракт, fake-пайплайн, диаризация
cd backend && uv run pytest           # API, Celery-задачи, напоминания, экспорт (нужны Postgres protocol_test, ffmpeg, soffice)
cd backend && uv run ruff check . && uv run ruff format --check .
cd backend && uv run python scripts/smoke_backend.py   # end-to-end через настоящий HTTP
cd bots && uv run pytest              # CLI, жизненный цикл бота, HTML-фикстуры в браузере
cd frontend && pnpm lint && pnpm test # eslint, vitest

Структура репозитория

frontend/        Next.js: экраны, i18n ru/kk, моки для офлайн-демо
backend/         FastAPI, Celery, Alembic, экспорт DOCX/PDF, СЭД-адаптер
  app/routers/     auth, participants, directions, meetings, tasks, notifications, exports
  app/services/    audio, access, speakers, notify, export, sed/
  app/tasks/       celery_app, process_meeting, reminders, run_bot
pipeline/        ML-пайплайн как библиотека
  pipeline/models.py       контракт MeetingResult
  pipeline/fake.py         детерминированная заглушка (PIPELINE_FAKE=1)
  pipeline/real.py         STT → диаризация → маскирование
  pipeline/stt/            локальный faster-whisper
bots/            Playwright-бот для Meet / Zoom / Teams
docs/            спецификация, демо-протокол, инструкции запуска, исследование ботов
scripts/         check.sh (локальный CI), local_dev.py
docker-compose.yml, .env.example

Полная проектная спецификация описывает контракты между модулями и экраны.

Команда 01husky

Работа ведётся в ветках feat/<task> от develop. PR идут в develop, после интеграционной проверки develop вливается в main.

Ограничения и развитие

Сейчас:

• Локальная Qwen3:8b извлекает поручения и саммари из транскрипта. Возможны пропуски, смысловые дубликаты и ошибки привязки имён; черновик проверяет секретарь. Методика и ограничения: локальная LLM.
• СЭД подключена через mock-адаптер с интерфейсом SEDClient.push_protocol(). Адаптер для конкретной системы (Documentolog, Directum) реализуется по этому интерфейсу.
• Бот входит во встречу как гость, поэтому нужен допуск организатора. Подробности: bots/README.md и исследование способов подключения.
• При live-записи транскрипт появляется после нажатия «Стоп».
• Уведомления работают внутри приложения.

Дальше:

• Повышение полноты извлечения поручений, устранение смысловых дубликатов и оценка качества на размеченных RU/KK-записях.
• Стриминговое распознавание во время совещания.
• Дообучение Whisper на казахских корпусах (ISSAI KSC2) для шала-казахской речи.
• Узнавание участников по голосу, в том числе без эталона: кластеризация по совещаниям организации.
• Контроль исполнения: эскалация руководителю при повторной просрочке, отчёт по исполнительской дисциплине.
• Интеграция с календарём: бот подключается к встрече по расписанию. Уведомления в email и Telegram.