От записи совещания до RAG: конвейер обработки конференций

Всё, предлагаю начинать. Тань, передаю тебе слово.

>> Ага, супер, спасибо. Слово принимаю. Так, меня сейчас должно быть слышно и видно.

>> Есть.

>> И видно мой экран.

>> Да.

>> Замечательно. Всё, тогда начинаем. Так, верхняя панелька зума у меня ещё сверху торчит, но она мне не помешает. Всё отлично. А так я очень рада всех приветствовать. Спасибо за интерес к теме. Я думаю, что, как я до этого и сказала, дискуссия должна быть интересной. А тема моя сегодняшняя от записи совещания до RAG конвейер обработки конференций. И давайте для начала пару слов о себе. А меня зовут Татьяна Глотких. Я F-разработчик в компании Финам. Отвечаю за работу со встречами. Проект называется Catalk Summary. Почему такое странное название? Будет понятно дальше. И я использую продуктовый подход к разработке. То есть мне очень важно, чтобы всё, что я делаю, было для пользователя и для бизнес-результата. И мне всегда очень интересно, как то, что я делаю, влияет, а на пользовательский путь и на бизнес-результат.

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

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

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

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

Итак, а как следует из названия моего доклада, мы собрали некий конвейер, через который проходят абсолютно все наши встречи, которые были записаны. А, и сейчас посмотрим на общую схему работы системы. Вот она на слайде. А, значит, этот Catalk, и как я говорила, будет понятно, почему так странно называется проект Catalk Summary. Контур Talk - это видеоконференцсвязь ВКС, с IP которого мы работаем. И если встреча записывалась, естественно, а через короткое время в API Catalk становится доступен, э, транскрипт встречи, а, то есть встречи текстом. Мы его забираем. Так.

Раньше времени. Ага, вот моя мышка. А мы его забираем себе в Catalk Summary и обрабатываем в несколько этапов. А мы сначала нарезаем чанки, затем запрашиваем эмбеддинги и затем делаем LLM-саморизацию. А, ну, если я понимаю, что часть из присутствующих не работали, не успели ещё поработать с технологиями AI, поэтому я буду пояснять абсолютно все понятия, которые сейчас прозвучали, чтобы мы были on the same page. Ну и основные задачи этого конвейера и в целом основные фичи системы, мм, это рассылка Summary на почту участникам и доступность встречи в поиске через окно умного чата.

И перейдём к более детальной схеме, которая отображает именно процесс обработки встречи. Она включает в себя три условных этапа, три фазы. Я буду употреблять эти понятия как равнозначные. Это Discovery, Transcript Handling, Summarization. И мы пойдём по ним step by step.

Первая фаза Discovery. Я уже немножко о ней сказала. Это этап, с которого начинается работа с материалами встречи. Здесь всё просто. А как только транскрипт, записанной встречи, становится доступен в Catalk Talk API, мы его забираем себе и вместе с метаинформацией. Что включает метаинформацию? Список участников, ссылка на запись, э, определённые тайминги, э, то есть активности, сколько каждый участник был подключён с видео, сколько с микрофоном. Ну вот такая метаинформация. Мы её сохраняем себе в базу данных.

Следующая фаза, а это обработка транскрипта. И здесь мы, естественно, остановимся чуть подробнее, потому что, как я поняла, по э-э нашему небольшому интро, интересная часть. Э, поэтому этому будет посвящена большая часть доклада. Аа, и давайте посмотрим сразу на более детальную схемку. А, значит, в верхней части э транскрипт в том формате, в котором он хранится в нашей базе данных. То есть это фамилия, имя. Ну вот здесь приведена только фамилия, но так, как правило, это фамилия, имя. И дальше пошли реплики.

А первый шаг обработки транскрипта - это разделение транскрипта на чанки. А для реализации гибридного поиска по транскрипту мы выделяем три типа чанков. Это реплики, это темы и это действия. Реплики выделяются на уровне кода разбиением транскрипта. То есть здесь всё понятно, это уже результат разбиения. То есть Иванов у нас сказал э какую-то одну фразу - это одна реплика. Петров сказал что-то другое - это вторая фраза, вторая реплика. А вот темы и действия мы выделяем с помощью нейросети, с помощью языковой модели. То есть как это происходит. Э вы мы отправляем в LLM параллельно два запроса. У нас первый с промптом на определение темы. Ну вот здесь кусочек приведён. Мы просим проанализировать транскрипт деловой встречи, выделить ключевые тематические блоки. А второй запрос, э, чтобы нейросеть нам, языковая модель, точнее, выделила мм конкретные действия, которые прозвучали на встрече, то есть договорённости к исполнению. И мы получаем, соответственно, два результата, а, которые нам предоставляет нейросеть. Это, во-первых, список тем, которые прозвучали на встрече, и список задач, которые были поставлены конкретному человеку. Конкретная формулировка задачи. И, как правило, ещё есть определённые метаданные, которые нейросеть смогла выделить. Это, например, Epic, например, сроки, ну, ещё какие-то договорённости, то есть всё, что нужно по факту для аа работы дальнейшей с задачей.

