AI asistent nad firemními daty: jak jsme propojili Notion, Asanu a Google Drive do jednoho mozku

Prodejna s 10 zaměstnanci. Tři nástroje na řízení firmy – Notion na poznámky a interní wiki, Asana na úkoly a projekty, Google Drive na smlouvy, faktury a obecné dokumenty. Každý nástroj plní svůj účel. Problém? Nikdo neví, kde přesně hledat.

„Kde je ten postup pro reklamace?“ v Notionu? V Driven? Jako příloha úkolu v Asaně?

„Kdo má na starosti dodavatele X?“ někde v poznámkách, ale ve kterých?

„Jaké byly podmínky té poslední smlouvy?“ určitě v Drivu, ale ve které složce?

Zaměstnanci trávili v průměru hodinu denně hledáním informací, které ve firmě existovaly – jen nikdo nevěděl kde. Nováčci se orientovali týdny. Seniorní lidé fungovali jako živé encyklopedie a místo své práce odpovídali na otázky kolegů.

Postavili jsme AI asistenta, který propojil všechny tři nástroje do jednoho rozhraní. Zaměstnanec se zeptá česky, normální větou – a dostane odpověď s odkazem na zdroj. Žádné prohledávání složek, žádné otravování kolegů.

Co je RAG a proč ne „obyčejné“ ChatGPT

Kdybychom zaměstnancům dali přístup ke ChatGPT, dostali by obecné odpovědi z internetu. Nic o jejich firmě, jejich procesech, jejich klientech.

RAG (Retrieval-Augmented Generation) funguje jinak. Místo toho, aby AI odpovídala „z hlavy,“ nejdřív prohledá firemní dokumenty a teprve z nich složí odpověď. Dva kroky:

1. Retrieval – systém najde relevantní úseky z firemních dat
2. Generation – jazykový model z nalezených dat sestaví srozumitelnou odpověď

Výsledek? AI, která zná vaši firmu. Odpovídá na základě vašich dat, ne obecných znalostí z internetu. A ke každé odpovědi přiloží odkaz na zdroj – takže si můžete ověřit, odkud informace pochází.

Když odpověď ve firemních datech není? Systém to řekne. Žádné vymýšlení, žádné halucinace.

Jak to celé funguje pod kapotou

Architektura systému má několik vrstev. Každá z nich řeší jiný kus problému.

1. Napojení na zdroje dat

Prvním krokem bylo propojení se všemi třemi nástroji přes jejich API:

• Notion API – stahuje stránky, databáze a jejich obsah včetně struktury (nadpisy, odrážky, tabulky)
• Asana API – čte úkoly, projekty, komentáře a přílohy
• Google Drive API – indexuje dokumenty, tabulky, prezentace i PDF soubory

Každý zdroj má svá specifika. Notion ukládá data v blocích, Asana má hierarchii projektů a úkolů, Google Drive obsahuje mix formátů. Pro každý nástroj jsme vytvořili konektor, který data normalizuje do jednotného formátu.

Synchronizace běží inkrementálně – systém neindexuje vše od nuly, ale sleduje změny. Když někdo upraví stránku v Notionu nebo přidá komentář v Asaně, změna se promítne do indexu do hodiny.

2. Chunking – rozřezání dokumentů na kousky

Jazykové modely mají omezené kontextové okno. Nemůžeme poslat celou firemní dokumentaci najednou. Dokumenty se proto rozřežou na menší úseky – chunky.

Zní to jednoduše, ale chunking je jedno z nejdůležitějších rozhodnutí celého systému. Příliš malé kousky ztrácejí kontext. Příliš velké vnášejí šum a zhoršují přesnost vyhledávání.

Použili jsme kombinaci přístupů:

• Rekurzivní dělení s velikostí 400–512 tokenů a 10–20 % přesahem mezi kousky, aby se neztratily souvislosti na hranicích
• Respektování struktury – chunky se neřežou uprostřed odstavce nebo tabulky
• Metadata – ke každému chunku přidáváme informaci o zdroji (Notion/Asana/Drive), autorovi, datu poslední úpravy a kategorii obsahu

3. Embeddingy – převod textu na čísla

Každý chunk se převede na vektor – číselnou reprezentaci jeho významu. Dva texty, které mluví o podobném tématu, budou mít podobné vektory, i když používají úplně jiná slova.

Tohle je klíč k tomu, proč systém najde odpověď, i když se zeptáte jinak, než je to napsané v dokumentu. Hledáte „postup při stížnosti zákazníka“ a systém najde dokument nazvaný „Reklamační řád“ protože význam je podobný.

4. Vektorová databáze

Vektory se ukládají do specializované vektorové databáze (v našem případě Qdrant), která je optimalizovaná na rychlé vyhledávání podle podobnosti. Při dotazu systém najde 5–10 nejrelevantnějších chunků za milisekundy.

5. Hybridní vyhledávání

Čistě sémantické vyhledávání má slabinu – špatně si poradí s přesnými názvy, kódy produktů nebo specifickými termíny. Proto kombinujeme dva přístupy:

• Sémantické vyhledávání – hledá podle významu (ideální pro obecné dotazy)
• Klíčové vyhledávání (BM25) – hledá podle přesných slov (ideální pro konkrétní termíny)

Výsledky obou metod se sloučí a přeřadí pomocí re-rankeru – modelu, který detailně porovná relevanci každého výsledku k původnímu dotazu.

6. Generování odpovědi

Nalezené úseky se vloží jako kontext do promptu pro jazykový model. Ten dostane jasnou instrukci: odpovídej výhradně na základě poskytnutého kontextu. Pokud odpověď v kontextu není, řekni to.

Uživatel: "Jaký je postup při reklamaci?"

