Scribe: от записи встречи к задачам с проверяемыми цитатами

Для полезной работы с записью встречи нужны три отдельных результата: сама запись, стенограмма, сохраняющая сказанное, и предлагаемые задачи, связанные с соответствующими словами и временными отметками. Связное резюме не заменяет стенограмму. Запись в сгенерированном JSON-файле — ещё не утверждённая задача в вашей системе управления проектами.

В этом руководстве с помощью Ofox мы расшифруем синтетическую запись длительностью 43.92 секунды с моделью elevenlabs/scribe_v2, а затем передадим ответ с временными отметками модели openai/gpt-6-luna. В записи намеренно упоминаются назначенная задача, задача без исполнителя, неутверждённая дата выпуска и неутверждённый бюджет. Текстовая модель вернула предлагаемые задачи и открытые вопросы, не отправляя сообщений и не создавая внешних задач. Исходные файлы и необработанные ответы можно скачать.

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

Определите результат, который можно проверить

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

Для записи задачи недостаточно удачной формулировки. В ней нужно различать саму задачу, исполнителя, срок и статус утверждения. Если запись не подтверждает какое-либо поле, укажите null или явно отметьте, что требуется подтверждение. Заполнение каждой ячейки догадкой не делает документ завершённее — оно снижает его полезность.

В рабочий комплект входят meeting-script.txt, аудиозапись встречи, meeting-transcript.json, extract_actions.py, запрос для извлечения задач и необработанный ответ. Эти файлы позволяют проверить всю цепочку, не загружая чужую конфиденциальную запись встречи.

Синтезированная запись вымышленной встречи

1. Получите разрешение на обработку записи и сохраните её временную шкалу

Используйте запись, которую разрешено обрабатывать с помощью выбранного облачного сервиса. Для рабочей встречи соблюдайте правила организации о записи, хранении и доступе к материалам. Не включайте пароли, закрытые токены доступа или посторонние персональные данные лишь потому, что они могут помочь модели понять задачу.

Сохраните исходный файл и при необходимости подготовьте копию в поддерживаемом аудиоформате. Проверенный здесь маршрут Ofox принимает WAV или MP3. Если вы извлекаете аудиодорожку из видео, зафиксируйте, какую дорожку выбрали и обрезали ли начало. Все последующие цитаты должны соответствовать правильной временной шкале.

Для этого примера из исходного сценария был создан MP3 длительностью 43.92 секунды. В нём есть несколько намеренно разных высказываний:

• Лео проверит пример API до 15 октября 2026 года.
• Исполнителя для записи японской озвучки не назначили.
• Говорящий не может утвердить выпуск в продакшен.
• Дата выпуска ещё не определена, поэтому приглашения пока отправлять нельзя.
• Обсуждался тестовый бюджет в тридцать долларов, но его не утвердили.

На этих различиях и строится проверка. Система, которая извлечёт «отправить приглашения», потеряв частицу «не», может сформировать убедительно выглядящий, но опасный список дел. Система, которая примет обсуждение бюджета за разрешение потратить деньги, уже не просто суммирует сказанное, а выдумывает новые факты.

2. Распознайте речь с помощью Scribe и сохраните исходный ответ

Задайте OFOX_API_KEY, установите requests, FFmpeg и ffprobe, затем запустите предоставленный клиент из каталога комплекта:

python3 audio_api.py transcribe \
  --input meeting.mp3 \
  --output my-meeting-transcript.json

Клиент отправляет данные в формате multipart form на /v1/audio/transcriptions, используя elevenlabs/scribe_v2 и verbose_json. Актуальный маршрут, доступный через Ofox, можно проверить на странице модели Scribe в Ofox. В этом примере не предполагается, что шлюз принимает все параметры из нативного API провайдера.

Сохраните ответ до редактирования. Образец JSON содержит полный текст и начальную и конечную временные отметки для каждого слова. Он также нормализует произнесённую дату до “October 15th, 2026” («15 октября 2026 года»). Такая нормализация удобна, но не доказывает, что модель знает текущую дату или всегда может безопасно разрешить относительный срок.

Запись заканчивается на отметке 43.92 секунды, а последнее возвращённое слово — на 43.74 секунды. Не смешивайте длительность записи с данными об использовании. Временная отметка последнего произнесённого слова не заменяет длительность файла и не определяет сумму списания за запрос на транскрипцию.

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

3. Проверьте стенограмму, уделив внимание ошибкам, влияющим на решения

В первую очередь проверьте имена, даты, числа, отрицания и высказывания о разрешениях. В этом синтетическом примере исходный сценарий доступен для сравнения. В реальной встрече первичным свидетельством остаётся запись; слайды, повестка и предыдущие заметки могут прояснить терминологию, но не должны незаметно подменять сказанное участником.

Ведите журнал исправлений. В строке можно указать исходную фразу ASR, исправленную фразу, временной интервал, причину и проверяющего. Если аудио не позволяет разобрать слова, отметьте неопределённость. Не назначайте исполнителя по имени лишь потому, что рядом говорил какой-то человек или обычно именно он выполняет эту работу.

