Второй мозг: преобразование стенограмм собраний в поисковую знаниевую сеть

The Problem

Nearly every organization depends on meetings to move work forward — planning discussions, calls with clients, sprint retrospectives, workshops for discovery. Each of these generates a steady flow of decisions, action items, risks, and commitments. And almost without exception, that information simply evaporates afterward.

The transcript gets dropped into a shared drive somewhere. Action items sit in someone's notebook for a while, then fade from memory. Weeks later, someone asks what was actually decided about a particular approach, and nobody can give a clear answer.

This isn't really a storage issue — the data exists somewhere. The real problem is that meeting content is unstructured, scattered across tools, and effectively invisible to any kind of search.

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

Визия: динамическая графовая структура знаний для каждого проекта

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

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

Интерфейс решения

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

Более подробный взгляд на компоненты

1. Extract_Entities_Tool — параллельная обработка

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

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

В результате модель генерирует выходные данные вроде "Review architecture | Owner: Archana | Due: Next sprint" — строку, которую приложение может затем преобразовать в структурированные словари {task, owner, due}, готовые к детальной отрисовке и формированию ребер в графе.

Автономное обнаружение терминов домена

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

2. Text2SQL_CosmosDB_Tool — Воспроизведение в естественном языке

Этот компонент принимает вопрос на обычном английском языке вместе с подсказкой, описывающей схему Cosmos, преобразует его в запрос Cosmos SQL, выполняет его и формирует ответ на основе полученных результатов. Сложность заключается в том, что диалект SQL NoSQL в Cosmos DB не позволяет напрямую использовать функцию CONTAINS() для полей-массивов. Решением стало предоставление инструменту явной подсказки о схеме, описывающей, как следует выполнять запросы к массивам.

3. Cosmos DB как сам мозг системы

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

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

Аналогия с мозгом — два режима памяти

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

Основные инженерные решения

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

Уроки, извлеченные

1. Поведение функции повторного запуска в Streamlit требует тщательной обработки состояния. Каждое нажатие кнопки приводит к повторной выполнению всего скрипта с самого начала. Все то, что должно сохраняться между взаимодействиями, необходимо записать в st.session_state до того, как будет отрисована кнопка, запускающая повторный запуск, а не после этого.
2. Диалект SQL в Cosmos DB не является стандартным ANSI SQL. Функция CONTAINS() работает только с строками, а не с массивами, поэтому в описании структуры данных требуется четкое указание способа использования — включая хотя бы один пример неверного способа написания запроса.

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

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

Для отрисовки графиков Pyvis внутри Streamlit необходимо записывать данные в временный файл, а не передавать строку в памяти. Используйте tempfile.NamedTemporaryFile и не забудьте удалить его позже. Также стоит отметить, что st.components.v1.html планируется к устареванию с 2026-06-01, поэтому в будущем следует использовать st.iframe.

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

Сама модель совершенно не имеет памяти; по своей природе она является безсостоянийной. Она читает фрагмент транскрипции и генерирует набор сущностей, читает вопрос и формирует SQL-запрос. Ничто не сохраняется между вызовами — каждая инициализация начинается с нуля.

Cosmos DB — это место, где хранится фактическая память. Как только что-то сохраняется в «мозг», временно извлечённое из модели превращается в стабильную, структурированную и поисковую запись. Словарь терминов данной области постоянно пополняется. Сеть взаимосвязей расширяется. Знания со временем накапливаются друг на друга.

Весь системный комплекс работает на уже существующей инфраструктуре — Azure VMs, Azure Functions, Azure Cosmos DB и Azure OpenAI — координируемой через AGF Hub. Никаких новых сервисов не вводилось, и не требовалась сложная система обработки данных. Основой её работы стал тщательно спроектированный хранилище памяти, чёткие границы ответственности каждого инструмента и языковая модель, задача которой заключается просто в чтении записей собраний, чтобы людям не приходилось этого делать.

Связанные материалы

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

RAG против Agentic RAG против Graph RAG: как выбрать подходящую архитектуру поиска — Узнайте, почему примитивный RAG не справляется с вопросами, требующими многократных переходов, и с структурированными данными, а также как циклы типа agentic и поиск на основе графов устраняют соответствующие недостатки.

Сокращение галлюцинаций в конвейере медицинского чат-бота на основе RAG — Узнайте, как гибридный поиск, переранжирование результатов и строгая политика отказа от выдумок позволяют создать более надежного медицинского чат-бота для исследований с использованием технологии RAG.

Объяснение технологии Retrieval-Augmented Generation: как устранять пробелы в знаниях ИИ — Узнайте, почему искусственные нейронные сети создают ложную информацию и устаревают, а затем пошагово ознакомьтесь с тем, как технология RAG загружает данные, разбивает их на фрагменты, встраивает информацию и дополняет запросы для решения этих проблем.