Ce este un graf de cunoștințe și de ce contează pentru firma ta
Căutarea îți dă documente de citit. Un graf de cunoștințe îți dă răspunsuri. Diferența dintre „găsește-mi emailurile despre Meridian” și „cine din echipă cunoaște Meridian cel mai bine”.
Ai folosit căutare în firmă. Scrii „preț Meridian" și primești 47 de emailuri, 12 documente și trei fire de discuție. Le parcurgi, deschizi câteva, reconstruiești singur cronologia și — douăzeci de minute mai târziu — știi ce s-a întâmplat.
Un graf de cunoștințe inversează lucrurile. În loc să cauți conținut care menționează Meridian, întrebi: ce știm despre Meridian? Și primești o hartă:
- Meridian Industries e o companie, cu o valoare estimată a contractului
- E legată de Sara (14 emailuri, 3 întâlniri), de Andrei (responsabil juridic) și de Marcu (contactul de securitate)
- Există o reînnoire deschisă, cu termen pe 28 aprilie
- Redlineul MSA v4 are o clauză DPA nerezolvată din 12 martie
- Prognoza de trimestru îi trece la 60% probabilitate
Nimeni n-a etichetat nimic. Nimeni n-a completat un CRM. Graful a dedus totul din datele brute.
Cum funcționează, pe scurt
Un graf de cunoștințe are două cărămizi:
- Entități — lucrurile din datele tale: oameni, companii, contracte, documente, date calendaristice, sume.
- Relații — cum se leagă între ele. „Sara a scris contractul Meridian." „Andrei a semnalat secțiunea 14.2." „Prognoza face referire la Meridian."
Construit manual, un graf ca ăsta e prohibitiv: cineva ar trebui să citească fiecare email și să adnoteze fiecare entitate. Automat, se face din patru pași:
- Recunoașterea entităților identifică persoane, organizații, sume, date și nume de documente.
- Extragerea relațiilor prinde verbele și prepozițiile care leagă entitățile: „a scris", „a trimis către", „a aprobat", „e blocat de".
- Rezolvarea entităților unifică duplicatele: „Sara P.", „S. Popescu" și „[email protected]" sunt aceeași persoană. Pasul ăsta e cel mai subestimat și cel care strică grafurile prost construite.
- Ordonarea temporală construiește cronologii: emailul ăsta a fost înaintea ședinței, care a generat sarcina cealaltă.
Rezultatul stă într-o bază de date de tip graf — noi folosim Neo4j — unde fiecare entitate e un nod și fiecare relație o muchie.
Ce poți face cu el
„Cine din echipă cunoaște X cel mai bine?" Cu căutare clasică: scrii numele companiei, parcurgi rezultatele, numeri cine apare mai des. Cu graf: o interogare întoarce oamenii cu legăturile cele mai puternice, ordonați după cât de recente și cât de adânci sunt.
„Care e istoricul complet al acestui contract?" Cu căutare: reconstruiești cronologia din fire de email, notițe și versiuni de contract. Cu graf: pornești din nodul contractului și tot ce e conectat e deja legat și ordonat.
„Există vreo legătură între firmele astea două?" Cu căutare: mult noroc. Cu graf: cauți drumul dintre două noduri.
„Ce decizii blochează ce contracte?" Cu căutare: citești tot. Cu graf: deciziile și blocajele sunt entități, legate de contracte. Interoghezi direct: arată-mi toate deciziile în așteptare legate de un contract care se închide în mai puțin de 30 de zile.
Diferența față de un index de căutare
Un index de căutare — ce folosesc majoritatea uneltelor de enterprise search — leagă cuvinte de documente. Scrii un cuvânt, primești documentele care îl conțin.
Un graf de cunoștințe leagă entități de entități. Știe că „Sara Popescu" e o persoană care lucrează la „Meridian Industries" și a scris un document numit „MSA v4", care conține o clauză despre rezidența datelor.
Consecința practică, spusă simplu: căutarea îți dă documente de citit; graful îți dă răspunsuri pe care poți acționa.
Asta nu înseamnă că graful înlocuiește căutarea. Cele două rezolvă întrebări diferite, și un sistem serios le are pe amândouă. Căutarea semantică e bună când știi aproximativ ce cauți; graful e bun când întrebarea ta e despre relații, nu despre conținut.
Unde se strică grafurile
Merită spus și ce nu merge, pentru că un graf prost e mai rău decât niciunul:
- Rezolvarea entităților. Dacă „Sara P." și „S. Popescu" rămân două noduri, toate răspunsurile despre ea sunt pe jumătate. E partea grea, și e locul unde se vede diferența între implementări.
- Datele murdare. Semnăturile de email, disclaimerele juridice și listele de distribuție generează entități-fantomă. Fără filtrare, graful se umple de zgomot.
- Context lipsă. Un graf construit doar pe email știe doar ce s-a scris în email. Deciziile luate pe telefon nu apar nicăieri — și niciun sistem nu le poate inventa.
Cum construiește Doyna graful
Când îți conectezi emailul și documentele, sistemul: transformă fiecare bucată de conținut în vectori pentru căutare semantică, extrage entitățile din fiecare email și document, unifică duplicatele între surse, scrie entitățile și relațiile în Neo4j pe măsură ce le descoperă, și actualizează continuu.
Graful crește singur. Poți să-l explorezi vizual sau pur și simplu să pui întrebări asistentului, care interoghează graful în spate și îți arată răspunsul cu sursele lui.
Tot ce se întâmplă aici se întâmplă în instanța ta: un graf de cunoștințe e, prin definiție, harta relațiilor interne ale companiei tale. E exact tipul de date care nu are ce căuta pe infrastructură partajată cu alți clienți.