Minulý pátek jsme se společně s Vaškem Viačkem zúčastnili konference EU Posted Workers pořádané HAVEL & PARTNERS, zaměřené na informování v souvislosti s evropskou směrnicí Posted worker directive ( PWD 96/71/EC ). Z pohledu podnikatele (avšak neodborníka v oblasti HR) oceňuji zejména srozumitelně odprezentovaný rámec problematiky posílání pracovníků mezi zeměmi EU. Velkým přínosem byly rovněž prezentace odborníků z jednotlivých členských států EU, kteří si dali práci s připravením přehledných specifik napříč jednotlivými státy.
Obr. 1: Přednáška Ewalda Oberhammera (Oberhammer Attorneys) byla pro mne z hlediska vhledu do problematiky PWD zásadní.
Co klíčového si z konference odnáším?
My lokální vývojové a marketingové firmy, které pracujeme v místě naší domovské země a dodáváme produkt online ven, jsme pro tento případ z obliga. Nicméně v momentě kdy fyzicky posíláme kolegy do jiných členských zemí například nainstalovat produkt, zaškolit personál, nebo na placenou stáž, týká se nás to také. Zpozornět bychom měli i když jedeme na pracovní meeting, konferenci, nebo odbornou přednášku. V takovém případě hraje roli do jaké země jedeme (různé členské země mají různá pravidla), počet dní (jak dlouho se zdržíme) i místo (typ budovy), kde se akce odehrává. Například v Itálii se podobné akce musí konat mimo budovu továrny / provozu.
Můj názor
Nejsem obdivovatelem evropské byrokracie. Jakkoliv se mi z mého úhlu pohledu složitost celé problematiky nemusí zamlouvat a mohu si myslet leccos o motivacích PWD. Tak realita je taková, že je tady. A budeme se v ní muset všichni zorientovat abychom mohli fungovat. Samozřejmě HAVEL & PARTNERS společně s PWA zajišťuje profesionální služby pro zajištění souladu pracovních pobytů v zahraničí s PWD směrnicí.
Jednoho dne mi Káťa říká: "Mám velkou radost jak ta naše Anička ve třech letech drandí na odrážedle, ale na kolo se pořád bojí, probereš to s Dušanem až se s ním uvidíš?". Dušan je náš kamarád, který má v Uherském Brodě prodejnu se špičkovými koly a lyžařským vybavením, celý život žije sportem, je mistrem Evropy v jízdě na vysokém kole a ohledně kol radí například prof. Pafkovi a prof. Pirkovi. Když jsme byli za pár dní s Dušanem na večeři, radil jsem se s ním, že Anička sice lítá na odrážedle jako drak, ale na šlapacím kole se bojí a když má přidělaná pomocná kolečka, nezačne šlapat. Dušan mi řekl ať za ním přijdu ráno do TK Sportu.
Dušan pro mě měl připravené dětské kolo KTM. Říkal mi: "Podívej se tohle kolo je speciálně vytvořené, aby na něj přešly děti z odrážedla. Má přední kolo větší než zadní. Anička bude mít jistotu, že došáhne nožičkami na zem, nebude se bát. Klidně se na něm může odrážet jak na odrážedle, ale zároveň jí budou šlapky působit nekomfort, bude jí to nutit dát nohy na šlapky. Aby se nebála, přidělám ti ještě vodící tyč. Až si zvykne, že jezdí a ty ji držíš za tyč, tak tyč pustíš."
Obr. 1: Anička na kole
Doma jsme s Káťou přemýšleli jak Aničku motivovat, aby se nebála kolo vyzkoušet, protože kdykoliv jsme navrhli jít na kolo Anička byla proti. Zkusil jsem: "Aničko, co kdybych zítra ráno nešel do práce a tys nemusela do školky a šli jsme spolu na kolo?" ... "Tatínku na kolo nejdu, to já raději půjdu do školky, do školky chci jít." ... "A co kdybychom šli na kolo, tys to zkusila a pak šli do Superlandu na hřiště?" ... "Tak jo táto, já to teda zkusím". Druhý den ráno jsme spolu vyrazili. Aničku jsem držel za vodící tyč, aby měla stabilitu, odrážela se nohami, současně věděla, že ji držím, a zkoušela šlapat nebo se pouštět z kopce. Opakoval jsem: "Víš co říkal strejda Dušan, kdykoliv můžeš dát nohy na zem." Zvykla si, že kdykoliv chce zastavíme a dá nohy na zem. Po chvíli mi povídá: "Táto drž mě za tyč, vůbec mě nepouštěj, zkusím víc šlapat." Šlapala zlehka po rovince až jsme dorazili pod kopeček. "Táto to nejde" ..."Protože musíš ten kopec vyšlápnout"... Anička zakřičela: "Kopci jeden já ti ukážu jak tě šlápnu" a opřela se do šlapek. Po hodině a půl říkám: "Aničko půjdeme domů a na to hřiště?" ..."Jo táto, ale já chci ještě s tebou jezdit." Objeli jsme ještě jednou rybník a pak šli na slíbené hřiště. Večer mi Anička povídá: "Táto půjdeš se mnou zase na kolo?". Když jsme šli příště, už se nebála, naučila se kolo rozšlapat a já si u toho pořádně zaběhal, když jsem běžel vedle ní držíc vodící tyč. Po nějaké době jsem na rovince tyč pustil. A Anička jela sama. Když pak zastavila, povídám: "Aničko, víš, že jsem na chvíli pustil tyč a tys jela úplně sama?" Anička šla domů pyšná jako páv: "Maminko já jela sama, já ti to příště ukážu chceš?" Když jsme šli příště i s Káťou a Adélkou, Anička rozšlapala kolo a křičí na mě: "Táto už pusť tu tyč ať ukážu mámě jak jedu sama." No a už jezdí sama. Tohle je pro mne jeden z těch pocitů totální radosti a životního štěstí.
Obr. 2: Anička na kole
Včera jsem volal Dušanovi: "Měls naprostou pravdu, přesně jak jsi řekl, tak to bylo." Dušan: "A víš co se říká u nás na Moravě? A vvvo tom to jé". Já: "A já jsem další pražák co říká pro kola se jezdí jedině k Dušanovi do TK Sportu."
Dnes jsem s Tommym navštívil konferenci AI transformace financí od České asociace umělé inteligence (ČAUI), která se shodou okolností konala v perfektních prostorách našeho klienta enforum event space.
Obr. 1: Zahájení konference AI transformace financí Lukášem Benzlem
První tři přednášky v podání Adama Leščišina (Accenture), Michala Amblera (Ernst Young) a Martina Ryšánka (IBM) byly zajímavé tím, že přednášející jsou manažeři, kteří mají za sebou stovky realizovaných AI projektů. Jejich příspěvky se týkaly především strategie v zavádění AI do klientských firem - správnému mapování potřeb, určení priorit. A v neposlední řadě tak trochu tlačení svých korporátních (nejen) AI řešení.
Obr. 2: Rozsáhlé zkušenosti Accenture s realizací klientských AI projektů, přednáší Adam Leščišin
Následovala perfektní prezentace od Karin Fuentesové ze startupu Digitoo, který automatizuje zpracování faktur. Prezentace se hodně zaměřovala na spolupráci s partnerem Raiffeisen bankou, který dodal čerstvému startupu tolik potřebnou důvěryhodnost na trhu i možnost cílit s nabídkou na své klienty. Dále prezentace obsahovala poměrně srozumitelné vymezení se proti konkurenčním firmám typu Rossum. Přiznám se, že o Digitoo jsem neslyšel poprvé. Jsme klienti Raiffeisen banky i Abra Flexibee a skrze jejich kanály jsem se já i Petr o Digitoo dozvěděli. Po dnešní prezentaci jsem probral s Petrem, zda nevyužít právě Digitoo pro zefektivnění zpracování faktur včetně Petrovi účetní firmy. Uvidíme, zda budou v Digitoo skutečně tak cenově výhodní ;)
Obr. 3: Příklad strategického mapování v oblasti AI, přednáší Michal Ambler z Ernst Young
Panel s pohledem do zákulisí AI inovací v bankách mne příliš nebavil. Při veškeré úctě k přednášejícím i perfektnímu moderování ze strany Lukáše, zde jsem se nedozvěděl pro sebe nic užitečného či zásadního.
Obr. 4: Tommy vyřizuje telefony během coffee break na střeše eNovation
Ve druhé části konference mne zaujaly především dvě přednášky. Ta první byla od Vojtěcha Dlouhého z Feedyou, který se představil, že má rád čísla a jeho prezentace byla skutečně čísly nabitá. U některých bych, přiznám se, rád viděl citované zdroje, ale to je jen mé rýpnutí, protože prezentace byla skvělým nahlédnutím pod pokličku AI chatu / virtuálních asistentů od Feedyou. Z prezentace si odnáším tvrzení: "správná identifikace uživatele je zásadní".
Obr. 5: Vratislav Kalenda ukazuje příklad selekce transakcí
Technologický bonbónek si pro nás ČAUI připravila nakonec. Vratislav Kalenda z Applifting se rozmluvil detailněji o principech, na kterých stojí jejich vývoj. Hned na úvod položil otázky, které mne zvedly ze židle:
Jak dostat relevantní transakce do kontextového okna AI.
Jak zabezpečit, aby AI měla přístup pouze k transakcím jednoho klienta.
LLM dělají při výpočtech chyby. Jak zařídit, aby analýza byla přesná.
Jak zabránit halucinacím.
Selekce transakcí pro mne nebyla ničím novým. Dospěli jsme s jinými daty z jiné problémové domény prakticky k témuž. To, že LLM dělají ve výpočtech chyby víme, prakticky u žádných modelů, které jsme dosud vyzkoušeli se nemůžeme spolehnout, že vyřeší zadanou "slovní úlohu" správně. Nicméně pochopil jsem, že mám zásadní mezery v pochopení a administraci AI agentů. A naivní řešení, které jsem hodlal před shlédnutím přednášky využít, by pravděpodobně bylo slepou cestou. Pro mne tedy byla konference jednoznačně přínosem a moc Ti děkuji Lukáši, že jsem se jí mohl zúčastnit.
Poslední dva měsíce jsem se v souvislosti s přípravou návrhu databáze pro AI projekt, který v TRITON IT chystáme společně s Karlem Pěnkou a Vaškem Viačkem, intenzivněji věnoval nastudování vektorových databází. Potřeboval jsem si ujasnit princip jejich fungování, zorientovat se v terminologii a odstranit řadu nejasností. Mé dosavadní poznatky sdílím s každým, koho zajímá proč a jak vektorové databáze vznikly, na jakých principech stojí a v čem jsou důležité pro práci s AI.
Obr. 1: Screenshot z testování multijazyčného jazykového modelu v kolekci ChromaDB, Python, PyCharm
Trochu historie a výzvy kladené na databázové systémy
Přelom 90.tých let a milénia se nesl ve znamení relačních databází založených na SQL. Tehdejší rychlý nástup webů, portálů, eshopů s sebou nesl potřebu efektivně ukládat uživatelská data a přistupovat k nim (filtrovat, řadit, vyhledávat). To se neslo ruku v ruce s normalizací relačních databází a tzv. normálními formami. Následný prudký rozvoj internetových aplikací zapříčinil, že relační databáze přestaly stačit. Nastupující sociální sítě, nebo eshopy přerostlé v mezinárodní internetové hypermarkety potřebovaly v reálném čase obsloužit miliony uživatelů. Analytické a vědecké aplikace zase potřebovaly co nejrychleji uložit velká data, vyhodnotit je a nasdílet výsledky. Na sklonku první dekády milénia nastala éra big data. Ruku v ruce s tím se začaly čím dále tím více uplatňovat NoSQL databáze. Zde byly normální formy ty tam. Prioritou se stala co největší dostupnost a rychlost čtení / zápisu. A to i za cenu duplicit na úrovni návrhu. Současně se rozvinula paralelizace - schopnost běžet jeden a tentýž databázový systém na více strojích (klastrech) současně a synchronizovat je mezi sebou. Pod náporem dat se řešilo balancování latence versus konzistence. Nad NoSQL databází Cassandra, konkrétně nad jejím optimalizovaným c++ klonem s názvem ScyllaDB běží i naše WebMedea. Vývoj šel dopředu a přicházely nové výzvy, které si vyžadovaly nové formy přístupu k datům. V souvislosti s nástupem AI se hovoří o nové průmyslové revoluci. A právě současný pokrok v AI byl stimulován rozvojem vektorových databází. Mimochodem věděli jste, že na tomto pokroku má lví podíl čech Tomáš Mikolov?
Motivace pro vektorové databáze
Co bylo impulsem pro vznik vektorových databází? Potřeba uložit a popsat vztahy mezi daty odlišným způsobem než doposud. Co je tím myšleno? Klasické relační databáze jsou založeny na vztazích (relacích) mezi řádky tabulek. To umožňuje popsat exaktní vztahy, například, že faktura má N položek, nebo že N osob může figurovat v M firmách. Ale reálný svět je spíše než booleovský (souvisí / nesouvisí) postavený na fuzzy (příslovečných 50 odstínů šedi mezi dvěma možnostmi). Reálný svět měří vztahy na úrovni míry shody či podobnosti něčeho s něčím. A právě na zmíněné fuzzy logice staví i teorie neuronových sítí. Ať už těch umělých nebo skutečných. Když se dítě učí mluvit, opakuje slova tak dlouho, dokud není vzdálenost jeho zvukového projevu od předlohy (odchylka) minimální. Požadavek byl proto jasný - mít možnost popsat vztahy mezi objekty v databázi pomocí míry, určující jak moc spolu objekty souvisí.
Co to je vektorová databáze a jak funguje?
Vektorová databáze umožňuje efektivně ukládat vektorové reprezentace dat a pomocí dotazů je opětovně získávat. Data mohou být slova, celé texty, obrázky, videa, či zvukové stopy. Vektorovými reprezentacemi jsou uspořádané n-tice číslic reprezentující umístění dat v n-rozměrném prostoru.
A teď se nabízejí následující otázky....
Můžeš mi lidsky říci, k čemu je tedy ta vektorová databáze užitečná?
Jak z dat dostanu zmíněné vektory a co potom s nimi udělám?
Mluvíš o n-rozměrném prostoru, ale jakém a čím jsou definovány rozměry?
Mluvíš o vzdálenosti, ale čím se ta vzdálenost měří?
Řekneš mi to nějak srozumitelně polopaticky?
Až tyto otázky probereme, získáme vhled do toho, jak vektorové databáze fungují. Jdeme na to.
ad 1. K čemu je vektorová databáze užitečná?
Představte si, že do databáze uložíte několik textů. Potom napíšete jiný text a pošlete ho jako dotaz na databázi. Jako výsledek se vám vrátí ten z dříve uložených textů, který se významově nejvíce shoduje s dotazem. Nebo dostanete na výstupu prvních N uložených textů, které se nejvíce shodují se zadaným textem seřazených je podle míry shody.
Příklad; V databázi máte uložené všechny projevy Milouše Jakeše. Jako dotaz pošlete "Chci ten projev, kde si Jakeš spletl drůbež a spotřebič na ohřev vody." V ideálním případě se vám vrátí legendární proslov o brojlerech a bojlerech. Jaktože vám databáze "rozumí"? Čtěte dál :)
ad 2. Jak se z dat stanou vektory?
Vektorovým reprezentacím dat se říká tzv. Embeddings (vzhledem k nejednoznačnosti doslovného překladu "vložení" budu používat anglický termín). Jak získat z dat embeddings?
Embeddings pro slova
Začněme nejprve slovy. Řešíme následující úlohu. Vzít slovník. Vytvořit n-rozměrný prostor a v rámci tohoto prostoru reprezentovat každé slovo ze slovníku pomocí vektoru. Cílem je získat co nejlepší rozložení slov, kde slova, která spolu souvisí méně jsou v prostoru dále od sebe. Slova, která spolu souvisí více jsou blíže u sebe. Konkrétněji? Podstatné jméno "šroubovák" bude mít od podstatného jména "višeň" mnohem větší vzdálenost než "meruňka". Přídavné jméno "kyselý" bude blíže višni než meruňce. Podstatné jméno "ovoce" bude višni a meruňce blíže než obecná "rostlina". Pořád jsme si ale neřekli, jak zmíněnou úlohu řešit. Existuje více přístupů. Jejich průkopníkem byl již zmíněný Tomáš Mikolov, který v roce 2013 publikoval nástroj word2vec. Jednalo se o neuronovou síť se dvěma skrytými vrstvami, která řešila optimalizační úlohu najít takovou vektorovou reprezentaci slov, který by co nejvíce odpovídala realitě. Tomáš k tomu použil tzv. velký jazykový korpus - soubor textů určitého jazyka, dostatečně velký na to, aby z něj bylo možné získat významové vztahy mezi jednotlivými slovy. Proč to udělal? Samotný slovník nestačí, někdo vám musí říct, že višeň je kyselá, že šroubovák šroubuje šrouby, nebo že "vydělat" je sloveso a často se vyskytuje s podstatným jménem "peníze". Buď by nějaký člověk musel popsat veškeré vztahy mezi veškerými slovy ve slovníku určitého jazyka. A pak v horším případě metodou pokus omyl, v lepším případě nějakým heuristickým algoritmem, budovat co nejlepší vektorovou reprezentaci všech slov. Nebo můžeme souvislosti automatizovaně vytěžit z dostatečně velké zásoby textů a použít neuronovou síť k nalezení nejlepší reprezentace.
Embeddings pro texty, větné transformátory, jazykové modely a LLM
V případě celých textů - vět a dokumentů je úloha složitější. Podobně jako u slov vyjděme z toho, že máme k dispozici jazykový korpus. Celý korpus není změtí náhodných dat, ale ohromnou znalostní bází, kterou vytvořili myslící lidé a zakódovali do ní významové souvislosti pomocí určitého jazyka. Cílem je zachytit tyto souvislosti do modelu (jazykového modelu), který bude definovat co nejlepší vzdálenosti mezi jednotlivými významovými celky. Klíčové je, aby takový model byl jednak co nejvíce vypovídající a současně rychlý pro použití. Nástroje, které takové jazykové modely budují se nazývají větné transformátory (z anglického sentence transformers) a využívají principu pozornosti (z anglického attention). Pro různé typy úloh existují různé jazykové modely. Některé se hodí spíše pro překlad, jiné pro významové prohledávání textu viz náš příklad s projevem Milouše Jakeše. Tím, že jazykové modely vydolují (dekódují) z textu význam v podobě embeddings, můžeme pak embeddings (ten význam) zakódovat do jiného jazyka (překlad), nebo embeddings porovnat s embeddings jiného textu a zjistit míru významové podobnosti.
Další příklad významové podobnosti; Nahrajeme do vektorové databáze všechny starověké texty, bibli, řecké báje a pověsti a další po kapitolách. Pošleme na databázi dotaz "Dej mi texty, které zmiňují velkou povodeň". V ideálním případě dostaneme příslušné kapitoly, z jednotlivých děl, které pojednávají o biblické potopě či zkáze Atlantidy.
V případě jazykových či jiných (pro zpracování grafiky či zvuku) modelů se tedy nejedná o žádné "vědomí", jak nám často povrchní a senzace chtiví internetoví článkaři prezentují současný nástup AI, ale pouze o sofistikované porovnání dat. Zde se také dostáváme k termínu velké jazykové modely (z anglického large language models, neboli LLM). Jsou to takové modely, které ke svému vytvoření použily dostatečně veliký jazykový korpus.
Poznámka: Kromě jazykových modelů mohou být na podobném principu tvořeny modely pro rastry, audio a další datové typy. Viz seznam dostupných OpenAI modelů.
ad 3. S kolika rozměrným prostorem pracujeme a jaký je význam jednotlivých dimenzí?
Celou dobu se bavíme o vektorech z n-rozměrného prostoru, který jsme si dosud blíže nepopsali. Záměrně jsem zatím využíval vádní označení n-rozměrný prostor, ve kterém využíváme "něco" k určení vzdálenosti prvků - vektorů. Vektorové databáze mohou využívat modely založené jak na vektorových prostorech, tak na metrických prostorech. Můžeme mít klasický euklidovský metrický prostor, nebo například vektorový prostor kosinové podobnosti. Rozvedu níže. A jak je to s tou dimenzionalitou? No :) Ti, co jsou (jako já) zvyklí, například ze statické klasifikace a rozpoznávání, že dimenze příznakového prostoru souvisí s konkrétními vlastnostmi objektu (třeba barva, hmotnost, délka atd. atd.), nejspíše zklamu. Protože dimenze metrických nebo vektorových prostorů používaných pro tvorbu embeddingů obvykle nemají žádný "lidsky popsatelný" význam. Tyto dimenze jsou často výsledkem optimalizační úlohy, která se snaží najít takové reprezentace dat, které nejlépe zachycují vztahy mezi nimi. Každá dimenze prostoru odpovídá různým charakteristikám nebo rysům dat, které nejsou snadno interpretovatelné lidmi. Počet dimenzí bývá určen empiricky při budování modelu a je optimalizován tak, aby co nejlépe vyhovoval potřebám konkrétního úkolu nebo modelu. Jinak řečeno. Neurové sítě větných transformátorů, které staví náš jazykový model, používají počet dimenzí jako proměnnou k tomu, aby nalezli optimální rozmístění vektorů v prostoru. Zatímco word2vec pracoval s cca 300 dimenzemi. Chat GPT pracuje přibližně s 1500 rozměrnými vektory a nové modely i s 3000 rozměrnými vektory.
ad 4. Čím se měří vzdálenost? Kosinová podobnost a embedding funkce
Různé modely mohou používat různou definici vzdálenosti. Dokonce u téhož principiálního modelu je leckdy možné si "hrát" s různými vzdálenostmi a vyrábět tak různé jeho klony a testovat jejich spolehlivost. Klíčové však je, že jakmile zvolíme určitu definici vzdálenosti a použijeme ji v rámci větného transformátoru k sestavení jazykového modelu, jsme již logicky vázáni na tuto vzdálenost. Vrátíme se nyní opět k počátkům word2vec od Tomáše Mikolova. Ten využil k určení podobnosti dvou vektorů kosinus - takzvanou kosinovou podobnost. Byly k tomu hned dva dobré důvody.
Kosinus lze snadno (a z hlediska výpočetní složitosti efektivně) spočítat jako podíl skalárního součinu obou vektorů (v čitateli) a součinu velikostí obou vektorů (ve jmenovateli).
Funkční hodnoty kosinu velmi dobře odráží vzájemnou (ne)souvislost slov. Kosinus nabývá hodnoty nula pro kolmé vektory => ideální pro slova, která spolu vůbec nesouvisí. Čím více spolu slova souvisejí a jsou s významově podobnější (blíží se synonymu), tím více se kosinus jejich vektorových reprezentací blíží jedničce. Čím více jsou slova související, ale jsou významově odlišná (blíží se antonymu), tím více se kosinus jejich vektorových reprezentací blíží mínus jedničce.
Kosinová podobnost je právě ten případ, kdy o ní nemůžeme hovořit jako o metrice, protože nesplňuje axiomy metriky (nezáportnost, symetrie, trojúhelníková nerovnost). Konkrétně nesplňuje nezápornost (nabývá hodnot -1 až 1). V dnešní době se používá celá řada metrik či podobností, včetně těch založených na modifikaci kosinové podobnosti. Vektorové databáze pracují s pojmem embedding funkce (embedding function). Skrze ni jim lze nainjektovat transformátor a "metriku" pro vybraný model tak, aby vytvořené embeddings s ním byly kompatibilní.
ad 5. Vše dohromady polopaticky
Konkrétně pro případ textů. Vyberu vhodnou vektorovou databázi. Navrhnu po jakých logických celcích data uložím. Vyberu si jazykový model vhodný pro řešení mé úlohy. Použiji implementaci příslušného větného transformátoru a embedding function k vytvoření embeddings.
Jakou vektorovou databázi zvolit?
V TRITON IT jsme se minulý podzim začali připravovat na dva investiční projekty, které jsme se společně s investory rozhodli postavit na AI. Marek nechal naše kluky z vývoje udělat rešerši dostupných vektorových databází. Měli jsme následující požadavky na vektorovou databázi.
snadno integrovatelná s OpenAI API,
mající driver pro Javu,
otevřená, srozumitelná, dobře zdokumentovaná, žádná nabubřelá korporátní zlodějna,
dostatečně prověřená a rozšířená.
Po přečtení rozboru, který mi Maxim sestavil, byla volba vítěze jasná - ChromaDB.
Představení ChromaDB
Základním stavebním kamenem ChromaDB jsou kolekce. Jedna databáze může obsahovat více kolekcí. Do jedné kolekce lze uložit několik dokumentů (textů). Jakou granularitu dat si zvolíme je na nás - dokumenty mohou být věty, odstavce, kapitoly. Na úrovni kolekce si lze zvolit, jakou embedding funkci pro kolekci použít. Tato funkce se pak používá pro všechny dokumenty dané kolekce. Lze tak mít různé embedding funkce pro různé kolekce, ale nikoliv pro různé dokumenty v rámci jedné a tytéž kolekce. Každý dokument v rámci kolekce má své ID, metadata a embeddingy (vektorovou reprezentaci příslušného dokumentu). ID slouží k identifikaci dokumentu v rámci kolekce, podobně jako je tomu u primárních klíčů relačních databází. Díky ID jsem schopen z obslužné aplikace přistupovat ke konkrétnímu dokumentu. Metadata slouží k filtrování. Mohu si tak popsat dokumenty pomocí jejich klíčových vlastností. A potom vybírat pouze ty dokumenty, které odpovídají požadovaným kritériím.
Příklad; Jste výrobce elektroniky, třeba monitorů jako MISURA ;). Vytěžíte veškeré recenze vašich produktů z různých e-shopů distributorů, srovnávačů, recenzních portálů atd.. Vytvoříte v ChromaDB kolekci obsahující všechny uživatelské recenze. Co dokument, to jedna recenze. Embeddingy již byly vytvořeny při vložení recenzí do kolekce. Metadata obsahují: rok vytvoření recenze, kód recenzovaného produktu, počet hvězdiček hodnocení. Chcete vybrat taková hodnocení za minulý rok, která souvisejí s typem, počtem a zapojením napájecích kabelů. Zašlete dotaz, kterým si přes metadata omezíte rok na minulý, nastavíte počet výsledků na 5 a současně zašlete v dotazu například řetězec "dej mi hodnocení, která souvisejí s napájením monitoru, typem, počtem a zapojením napájecích kabelů". Databáze si nejprve dokumenty klasickým způsobem vyfiltruje podle roku, pro zúžené dokumenty vytáhne jejich embeddingy a porovná je s embeddingem, který vytvoří pro text zaslaný v dotazu. Výsledkem bude 5 recenzí z minulého roku, které nejvíce významově odpovídají požadavku.
Proč a jak propojit databázi s OpenAI či jinými LLM?
Vektorové databáze jsou využívány zejména pro uchování a poskytnutí vlastního kontextu pro lokální či externí (ne nutně) jazykové modely, dostupné přes API třetích stran. A to zejména v případech, když se jedná o big data a kontext je značně objemný. V takovém případě využijeme možnosti zakódovat kontext do embeddingů, efektivně ho uchovat v zakódované podobě v databázi i využít vektorové databáze k omezení kontextu, pokud je dobře strukturován pomocí metadat. Naopak pokud je kontext malý, existuje dnes celá řada nástaveb pro standardně rozšířené AI chaty, nebo specializovanější softwary. Navíc tento obor se extrémně rychle rozvíjí. Co nebylo k dispozici dnes, bude zítra.
Příklad; Vezměme si předchozí příklad s recenzemi. Tentokrát však chceme odpověď na otázku: "Co zákazníci nejvíce vyčítají produktu <kód produktu>?", nebo požadujeme: "Napiš mi normostranu textu o tom s čím jsou zákazníci spokojeni u produktů <značka-kategorie>." Potom se nám hodí využít například OpenAI ChatGPT a jako kontext použít natěžené recenze. Vzhledem k tomu, že se jedná o velké množství textu, bude pro nás efektivní i ekonomicky výhodné (přístup k OpenAI API je objemově zpoplatněná služba), když recenze zašleme ve formě embeddingů. V případě prvního dotazu můžeme navíc zaslat jen embeddingy z dokumentů, jejichž metadata jsou spojena s daným kódem produktu. Ve druhém případě zase můžeme pomocí metadat odstranit recenze se špatným hodnocením, protože správným kontextem pro AI jsou pouze pozitivní recenze.
Efektivita komunikace s OpenAI a dostupné embedding funkce
Kontext můžeme do OpenAI zasílat jako klasické řetězce. Nicméně výhodnost tohoto přístupu dramaticky klesá s délkou řetězce (textu). Zaslat kontext v podobě embeddingů má následující výhody:
Embeddingy jsou z hlediska objemu dat výrazně úspornější pro přenos dat => větší efektivita
Embeddingy již v sobě nesou nemalou investici výpočetního času na jejich zakódování => není nutné provádět na serveru třetí strany => opět vyšší efektivita
Protože čas jsou peníze, zejména v případě OpenAI. Jsou k dispozici v OpenAI různé embedding funkce na míru potřebám uživatele. Správná volba embedding funkce dokáže ušetřit cenný čas zpracování a tím i prostředky vynaložené na kredit pro OpenAI. OpenAI své embedding funkce pravidelně zdokonaluje a poskytuje detailní informace o nových embedding funkcích. Jít v tomto ohledu s dobou znamená ušetřit peníze. Například:
text-embedding-3-small nahrazuje původní text-embedding-ada-002 a je výrazně efektivnější pro zpracování než zmíněný předchůdce. To umožňuje při jejím použití ušetřit až 5x tolik kreditu.
text-embedding-3-large naopak umožňuje lépe zachytit význam z velmi dlouhých textů pomocí 3072 dimenzionálního prostoru.
Už to tak bývá zvykem, že s každým upgradem operačního systému si člověk pokládá otázky: "Tak kolik nepotřebných fíčurek zase přidali? a "O co pomalejší to zas celé bude?". Ty nejhorší sajrajty se zpravidla už roky protlačují pod záminkami větší bezpečnosti, nebo údajně více přívětivého uživatelského prostředí. Ano, mé konzervativní srdce potěší jen málo co :)) Proto už skoro 18 let používám Linux jako svůj hlavní operační systém. Z toho cca 14 let Archlinux, který vyniká svižností, stabilitou a naprostou bezúdržbovostí.
Obr. 1: Grafické prostředí KDE 6 po upgrade
Jaká grafická prostředí jsem používal
Jako grafické prostředí jsem používal všelicos. Na začátku to bylo Gnome. Potom jsem se zhlédl v minimalističnosti Xfce, pro něž jsem založil zápis na české Wikipedii. Následovalo další minimalistické prostředí LXQt do nějž jsem svého času přispíval jako programátor zdokonalováním správce souborů Qtfm. Pak mě posedlost minimalističností přestala bavit a již natrvalo jsem zakotvil u KDE.
Přechod z KDE 5 na KDE 6
KDE 5 tady bylo 10 let. Svižné, plnohodnotné grafické prostředí, které se díky Plasmě srovnalo se svými komerčními konkurenty. A v lecčems je i překonalo. Minulý týden jsem zjistil, že mi do archovských repozitářů doputovalo KDE 6. S trochou obavy jsem do Yakuake podvědomě psal archlinuxákům notoricky známé "pacman -Syu". V paměti jsem měl ještě přechod z KDE 4 na KDE 5, kdy jsem si pak dva dny dával dohromady pracovní prostředí. Obavy vystřídal úžas. Do 10 minut nainstalováno i s rebootem. Naprosto hladký přechod, bez jediného problému. A ta rychlost! Mám klasický kancelářský T-čkový Thinkpad se čtyřjádrovým Intel i5 a 48 GB RAM, na nedostatečný výkon si nemůžu stěžovat ani se stovkami tabů v Chrome. Ale ten rozdíl byl stejně cítit. Okamžitá odezva čehokoliv. Žádná prodleva nikde.
KDE 6 oživilo i starý stroj
O víkendu jsem doma šel pozlobit i svůj vysloužilý, stařičký Thinkpad T460, který řádně funí a laguje, když na něm současně běží integrační testy WebMedea jobů pro zpracování dat a současně mám otevřeny 3 robustní IDE a mraky záložek v prohlížeči. Po instalaci KDE 6 nastala opět dramatická změna. Už jsem měl pro něj rezervované místo v našem pohřebišti vysloužilých Thinkpadů, ze kterého si Marek bere součástky, když někomu z rodiny či kolegů potřebuje opravit notebook. Ale stal se tak použitelným. KDE 6 vřele doporučuji.
Dnes jsem věnoval trochu času údržbě blogu. Prošel jsem staré články a opravil odkazy vedoucí z nich. Bylo zajímavé podívat se na to, co se za ta léta změnilo. V zásadě...
Řada webů i větších portálů, institucí (například caves.cz) při svých redesignech kašlou na zachování původní struktury URL, nebo vyřešení přesměrování původních URL na nové. A pak se třeba leckdy díví, že jim klesá organická návštěvnost. To, co ve své informační bublině považujeme za dnes již samozřejmé, řada webařů pořád nedodržuje, ke škodě své a svých klientů.
Odkazoval jsem restaurace napříč republikou, které jsem v průběhu let navštívil. Většina jich už neexistuje. Nejspíše nepřežily Covid. Jejich weby zmizely v propadlišti dějin. Příslušné domény posloužily jako mršiny pro internetové affiliate supy. Ti koupili smazané domény a přesměrovali je na různé online byznysy. Například doménu restaurace cernyjanek.cz na zonky.cz.
Rád odkazuji cokoliv mě zaujme, takový odkaz pak již neměním dokud existuje původní stránka s původním obsahem. Jinak se rozhoduji podle výše uvedených případů. V tom prvním opravím odkaz na novou URL, na které je původní obsah. V tom druhém odkaz většinou smažu. Když afiláci zachovají, nebo dokonce vylepší, původní obsah a v něm si najdou tématický můstek pro odkazování čehokoliv, odkaz nechávám. Pokud ale mrtvolu vykuchají a vyzvrací do ní skladiště PR textů, nebo rovnou přesměrují na pro ně aktuálně výhodný handl, pak tomuto nehodlám sloužit.
Obr. 1: Vytvářet skladiště PR textů má dnes asi stejný význam jako vozit odpad to lesa, vytvořeno v Midjourney
Vnímám webové prostředí jako ekosystém. Weby neustále vznikají i zanikají. Pokud je smysluplný obsah tvořený pro lidi, vždy má svůj smysl bez ohledu zda ho tvoří člověk nebo mu s tím pomáhá umělá inteligence. Naopak výroba bezduchých skladišť odkazů a nic neříkajících textů pro "oklamání" Google nikam nevede. Ať už tyto texty tvoří copywriter za 40 Kč za normostranu, nebo OpenAI. Stejně tak jako pouhé přesměrovávání mrtvých domén není dlouhodobá výhra. Více se tomuto tématu budu věnovat v budoucnu. Dat z WebMedea máme již dost i spoustu zajímavých zjištění.
UPDATE 5. 3. 2024
Já o vlku a Google v aktuálním update vyhledávače oznámil, že se zaměřil na "expired domain abuse" tedy manipulaci s expirovanými doménami, kterou jsem popsal výše.
Před 7 lety jsem na micropage SEO analytika publikoval čtyři archetypy takzvaných SEO šmejdů. Na sklonku roku 2019 jsem sem na svůj blog postupně sepsal zkušenosti se zmíněnými šmejdy. Dnes jsem se k těmto článkům vrátil. Za prvé kvůli opravě a doplnění odkazů, za druhé z nostalgie, protože zmíněné zkušenosti jsou spojeny s našimi začátky a letos bude TRITON IT slavit 10 let.
Když už jsem se k článkům vrátil, rozhodl jsem se, že ty suché odstavce textu (slovy Petra Kulhánka "chleby") obarvím. Že zkusím vygenerovat přes AI zosobnění zmíněných archetypů SEO šmejdů. To, jak přesné karikatury mi na základě mého popisu zhuštěného do několika promptů vypadly, mě samotného zaskočilo :D. Oni to chování mají vepsané do očí, přesně jako ve skutečnosti...
Obr. 1: SEO šmejdi
Tak schválně - který je který? Přidávám odkazy na popisy SEO šmejdů...
S odstupem času jsem si uvědomil, že se mi možná trochu povedlo vystihnout obecné archetypy šejdířů. Doba se přecijen změnila. A online prostor se za ta léta zvětšil. Nejen SEO, ale i jiné obory jako AI, koučink všeho možného, nebo oborový influenceři mají dnes svá temná zákoutí, ve kterých se zmíněné archetypy pohybují. Možná jste už na ně narazili. Upozornila mě na to například moje manželka Káťa, která má vystudovanou biochemii na VŠCHT (nutnou podmínkou pro její kvalifikaci je ovládat biochemické cykly řídící metabolismus látek v lidském těle) a léta klinické praxe v nemocnici na Homolce. A to v momentě, kdy se na sítích začali objevovat oblíbení influenceři takzvaní "proroci jednoho prvku". Ti si vyberou jeden prvek periodické soustavy, ten glorifikují a tvoří o něm obsah založený z části na veřejně dostupných informacích a z části na smyšlených bludech. Ve svém "shopíku" pak prodávají produkty založené na tomto prvku. V četných rozhovorech se pak prezentují jako ti kdo objevili / prohlédli jakési "hlubší souvislosti a podstatu", nebo, že se dostali k informacím, které "doktoři zamlčují". Tedy typičtí reprezentanti archetypu pana Tajemného. Útěchou budiž, že si dnes vybírají prvky typu hořčík nebo selen. Od zázračného léku radithoru, jsme snad přecijen někam za těch 100 let dospěli.
V TRITON IT nedáme dopustit na školení od Michelle Losekoot. Byli jsme na "Jak na sítě" i "Jak na obsah, jako profesionální kreativci". A protože teď máme na sociální sítě nového šikovného kolegu Seržu, posíláme ho na "Jak na sítě". Myslím, že se z toho tady stane taková tradice. Samozřejmě za prvotní výběr Michelle patří velký dík Lucce.
Michelle mne na školení zaujala, mimo jiné, přístupem, kdy si prochází příspěvky na sociálních sítích, vybírá ty zajímavé, podrobuje je analýze a používá je k výuce. Analýza spočívá v konfrontaci sdělení s jedním nebo více Karly (Karel je alegorie typického reprezentanta určité cílové skupiny). Pokud příspěvek projde u jednotlivých Karlů, včetně Karla - věčně remcajícího mrzouta, nebo Karla - znuděného týpka co už všechno viděl a všechno zná, tak má šanci obstát.
Jednu takovou malou ukázku perfektního příspěvku mám z LinkedIn. Autorkou příspěvku je Moni Jiroušková, která nabízí angličtinu a pohybuje se mezi manažery na LinkedIn. Představte si Karla, který je manažer. Angličtinu se několikrát v životě učil a běžně ji používá při obchodních jednáních, zároveň podvědomě cítí, že by na ni mohl ještě zapracovat. Pravidelně ho bombarduje reklama a příspěvky s texty "angličtina snadno a rychle, zaručeně jen u nás, my jsme lepší než nejlepší, u nás na to jdeme jinak". A pak uvidí příspěvek od Moniky "Cítíte se někdy v hovorech v angličtině nekomfortně?" Kdo má největší šanci trefit se do Karlových potřeb a zaujmout ho?
Obr. 1: Perfektní zacílení příspěvku na manažery
Proč je to tak důležité? Který příspěvek s větší pravděpodobností dosáhne lepších výsledků po naboostování kreditem? Ten co má vyladěný obsah a prošel přes Karly, nebo ten co byl vytvořen podle chvilkové emoce či domněnky? A to je důvod, proč i když TRITON IT je primárně analytická firma, tak dbáme na to, abychom se cvičili v údernosti komunikace. Cvičíme si ty naše Karly v hlavě.
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