А, и дальше мы запрашиваем эмбеддинги для всех типов чанков и записываем себе в базу данных. Давайте проговорим, что такое эмбеддинги и зачем они нужны. Ну, эмбеддинги - это способ представления объектов, а, то есть слов, предложений, изображений, других типов данных в виде числовых векторов. И эти векторы позволяют работать с различными типами данных и анализировать их взаимосвязи. То есть, по факту, главная задача эмбеддингов - это преобразование сложных данных в набор чисел, вектор. И именно векторы помогают AI находить сходство, понимать смысл и делать выводы. А представлять, в виде эмбеддингов можно всё, что угодно: отдельные слова, фразы, предложения, изображения, звуки, видео и даже поведение пользователей. И схематично это можно представить вот таким образом. То есть на вход в модель, а, подаются данные, на выход мы получаем массивы эмбеддингов. А наши, в нашей базе данных эмбеддинги хранятся вот примерно в таком виде. А, то есть, э, у каждого чанка есть тип. То есть вот он текст чанка. Это примеры прямо из нашей базы данных. А у него есть тип, то есть то, что мы посмотрели два слайда назад - это реплика, тема и действия. И пошёл набор числовых векторов, то есть эмбеддингов.

Для чего это сделано? Это сделано для RAG. Что такое RAG? RAG - это технология, которая объединяет языковые модели с внешними базами данных. То есть она позволяет модели перед ответом находить актуальные проверенные данные, а это устраняет галлюцинации и обеспечивает работу с закрытой или новой информацией, как в нашем случае. Вот как это работает на примере встреч. Ну, дело в том, что очевидно, что э нейросети для того, чтобы ответить на какие-то вопросы про наши встречи, для того, чтобы вообще о них знать, ей нужен какой-то контекст, нужны данные встречи. И если их не будет, она нам, конечно, придумает что-то, но это будет вообще совершенно нерелевантный ответ. Вот. И поэтому, а, мы должны ей эти данные предоставить. И для того, чтобы ей предоставить эти данные, нам нужно сначала найти нужные встречи среди всех остальных. И все этапы обработки транскрипта, которые мы посмотрели ранее, сделаны именно для возможности поиска по транскриптам.

И давайте чуть-чуть углубимся в этот вопрос и посмотрим, а как это работает. То есть гибридный поиск нам нужен для того, чтобы с помощью RAG мы могли пользователю предоставить релевантный ответ. А в чём здесь общая идея? Мы используем гибридный поиск. Одновременно задействуется векторный поиск по семантической близости и полнотекстовый поиск по ключевым словам. И результаты поиска по всем каналам объединяются через алгоритм RRF, и происходит ранжирование по конференциям.

А давайте немножко переключимся на пример. Вот, как мы говорили чуть выше, у нас мы получили текст транскрипта, а нарезали его на чанки и получили через embedding API эмбеддинги, сохранили себе в базу данных. Пользователь нам делает запрос через окно умного чата. Какие сроки доработки авторизации мы обозначили на прошлой встрече? Вот, соответственно, нейросеть должна работать каким-то образом, как-то найти ответ на этот вопрос. Соответственно, мы идём в нашу базу данных, и поиск у нас осуществляется по запросу "сроки доработки авторизации". То есть выделяется самое главное сначала с помощью нейросети. А, а вот с этим, с этой фразой "сроки доработки авторизации" мы уже работаем на уровне гибридного поиска. Вот, чтобы ответить на вот этот вопрос, мы должны найти встречу, на которой обсуждались сроки доработки авторизации.

>> Я извиняюсь. Привет. Не надо слайд переключить случайно?

>> А что, ещё раз?

>> Лай висит. RG RAG. Может, вы про другое уже рассказываете?

>> А-а, сейчас гибридный поиск слайд, правильно? Векторный поиск.

>> Да, всё правильно.

>> Самый >> не Всё, всё супер, да, спасибо за комментарий. Всё огонь. Мы идём дальше и смотрим на поиск по каналам. Вот. А здесь, на самом деле, просто особо не проиллюстрируешь то, что я говорю, поэтому я иллюстрирую на словах. Так, в общем, поиск по каналам. Смотрим на поиск по каналам. А давайте обратим внимание сначала на первую колонку, то есть пойдём step слева направо. Значит, на первой колонке, мм, как я говорила, мы ищем векторным и полнотекстовым поиском по каждому из трёх типов чанка. То есть уже здесь знакомый нам топик и actions. В сумме получается шесть каналов поиска. Поиск ведётся одновременно по всем каналам. Ещё раз напоминаю, что у нас задача найти релевантную встречу.

