Зачем и как переходить от транскрибации к «стерилизованным» AI-протоколам совещаний

Замечу, что «транскрибация» — это преобразование аудио в текст с сохранением всех сказанных слов (и его результатом является «транскрипт»). Слово «транскрибация» пока отсутствует в русском языке: английское transcription официально переводится как «расшифровка» или «транскрипция». Однако «расшифровка» и особенно «транскрипция» имеют совсем другие известные смыслы, поэтому эти слова намного реже встречаются в русскоязычном Интернете применительно к задачам «аудио в текст», и еще реже используются специалистами в данной области. Так что в этой статье я буду все-таки говорить про транскрибацию.

---

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

Просто транскрибируем встречи. Чем это плохо?

Предположим, вы уже используете SaaS-систему транскрибации, которая удовлетворяет вашим потребностям: совместимо с вашей ВКС, нравится вам по фичам и по юзабилити. Если она имеет API для интеграции с внутренними системами компании, то такой тариф стоит около 1500-2500 рублей в месяц на человека. А вариант on-premise (развертывание в контуре вашей компании) — обычно еще дороже в первый год, но дешевле потом.

Теперь вы хотите масштабировать это решение на всех сотрудников компании: например, 1 млн. руб/мес на компанию в 500 человек. Какую выгоду компания может получить за эти деньги?

Не говорю уже низком проценте использования AI-фич этих систем: например, мало кто создает задачи в своем таск-трекере на основе созданных транскрибатором списков Action Items, поскольку это означает весьма неудобный copy-paste.

Одна из причин невысокой степени принятия транскрибаторов пользователями — естественное для большинства людей нежелание менять свои привычки («Придумали очередную ерунду, только работать мешают»… «Раньше жили без этого — и сейчас проживем»… «ОК, теперь есть возможность быстро найти забытую информацию со встречи, но лень, обойдусь»…). В результате результатами транскрибации на еженедельной или тем более ежедневной основе пользуются лишь немногие энтузиасты (если не дополнять их чем-то еще, см. ниже).

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

Изначально в нашей компании этот показатель составлял около 30%, теперь он в 3 раза больше, но для этого оказалось недостаточно внедрить систему транскрибации видеоконференций. Для этого нужно:

1. обрабатывать транскрипты с помощью отдельного искусственного интеллекта (см. ниже)
2. интегрировать резюме встреч, протоколы и другие AI-артефакты в рабочие процессы — хотя бы просто через отправку сообщений людям в корпоративный мессенджер (по разным триггерам).

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

• Как минимум, транскрипты подсвечивают бесполезность большой части обсуждений на встречах, и люди это чувствуют: жизнь их заставляет менять формат их участия во встречах или даже менять формат самих встреч… а меняться — это «больно».
• Более того, повышение эффективности предполагает отмену некоторых привычных встреч либо отмену участия некоторых людей в них, поскольку они могут просто получать дайджесты с резюме этих встреч, и не тратить рабочее время впустую. Если человек — менеджер, это может у него вызвать беспокойство от «потери контроля» и даже эмоции типа «а зачем я тогда нужен?».
• Как максимум, в компании меняется культура прозрачности информации и, как следствие, культура принятия решений.

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

Эти проблемы технически возможно решить правильной системой разграничения доступа, но в готовых SaaS-решениях это сделать затруднительно, даже если эти решения так давно на рынке, как Fireflies (см. типичную проблему на схеме выше).

Чтобы избежать возможных проблем, люди просто не транскрибируют многие важные совещания (отключают транскрибатор на них).

Кроме того, люди в присутствии транскрибатора могут перестать открыто высказываться по многим вопросам на «официальных» встречах. Это приведет к росту суммарного времени на коммуникации (если эти вопросы придется дополнительно обсуждать «втихую»), а также к понижению прозрачности работ, со всеми вытекающими из этого последствиями.

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

Переходим от расшифровок аудио к протоколам совещаний

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

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

А с другой стороны, краткие резюме встреч и «не по-человечески написанные» списки задач, которые нередко входят в число фич системы транскрибации (см. подробнее про эти и другие артефакты) — это лишь небольшая польза, которую можно вынести из встреч. Для многих людей это вообще лишь «рюшечки» — конкретные детали со встреч важнее (поскольку общую информацию мозг участников встречи запоминает лучше, нежели детальную).

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

• Протокол — самый сложный в генерации артефакт встречи. Техническая возможность делать качественные протоколы появилась лишь в мае 2024 с появлением очень мощной большой языковой модели (LLM) — GPT-4o и затем Claude 3.5 Sonnet. Даже GPT4-turbo, Claude 3.0 Opus и Gemini 1.5 Pro, по результатам моих тестов, с этой задачей не справляются на приемлемом уровне.
• Большинство пользователей пока что видели только сам транскрипт, резюме (summary), и в редких случаях перечень задач (action items). Другими словами, большинство клиентов систем транскрибации еще не поняли, что у них есть спрос на протоколы.
• Как следствие, системы пока не увидели смысла вкладываться в сложные промпты и в дообучения своих LLM, которые могли бы давать качественные протоколы.
• И даже если они захотят в это вложиться, есть проблема: их собственные LLM созданы на основе открытых LLM типа Llama (т.е. не таких «умных», как GPT-4o или Claude), и их качество недостаточно для задачи генерации протокола. Я тестировал хваленую Llama 3.1 405B, но при создании русскоязычного протокола она провалилась. Из всех открытых моделей с этой задачей на русском справилась только Qwen2.5 72B.
• Как бы то ни было, даже когда качество таких LLM вырастет до нужного уровня, весьма маловероятно, что содержимое протоколов от систем транскрибации будет удовлетворять требованиям вашей команды/компании.