Этот ответ не содержит подтверждённых меток говорящих. Фраза “Leo speaking” («говорит Лео») намеренно произнесена в сценарии. Это текст в аудиофайле, а не акустическое доказательство того, что говорил именно конкретный сотрудник. В запросе на извлечение прямо сказано, что следующая модель не должна выводить личность говорящего из этой условности.

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

4. Попросите текстовую модель подготовить предложения со ссылками на доказательства

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

Полный запрос находится в actions-request.json. Основная инструкция выглядит так:

Use only the supplied ASR words and text.
Return actions, decisions, and open_questions.
Each action needs task, owner, due_date, status=proposed,
an exact supporting quote, and start/end seconds copied
from the word timestamps. Use null for unknown fields.
Separate commitments, proposals, and negations.
Do not infer acoustic speaker identity from a spoken name.
Do not invent approvals, send messages, or create tasks.

Запустите extract_actions.py, чтобы воспроизвести пример извлечения из комплекта. Скрипт использует openai/gpt-6-luna через /v1/chat/completions, читает стенограмму с временными отметками и сохраняет необработанный результат. Поставляемый скрипт отказывается перезаписывать существующий actions-response.json. Если вы намеренно отправляете ещё один платный запрос, выберите отдельную рабочую копию или версионированный файл для вывода.

Пример запрашивает JSON с помощью инструкций, а затем сохраняет ответ для проверки. В нём не утверждается, что на уровне API была принудительно задана схема структурированного вывода. В рабочей системе проверяйте разобранный объект по собственной схеме, даже если сообщение модели выглядит как корректный JSON.

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

5. Изучите фактический результат, включая его недостатки

Модель вернула вложенный объект actions с обязательствами, предложениями и отрицаниями, а также decisions и open_questions. У всех задач статус proposed. Необработанный ответ показывает один полученный результат; его не следует считать стабильной схемой API для будущих запросов.

В необработанном ответе также есть отдельное предложение “I can review the example” («Я могу проверить пример»). Оно может пересекаться с задачей проверки API. Перед экспортом задач проверяющий должен решить, относится ли это к той же работе. Автоматическое создание обеих задач может привести к дублированию, хотя каждая из них подкреплена реальной цитатой.

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

Полезный итог проверки может сохранить явно назначенную проверку API, оставить демонстрацию как предложение без назначенного исполнителя, сохранить три открытых вопроса, а ограничение на отправку приглашений записать как ограничение, а не задачу к исполнению. Храните такую редакционную интерпретацию отдельно от actions-response.json, чтобы исходный результат можно было проверить.

6. Проверьте цитаты, временные отметки и незаполненные поля

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

Сверьте точные цитаты со стенограммой. Если для сравнения вы нормализуете пробелы или пунктуацию, зафиксируйте это правило. Не используйте слишком широкое нечёткое сопоставление, при котором “approved” и “not approved” могут считаться взаимозаменяемыми. В примере цитата о бюджете включает отрицание утверждения; если убрать эту часть, смысл изменится.

Затем проведите семантическую проверку. Даже точная цитата может подтверждать неверный вывод. Фраза “I cannot approve the production release” («Я не могу утвердить выпуск в продакшен») указывает на ограничение, а не на разрешение развернуть продукт. Фраза “The release date is still undecided” («Дата выпуска ещё не определена») не подтверждает срок, выведенный из другого предложения с датой проверки API.

Неизвестные значения должны оставаться видимыми в интерфейсе. Пустое поле исполнителя не должно незаметно заполняться автором загрузки, организатором встречи или первым упомянутым человеком. Если срок не указан, не подставляйте вместо него сегодняшнюю дату. Если последующему инструменту нужны эти поля, оставьте пункт в очереди на проверку, а не выдумывайте данные ради заполнения формы.

7. Не смешивайте извлечение задач с их созданием

В этом руководстве процесс заканчивается на предложенных записях. Он не создаёт задачу в трекере, не отправляет письмо и не добавляет событие в календарь. Эта граница важна: транскрипция и интерпретация могут быть ошибочными, даже если оба API-запроса вернули HTTP 200.

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

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

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

8. Проверяйте процесс поэтапно

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

Если транскрипция неполная, проверьте исходное аудио, выбранную дорожку и завершение загрузки. Если текстовая модель вернула некорректный JSON, сохраните исходный ответ и исправьте этап извлечения или проверки. Не загружайте ту же запись повторно, если ошибка возникла только при форматировании JSON на последующем этапе.

Если результат выдумывает исполнителей или сроки, усильте требования к подтверждениям и проверьте реальные примеры. Более длинный запрос не гарантирует соблюдения инструкций. Сохраняйте тестовые случаи с неназначенными задачами, предварительными датами, отказом в разрешении и противоречивыми высказываниями; валидатор и проверяющий должны их обнаруживать.

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

9. Оценивайте полезность результата, а не длину резюме

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

При проверке расходов учитывайте использование ASR и текстовой модели отдельно. Показатель ASR в расчёте на секунды и количество текстовых токенов — разные единицы. Метаданные материалов помогают сопоставить запросы с вашими данными биллинга, но в этом руководстве не выдаётся несверенная оценка за фактический счёт.

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