В колонке два обозначен метод, с помощью которого мы ищем. То есть, а, при поиске пользователя, при поиске, точнее, запрос пользователя также превращается в вектор, и система будет искать, э, искать чанки, чьи векторы направлены похожи в многомерном пространстве. То есть по косинусному расстоянию. А для каждого канала установлен threshold. Threshold у нас касается только векторного поиска. Э, ну, потому что для поиска по ключевым словам он не имеет значения, там либо да, либо нет. А, и значения ниже вот этого порога, вот этого threshold, они считаются нерелевантными. А, значит, здесь мы для поиска по векторам мы используем расширение pgvector. Ну, очевидно, у нас PostgreSQL база данных. И используется индекс IVFFlat, ну, который, собственно, для векторного поиска и нужен, и просто ускоряет нам э поиск. Вот это что касается векторного поиска. Что касается поиска по ключевым словам, которые также одновременно происходят с векторным, он работает, ну, также мы делаем это возможностями PostgreSQL. Он работает у нас на уровне, на уровне нормальных форм слова, то есть PostgreSQL разбирает текст и запрос э через словарь русского языка. То есть, если у нас идут какие-то склонения слова "авторизация" и, например, у нас лемма "авторизации". Если мы там "переписали", то лемма "переписать", а, и, соответственно, проверяет, есть ли пересечение лемм, а, лемм запроса и лемм текста. А, ну, и, как я сказала, здесь порог не нужен, потому что у нас здесь, э, мы либо нашли, либо нет. А если совпадение точное, значит, лемма есть в тексте, значит, мы берём этот результат.

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

Также, кстати, про ограничения. У нас есть в запросе определённые фильтры. Это уже касается кода, ну, возможно, частично кода. А, то есть те фильтры, по которым мы ищем в базе данных. А, нам может передать, э-э, прийти от пользователя запрос на определённые даты конференции. Может прийти, кстати, конкретное название. А, и здесь у нас, а, идёт также векторный поиск по названию, потому что мы ещё берём эмбеддинги от заголовков конференции, точнее, не от заголовков, простите, от названия конференций. Вот. И они тоже хранятся у нас в базе данных. То есть мы используем векторный поиск ещё и для поиска по title. И дальше у нас идёт по participants. Мы можем искать тех, э, все сотрудники из указанных были на встрече, а был кто-то один из указанных, и вот этих сотрудников точно не было. То есть это такие жёсткие фильтры идут. Вот.

А дальше у нас, э, происходит ранжирование. То есть мы через алгоритм RRF объединяем результаты данных результаты, полученные в результате поиска, простите, от по всем каналам. И, соответственно, если один и тот же чанк у нас попадает в несколько каналов, то его вот этот скор, полученный RRF score, они суммируются. А, и в целом это, ну, центральный механизм. То есть чанк, найденный и векторно, и по ключевым словам, получает более высокий итоговый скор. То есть что происходит дальше? У нас мы группируем чанки по ID-встрече. То есть у нас вполне возможна ситуация, когда, мм, например, 20 первых чанков в выдаче, то есть самых релевантных чанков, а у нас будут относиться к одной встрече. Ну, например, мы очень активно обсуждали ту же авторизацию, про которую я говорила ранее, и, э, ну, у нас получается, что на других встречах данный пользователь не обсуждал авторизацию. И, соответственно, нам нужно сгруппировать, э, чтобы мы получили в итоге только одну встречу, потому что нам не нужно 20 экземпляров одной встречи. Вот. Рассчитываем RRF score, э, соответственно, по тому алгоритму, который я показала до этого, и возвращаем топ-7 конференций. То есть семь конференций - это не магическое число, хотя, возможно, оно немножко магическое, потому что, а, ну, мы экспериментально подбирали некоторые числа, а, то есть чисто, ну, ставили гипотезу и смотрели, как, э, мм, какие результаты будут наиболее релевантными. Вот как-то сошлись на цифре семь. Она оказалась наиболее оптимальной. Мм, вот.

И дальше я хотела бы собрать немножко всё, что мы проговорили до этого. То есть, что происходит, а-а, когда пользователь нам пишет какой-то запрос, тот же, который я приводила до этого: "Расскажи там, какие сроки доработки авторизации поставлены на встрече". А у нас мы берём вектор запроса, получаем в Embed. Дальше мы ищем его по шести параллельным каналам поисков. Дальше мы всё это ранжируем, берём топ-7 конференций по суммарному скору. Дальше отправляем транскрипты этих конференций в языковую модель вместе с запросом пользователя и, соответственно, получаем ответ. Пользователь пользователь получает свой ответ. Нейросеть уже отдаёт ему. Вот.

