У нас уже работал автоматический анализ стенограммы и вложений. Теперь мы проектируем секретаря, к которому участник сможет обратиться прямо во время встречи: восстановить пропущенное, проверить договорённость или подготовить задачу. Для первой версии выбрали приватный чат, где человек сам задаёт вопрос и может сверить ответ с источником.
Мы уже занимаемся распознаванием речи и обработкой записей после встречи. О качестве диаризации и инструментах ручной разметки я писала отдельно. Секретарь для работы во время разговора пока в разработке; его пользу предстоит проверить на внутренних встречах.
От автоматического разбора к запросу участника
К сентябрю мы добавили анализ документов, приложенных к встрече. Модель составляла краткое содержание, выделяла обязательства, риски и вопросы для уточнения. После обработки двух DOCX мы получили жалобу на длинные ответы с повторами. В первом разборе был 31 вопрос, во втором — 16. Многие из них пересказывали замечания из раздела рисков.
Мы уточнили в инструкции назначение вопросов: они должны запрашивать недостающие сведения или документы. Если модель уже предложила согласовать методику оценки, повторять это предложение в форме вопроса незачем. Заодно разрешили оставлять раздел пустым. Существенные самостоятельные риски требовалось сохранить, даже если итоговый ответ из-за них останется длинным.
При повторном анализе тех же документов в первом ответе осталось три вопроса, во втором — ни одного. Самостоятельные риски сохранились. На этих двух примерах мы проверили конкретную правку: удалось убрать повторные вопросы. Пользу анализа в повседневной работе по двум таким прогонам оценить нельзя. Человеку может быть совершенно не нужен подробный разбор документа в этот момент, даже если текст составлен аккуратно.
На встрече 29 сентября я сказала, что пользу дополнительного анализа ещё не тестировала. Мы отдельно обсуждали, когда его вообще стоит запускать. Каждый запуск увеличивает расходы на модель, а полученный ответ требует внимания. Документ могли приложить, чтобы сохранить его рядом с записью; одно его наличие ещё не означает просьбы разобрать все условия.
Для дальнейшей работы выбрали запуск по запросу. Например, участник просит сверить обсуждаемый срок с приложенным планом или найти в документе условие, о котором сейчас говорят. Такой запрос задаёт цель анализа и помогает понять, какой ответ будет полезен. Обсуждали и явную просьбу, прозвучавшую во время разговора, но простого упоминания документа для запуска недостаточно.
Переход к этому режиму ещё в разработке. Дальше предстоит посмотреть вместе с пользователем, какие ответы помогают ему во время встречи, что приходится уточнять и когда дополнительный анализ оказывается лишним.
Вопрос возникает во время разговора
На обсуждении продукта в конце сентября я предложила простой сценарий: человек опоздал на встречу и хочет узнать, что обсуждали до его прихода. Он пишет вопрос в чат рядом со стенограммой и получает ответ, пока разговор продолжается.
В готовой записи можно найти нужное место, прослушать его и прочитать резюме. Во время встречи на такой поиск меньше времени: коллеги уже перешли к следующей теме, а участнику нужно уточнить предыдущую. Иногда он пропустил начало. Иногда хочет проверить, правильно ли понял договорённость. Иногда рядом нужен документ, о котором сейчас говорят.
На созвоне мы обсуждали и голосового помощника, который сам включается в разговор. Но у такого поведения есть отдельная сложность: ответ слышат все, он прерывает человека и меняет ход встречи. Вопрос к помощнику может быть предварительным — участник ещё сам не уверен, что хочет вынести его в общее обсуждение.
Для первой версии выбрали приватный текстовый чат. По задумке вопрос и ответ видит тот, кто обратился к секретарю. Ответ не озвучивается другим участникам. Голос и проактивные подсказки оставили за пределами ближайшего внутреннего пилота.
Так мы можем сначала проверить содержательную часть: понимает ли помощник вопрос, находит ли нужный фрагмент и успевает ли ответить, пока ответ ещё полезен. Возможность говорить вслух потребует отдельного решения о том, когда и как секретарю позволено вмешиваться.
Ответ должен вести к источнику
Для первого сценария достаточно уже сказанного на встрече. Вопрос «Какой срок мы сейчас обсуждали?» требует найти реплику и показать её вместе с ответом. Если участники назвали несколько вариантов и ещё не выбрали один, помощник должен сохранить эту неопределённость.
Поэтому в требования первой версии входят ссылки на фрагменты стенограммы и переход по времени записи. Участник сможет открыть место, на котором основан ответ, и проверить контекст. Например, фраза о пятнице могла быть предложением, возражением или окончательной договорённостью. По одному извлечённому слову это не определить.
В живой стенограмме добавляется ещё одна особенность: распознаватель может уточнять текст, пока человек продолжает говорить. Черновая реплика и подтверждённый результат должны различаться в интерфейсе. Иначе пользователь увидит уверенный ответ по фразе, которую через секунду исправит сама система распознавания.
Сохранение этих различий входит в текущую работу над Live-режимом. Мы ещё должны проверить полный путь: от поступления аудио до ответа секретаря и перехода к исходной реплике. Работоспособность отдельных элементов этого пути сама по себе не подтверждает готовность всей версии.
Контекст встречи и документы компании
На встрече мы отдельно обсуждали, какую пользу дадут подключённые источники компании. Стенограмма помогает ответить на вопрос о произнесённых словах. Для сверки с действующим документом нужен доступ к самому документу.
У этих ответов разные основания. «На встрече предложили перенести срок» — вывод из разговора. «В плане указан другой срок» — результат чтения плана. Секретарю предстоит показывать оба источника, чтобы человек мог разобраться в расхождении. Он не должен незаметно подменять согласованный документ последней репликой.
Для пилота подойдут, например, такие запросы:
| Запрос участника | Что нужно для ответа | Что показать человеку |
|---|---|---|
| «Что обсуждали до моего прихода?» | Предыдущую часть текущей встречи | Краткое изложение с переходами к репликам |
| «Мы уже договорились о сроке?» | Предложения, возражения и итог обсуждения | Договорённость либо пояснение, что решение ещё не принято |
| «Сверь это с приложенным планом» | Реплику и доступную версию документа | Найденное совпадение или расхождение со ссылками |
| «Подготовь задачу по этой договорённости» | Формулировку, исполнителя, срок и исходный фрагмент | Проект задачи для проверки и подтверждения |
Доступ к источникам тоже входит в проектирование. Участие во встрече не должно автоматически открывать все документы компании. Для секретаря нужны права конкретного пользователя и понятный ответ, когда нужный источник недоступен. Подключение источников и проверка этих ограничений остаются частью работы над продуктом.
Из договорённости получается проект задачи
Мы хотим, чтобы секретарь помогал подготовить задачу, пока её содержание ещё можно уточнить у участников. В проекте должны быть формулировка, ответственный, срок и ссылка на исходный фрагмент. Перед сохранением человек сможет исправить или отклонить предложенное.
Здесь особенно важно не додумывать отсутствующие детали. Если никто не взял задачу на себя, поле исполнителя требует уточнения. Если участники обсуждали несколько сроков, нужно вернуться к решению. Такое поведение мы закладываем в сценарий подтверждения.
Саму задачу планируем хранить в общей системе задач. Встреча будет сохранять связь с ней и показывать её в своём контексте. Это позволит продолжить работу после закрытия записи: назначить исполнителя, изменить срок, отметить выполнение. Отдельный список, существующий только внутри одного разговора, для этого неудобен.
Создание таких проектов из Live и общий жизненный цикл задач ещё предстоит реализовать. Сейчас это выбранное направление, по которому мы будем оценивать первую версию.
Что проверим на внутренних встречах
В плане пилота — пять–десять внутренних встреч, в том числе разговоры дольше часа с тремя и более голосами. Нужно проверить сохранность записи, устойчивость подписей участников, работу приватного чата, переходы к источникам и подготовку задачи. Этот пилот предстоит провести.
Во время одной из встреч уже возникла проблема: после закрытия крышки ноутбука запись сохранилась полностью, а обработка спикеров осталась неполной. Поэтому сохранённое аудио, готовая стенограмма и завершённая обработка должны проверяться отдельно. Потеря сети, переподключение и завершение встречи тоже входят в сценарии испытаний.
Для оценки пользы я бы смотрела на конкретные обращения: удалось ли восстановить пропущенную часть разговора, проверить спорный факт по источнику, подготовить задачу без долгого переписывания. Эти наблюдения предстоит собрать вместе с техническими сбоями. Пока у нас есть выбранный сценарий и план его проверки; вывод о пользе сделаем после работы на собственных встречах.
Материал может пригодиться коллегам? Отправьте им ссылку на статью.