Jak Dynamic Semantic Module doopravdy funguje

Co je DSM?

Dynamic Semantic Module je proprietární engine StellarBase pro porozumění datům. Na rozdíl od tradičních vyhledávání nebo RAG systémů, které berou dokumenty jako izolované kusy textu, DSM staví živý znalostní graf, který zachycuje vztahy, entity a sémantická propojení napříč celým vaším datovým korpusem.

Představte si to takhle: když několik měsíců čtete firemní dokumenty, přirozeně si stavíte mentální model toho, jak věci souvisí. Víte, že „Q3 report” se vztahuje k „Q2 reportu”, že „Project Atlas” zahrnuje engineering tým a že konkrétní smlouva odkazuje na konkrétního klienta. DSM dělá totéž — automaticky, ve velkém a bez jakéhokoli LLM zapojeného do procesu porozumění.

Tohle je zásadní rozdíl. DSM nevolá GPT-4 ani Claude, aby porozuměl vašim dokumentům. Používá vlastní účelové modely pro extrakci entit, detekci vztahů a sémantickou analýzu. LLM přijde na řadu až ve chvíli, kdy se uživatel zeptá — a tou dobou už DSM odvedl tu těžkou práci s porozuměním datům.

Tři fáze

DSM zpracovává každý dokument třemi sekvenčními fázemi. Každá fáze staví na výstupu té předchozí a postupně obohacuje znalostní graf.

Fáze 1: Analýza obsahu

Když dokument vstoupí do systému, DSM nejdřív provede hlubokou analýzu obsahu. Tohle jde mnohem dál než prostá extrakce textu. Engine identifikuje:

• Pojmenované entity — osoby, organizace, lokality, produkty, data, peněžní hodnoty
• Klíčové koncepty — témata, motivy a doménově specifická terminologie
• Strukturní prvky — nadpisy, sekce, tabulky, seznamy a jejich hierarchie
• Sentiment a záměr — je to návrh, report, stížnost, rozhodnutí?
• Časové ukazatele — kdy to bylo napsáno, jaké období to pokrývá, jsou tam termíny?

Analýza obsahu běží lokálně přes pipelinu specializovaných modelů — jeden pro NER, jeden pro topic modeling, jeden pro parsování struktury. Každý model je malý (pod 500 MB) a optimalizovaný na propustnost. V téhle fázi žádná data neopouští vaši infrastrukturu.

Fáze 2: Objevování vztahů

Jakmile jsou entity a koncepty extrahované z jednotlivých dokumentů, DSM hledá propojení napříč celým korpusem. Tady se děje to kouzlo.

Engine na objevování vztahů používá kombinaci přesné shody, fuzzy matching a sémantické podobnosti, aby našel propojení, která by tradiční vyhledávání minulo. Identifikuje šest typů vztahů:

Semantic:    "cloud infrastructure" ↔ "AWS deployment guide"
Temporal:    "Q3 Report" → follows → "Q2 Report"
Structural:  Chapter 3 → part_of → "Architecture Manual"
Referential: Email → mentions → "Project Atlas"
Causal:      "Server migration" → caused → "Downtime incident"
Authorial:   "Design spec" → created_by → "Engineering team"

Objevování vztahů je inkrementální. Když do systému přijde nový dokument, DSM nezpracovává celý korpus znovu. Identifikuje entity v novém dokumentu a porovnává je proti existujícímu grafu, přidává nové uzly a hrany v reálném čase. Nový dokument je plně integrovaný do grafu pod 200 milisekund.

Fáze 3: Sestavení grafu

Závěrečná fáze sestaví všechny entity, koncepty a vztahy do dotazovatelného znalostního grafu. Tohle není statická datová struktura — je to vážený orientovaný graf, kde váhy hran reprezentují sílu propojení a kontinuálně se aktualizují, jak přibývají nová data.

Document: "Q3 Revenue Report"
  ├── mentions: "ACME Corp" (Organization)
  ├── contains: "$2.4M ARR" (Metric)
  ├── references: "Enterprise Plan" (Product)
  ├── authored_by: "Sarah Chen" (Person)
  └── relates_to: "Q2 Revenue Report" (Document)
       ├── mentions: "ACME Corp" (Organization)
       ├── contains: "$1.8M ARR" (Metric)
       └── shows_trend: +33% growth

Graf podporuje multi-hop traversal, což znamená, že dotazy mohou sledovat řetězce vztahů a najít odpovědi, které se rozpínají přes více dokumentů. Zeptejte se „Jak si stojí ACME Corp?” a DSM dokáže projít z uzlu firmy na finanční reporty, růstové trendy, členy týmu a aktivní smlouvy — vše v jednom průchodu grafem.

DSM vs. tradiční RAG