И на самом деле, как выглядит результат вот этого всего, я покажу чуть позже. А мы сейчас давайте посмотрим ещё на одну фичу нашей системы, которая также связана с работой с языковой моделью. А это фаза самаризации. То есть мы ещё не закончили работу с транскриптом. У нас после того, как мы обработали транскрипт для векторного поиска, для осуществления векторного поиска, мы дальше его суммируем. Несмотря на то, что блок выглядит очень большим, на самом деле он гораздо проще, чем то, что я рассказывала до этого. А, значит, у нас происходит категоризация встречи на первом шаге. А что это значит вообще? Зачем это нужно? А для каждой встречи по транскрипту мы определяем, к какой категории она относится. Это нужно для более точной саморизации в дальнейшем. Ну, очевидно, что у нас вебинар будет немного отличаться по целям от собеседования, например, а дейли будет немного отличаться от планирования. Ну, соответственно, для этого мы и выделили эти категории. И, э, вот здесь на слайде представлен список этих категорий и описание, которое мы и отправляем нейросети с просьбой определить, к какому, к какой категории относится встреча. То есть мы берём список вот этот, а, берём описание, берём транскрипт встречи, отправляем в языковую модель с просьбой: "Определи, пожалуйста, к какой категории относится встреча". И языковая модель нам возвращает ответ, что, например, это был вебинар. Совершенно точно, ну, или не точно. Потому что иногда, ну, галлюцинацию никто не отменял, она иногда ошибается.

А после того, как категорию мы определили, мы переходим к подготовке схемы ответа. Э, мы работаем на Node.js, поэтому если кто-то тоже работает с этими библиотеками, сча, я думаю, что вы знакомы с этим синтаксисом. Вот. А, ну, в чём здесь суть? Зачем нам готовить ответ? Чтобы получить ответ в том виде, с которым мы можем работать далее, то есть в виде объекта с определённым образом названными полями, аа нам дело в том, что после того, как мы получаем сам от нейросети, нам нужно его каким-то образом обработать, а именно засунуть в HTML-шаблон в письмо и потом разослать пользователям. Так вот, для этого нам нужно, чтобы нам нейросеть прислала определённый набор полей, а иначе на уровне кода мы просто не сможем с этим ничего сделать. Вот. И поэтому мы в зависимости от категории встречи мы как и кусочки пазла собираем, э, во-первых, промпты, во-вторых, разделы. То есть э выглядит это вот так. Я опять потеряла мышку. А у нас есть, например, разделы маркированный список. Есть, например, разделы карточки с задачами. И здесь у нас будут определённые поля определённого типа. И мы всё это наросети прописываем, а, чётко и конкретно, чтобы нам пришёл ответ именно в том виде, в котором мы, э, хотим получить его. И вот здесь уже в схеме мм будет происходить запрос в модель, которую мы также укажем вот здесь. Вот. А, и набор, как я сказала, элементов ответа будет зависеть от категории встречи. Но у нас также есть интерфейс. Это такой офтоп небольшой, в котором можно гибко настраивать шаблон под себя, задавать разделы, промпты к ним и формат отображения в письме. А, то есть каждый пользователь может зайти и самостоятельно себе настроить.

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

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

И следующее, а, сделаем небольшой шаг назад и посмотрим на результаты непосредственно RAG. Это запросы, примеры запросов в наш умный чат. Аэ, примеры результата поиска по встречам. Вот он выглядит вот таким образом. То есть, например, а это всё мои запросы. Я задавала вопросы по своим встречам. Например, я спросила: "Что обсуждалось на моих встречах в марте? Напомню, ключевые договорённости и задачи, поставленные мне". А в этот момент, э-э, мы сходили в базу данных, собрали все мои встречи за март, обработали их таким образом, по которому, ну, по тому алгоритму, про который я говорила ранее. И вот здесь мы получили конкретный результат. Вот с некоторыми даже уточнениями. Далее, "О чём говорилось на последней встрече?". Здесь с нейросеть, точнее, наша система умеет с таким работать. Тоже запрос делался давно, здесь встрече за 23 марта, но тем не менее, если я сделаю запрос сейчас, э, он мне выдаст встречу, которая была вот буквально полчаса назад закончилась. И, соответственно, "Сроки по задаче". Запрос тоже, а нейросеть корректно вытащила все данные, которые, мм, ту информацию, о которой я её спросила. Вот.