→ Systém najde 3 relevantní chunky z Notionu (reklamační řád)
  a 2 úkoly z Asany (aktuální reklamační workflow)

→ LLM sestaví odpověď + připojí odkazy na zdrojové dokumenty

Co jsme řešili a co nás překvapilo

Kvalita dat rozhoduje o všem

Garbage in, garbage out. Než jsme spustili RAG, museli jsme s klientem projít existující dokumentaci. Část stránek v Notionu byla neaktuální, některé soubory v Drivu duplicitní, v Asaně chyběly popisy úkolů.

Investice do čištění dat se vyplatila víc než jakákoli optimalizace algoritmu. Sebelepší AI neodpoví správně, když čerpá ze zastaralých podkladů.

Lidé se neumí ptát (a to je v pořádku)

„Jak to funguje?“ není otázka, na kterou AI dokáže odpovědět. Funguje co? Reklamace? Objednávky? Celá firma?

Přidali jsme vrstvu, která dotazy přeformuluje a upřesňuje. Systém se dovede doptat nebo nabídne možnosti: „Máte na mysli postup zpracování reklamací, nebo reklamační podmínky pro zákazníky?“

Bezpečnost a přístupy

Ne všichni zaměstnanci mají vidět všechno – mzdové dokumenty, smlouvy s dodavateli nebo interní hodnocení. Systém filtruje výsledky podle role uživatele. Prodavač dostane jiný rozsah odpovědí než vedoucí prodejny.

Metadata, která ke každému chunku přidáváme při indexaci, slouží právě k tomuto – systém ví, odkud chunk pochází a kdo k němu má přístup.

Notion, Asana a Drive mluví jiným jazykem

Každý nástroj strukturuje data jinak. Notion má bloky a databáze. Asana má projekty, úkoly a podúkoly. Google Drive má složky a soubory v desítkách formátů.

Jednou z výzev bylo propojení entit napříč nástroji – aby systém pochopil, že úkol „Aktualizovat ceník“ v Asaně souvisí se souborem „Ceník 2024.xlsx“ v Drivu a stránkou „Cenová politika“ v Notionu.

Tech stack

Azure OpenAI jsme zvolili kvůli GDPR – data zůstávají v evropském datacentru a neprocházejí přes americké servery.

Jak to vypadá v praxi

Pár reálných dotazů, které systém denně zpracovává:

„Kdo je zodpovědný za objednávky u dodavatele Novák?“ → Odpověď z Notionu (interní wiki) + odkaz na související úkoly v Asaně

„Kde najdu aktuální ceník pro velkoobchodní partnery?“ → Přímý odkaz na soubor v Google Drive + shrnutí klíčových podmínek z Notionu

„Jaký je postup, když zákazník chce vrátit zboží po 14 dnech?“ → Odpověď složená z reklamačního řádu (Notion) a aktuálního workflow (Asana)

„Co jsme řešili s klientem ABC minulý měsíc?“ → Souhrn z úkolů v Asaně + relevantní dokumenty z Drivu

Zaměstnanci systém používají přes jednoduché chatovací rozhraní – vypadá jako firemní ChatGPT, ale odpovídá na základě firemních dat.

Výsledky po 3 měsících

• Zhruba hodinu denně ušetří každý zaměstnanec na hledání informací – to je u 10 lidí 50 hodin týdně
• Noví zaměstnanci se orientují za dny, ne za týdny – asistent funguje jako neúnavný mentor, který odpoví na jakýkoli dotaz
• Seniorní lidé se vrátili ke své práci – místo odpovídání na opakující se otázky kolegů řeší to, co přináší hodnotu
• 85 % dotazů systém zodpoví bez nutnosti eskalace na člověka
• Citace zdrojů budují důvěru – zaměstnanci si ověřují odpovědi a vědí, že AI „nevymýšlí“

Kdy RAG dává smysl

RAG není pro každého. Dává smysl, když:

• Máte data roztříštěná ve více nástrojích – a lidé tráví čas hledáním místo prací
• Zaměstnanci opakovaně řeší stejné dotazy – a seniorní lidé fungují jako živé FAQ
• Onboarding nových lidí trvá dlouho – protože „vědění“ je v hlavách, ne v systému
• Vaše dokumentace existuje, ale nikdo v ní nehledá – protože je to zdlouhavé a nepřehledné

Nepotřebujete tisíce dokumentů. Stačí desítky, pokud jsou aktuální a dobře strukturované. Důležitý je přínos – kolik času váš tým ušetří, když odpověď přijde za 5 sekund místo za 20 minut hledání.

Co je potřeba k rozjezdu

Typický projekt tohoto typu zabere 3–5 týdnů:

1. Týden 1 – Zmapování datových zdrojů, audit kvality dokumentace, nastavení přístupů
2. Týden 2–3 – Napojení konektorů, indexace dat, nastavení chunkingu a embeddingů
3. Týden 3–4 – Ladění vyhledávání, testování s reálnými dotazy, prompt engineering
4. Týden 4–5 – Nasazení, zaškolení týmu, sběr zpětné vazby a doladění

Nejdůležitější část? Ten první týden. Kvalita dat rozhoduje o úspěchu víc než volba konkrétní technologie.

Chcete podobného asistenta?

Pokud vaši lidé tráví čas hledáním informací místo prací, pravděpodobně řešíte stejný problém. Nezáleží na tom, jestli používáte Notion, Confluence, SharePoint nebo Excel na sdíleném disku – princip je vždy stejný.

Ozvěte se nám – na krátkém hovoru zjistíme, jestli to pro vás dává smysl a jak by to mohlo vypadat. Víc o tom, jak stavíme RAG asistenty a další AI řešení, najdete na stránce AI & Automatizace.