Drugi mózg: Przekształcanie notatek z spotkań w graf wiedzy nadający się do wyszukiwania

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.

Potrzebny był system zdolny do masowego przetwarzania transkryptów spotkań, automatycznego wydobywania strukturyzowanych informacji oraz umożliwiający ludziom wyszukiwanie tych informacji za pomocą zwykłego języka angielskiego — przy jednoczesnym tworzeniu dynamicznego mapowania relacji, które staje się coraz bogatsze z każdym dodanym spotkaniem. System ten otrzymał nazwę Second Brain.

Wizja: Dynamiczna grafika wiedzy dla każdego projektu

Podstawowa idea jest prosta. Za każdym razem, gdy zostanie przesłany transkrypt spotkania, system go analizuje, aby określić, kto mówił o którym projekcie, jakie decyzje zostały podjęte, jakie ryzyka się pojawiły oraz kto jest odpowiedzialny za dane działania następcze. Wszystko to jest zapisywane w Azure Cosmos DB. Stamtąd można zadać pytanie w języku naturalnym i otrzymać odpowiedź w formie punktowanych informacji z odniesieniami.

Gdy gromadzi się coraz więcej transkrypcji, naturalnie kształtuje się graf wiedzy — rozwijająca się sieć łącząca osoby, decyzje, działania i ryzyka z każdej nagranej sesji.

Interfejs rozwiązania

System oferuje interaktywny interfejs użytkownika, który umożliwia przesyłanie transkrypcji, przeglądanie wydobytych entytetów, zadawanie pytań w języku naturalnym oraz wizualne badanie powstałego grafu wiedzy.

Bliższe spojrzenie na komponenty

1. Extract_Entities_Tool — Wydobywanie w sposób równoległy

To narzędzie wykonuje najtrudniejszą pracę. Na podstawie surowego ciągu tekstu dzieli ono transkrypcję na fragmenty zgrupowane według akapitów, wykonywa wydobywanie entytetów z każdego fragmentu równocześnie przy użyciu ThreadPoolExecutor, a następnie łączy wyniki poprzez ocenianie każdej unikalnej wartości pod kątem pewności wydobywania oraz częstotliwości jej występowania.

Zdefiniowano siedem typów entytetów w formacie oddzielonym przecinkami, który model językowy może konsekwentnie stosować.

W rezultacie model wytwarza wyniki takie jak "Architektura recenzji | Właściciel: Archana | Termin: Następny sprint" — ciąg znaków, który aplikacja może następnie przetworzyć na ustrukturyzowane słowniki {task, owner, due}, gotowe do szczegółowego wyświetlania oraz tworzenia krawędzi w grafie.

Autonomiczne odkrywanie terminów z danej dziedziny

Jedną z ważnych decyzji projektowych było całkowite pominięcie parametru wejściowego domain_context i zamiast tego pozwolenie modelowi na samodzielne odkrywanie słownictwa specyficznego dla danej dziedziny. Każde polecenie używane do wyodrębniania fragmentów tekstu zawiera dedykowaną sekcję, w której prosi się model o zidentyfikowanie terminów z danej dziedziny, skrótów oraz nazw systemów występujących w tekście.

2. Text2SQL_CosmosDB_Tool — Wywoływanie w języku naturalnym

To komponent przyjmuje pytanie napisane zwykłym językiem angielskim wraz z wskazówką opisującą schemat Cosmos, przekształca je w zapytanie SQL dla Cosmos, wykonuje je i generuje odpowiedź na podstawie uzyskanych wyników. Trudnością jest to, że dialekt SQL NoSQL w Cosmos DB nie pozwala bezpośrednio używać funkcji CONTAINS() w polach tablicowych. Rozwiązaniem było dostarczenie narzędziu wyraźnej wskazówki dotyczącej schematu, która opisuje, w jaki sposób należy zamiast tego wyszukiwać dane w tablicach.

3. Cosmos DB jako sam mózg

To zbiór danych stanowi serce całego systemu. Nie pełni funkcji cache ani magazynu logów — Cosmos DB jest w rzeczywistości Drugim Mózgiem, warstwą pamięci trwałej, w której przechowywane są wszystkie pozyskane informacje, gromadzone i udostępniane do wyszukiwania.

Każdy dokument z wyodrębnionymi informacjami z spotkań przechowuje każdą entytetę dwukrotnie: raz jako prosty tabliczka ciągów znaków, co umożliwia zapytania oparte na SQL, a raz jako tabliczka strukturyzowanych obiektów, co zapewnia szczegółowe wyświetlanie w interfejsie użytkownika oraz generowanie krawędzi grafu. Ta podwójność powoduje niewielki dodatkowy zużycie pamięci na dokument, ale pozwala uniknąć konieczności analizowania danych na warstwie aplikacji po ich przyjściu z bazy danych.

Analogia mózgu — dwa tryby pamięci

Pamięć ludzka funkcjonuje w dwóch odrębnych trybach: pamięci epizodycznej, która przechowuje to, co faktycznie wydarzyło się podczas danego zdarzenia, oraz pamięci semantycznej, która przechowuje ogólne fakty i definicje – co oznacza dana skrót, kim jest określona osoba. Model danych Cosmos został celowo zaprojektowany tak, aby odzwierciedlać to rozdzielenie, przechowując dane epizodyczne dotyczące konkretnych spotkań oddzielnie od rosnącego semantycznego glosariusza osób, terminów i systemów.

Kluczowe decyzje inżynieryjne