И я предлагаю вернуться к проблемам, о которых я говорила в самом начале, и посмотреть, удалось ли нам решить их с помощью тех фичей, э, с помощью алгоритма обработки, про который я рассказала. Итак, никто не ведёт протокол встреч, часто договорённости не фиксируются. Мы решили эту проблему автоматической рассылкой summary на почту участникам. Если пропускаю важную встречу, так и не узнаю, что на ней было и к чему пришли. А здесь summary получают все приглашённые, а не только фактически подключившиеся. То есть, если вы пропустили встречу, summary вам всё равно придёт. На вопрос "На какой встрече мы обсуждали сроки по проекту X?", никто не может ответить. Может, можно получить ответ на этот вопрос с помощью умного поиска по встречам. То есть можно вытащить цитаты из транскрипта или попросить бота прислать ссылку на запись. Э, как мы видели на предыдущем слайде, он это тоже умеет. Вот. И на вопрос "Какую встречу мне поставили в понедельник на дейли?". А ответ также доступен благодаря умному поиску. А, кстати, можно вытащить конкретную формулировку задачи, а также создать её прямо в окне умного чата. Это мы тоже умеем. То есть, если мы вот вернёмся на шаг назад, вот смотрите, например, м вот здесь пример, что обсуждалось на встречах в марте. Вот любую ключевые задачи, точнее, выдели, которые обсуждались на встречах в марте. Мы можем взять любую вот из этих задач и попросить э чат создать нам задачу в Jira, так как у нас есть интеграция с Jira. Это тоже разработка нашей команды. А чат, умный, задаст нам несколько вопросов по названию проекта, например, ну, или по тем данным, которые он не смог о нас собрать. А и запрос улетит в Jira. В Jira создастся задача. Также, э, создать задачу можно не только по, э, из окна умного чата теперь, но и по ссылке из summary. То есть сейчас это буквально вот совсем новая фича. В том письме, которое я показывала, её нет. А-а, можно нажать под блоком с задачами кнопку, и вас перекинет на интерфейс, где будут уже часть полей предзаполнены, и можно просто через удобный интерфейс тоже создать задачу в Jira. Там тоже настроена интеграция с MCPRA. Вот.

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

>> Тань, спасибо. Есть вопросики? Скажи, пожалуйста, вот в Catalk есть свой самаризатор, вы его используете или вы отдельно писали?

>> А, да, Вов, спасибо за вопрос. Нет, мы не используем самаризатор Catalk. Мы получаем по API транскрипт встречи. То есть это чисто набор реплик. А дальше всё мы делаем сами на своей стороне. Кстати, самаризатор у них появился уже после того, как мы сделали его у себя. Вот так. Что у нас немножко >>

>> Диаризацию вы делаете сами или на базе Catalk по активности?

>> Кого делаем?

>> Диаризацию.

>> А это в смысле не совсем поняла. Это обработка голоса.

>> Это да. Раскидывание по спикерам.

>> Это делается на стороне Catalk. То есть она нам присылает уже готовые реплики по таймингам, по информации, сколько у каждого участника, точнее, ну, как с какого по какое, с какую по какую минуту встречи у участника был включен микрофон, когда была включена камера. То есть там довольно большое количество метаинформации, но это всё делает Catalk, да, мы это не делаем.

>> А >> если перебивают или вдвоём он разговаривает,

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

нормальные транскрипты, с которыми можно работать.

>> А вы что используете Виспер для того, чтобы англицизмы распознавать и в принципе аббревиатуры там английские какие-то?

>> А не используем? Нет, мы отправля обрабатываем только неросечью. Сам текст, >> как называется? Мы нейросетью обрабатываем, то есть мы в языковую модель отправляем, и она нам всё делает. Дополнительно мы с транскриптом никак не работаем.

>> А то есть, ну, транскрипто вы чем не выдёргиваете?

>> Попи >> и толка >> чисто чисто. Дада. Да, чисто нам вендер присылает толк.

>> Всё, я понял. И ещё у меня был вопросик. Смотри. О, ну, наверное, какое количество встреч вообще обрабатывается? Сколько мощностей у вас эта история съедает? Вы это делаете в оффлайне или в реалтайме? Очередь какая-то реализована на обработку?

