AI je pronašao dokument. Ali da li razume kontekst?

Povezivanje SharePointa sa Langdockom, ChatGPT-jem ili drugim AI asistentom razuman je prvi korak. Zaposleni brže pronalaze dokumente, dobijaju sažetke i postavljaju pitanja nad postojećim fajlovima. Za manje timove i jednostavne zahteve to može biti sasvim dovoljno.

Kada sistem koristi nekoliko hiljada zaposlenih, izazov se menja. Nije dovoljno pronaći pasus koji liči na traženu informaciju. Potrebno je izvući važeći podatak, odgovarajuću reviziju, poslovni kontekst i proverljiv izvor — uz kontrolisanu latenciju i operativne troškove.

Zato pravo pitanje nije koji konektor ume da pretraži SharePoint, već kakva RAG arhitektura omogućava da informacije pouzdano pronađemo, razumemo i upotrebimo u konkretnom poslovnom procesu.

Langdock podržava integracije sa poslovnim izvorima i funkcije pretrage relevantnog sadržaja. Bilo bi pogrešno tvrditi da pri svakom pitanju šalje kompletne SharePoint dokumente jezičkom modelu. Savremeni retrieval mehanizmi mogu da izaberu relevantne odlomke i rangiraju ih.

To jeste korisno, ali samo po sebi ne rešava pitanje koji je podatak poslovno važeći. Konektor ne zna automatski koja verzija tehničkog crteža je odobrena, da li dva naziva označavaju isti deo ili koje uputstvo važi za određenu konfiguraciju mašine.

Jezički model može da zaključi da su pojmovi povezani, ali takav zaključak nije zamena za master data, dokumentovana poslovna pravila i pouzdane relacije. Tehnički pristup fajlovima nije isto što i pouzdana arhitektura znanja.

Prodaja organizuje dokumentaciju po kupcima, engineering po projektnim brojevima, servis po mašinama, a proizvodnja po linijama. Ista komponenta pojavljuje se pod različitim imenima. Duplikati, stare revizije, PDF prilozi i tabele dodatno otežavaju identifikaciju važećih informacija.

Primer iz mašinske industrije: serviser pita koje uputstvo za održavanje pogonske jedinice važi za trenutnu konfiguraciju određene mašine. Tekstualna pretraga može da vrati više uverljivih rezultata. Pouzdan odgovor zahteva povezivanje konfiguracije mašine, komponente, ID-ja dokumenta, statusa odobrenja i važeće revizije.

Ti odnosi često nisu u celosti zapisani u SharePointu. Podaci su raspodeljeni između ERP-a, PLM-a, MES-a i drugih sistema. Moramo ih namerno integrisati i modelovati.

Ontologija definiše poslovne pojmove, njihova svojstva i dozvoljene odnose. Knowledge Graph može da opiše konkretne entitete i njihove veze: mašina X sadrži pogonsku jedinicu A; ona koristi komponentu B; za komponentu B važi uputstvo W u reviziji 4, koje zamenjuje reviziju 3.

Nije svakom sistemu potreban Knowledge Graph. Stabilni identifikatori, referentne tabele i dobro održavani metapodaci često su dovoljni. Grafovski sloj ima smisla kada sama pitanja zahtevaju složene relacije između više poslovnih sistema.

Relacije koje model predloži moramo proveriti pre nego što ih tretiramo kao važeće činjenice. Embedding pretraga pronalazi sličan tekst, ali ne dokazuje da je neko servisno uputstvo odobreno za konkretnu mašinu.

Dobra RAG pipeline bira izvore koji su stvarno potrebni za odgovor. Loše implementacije često šalju previše rezultata, ponovljenih odlomaka ili velikih delova dokumenata bez odgovarajućih filtera.

Ilustrativan proračun: 1.500 zaposlenih postavlja po osam pitanja dnevno. Sa 12.000 kontekstnih tokena po pitanju to je 144 miliona tokena dnevno. Sa 2.000 tokena po pitanju — 24 miliona. Potrošnja konteksta je šest puta veća. Ovo nije rezultat merenja Langdocka, niti znači da su ukupni troškovi šest puta veći.