Wiele świadomych wyborów wpłynęło na funkcjonowanie systemu – od decyzji o rezygnacji z ręcznej konfiguracji domeny na rzecz automatycznego odkrywania, przez przechowywanie danych entytetów w sposób redundancyjny zarówno dla potrzeb SQL, jak i interfejsu użytkownika, aż po ograniczenie roli LLM wyłącznie do ekstrakcji informacji i generowania zapytań, bez pozwalania mu na formatowanie lub ustalanie reguł biznesowych.

Lekcje wyciągnięte

1. Zachowanie ponownego uruchamiania w Streamlit wymaga starannego zarządzania stanem. Każde kliknięcie przycisku powoduje ponowne wykonanie całego skryptu od początku. Wszystko, co musi przetrwać między interakcjami, musi zostać zapisane do st.session_state przed narysowaniem przycisku uruchamiającego ponowne wykonanie, a nie później.
2. Dialekt SQL w Cosmos DB nie jest standardowym ANSI SQL. Funkcja CONTAINS() działa tylko na ciągach znaków, a nie na tablicach, dlatego model wymaga wyraźnych wskazówek w schemacie — w tym co najmniej jednego przykładu błędnego sposobu napisania zapytania.

Nie można polegać na modelach językowych, że zawsze będą przestrzegać instrukcji dotyczących formatu wyjściowego. Nawet przy jasnych instrukcjach syntezy model czasami zwraca jedynie krótkie zdanie wprowadzające zamiast pełnej odpowiedzi. Z tego powodu deterministyczne rozwiązanie awaryjne, które buduje odpowiedź bezpośrednio na podstawie surowych uzyskanych danych, nie jest dodatkowym ulepszeniem — to konieczna zasłona bezpieczeństwa.

Narzędzia powinny mieć wąskie, dobrze zdefiniowane obowiązki. Kuszące jest włączanie logiki formatowania, zasad biznesowych lub wiedzy specjalistycznej bezpośrednio do narzędzia, ale należy temu oprzeć się — narzędzie powinno być odpowiedzialne dokładnie za jedną funkcję.

Aby wyświetlić wykresy Pyvis wewnątrz Streamlit, konieczne jest zapisywanie danych do pliku tymczasowego zamiast przekazywania ciągu znaków pamięciowego. Należy użyć tempfile.NamedTemporaryFile i pamiętać o usunięciu tego pliku później. Warto również zaznaczyć, że st.components.v1.html ma zostać wycofane od 2026-06-01, dlatego w przyszłości należy używać st.iframe.

Główna koncepcja projektu

Prawdziwa inteligencja w takim systemie nie pochodzi z modelu językowego — pochodzi z magazynu pamięci, który za nim stoi.

Sam model nie posiada żadnej pamięci; z natury jest bezstanowy. Czyta fragment tekstu i generuje zestaw entytetów, czyta pytanie i tworzy zapytanie SQL. Nic nie jest przechowywane między wywołaniami — każde z nich rozpoczyna się od zera.

Cosmos DB to miejsce, w którym znajduje się rzeczywista pamięć. W momencie, gdy coś zostanie zapisane w „mózgu”, tymczasowe wydobycie informacji z modelu przekształca się w trwały, uporządkowany i możliwy do wyszukiwania zapis. Słownik terminów specjalistycznych stale się rozszerza, a sieć powiązań między elementami systemu rośnie. Wiedza z biegiem czasu się pogłębia.

Cały system działa na istniejącej już infrastrukturze — Azure VMs, Azure Functions, Azure Cosmos DB oraz Azure OpenAI — koordynowanej za pośrednictwem AGF Hub. Nie wprowadzono żadnych nowych usług, ani nie było potrzeby skomplikowanych procesów. Kluczem do jego funkcjonowania była starannie zaprojektowana baza pamięci, jasne zasady dotyczące obowiązków poszczególnych narzędzi oraz model językowy, którego zadaniem jest po prostu odczytywanie notatek z spotkań, aby ludzie nie musieli tego robić osobiście.

Literatura pokrewna

• Dlaczego koszty agencyjnego AI rosną: model kosztów oparty na architekturze — Wyjaśnia, dlaczego koszty agentów opartych na LLM należy mierzyć według ukończonych zadań, a nie według połączeń, oraz przedstawia narzędzia architektoniczne takie jak routowanie modeli, budżety kontekstu i cache do kontrolowania wydatków.
• Zrozumienie agentów AI: cele, narzędzia, pamięć i pętla agenta — Przystępne dla początkujących wyjaśnienie różnic między agentami AI a chatbotami, obejmujące podstawowe komponenty, pętlę decyzyjną, poziomy autonomii oraz praktyczne zastosowania w rzeczywistym świecie.

RAG vs Agentic RAG vs Graph RAG: Wybór odpowiedniej architektury wyszukiwania — Dowiedz się, dlaczego prosty model RAG zawodzi przy pytaniach wieloetapowych i danych strukturyzowanych, oraz w jaki sposób pętle agentywne i wyszukiwanie oparte na grafach rozwiązują różne słabości tego podejścia.

Zmniejszanie halucynacji w pipeline’u chatbota medycznego opartego na RAG — Poznaj, jak hybrydowe wyszukiwanie, ponowna sortowanie wyników oraz ścisła polityka zakazująca tworzenia fałszywych informacji pozwalają stworzyć bardziej wiarygodnego chatbota do badań medycznych wykorzystującego technologię RAG.

Wyjaśnienie Retrieval-Augmented Generation: Usprawnianie luk wiedzy LLM — Dowiedz się, dlaczego modele LLM tworzą halucynacje i stają się przestarzałe, a następnie zobacz krok po kroku, jak RAG pobiera dane, dzieli je na fragmenty, wstawia informacje i ulepsza prompty, aby to naprawić.