Мой ответ — для преобразования транскриптов в протоколы нужно применять отдельные от систем транскрибации инструменты с генеративным искусственным интеллектом (с мощными LLM).

При этом необязательно их дообучать (LLM fine-tuning — это серьезная работа, требующая привлечения специалистов). Конечно, если вы вынуждены брать за основу бесплатную LLM, то дообучение будет необходимо. Но по моему опыту с коммерческими LLM, для них достаточно написать качественные промпты, учитывающие специфику вашей компании. Основу для таких промтов я дам в следующем разделе.

Пишем промты для генерации протоколов

Итак, что нам нужно от протокола:

1. «Стерильность», т.е. отсутствие небезопасных высказываний. Очень плохо, если со встречи утекут не совсем цензурные слова, негативные оценки коллег, команд, клиентов и другие рискованные фразы. Однако в понятие «стерильности» не входит конфиденциальность: это регулируется системой доступа к данным, которая сильно зависит от компании.
2. «Минимальная полнота». Полнота означает, что каждая высказанная на встрече мысль должна быть записана, если она напрямую относится к одной из затронутых на встрече тем (просто формулировки всех тем — недостаточно). «Минимальность» означает, что мысль должна быть сформулирована без излишеств, тогда как многие люди очень путанно и долго формулируют свои мысли, и далеко не все их слова способствуют понятности мыслей.
3. Терминологическая корректность. Расшифровка встречи — даже самой лучшей системой транскрибации — отнюдь не гарантирует отсутствия неверно распознанных слов. Когда какая-то реплика траскрибируется человеком, при распознавании нечетко произнесенного слова он смотрит на общий смысл данной реплики, предыдущей реплики другого спикера и даже на более широкий контекст. То же самое должен делать и искусственный интеллект.

Этим требованиям (по крайнем мере, первым двум) отвечают протоколы, генерируемые через API Anthropic или OpenAI со следующим промптом:

Правда, этот промпт дает качественные протоколы лишь в случае его использования с конкретными LLM (Claude 3.5 Sonnet и, с натяжкой, GPT-4o). Для локальных опенсорсных LLM такая задача пока «не по зубам».

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

Вероятно, кастомизация промпта была бы также полезна для вычистки конфиденциальной информации, которая не должна быть доступна вне определенного круга сотрудников (например, названия компаний-клиентов в протоколе можно заменять на «Клиент 001» и т.д.). Но лично я эту задачу с помощью AI не решал. На мой взгляд, надежнее организовать в компании правильную систему доступа к протоколам, которая эту задачу решает.

Оцениваем выгоду от перехода к протоколам

Таким образом, конечно, в ходе внедрения системы транскрибации вместе с протоколами требуется больше усилий, чем если внедрять только саму систему. Имею ввиду усилия на подключение к выбранному вами транскрибатору еще одного «архитектурного слоя» на базе генеративного AI (LLM), а также на эксперименты с разными аудиозаписями и с разными модификациями промта.

По моим подсчетам на данных внутренних созвонов ScrumTrek через токенизатор OpenAI, около 50000 input tokens требуется для обработки 5 часов транскриптов встреч на русском языке (5 часов я взял как минимальное время встреч на одного организующего встречи сотрудника за месяц). Что до числа токенов в системном промте, то оно пренебрежимо мало в сравнении с типичным транскриптом. Далее, при типичном для вышеуказанного промта «коэффициенте сжатия», равном 1/4 (1 токен протокола на каждые 4 токена транскрипта), получается около 12500 output tokens. В нашей компании мы пока используем внешние LLM (OpenAI, Anthropic) с доступом через российский «прокси», поэтому получается всего около 100 руб на человека в месяц.

Получается, собственная обработка транскриптов стоит на порядок меньше, чем сам траскрибатор (который при поминутной тарификации стоит 6-10 руб/мин, т.е. 1800-3000 руб. за те же 5 часов на одного организатора встреч в месяц). Разумеется, вместо 5 часов у вас может быть и 40 часов в месяц на человека (особенно если встречи создаются лишь небольшим процентом сотрудников: например, только менеджерами), но от числа часов не зависит 10-20-кратная разница между прямых расходами на получение транскриптов и на протоколы из них.

А главное, подход с протоколами дает немало выгод в плане usability, user adoption, экономии усилий и информационной безопасности, они приведены на этой схеме:

Это весьма отрадно и удивительно, ведь в содержании встреч непросто разобраться даже людям, если они находятся вне контекста вашей компании (как и LLM 😊) или просто недостаточно квалифицированы в роли составителя протоколов по вашей тематике.

Резюме

Таким образом, в статье предложен новый подход к обработке содержания рабочих встреч, при котором доступ к транскриптам через сам транскрибатор заменяется на доступ к созданным с помощью AI «стерилизованным» протоколам через ваши собственные технические средства (база данных с нужным вам разграничением доступа, корпоративный мессенджер, email, …).

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

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

Почему в это стоит вложить усилия?

• Чтобы из встреч одной команды коллегам из других команд не утекали негативные оценки людей, ненормативные слова и прочие рискованные фразы.
• Чтобы вместо слишком многословного транскрипта люди могли читать более краткий и более понятный протокол встречи, свободный от большинства погрешностей транскрибации (которые неизбежны, поскольку транкрибатор не может понимать смысл сказанного в контексте встречи в целом).

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

Только вы сами, обнаружив неверную лексику, не слишком корректные высказывания или утечку в протоколы чувствительной информации, можете внести соответствующие улучшения в ваше AI-driven решение!

---

Приглашаю в телеграм-канал ScrumTrek, где я публикую полезные промпты и материалы про искусственный интеллект, в том числе, видеозаписи митапов сообщества AI-энтузиастов AIDEA. Канал особенно полезен для руководителей!