Stvarni troškovi zavise od cene modela, cache pogodaka, indeksiranja, rerankinga, dodatnih tool poziva i kvaliteta odgovora. Zato optimizujemo cenu po uspešno rešenom zadatku, a ne najmanji broj tokena po svaku cenu.

Konverzija PDF-ova, Word dokumenata i tabela u Markdown može biti korisna. Markdown je čitljiv, pogodan za verzionisanje i praktičan za mnoge retrieval pipelineove. Ipak, 10.000 nekonzistentnih PDF fajlova konverzijom ne postaju 10.000 pouzdanih jedinica znanja.

Revizije, prava pristupa, poslovne relacije, struktura tabela, source ID-jevi i status odobrenja moraju se obrađivati zasebno. Vector index ne rešava loš kvalitet podataka. Greške u ekstrakciji mogu da izgube jedinice mere, relacije u tabelama ili reference na crteže.

Zato kvalitet obrade ne merimo brojem chunkova, već time da li sistem može da pronađe relevantnu informaciju zajedno sa njenim poreklom, ograničenjima i potpunim značenjem.

Detaljnije o strategijama segmentacije i LLM-assisted pristupu pišemo u tekstu Agentic Chunking: Kada LLM poboljšava RAG.

Pipeline počinje u stvarnim izvornim sistemima. SharePoint i Google Drive sadrže dokumente; ERP, CRM, PLM, MES i baze podataka često čuvaju merodavne strukturirane informacije. Povezujemo samo izvore koji su potrebni za konkretan use case, umesto da sve prekopiramo u još jedan folder.

Zatim ekstrahujemo i klasifikujemo sadržaj, čuvamo smislene odeljke, normalizujemo oznake i jedinice mere i dodeljujemo reference, verzije, vremenske oznake i access-control metapodatke. Izmene i brisanja moraju da stignu i do search indeksa.

Kada postoje pouzdani strukturirani podaci, koristimo API-je i strukturirane upite. Kada su pitanja jezički neprecizna, dopunjavamo ih semantičkom pretragom. Retrieval sloj tako postaje namerno projektovana veza između podataka i modela.

O izgradnji takvih pipelineova i modela saznajte više kroz Data Engineering.

Tačne šifre delova i kodovi grešaka često se najpouzdanije pronalaze klasičnom pretragom. Opisi tehničkih problema češće imaju korist od semantičke pretrage. Za radna uputstva potrebni su filteri za verziju, lokaciju, tip mašine i status odobrenja.

Pouzdana RAG arhitektura prema potrebi kombinuje keyword search, vector search, hybrid search, metadata filtering, reranking i strukturirane upite prema bazama i API-jima. Orkestracija ne treba da pribavi što više izvora, već baš one koji odgovaraju pitanju.

Model zatim dobija ograničen skup informacija sa proverljivim referencama. Ako su podaci protivrečni ili nedostaju, aplikacija to treba jasno da pokaže umesto da generiše lažno siguran odgovor.

Osnovne principe retrievala i generisanja odgovora dodatno obrađujemo u tekstu Agentic Chunking i struktura dokumentacije.

Naziv PDF fajla retko je dovoljan da se proveri važna tvrdnja. Korisniji su izvorni sistem, ID dokumenta, revizija, vreme ekstrakcije, transformacije i tačan odlomak korišćen pri generisanju.

Data Lineage pokazuje odakle informacija potiče i kako je obrađena. Tracing konkretnog zahteva dodatno beleži pretragu, odabrane rezultate, tool pozive, model i odgovor. Ova dva pogleda se dopunjuju, ali nisu isto.

Ako asistent vrati pogrešno uputstvo za održavanje, moramo utvrditi da li je izvor bio zastareo, ekstrakcija izbacila uslov, retrieval koristio pogrešan filter ili je model pogrešno protumačio ispravan izvor. Duži prompt ne popravlja pogrešan master-data zapis.