>> А, ну да, конечно, это реализовано очередями, потому что с нейросетями, по-моему, по-другому невозможно работать с языковыми моделями. А, ну тут нужно понимать, что в у нас в языковую модель ещё параллельно идут запросы не только от нашей системы, но и от многих других. Вот поэтому сейчас отве чуть отвлеклась, отвечу на вопрос. А значит, вообще это занимает какое-то время. То есть сначала мы ждём, пока станет доступен транскрипт в контурлкапе. То есть они тоже не сразу его нам присылают. Потом мы его забираем и получается здесь у нас уже чисто идёт набор очередей. То есть вот все этапы, про которые я рассказывала, у нас на первом этапе, ну, мы очень много раз отправляем транскрипт в языковую модель. И на всех этапах у нас реализованы очереди, то есть у нас просто, э, Джоба отрабатывает там раз в 5 минут по обработке встреч. И вот, например, у нас на первом этапе стоит нужна языковая модель для этого. У нас здесь идёт очереди, очередь может быть, ну, определённая задержка возникнуть. Потом на следующем этапе там определение категории, самаризация, там тоже определённая, ээ, ну, возникают очереди, но как бы сейчас в данный момент вот раз в 5 минут мы ходим, э, ну, осуществляем вот эту обработку, а модели справляются с этим. То есть никаких моментов, что вот прямо немножко не об этом вопрос. Энтересует утилизация машинного имени. Ну, то есть смотри, количество встреч сколько, допустим, 100 встреч в час. Вот, соответственно, вы отправляете каждые 5 минут, там идёт какая-то загрузка, у вас есть определённая, а, машинная мощность, да, там какая-то гпушки какие-то стоят. Вот сколько этих гпушек, сколько вы зараз можете обработать условно этих гпушек? Какая утилизация происходит?

>> Ну, то есть >> ну вот здесь, да, поняла вопрос. Э, ну, насчёт, э, 100 встреч в час такое возможно в какие-то нагруженные часы? Насчёт мощностей по LLM не могу ничего ответить.

>> Эй, >> я просто я не в курсе.

>> Да, Магата, у тебя что-то заблокировано, разблокировано или как? Агата всё равно.

>> Да, >> Кирилл, у тебя микрофон.

>> Извините, >> у меня есть вопросик небольшой. Возможно, упоминалось, как долго вы пробуете эту систему на практике?

>> Нет, это не обсуждалось. Спасибо за вопрос. Где-то по сейчас я скажу поточнее, да, в августе у нас был запущен, ну, так скажем, пило аля пилот MVP. Вот вот это вот эта система в том виде, в котором мм про которые я рассказывала, она работает с декабря. Мы зарелизились в декабре. Вот эту систему мультичанкинга и всего прочего, ну, с декабря

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

>> Ну, кстати, нет, э, вот такого эффекта нет. А наоборот, э коллеги отмечают, э положительный эффект от нашей системы. А то есть каким образом мы это понимаем? Во-первых, есть положительная обратная связь, а то, что они с удовольствием, во-первых, ждут этих самре, а чтобы именно получить фиксацию договорённости. То есть, естественно, на встрече ты не отключаешься, а потому что в момент происходит обсуждение какое-то. Вот. А именно фикса, за фиксацию договорённости отвечает наша система. И вот в какой-то степени это становится проблемой, когда у нас, например, происходит сбой на нашей стране. То есть у нас система имеет очень много интеграции и как бы на какой-то где-то, да, может в какой-то момент не сработать. И вот если самари не пришли, например, произошёл какой-то массовый сбой, мы получаем очень много жалоб непосредственно от пользователей тоже, потому что на самре рассчитывают. Вот таким образом, да, я немножко тут поменяла свою позицию в ходе ответа, но здесь, наверное, 50 на50. То есть в моменте навстрече вовлечённость не снижается, но договорённости фиксировать в вот именно текстом уже никто не фиксирует, потому что рассчитывают, что им сделает этонсеть. Вот такой ответ.

>> И ещё небольшой дополнительный вопрос. Э может ли есть ли у этой системы какой-то предиктивный эффект? То есть, если вы раскладываете данные на вектора, ээ может ли она в реальном времени условно сказать, что через 10 секунд вот такой сотрудник будет вовлечён, потому что это его задача, потому что мы где-то рядом, и нужно отправить ему пуш, чтобы он пришёл с другого созвона.

>> Это, кстати, очень интересно, интересный момент, но нет, у нас такого нет. Такое мы ещё не умеем. Умеем только обрабатывать, искать, фиксировать договорённости. Ну, пока нет.

>> Понял. Спасибо.

>> Да, Тань, спасибо, что позвала. Тоже было очень интересно. Вообще очень много знакомых лиц. Всем привет. А >> спасибо, что пришли. Очень приятно. Да, вот если не секрет, долго разрабатывали эту систему, каким составом? Ну и вот, ну, как как бы так такую вот процессную часть, то есть, >> я так понял, у тебя была там ведущая роль.