Retrieval-Augmented Generation se stalo standardním přístupem pro ukotvení LLM v podnikových datech. Ale RAG má fundamentální limity, které DSM byl navržený překonat.

Jak funguje RAG

Tradiční RAG rozseká dokumenty na chunky, naembeduje je jako vektory a získá top-K nejpodobnějších chunků pro daný dotaz. Získané chunky se pak pošlou do LLM jako kontext. Tohle dobře funguje pro jednoduché, přímé otázky, ale rozpadá se u čehokoli, co vyžaduje syntézu nebo uvažování přes více dokumentů.

Kde RAG selhává

• Nezná vztahy — RAG bere každý chunk jako nezávislý. Neví, že dva chunky z různých dokumentů jsou o stejném projektu nebo že si jeden protiřečí s druhým
• Problém hranic chunků — důležitý kontext často přesahuje přes víc chunků. Když tabulka začíná v jednom chunku a končí v druhém, embedding přesně nezachytí ani jednu část
• Nemá časové porozumění — RAG nedokáže rozlišit mezi Q2 reportem a Q3 reportem, pokud dotaz explicitně nezmiňuje kvartál. Nechápe, že jeden nahrazuje druhý
• Strop recallu — top-K retrieval znamená, že vidíte jen K chunků, i když odpověď vyžaduje informace z 20 různých dokumentů
• Drift embeddingů — stejný koncept vyjádřený jinak ve dvou dokumentech může mít velmi rozdílné vektorové reprezentace, což způsobuje minutí při retrieval

Jak to DSM řeší

// Traditional RAG
query: "How is ACME Corp doing?"
→ vector search → top-5 chunks → LLM summarizes
→ "ACME Corp revenue is $2.4M" (no context, no trend)

// DSM-powered query
query: "How is ACME Corp doing?"
→ graph traversal → connected nodes → full context
→ "ACME Corp ARR grew 33% from $1.8M to $2.4M between Q2-Q3,
   driven by Enterprise Plan adoption. Sarah Chen's team
   manages the account." (rich, connected answer)

DSM nenahrazuje vektorové vyhledávání — rozšiřuje ho. Když přijde dotaz, DSM nejdřív identifikuje relevantní entity a koncepty, pak prochází znalostním grafem a sbírá propojený kontext. Tenhle kontext je mnohem bohatší než to, co by sám top-K retrieval vrátil, a obsahuje informace o vztazích, které LLM může použít k vygenerování přesnějších a kompletnějších odpovědí.

Proč žádná závislost na LLM pro porozumění

Častá otázka, kterou dostáváme: „Proč prostě nepoužít GPT-4 k analýze dokumentů a extrakci vztahů?” Jsou tři důvody:

• Cena — zpracování milionu dokumentů přes GPT-4 by stálo desítky tisíc dolarů. Lokální modely DSM zpracují stejný korpus jen za cenu výpočetního výkonu
• Soukromí — posílat každý dokument přes externí LLM k analýze je v rozporu se smyslem self-hosted znalostní platformy. DSM drží veškeré porozumění lokálně
• Konzistence — LLM jsou nedeterministické. Stejný dokument zpracovaný dvakrát může vyplodit různé extrakce entit. Modely DSM jsou deterministické — stejný vstup, stejný výstup, pokaždé

LLM jsou výborné na generování odpovědí v přirozeném jazyce. Nejsou ten správný nástroj pro systematické, velkoškálové porozumění datům. DSM zvládá porozumění; LLM zvládá konverzaci.

Výkonové charakteristiky

DSM je navržený zvládat data v podnikovém měřítku. Tady jsou čísla z našich interních benchmarků:

Benchmark: 1M documents, 50K unique entities

Indexing throughput:     ~2,400 documents/minute
Graph construction:     ~45 minutes for full corpus
Incremental update:     <200ms per new document
Query (graph traversal): <15ms avg, <50ms p99
Memory footprint:       ~2.1 GB for full graph
Storage overhead:       ~12% of source document size

Graf je uložený ve vlastním formátu optimalizovaném na rychlost průchodu. Podporuje souběžné čtení a zápisy, takže dotazy nejsou blokované, když se právě indexují nové dokumenty. Celý graf lze serializovat a zazálohovat bez výpadku.

Pro většinu organizací běží DSM komfortně na jednom uzlu s 8 CPU jádry a 16 GB RAM. Pro větší nasazení (10M+ dokumentů) podporujeme horizontální shardování přes více uzlů s automatickým rebalancováním.

DSM je základ, který umožňuje vše ostatní v StellarBase — od přesných AI agentů přes inteligentní vyhledávání po automatizovaná workflow. Pokud to chcete vidět v akci, navštivte stellarbase.ai/platform nebo vyzkoušejte interaktivní demo.