Deset unapred pripremljenih pitanja ne dokazuje da sistem može pouzdano da radi u produkciji. Potrebni su reprezentativni testovi sa stvarnim pitanjima, očekivanim izvorima i jasnim pravilima za ispravne i nedozvoljene odgovore.

Retrieval Recall i kvalitet rangiranja pokazuju da li je relevantan izvor uopšte pronađen. Faithfulness i stručna provera odgovora pokazuju da li je tvrdnja potkrepljena izvorima. Testovi moraju obuhvatiti zastarele dokumente, kontradiktorne revizije, nedostajuće podatke i dvosmislena pitanja.

Frameworkovi poput Ragas mogu da pomognu pri evaluaciji, ali automatsko ocenjivanje ne zamenjuje stručno proverene uzorke. Regression testove pokrećemo posle izmena chunkinga, indeksa, filtera, promptova ili modela.

U produkciji pratimo svežinu pipelinea, retrieval latenciju, kvalitet rezultata, greške modela, input i output tokene, cenu po zahtevu i p95 vreme odgovora. Traces povezuju retrieval, tool pozive i obradu u modelu.

OpenTelemetry i distributed tracing pružaju tehničke osnove. Ne moramo da kopiramo osetljive dokumente u logove; beležimo samo metapodatke i identifikatore koji su potrebni za analizu, uz odgovarajuću kontrolu pristupa.

Tek sa uvidom u čitav sistem možemo da povežemo loš odgovor sa uzrokom i svesno balansiramo kvalitet, latenciju i troškove.

Serviser dobije ispravnu preporuku za održavanje. Ako zatim mora ručno da otvori tiket, pronađe mašinu i odgovornu osobu, AI je i dalje izvan glavnog poslovnog procesa.

Aplikacija može da poveže proverene informacije sa strukturiranim poslovnim podacima i pripremi konkretan zadatak: ID mašine, reviziju dokumenta, izvor, vreme i odgovornu ulogu. Kritične aktivnosti i dalje zahtevaju definisana odobrenja.

Upravo na tu vezu između podataka i akcija usmeren je Valanor AI. Povezujemo poslovne podatke, analitiku, Machine Learning i AI sa zadacima koji mogu da se provere i sprovedu.

Nije svakom workflowu potreban AI agent. Pravila ili strukturirani upiti ponekad su pouzdaniji izbor.

Za pregledan skup dokumenata, jasnu odgovornost za sadržaj i jednostavna pitanja standardni konektor je često najbolji početak. SharePoint može ostati glavni sistem za dokumente, Langdock korisnički interfejs, a Google Drive okruženje za saradnju.

Složeniji model znanja postaje važan kada se povezuje više sistema, revizije imaju poslovne posledice, odgovori pokreću operativne odluke ili trošak pogrešnog retrievala raste sa brojem zahteva.

Ovo nije argument protiv Langdocka niti poziv da se sve pravi od nule. Standardni softver dopunjujemo tamo gde proces zahteva dodatni sloj podataka i poslovnog konteksta.

Povezivanje SharePointa sa Langdockom može biti dobar prvi korak. Pouzdana RAG arhitektura nastaje kada poreklo podataka, važenje, poslovne relacije, retrieval, evaluacija i operativni rad funkcionišu kao celina.

Cilj nije da svaki problem prikrijemo dodatnim kontekstom u promptu. Cilj je da model dobije prave informacije, da smanjimo nepotrebno rekonstruisanje odnosa i da proverene rezultate povežemo sa poslovnim procesima.

Kroz Data & AI Engineering razvijamo tehničku osnovu, a kroz Valanor AI povezujemo je sa proverljivim preporukama i operativnim zadacima.

Kako povezujemo podatke i AI sa konkretnim radnim procesima: Valanor AI.

Langdock: Company Knowledge i dokumentacija enterprise pretrage.

Microsoft Graph: Delta Query za DriveItem.

Microsoft GraphRAG: Pregled arhitekture.

Ragas: Evaluation Metrics.

OpenTelemetry: Generative AI Semantic Conventions.