>> Ну, по факту, да, не в MVP. MVP делалось до меня, а потом уже вот та те фичи те фичи, про которые я рассказывала, там уже, да, непосредственно я их делала. А в команде непосредственно, точнее не в команде, а коллеги, которые работали над этим над этими фичами, три, э, фулстака, ну, как бы там у нас много систем, поэтому мы в целом между ними иногда мигрируем. И Но в сухом остатке работало три человека над вот этими фичами. Если мы берём фулстаков, а мы пишем на в иноджесе. И плюс один ML разработчик. То есть вот момент с гибридным раго. А это были во многом идеи, предложения и м, скажем так, а тестирование гипотез по Весам, про которые я тоже рассказывала, про а ранжирование. Это были во многом идеи ML-разработчика. Ну а там в целом командная работа была вот по срокам. А здесь, на самом деле, интересный момент. Точно я прямо ответить не могу, потому что у нас R&D команда, и у нас, как правило, когда мы начинаем какую-то задачу, у нас нет видения конечного результата. То есть как бы даже не результата, а окончательного пути, к которым мы к этому результату сможем прийти. Поэтому вот вот та тот мультичанкинг и тот гибридный поиск, про который я рассказала - это вторая или даже третья итерация была. А, то есть всё это дорабатывалось, потом тестировалось, ещё дорабатывалось. И вот мы остановились в итоге в декабре вот на таком формате работы. Нас сейчас он полностью устраивает. То есть, э, эту систему мы как будто, ну, вот конкретно вот эту часть системы мы как будто больше не трогаем, потому что она работает достаточно хорошо. Вот так. Надеюсь, ответила на вопрос.

>> Да, спасибо, Таня. Ещё такой вопрос. Смотри, вот перед тем, как отправить самри по встрече, есть какой-то блок валидации, что там не отправляется фигня какая-то?

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

>> Спасибо.

>> У меня ещё один вопрос прошедшую тему. предыдущего спикеру. Случайнысь ли ситуации, когда договорённости, которые для человеческого уха звучат как сформулированные и договорённые пропускались нейронкой? Либо наоборот? И в таком случае у вас на практике приходило к тому, что результат записи разговора является каким-то последним аргументом. Ну, то есть кто-то говорит, условный руководитель, я сказал тебе и тебе сделать вот это и это. А они говорят: "Да нет, смотри, не говорил".

>> Ага, я поняла вопрос. А, но на самом деле ни разу не слышала, чтобы сам Мария использовалась как инструмент какого-то подтверждения в конфликтах, но тут нужно понимать, что у нас всегда есть ссылка на запись в письме. То есть мы можем конкретно услышать из уст того человека, который это говорил, какую-то конкретную реплику. И в целом какие-то вопросы, вот, например, если мы умный чат даже берём, а мы можем задавать какие-то вопросы, можем попросить ссылку на запись, он также может её прислать. И если прямо какие-то серьёзные моменты, ну, как будто лучше всё-таки не опираться на нейросеть, они ещё не настолько совершенные, а лучше э посмотреть видео. Но ссылку на запись можно найти с помощью нашего умного чата. Ну, про такие кейсы всё равно не слышал.

>> Это я сейчас собрала просто ответ. Каждому созвону, получается есть видеозапись разговора, которая хранится у пользователей или на стороне сервиса. И в одном, в другом случае, как будто бы возникает проблема, что через год это будет огромный объём данных.

>> А, ну храним запись не мы, мы храним только ссылку на запись. То есть у контртолка есть пространство, соответственно, всё хранится там.

>> Угу. Благодарю. Так быстро вопросы закончились. О'кей, ребята, есть ещё вопросы?

>> Есть, есть.

>> Неожиданно.

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

>> Так, давай смотреть >> вот шесть параллельных. Это что такое?

>> Да, это шесть параллельных каналов поиска, которые мы используем, чтобы найти релевантную встречу нам. Вот что это за каналы? А, ну это я в целом подробно рассказала, но в двух словах, если отвечать, а мы используем два типа поиска. Во-первых, векторный и полнотекстовый. И э ищем по тем чанкам, которые мы выделяем, ну, на самом первом этапе.

>> То есть вот это на канале есть шесть шесть канов.

>> Каким образом?

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

>> Ну, то есть за счёт вот этих шести методов вы как раз этих галлюцинацию избегаете. Получается так.

>> А это нам позволяет находить релевантные конференции. Ой, ну да, релевантные конференции, релевантные встречи по запросу пользователя. То есть, ну, не сказать, что мы прямо избегаем. Это скорее, знаешь, про что? Про поиск м ну про поиск релевантной встречи, да? То есть, если, например, взять, э, ну, за основу, что вот у меня, например, в день там было, ну, не знаю, ладно, в неделю, а сколько сколько могло быть встреч в неделю, например, там 25-30 встреч, да? И я хочу среди них найти какую-нибудь конкретную. Вот если брать пример, на который обсуждались сроки авторизации, и как бы нам по вот этим всем встречам нужно найти наиболее релевантную, но как бы это я сейчас неделю взяла условно. А пользователь может спрашивать, что было полгода назад, что было там несколько месяцев назад. И нам нужно как бы поднять всю эту информацию и найти среди неё, что он имел в виду. И здесь нужно понимать, что пользователь не будет формулировать, скорее всего, запрос в тех словах и выражениях, которые прозвучали на встрече. И именно этот момент покрывается косинусной близостью, то есть покрывается векторным поиском. Именно поиск по смыслу.

