Другий мозок: перетворення стенограм зустрічей на знаннєву графіку для пошуку

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 та інтерфейсу користувача, а також до обмеження ролі LLM лише до вилучення інформації та створення запитів, а не до форматування чи встановлення бізнес-правил.

Уроки, винесені з досвіду

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 зазнає невдач при роботі з запитами багатьох кроків та структурованими даними, а також як агентні цикли та пошук на основі графів усувають різні слабкості.

Зменшення галюцинацій у конвеєрі медичного чат-бота на основі RAG — Дізнайтеся, як гібридний пошук, переранжування та сувора політика відмови від вигадок допомагають створити більш надійного медичного чат-бота для досліджень за допомогою RAG.

Пояснення концепції Retrieval-Augmented Generation: як усунути прогалини в знаннях LLM — Дізнайтеся, чому LLM створюють хибну інформацію та втрачають актуальність, а потім дізнайтеся крок за кроком, як технологія RAG здійснює пошук, розділення на частини, вбудовування даних та покращення запитів для усунення цих проблем.