>> Смотри, некоторое сематическое ядро. Как раз вот ты говоришь про по смыслу. Вот у нас часто мы сталкиваемся в векторе с проблемой. У нас в документе написано, допустим, супруга, пользователь спрашивает про жену. Вы что делаете? Как ядро формируете?

>> Ну вот здесь я прямо вообще по идее, короче, я вот прям мм как это реализовано на стороне модели, которая у нас отвечает за имбединги, я не знаю, потому что не мы за неё отвечаем, мы используем только IP. Но в целом в смысловом пространстве они должны быть примерно равнонаправлены.

>> Су, >> то есть получается, что у вас, когда кто-то какая-то модель раскладывает на мбендинге, она как раз уже как-то маркирует по синонимам или как?

>> Ну, по факту, да. И здесь есть ещё момент, э, по которому мы вообще всё вот это делали. То есть зачем нам топики, реплики, действия? Мы, по идее, могли бы просто, ну, взять куски транскрипта и условно загнать их в языковую модель и взять оттуда эмбдинги и как бы по ним искать. Но это так не работает. А вот именно потому, что м эмбединг берётся от всего чанка сразу. И если мы берём какую-то реплику, у меня там могло прозвучать очень много слов. То есть мне, ну, как бы мне как пользователю нужно найти слово авторизация и, ну, потом как бы точнее в базе данных нам нужно найти, где употреблялось слово авторизация. Но у меня там помимо слова авторизации прозвучало ещё миллион слов. И вот мм значение вектора здесь будет сильно перетягиваться аа всеми остальными словами. То есть здесь нужно понимать, что мы берём именно от э всей фразы, всей реплики мы берём бединг. И для этого мы делаем по топикам и по экшенам мы выделяем, чтобы просто вот именно в смысловом пространстве мы могли эту самую несчастную авторизацию найти, даже если вот по репликам, по самим мы её не найдём, потому что там, ну, как бы вектор сильно смещён в другую сторону.

>> Так говорится, очень интересно, ни хрена не понятно. Всё равно спасибо. Я попыталась объяснить, честно, если есть какие-то наводящие вопросы, я могу попытаться ответить ещё более понятным языком.

>> Тань, а реализована как-то защита? Ну, например, я хочу узнать сам или по другой встрече, на которой я не был и на которую я не приглашён?

>> Нет, у нас там ээ идут жёсткие фильтры по участникам. То есть пользователь не может, ну, не может искать, ээ, по чужим встречам, не может смотреть чужие договорённости. Он находится только в том, ну, он получает встречи только из того контекста, в котором он есть. Это на уровне базы данных. Здесь никаких глюков нейронки не может быть, потому что мы это захардкодили, условно, жёсткие фильтры.

>> Угу. Понятно. Ну тогда я тоже задам один маленький вопрос. Насколько вообще приятно работает с лмками? Ну, вообще в целом, а здесь есть очень большая специфика, особенно если взять момент перехода от просто работы с кодом и с обычными опишками, где данные чётко задокументированы заранее. Вот именно вот этот момент перехода на работу с нейросетями, я бы сказала, что он довольно непростой, потому что есть определённая специфика. И здесь даже дело не в том, что нужно там обрабатывать с помощью очередей и всего остального, а именно, а, ну вот как будто, э, нужно это прочувствовать. Такое странное слово на технической конференции будет, но как будто как будто, да, то есть, э понять, как именно работает модель конкретная, вот прямо досконально можно, но всё равно надо приспосабливаться к каждой конкретной модели. То есть вот если, например, э мы берём разные модели, берём там не в контексте уже нашего проекта, а вообще в целом, а какой-нибудь GPT, а берём там, например, а Квен, они будут по-разному работать с текстом, они будут по-разному работать с ответами на технические вопросы, на нетехнические вопросы и на разные. То есть нужно, но нужна насмотренность для того, чтобы понять, вот эта модель конкретная, она на какие вопросы лучше отвечает. Вот я бы ответила так. Но в целом это интересное, это интересный опыт. Мне в целом нравится работать.

О'кей. Я думаю, исходя из таймслота выделенного, ребят, давайте заканчивать тогда наше выступление. Вот. Спасибо большое тебе, было максимально интересно. Да, спасибо большое всем, спасибо организаторам и спасибо всем, кто пришёл. Особенно приятно было видеть знакомые лица и новые тоже. Так что спасибо всем большое. Спасибо за интересные вопросы. Было очень приятно.

>> Спасибо, Татьяна.