4.6 BIBLIO-CHAT

---

Nasledujúca časť dokumentu prináša opis výsledkov výskumno-vývojovej línie biblio.chat v rámci projektu BIBLIB.AI. Riešenie je zamerané na vyhľadávanie nad bibliografickými metadátami formou dialógu čitateľa so systémom. Predstavuje architektúru, ktorá prepája spracovanie prirodzeného jazyka, deterministické pravidlá, hybridné vyhľadávanie a preskúmateľné spracovania. Kapitola podrobne rozoberá východiskové zadanie, teoretické základy, viacfázový návrh linky spracovania (pipeline), implementačné rozhodnutia, testovaciu a validačnú vrstvu, ako aj prínosy a limity riešenia. Dôraz sa kladie na to, že jazykový model nie je použitý ako nekontrolovaný generátor odpovedí, ale ako riadená interpretačná a plánovacia vrstva nad reálnymi dátami online katalógu knižnice. Za osobitne významné možno považovať zavedenie logickej vrstvy prezentácie dotazu SearchPlan, zavedenie experimentálnej fázy NULA (Phase 0), vrstvy ktorá umožňuje prieskum v dátach a tiež zavedenie interakcie v dialógu s čitateľom.. Výsledok presahuje úroveň lokálneho „proof-of“ konceptu a predstavuje prenositeľný základ pre integráciu do ďalších katalógových systémov, osobitne do prostredia INFOGATE, BIBLIB A DAWINCI OPAC.

Vyhľadávanie dialógom; bibliografické metadáta; RAG; BIBLIB.AI; Elasticsearch; hybridné a sémantické vyhľadávanie; jazykové modely

Oblasť biblio_chat vznikla ako reakcia na praktický problém, ktorý je v knižnično-informačných systémoch dlhodobo prítomný: medzi používateľským spôsobom formulácie informačnej potreby a vnútornou štruktúrou bibliografických databáz existuje výrazná medzera. Tradičné katalógové rozhrania sú silné vtedy, keď používateľ vie, čo presne hľadá, rozumie logike vyhľadávacích polí a dokáže pracovať s fazetami (hierarchické spresňovanie dotazu), filtrami a kombináciami dotazov. V reálnom používaní však veľká časť používateľov vstupuje do systému skôr prostredníctvom prirodzeného jazyka, neúplných formulácií a postupného spresňovania zámeru. Zadanie biblio_chat preto nemožno vnímať iba ako technický doplnok existujúceho OPAC rozhrania, ale ako pokus premostiť rozdiel medzi prirodzenou komunikáciou a formálne organizovaným bibliografickým priestorom.

Východisková požiadavka smerovala k vytvoreniu prakticky použiteľného dialogického rozhrania, ktoré nebude fungovať ako všeobecný chatbot odpovedajúci na otvorené otázky, ale ako systém pevne ukotvený v reálnych katalógových dátach. Táto požiadavka je kľúčová, pretože v oblasti knižničných katalógov nie je prípustné, aby jazykový model len vierohodne formuloval odpovede bez väzby na dostupné záznamy. Systém musel byť schopný previesť používateľský vstup na kontrolovaný vyhľadávací plán a následne tento plán vykonať nad indexovanými bibliografickými metadátami. Základný problém teda nespočíval len v porozumení prirodzenému jazyku, ale aj v zabezpečení toho, aby interpretácia dopytu zostala auditovateľná, reprodukovateľná a spätne overiteľná.

Zadanie bolo od začiatku formulované ako viacvrstvové. Na jednej strane išlo o návrh backendovej architektúry, ktorá dokáže spracovať viacotáčkový dialóg, udržiavať kontext relácie, rozpoznať rozdiel medzi novým vyhľadávaním a upresňovaním (refine) už existujúceho výsledku a poskytovať stabilné API rozhranie pre používateľa (frontend). Na druhej strane bolo potrebné navrhnúť interpretačnú vrstvu, ktorá zvládne prevádzať neformálny používateľský vstup na štruktúrované podmienky. Na tretej úrovni bolo nutné vyriešiť samotné vyhľadávanie tak, aby podporovalo nielen presné lexikálne dotazy, ale aj menej exaktne formulované tematické a odporúčacie dopyty. Súčasťou zadania napokon bolo aj to, aby riešenie bolo technicky prenositeľné a aby sa z neho dali abstrahovať princípy použiteľné v ďalších produktových líniách.

Z pohľadu projektového riadenia je dôležité, že biblio_chat nebol chápaný ako izolovaný experiment, ale ako komponent, ktorý má ambíciu vstúpiť do širšieho ekosystému BIBLIB. Tomu zodpovedá aj charakter dosiahnutých výstupov: výsledkom nie je iba zdrojový kód funkčného backendu, ale aj súbor návrhových, analytických, validačných a prenosových dokumentov. Tieto dokumenty tvoria dôležitú súčasť výsledku, pretože formalizujú architektonické rozhodnutia, pomenúvajú hranice použiteľnosti a umožňujú preniesť poznatky do ďalších implementačných prostredí. V tomto zmysle má biblio_chat dvojitú hodnotu - ako softvérové riešenie aj ako výskumno-vývojový artefakt.

Teoretické zázemie riešenia tvoria tri navzájom previazané oblasti: informačné vyhľadávanie, spracovanie prirodzeného jazyka a práca so štruktúrovanými bibliografickými metadátami. Každá z týchto oblastí prináša do návrhu odlišné obmedzenia aj príležitosti. Informačné vyhľadávanie poskytuje modely ranking-u, relevancie a práce s indexami. Spracovanie prirodzeného jazyka umožňuje interpretovať voľne formulované otázky, rozpoznávať zámer a extrahovať významové prvky zo vstupu. Bibliografické metadáta zase reprezentujú štruktúrovaný opis dokumentov, ktorý sa vyznačuje vysokou mierou formalizácie, prítomnosťou riadených slovníkov, viacjazyčnosťou a heterogénnou kvalitou jednotlivých polí.

V klasickom katalógovom prostredí sa vyhľadávanie opiera o presne definované polia, ako sú názov, autor, predmetové heslá, jazyk, rok vydania alebo typ dokumentu. Takýto model je veľmi presný, no používateľsky náročný. Používateľ musí implicitne rozumieť tomu, že systém rozlišuje napríklad medzi témou a autorom, medzi názvom diela a názvom série, alebo medzi jazykom dokumentu a jazykom záznamu. Prirodzený jazyk naopak umožňuje formulovať potrebu spontánne, bez poznania vnútornej dátovej schémy, ale zavádza neurčitosť, synonymiu, elipsu, nejednoznačnosť a vysokú variabilitu jazykových prejavov. Riešenie biblio_chat preto vychádza z toho, že dialóg nad katalógom nemôže byť redukovaný na jednoduchú tokenizáciu textu alebo na priamy preklad otázky na súbor kľúčových slov.

Metodologicky významným princípom sa stalo explicitné oddelenie interpretácie zámeru od vykonania vyhľadávania. Ide o rozhodnutie, ktoré má nielen technickú, ale aj epistemologickú hodnotu. Jazykový model môže pomôcť porozumieť tomu, čo používateľ pravdepodobne zamýšľa, ale nemá byť zdrojom samotných bibliografických faktov. Z tohto dôvodu vzniká medzi používateľským vstupom a finálnym dotazom do Elasticsearch kontrolovateľná medzireprezentácia vo forme SearchPlan. Táto vrstva znižuje riziko halucinácií, podporuje auditovateľnosť a umožňuje vývojárovi alebo analytikovi spätné vysvetlenie toho, prečo systém vykonal konkrétny dotaz práve takým spôsobom.

Ďalším teoretickým pilierom je hybridné vyhľadávanie. Čisto lexikálne prístupy fungujú veľmi dobre pri explicitných názvoch, pri autoroch a pri ostro špecifikovaných filtroch. Horšie však zvládajú prípady, keď používateľ zadáva tematický dotaz, parafrázu, neúplnú formuláciu alebo dopyt, ktorý sa významovo podobá relevantným dokumentom, ale nepoužíva rovnakú slovnú zásobu. Čisto sémantické prístupy naopak zvyšujú odolnosť voči formulácii, no bez doplnenia štruktúrovanými obmedzeniami neposkytujú potrebnú kontrolu nad katalógovou presnosťou. Kombinácia lexikálnej a vektorovej zložky preto predstavuje pragmatický kompromis medzi presnosťou a robustnosťou.

Dôležitou metodologickou kategóriou je aj konverzačné vyhľadávanie. V praxi je bežné, že používateľ neformuluje kompletný dopyt naraz, ale buduje ho postupne. Najprv zadá všeobecnú tému, potom doplní jazyk, vylúči autora, obmedzí obdobie alebo spresní typ dokumentu. Systém preto musí uchovávať stav relácie, vedieť pracovať s pamäťou predchádzajúcich konverzácií a deterministicky rozhodovať, či nová vstupná veta predstavuje nové hľadanie alebo upresňovanie predchádzajúceho výsledku. V bibliografickej oblasti je táto požiadavka obzvlášť citlivá, pretože malé spresnenia môžu výrazne meniť množinu výsledkov a systém musí zachovať používateľskú dôveru tým, že nebude svojvoľne strácať kontext.

Napokon treba zdôrazniť význam vysvetliteľnosti (transparentnosti), teda schopnosti systému priebežne reportovať a spätne rekonštruovať vlastné spracovanie. Pri orchestrácii viacerých krokov, v ktorých sa stretáva deterministický parser, LLM vrstva, vyhľadávanie v Elasticsearch a sumarizačná vrstva, vzniká vysoká potreba diagnostiky. Observabilita tu neplní iba prevádzkovú funkciu, ale stáva sa súčasťou metodológie validácie. Umožňuje analyzovať, v ktorom kroku vznikol problém, aké vstupy boli do jednotlivých fáz odovzdané a ako boli rozhodnutia podložené údajmi z katalógu. Takto chápaná observabilita je predpokladom spoľahlivého výskumu aj bezpečného nasadenia.

Návrh biblio_chat je založený na zásadnej architektonickej téze: dialogické rozhranie nemá obchádzať existujúcu vyhľadávaciu vrstvu, ale má nad ňou vytvoriť inteligentnú a kontrolovanú nadstavbu. Táto myšlienka je dôležitá z dvoch dôvodov. Po prvé, zachováva kontinuitu s už existujúcou vyhľadávacou infraštruktúrou platformy BIBLIB / DAWINCI a umožňuje využiť overené indexy, polia a filtre. Po druhé, zabezpečuje, že prirodzený jazyk slúži ako vstupný komunikačný kanál, nie ako náhrada samotného katalógového modelu. Výsledkom je architektúra, ktorá vie interpretovať používateľský zámer, no stále rešpektuje štruktúru bibliografických údajov a princípy katalogizačného vyhľadávania.

Kľúčovým návrhovým rozhodnutím sa stala viacfázová linka spracovania. V ustálenom tvare riešenia sa rozlišuje päť krokov, ktoré tvoria logickú aj implementačnú kostru systému. Fáza NULA (phase 0) vykonáva ukotvenie (grounding) nad katalógom prostredníctvom lacných prieskumných dotazov, ktoré zhromažďujú indície o jazyku, autoroch, dominantných rokoch či tematických kľúčových slovách. Fáza A interpretuje zámer používateľa a snaží sa rozlíšiť typ dopytu. Fáza B generuje explicitný vyhľadávací plán. Nasleduje vykonanie samotného vyhľadávania v indexe a vo fáze C sa pripraví používateľská odpoveď spolu so sumarizáciou výsledkov a aktualizáciou pamäte relácie. Dôležité je, že jednotlivé fázy nevystupujú ako izolované kroky, ale ako navzájom previazané rozhodovacie stupne, ktoré sa opierajú o predošlé výstupy.

Významnou vlastnosťou návrhu je, že nie každý vstup musí prechádzať celým jazykovo orientovaným procesom spracovania. Pre explicitné a štruktúrovane formulované príkazy bola zavedená deterministická skratka. Ak používateľ zadá upresnenie typu jazyk: eng, autor: Eco, rok: 2020 alebo formuláciu s významom zobraz iba, systém takýto vstup rozpozná ako operáciu upresnenia a obíde nákladnejšie kroky založené na LLM. Toto rozhodnutie má vysokú praktickú hodnotu: znižuje latenciu, znižuje náklady, obmedzuje variabilitu správania a zároveň zvyšuje predvídateľnosť v situáciách, kde je požadované skôr presné vykonanie inštrukcie než sémantická interpretácia.

Jadrom architektúry je meta-reprezentácia SearchPlan. Slúži ako kontrakt medzi interpretačnou vrstvou a vyhľadávacou vrstvou a súčasne ako nositeľ vysvetľujúcich artefaktov. Obsahuje nielen základný dopyt, ale aj režim výberu metódy hľadania (zámer čitateľa), váhy lexikálnej a sémantickej zložky, jazykové filtre, autorov na zahrnutie či vylúčenie, obmedzenia rokov, tematické termíny a ďalšie parametre. Vďaka tomu možno spätne skúmať, ktoré aspekty používateľskej požiadavky sa pretavili do finálneho dopytu a ktoré ostali mimo. Architektonicky ide o mimoriadne dôležitý prvok, pretože umožňuje udržiavať systém rozšíriteľný bez toho, aby sa logika spracovania strácala v neprehľadnom spletení dotazov (prompt) a ad hoc výnimiek.

Samostatnú hodnotu má aj dokumentačná vrstva architektúry. Dokumenty phase0_grounding_design.md, query_set_analysis.md, trace_observability.md a séria dawinci_chat_* nevystupujú iba ako doprovodná technická dokumentácia, ale ako nositelia formalizovaného know-how. Vďaka nim možno architektúru nielen implementovať, ale aj analyzovať, obhajovať a prenášať. To je pre projekty ako biblib.ai obzvlášť dôležité, pretože v prostredí výskumno-vývojových projektov sa úspech riešenia nemeria tým či funguje v jednom nasadení, ale aj tým, či je možné jeho princípy generalizovať do ďalších produktových a inštitucionálnych kontextov.

Implementácia biblio_chat je realizovaná ako samostatný backendový servis nad prostredím FastAPI. Táto voľba je pragmatická aj architektonicky vhodná: FastAPI prirodzene podporuje explicitne definované vstupné a výstupné modely, jednoduchú prácu s JSON payloadmi, asynchrónne spracovanie a transparentnú dokumentáciu endpointov. Exponované rozhrania POST /api/chat/start, POST /api/chat/turn, GET /api/chat/progress a GET /api/health pokrývajú základný životný cyklus relácie. Systém tak disponuje čistým API kontraktom, ktorý je vhodný pre frontendovú integráciu aj pre technické testovanie.

Na úrovni dátových kontraktov sa využívajú modely Pydantic. Tento prvok síce môže pôsobiť ako štandardná implementačná voľba, no v kontexte biblio_chat má zásadný význam. Keďže systém pracuje s viacerými druhmi payloadov - od založenia relácie, cez jednotlivé turny, priebehový stav, debug informácie až po sumarizované odpovede - explicitná validácia vstupov a výstupov znižuje riziko tichých chýb a uľahčuje budúce rozširovanie. Zároveň ide o dôležitý predpoklad integračnej disciplíny, pretože stabilita rozhraní je pri viacvrstvovom riešení kritická.

Riadiacim jadrom systému je trieda ChatOrchestrator. Práve v nej sa koncentruje rozhodovacia logika jedného turnu. Orchestrátor načíta reláciu, vytvorí trace_id, nastaví priebehový stav, spustí parser zámeru, podľa potreby aktivuje grounding a plánovanie, vykoná vyhľadávanie, pripraví výslednú odpoveď a aktualizuje pamäť relácie. Takáto koncentrácia runtime logiky do centrálneho komponentu má výhodu v tom, že znižuje rozptýlenosť správania a uľahčuje ladenie. Zároveň vytvára jednoznačné miesto, v ktorom sa dajú dopĺňať ďalšie pravidlá, špeciálne vetvy alebo dodatočné diagnostické mechanizmy.

Perzistencia kontextu je v aktuálnom stave riešená prostredníctvom InMemorySessionStore. Tento komponent uchováva históriu turnov, predchádzajúce plány, sumarizáciu pamäte, posledné reasoningové vysvetlenie aj aktuálny stav priebehu relácie. Z implementačného hľadiska ide o riešenie primerané predprodukčnému a experimentálnemu štádiu: poskytuje nízku latenciu a jednoduchú správu, no zároveň transparentne definuje limit, že pri produkčnom škálovaní bude potrebné prejsť na distribuované ukladanie. Dôležité je, že tento limit je v projekte korektne pomenovaný a nie je zamlčaný, čo zvyšuje technickú dôveryhodnosť riešenia.

Parser zámeru je implementovaný deterministicky prostredníctvom regulárnych výrazov a jednoduchých pravidiel. Rozlišuje základné triedy reset, new_search a refine, pričom pri refine vie explicitne rozpoznať jazyk, rok, autora, vylúčenie autora, tému a názov. Práve tento parser predstavuje významný stabilizačný prvok celého systému. V oblastiach, kde sa používateľské inštrukcie opakujú v relatívne predvídateľných formách, je deterministické spracovanie presnejšie a prevádzkovo výhodnejšie než inferencia jazykovým modelom. Riešenie tak ukazuje rozumnú distribúciu zodpovednosti medzi pravidlá a generatívne metódy.

Osobitnú implementačnú hodnotu má modul ElasticsearchGateway. Jeho úloha nie je obmedzená iba na zostavovanie finálneho dopytu a komunikáciu s indexom. Modul realizuje aj experimentálnu Phase 0 vrstvu, v ktorej sa vytvárajú adaptívne prieskumné dotazy raw_sample, language_filtered_sample, author_exact_sample a pri dostupnom embedding servise aj semantic_sample s broadfallback mechanizmom. Výsledkom je štruktúra Phase0Evidence, ktorá zhromažďuje signály o dominantných jazykoch, kľúčových slovách, rokoch a kandidátnych autoroch. Tým sa znižuje riziko, že neskoršie fázy budú pracovať v úplne abstraktnom priestore bez kontaktu s konkrétnym rozložením dát v katalógu.

Finálne vyhľadávanie je postavené na modeli SearchPlan a podporuje režimy lexical, hybrid a semantic. Táto trojica režimov je implementačne dôležitá, pretože umožňuje adaptovať stratégiu podľa charakteru dopytu aj podľa dostupnosti infraštruktúrnych služieb. Ak je k dispozícii embedding služba, systém môže kombinovať lexikálny a sémantický prístup s nastaviteľnými váhami. Ak embedding služba dostupná nie je alebo je nekorektne nakonfigurovaná, systém degraduje kontrolovane, bez zlyhania celej služby. Z prevádzkového hľadiska ide o jednu z najcennejších vlastností riešenia, lebo znižuje riziko úplnej nedostupnosti pri čiastkovom výpadku externých komponentov.

Vyhľadávacia vrstva súčasne rešpektuje viaceré režimy vyhľadávania (searchscope): INFOGATE, MYLIB, BIBLIB_standalone a BIBLIB_shared. Scope ovplyvňuje výber indexu aj povinné filtre, napríklad filtráciu podľa používateľského identifikátora v holdingoch alebo prepnutie na knižničný index s viazaním na konkrétnu inštitúciu. Biblio_chat teda nevznikol len ako sterilné laboratórne riešenie nad jedným idealizovaným datasetom, ale ako komponent navrhovaný s vedomím reálnych prevádzkových scenárov, v ktorých môžu platiť odlišné prístupové, inštitucionálne a dátové podmienky.

SearchPlanner predstavuje samostatnú vrstvu s praktickou hodnotou. Obsahuje mechanizmy na tvorbu základného plánu, budovanie plánu z parsera zámeru, prácu s LLM výstupom, sanitizáciu vstupných hodnôt a fallback heuristiky. Sanitizačné pravidlá normalizujú jazykové kódy, obmedzujú neplatné hodnoty a korigujú rok vydania či retrieval režim. Dôležitá je aj schopnosť zostaviť použiteľný plán bez aktívneho OpenAIbackendu iba zo správy používateľa a z evidence získanej v Phase 0. Táto vlastnosť robí z plannera nielen pomocnú vrstvu, ale jeden z hlavných stabilizačných mechanizmov celej architektúry.

LLM integrácia je realizovaná cez OpenAIResponsesClient využívajúci endpoint /responses. Podstatné však nie je len to, že systém komunikuje s jazykovým modelom, ale ako je táto komunikácia zapojená do architektúry. Model nevracia hotový Elasticsearch DSL a nevykonáva vyhľadávanie namiesto systému. Jeho úlohou je formulovať interpretáciu zámeru a navrhnúť vyhľadávací plán v kontrolovanom tvare. Toto rozhodnutie možno označiť za architektonicky kľúčové, pretože zveruje modelu tie činnosti, v ktorých je silný - sémantickú interpretáciu a plánovanie - a zároveň mu neprenecháva kompetencie, ktoré by znižovali kontrolu nad väzbou na skutočné dáta.

Multijazyčnosť je implementovaná systematicky prostredníctvom BackendI18n a samostatných JSON zdrojov pre jazyky sk, en, cs, de a uk. Slovenčina funguje ako kanonický fallback, na ktorý sa vrství zvolený jazyk. Ide o dôležité rozhodnutie, pretože rozširuje použiteľnosť riešenia bez potreby budovať samostatné vetvy logiky pre každý jazyk. Zároveň sa tým znižuje riziko neúplných prekladov pri ďalšom rozširovaní systému. Lokalizované nie sú iba textové odpovede, ale aj promptové inštrukcie a niektoré backendové hlášky, čo posúva multijazyčnosť z prezentačnej vrstvy do samotného jadra spracovania.

Významným implementačným výsledkom je observabilita. Komponent QueryLogger umožňuje samostatne prepínať logovanie Elasticsearch dotazov, HTTP requestov, OpenAI udalostí, payloadov, interactiontrace a ES odpovedí. Dokument trace_observability.md spolu s exportným skriptom extract_session_trace.py vytvárajú časovú os spracovania jedného turnu. Takáto observabilita zásadne zvyšuje schopnosť spätnej analýzy a skracuje cestu od zistenia problému k jeho reprodukcii. V oblasti komplexných AI orchestrácií ide o rozdiel medzi systémom, ktorý sa dá seriózne prevádzkovať, a systémom, ktorý je síce efektný, ale ťažký na správu.

Napokon treba spomenúť pripravenosť na nasadenie. Modul bol nasadený do vývojových aj testovacích rozhraní a experimentálne 16.4 aj do verejného riešenia INFOGATE.SK. V aktuálnom stave je formulovaný ako služba, ktorú možno rozumne integrovať, konfigurovať, monitorovať a ďalej rozvíjať.

Testovacia vrstva riešenia je viacúrovňová a pokrýva implementačnú korektnosť, technickú integritu aj doménovo orientované behaviorálne scenáre. Projekt obsahuje samostatné automatizované testy, smoke testy, sanity-checky a dokumentované akceptačné frázy, teda sa snaží o maximálnu mieru technickej disciplíny, než býva bežné pri experimentálnych AI komponentoch. Testovanie tu neplní iba rolu kontroly chýb v kóde; funguje aj ako mechanizmus postupného formalizovania poznatkov o tom, ktoré typy dopytov systém zvláda stabilne a kde sa nachádzajú jeho hranice.

Automatizované testovanie je realizované pomocou skriptov (py -3 -m pytest -q) a výsledky boli ručne validované. Na testovanie bola použitá databáza INFOGATE s 2.3 miliónom záznamov. Pre tieto účely bola databáza doplnená o vrstvu sémantického vyhľadávania, index bol migrovaný na poslednú verziu ElasticSearch a pre každý záznam bol pomocou LLM vygenerovaný embedding vektor.

Scenár viackolového dialógu s dopytom „hľadám knihy o astronómii“ a následným spresnením zobraz iba jazyk slo poskytol veľmi hodnotnú empirickú sondu do správania systému. Pri prvom kole systém vrátil 815 výsledkov, z ktorých zobrazil desať najrelevantnejších, pričom z log údajov vyplynulo, že pracoval v režime hybrid, s úspešne aplikovanou sémantickou zložkou, embeddingom dimenzie 384 a vo fáze NULA použil dva sondovacie dotazy a dosiahol odozvu z vysokou mierov dôvery. Druhé kolo s jazykovým obmedzením znížil počet výsledkov na 442, relácia korektne prešla do režimu „refine“ so „strict_mode“ a deterministickým mechanizmom spracovania. Táto sekvencia veľmi dobre ilustruje jeden z hlavných cieľov riešenia: systém dokáže kombinovať flexibilné prvotné vyhľadanie s presným a lacným presným dotazom bez straty kontextu.

Obsah jednotkových a integračných testov pokrýva najdôležitejšie vlastnosti architektúry. Testy parsera overujú reset, jazykové refine vstupy a správanie pri existujúcom i neexistujúcom kontexte. Testy scope logiky verifikujú mapovanie medzi vstupnými parametrami relácie a režimami MYLIB, INFOGATE, BIBLIB_standalone a BIBLIB_shared. Tieto testy sú dôležité preto, že práve scope rozhoduje o tom, nad akým informačným priestorom sa používateľ v skutočnosti pohybuje, a chyby v tejto vrstve by mali zásadné dôsledky na relevanciu aj bezpečnosť výsledkov.

Osobitnú pozornosť si zaslúžia testy plannera a využitia „Phase 0“. Overuje sa v nich, že fallback mechanizmy dokážu využiť dominantný jazyk, dominantné kľúčové slová a kandidátnych autorov pri tvorbe vyhľadávacieho plánu. To znamená, že grounding nie je len pasívna diagnostická stopa, ale reálne vstupuje do rozhodovania o ďalšom spracovaní. Takéto prepojenie medzi prieskumnou a plánovacou vrstvou zvyšuje dátovú ukotvenosť architektúry a zároveň znižuje riziko príliš abstraktných interpretačných krokov.

Testy ElasticsearchGateway sa zameriavajú na konštrukciu prieskumných dotazov, prítomnosť sampler agregácií, jazykové filtre, script_score sémantické dotazy, broadfallback pri slabom striktne sémantickom probe a čistenie dotazu od boilerplate jazyka. Význam týchto testov spočíva v tom, že Phase 0 je jednou z najinovatívnejších častí riešenia a bez testov by išlo len o zaujímavý návrhový nápad. Vďaka testovaciemu pokrytiu však možno tvrdiť, že ide o implementovaný a validovaný subsystém.

Testy orchestrátora ďalej overujú tvorbu interaction_trace, zachovanie searchscope po resete, vynechanie Phase 0 pri deterministickom refine a prenášanie phase0_evidence do payloadov fáz A a B. Mimoriadne dôležitý je test fallbacku pri chýbajúcom OpenAI API kľúči. Potvrdzuje, že systém zostáva funkčný aj bez aktívneho LLM backendu. V kontexte produkčného nasadzovania ide o strategicky významný výsledok, pretože služba sa nestáva úplne závislou od nepretržitej dostupnosti externého modelového poskytovateľa.

Medzi technicky menej nápadné, no prakticky zásadné oblasti patria testy internacionalizácie a logovania. Normalizácia locale aliasov, načítanie jazykových zdrojov a úplnosť kľúčov voči slovenskej základni zvyšujú dôveryhodnosť multijazyčnej vrstvy. Overenie správania loggera pri zapnutom aj vypnutom logovaní zas dokazuje, že observabilita je implementovaná kontrolovane a nevytvára nechcené vedľajšie artefakty. Práve tieto zdanlivo sekundárne vrstvy často rozhodujú o tom, či je systém dlhodobo prevádzkovateľný.

Pre potreby dokumentácie je vhodné uviesť aj reprezentatívne scenáre, ktoré kombinujú návrhové test cases s reálnym behom nasadeného API. Nižšie uvedené výsledky pochádzajú z overenia proti backendubiblio_chat; keďže ide o živé dátové prostredie, presné počty výsledkov sa môžu v čase meniť podľa stavu indexu, aktualizácií dát a správania ranking vrstvy.

Z uvedených scenárov vyplýva, že riešenie dosahuje veľmi dobré výsledky v tematických, autorovo orientovaných a deterministicky spresňovaných dopytoch. Zároveň sa potvrdzuje, že pri šumových alebo opakovane formulovaných vstupoch je systém funkčný, no jeho správanie ešte ponúka priestor na ďalšiu stabilizáciu. Táto asymetria nie je nedostatkom dokumentácie, ale dôležitým výskumným zistením, ktoré pomáha presne vymedziť hranice súčasnej verzie.

Príklady komunikácie medzi frontendom a backendom

Pre potreby opisného dokumentu je vhodné komunikáciu medzi frontendom a backendom zobrazovať v skrátenej forme. Nižšie uvedené ukážky zachovávajú rozhodujúce polia, ale zámerne vypúšťajú rozsiahle časti odpovedí, ako sú celé zoznamy výsledkov, dlhé textové sumarizácie alebo kompletné debug štruktúry.

1. Inicializácia relácie

Frontend odošle požiadavku na vytvorenie relácie:

HTTP

POST /api/chat/start

Content-Type: application/json

{}

Backend odpovie stručným identifikátorom relácie:

JSON

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”

}

Tento krok je dôležitý preto, že všetky ďalšie turny sa viažu na konkrétnu reláciu a systém v nej uchováva kontext predchádzajúceho vyhľadávania.

2. Prvý vyhľadávací turn

Skrátený príklad požiadavky frontendu:

HTTP

POST /api/chat/turn

Content-Type: application/json

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”,

“message”: “hladam knihy o astronomii”,

“locale”: “sk”,

“response_language”: “sk”,

“top_k”: 5

}

Skrátená odpoveď backendu:

JSON

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”,

“answer”: “Nasli sa knihy o astronomii, vesmire, hviezdach a planetach…”,

“search_plan”: {

“query”: “astronomiavesmir hviezdy planety kozmonautika”,

“retrieval_mode”: “hybrid”,

“semantic_query”: “knihy o astronomii, vesmire, hviezdach a planetach”,

“languages”: [“rus”, “cze”, “slo”, “pol”],

“top_k”: 5

},

“total_results”: 1249,

“returned_results”: 5,

“results”: [

{ “title”: “Vesmir”, “year”: 1995 },

{ “title”: “Vesmir”, “year”: 2004 },

{ “title”: “Planety”, “year”: 1963 }

],

“debug”: {

“phase0_meta”: {

“status”: “ok”,

“probe_count”: 2,

“confidence”: “high”

},

“search”: {

“used_attempt”: “original”,

“semantic”: {

“applied”: true,

“status”: “ok”,

“vector_dims”: 384

}

}

}

}

V tejto ukážke je dobre viditeľné, že backend nevracia iba textovú odpoveď, ale aj štruktúrovaný vyhľadávací plán, zoznam výsledkov a diagnostické údaje, ktoré možno použiť na ladenie alebo detailnejšiu interpretáciu.

3. Kontextové spresnenie v tej istej relácii

Frontend po prijatí prvého výsledku odošle nový turn:

HTTP

POST /api/chat/turn

Content-Type: application/json

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”,

“message”: “zobraz iba jazyk slo”,

“locale”: “sk”,

“response_language”: “sk”,

“top_k”: 5

}

Skrátená odpoveď backendu:

JSON

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”,

“search_plan”: {

“retrieval_mode”: “hybrid”,

“languages”: [“slo”],

“top_k”: 5

},

“total_results”: 641,

“returned_results”: 5,

“context_depth”: 2,

“debug”: {

“plan_mode”: “refine”,

“strict_mode”: true,

“phase0_meta”: {

“status”: “skipped_structured_refine”,

“probe_count”: 0

},

“phase_a_source”: “deterministic_refine”,

“phase_b_source”: “deterministic_refine”

}

}

Táto komunikácia ilustruje jednu z najsilnejších vlastností riešenia: jednoduché spresnenie nepotrebuje opakovať celý interpretačný cyklus a je spracované ako deterministická operácia nad existujúcim kontextom.

4. Priebehový stav relácie

Na účely frontendovej signalizácie alebo debugovania je možné čítať aj priebehový stav:

HTTP

GET /api/chat/progress?session_id=cdaed202-8d16-4231-ae0a-1861f39a5ab1&locale=sk&response_language=sk

Skrátená odpoveď:

JSON

{

“session_id”: “cdaed202-8d16-4231-ae0a-1861f39a5ab1”,

“state”: “done”,

“step”: “completed”,

“meta”: {

“total_results”: 641,

“shown”: 5

}

}

Takáto odpoveď je dobre využiteľná vo frontendovom rozhraní na indikáciu stavu spracovania, priebežné aktualizácie používateľského rozhrania alebo diagnostické zobrazenie.

Najvýznamnejším prínosom riešenia je skutočnosť, že dokáže sprostredkovať čitateľovi prirodzený vstup do bibliografického prostredia aj s pomocou LLM ale bez toho, aby sa rozpojila väzba na reálne dáta. V dobe, keď mnohé generatívne riešenia zvyšujú komfort používateľa za cenu nižšej kontroly a vyššieho rizika halucinácie, predstavuje biblio_chat odlišný typ prístupu. Používateľský komfort sa tu zvyšuje nie nahradením katalógu, ale inteligentným nadviazaním naň. Z pohľadu knižnično-informačných systémov ide o strategicky dôležitú vlastnosť, pretože zachováva presnosť, dohľadateľnosť a možnosť auditovať výsledok.

Za druhý zásadný prínos možno považovať architektonickú disciplínu pri rozdelení rolí medzi jednotlivé komponenty. Deterministický parser rieši explicitné a opakujúce sa refine operácie, SearchPlanner formalizuje prechod od zámeru k plánu, ElasticsearchGateway realizuje dátovo ukotvené vyhľadávanie a LLM vrstva pomáha tam, kde je potrebná sémantická interpretácia. Takáto distribúcia zodpovednosti je rozumným návrhovým rozhodnutím, pretože nevkladá všetku inteligenciu do jedného netransparentného kroku a umožňuje postupné zlepšovanie jednotlivých častí bez nutnosti prepisovať celý systém.

Tretím prínosom je zavedenie Phase 0 grounding vrstvy. V mnohých konverzačných vyhľadávacích systémoch vzniká plánovanie nad používateľskou otázkou bez akéhokoľvek predbežného kontaktu s dátami. Biblio_chat naopak vytvára lacné prieskumné dotazy, ktorými zbiera signály o skutočnom profile výsledkov v indexe. To znižuje pravdepodobnosť nereálnych interpretačných krokov a posúva plánovanie bližšie k dátovo podloženému rozhodovaniu. Z vedecko-technického hľadiska ide o dôležitú inováciu, pretože spája silu generatívnej interpretácie s disciplínou empirického overovania ešte pred samotným rankingom.

Štvrtým prínosom je vysoká úroveň observability. Trasovanie interakcie, logovanie dotazov, možnosť exportu „session“ ID a bohatý výstup ladenia zvyšujú nielen udržateľnosť systému, ale aj jeho skúmateľnosť. V praxi to znamená, že problémové správanie možno spätne rozobrať bez improvizovaného dohľadávania roztrúsených logov. V širšom pohľade ide o dôležitý posun: riešenie sa nehodnotí len podľa toho, či produkuje prijateľný výsledok, ale aj podľa toho, či dokáže vysvetliť vlastný proces.

Riešenie však má aj jasne identifikované limity. Niektoré z nich sú prirodzené vzhľadom na aktuálne štádium projektu. InMemorySessionStore limituje horizontálne škálovanie a viacworkerové produkčné nasadenie. Kvalita sémantickej zložky je čiastočne viazaná na dostupnosť a konfiguráciu embedding služby. Relevancia pri čisto odporúčacích alebo veľmi subjektívnych dopytoch zatiaľ nedosahuje rovnakú stabilitu ako pri autorových, tematických či filtrovaných požiadavkách. Slabšou oblasťou sú aj otázky viazané na okamžitú dostupnosť dokumentu alebo na atribúty, ktoré nebývajú konzistentne prítomné v bibliografických metadátach, napríklad počet strán.

Tieto limity však nemožno interpretovať ako zlyhanie konceptu. Naopak, ich explicitné pomenovanie je znakom zrelosti výstupu. Projekt neprezentuje nerealistický obraz univerzálne fungujúceho chatového vyhľadávania, ale pomerne presne vyznačuje hranice, v ktorých je riešenie silné a kde je potrebné ďalšie rozšírenie doménových znalostí, metadát alebo rankingových signálov. Práve táto kombinácia funkčného prototypu a realistickej reflexie limitov robí z biblio_chat hodnotný výskumno-vývojový základ. Ďalší výskum reálnych vstupov a výsledkov z reálnej prevádzky bude pre ďalší vývoj veľkou výzvou.

Významnou črtou dosiahnutého riešenia je jeho prenositeľnosť. To, že popri implementácii vznikla aj séria dokumentov pre prostredie DAWINCI, nie je len vedľajším administratívnym výstupom. Ide o dôkaz, že architektúra dosiahla úroveň abstrakcie, pri ktorej možno oddeliť všeobecné princípy od konkrétnych detailov jednej platformy. Takáto prenositeľnosť je v oblasti informačných systémov dôležitá, pretože hodnota výskumno-vývojového výsledku rastie, ak sa dá aplikovať aj v susedných doménach a nie je uzamknutý v jedinej implementácii.

Prenositeľné sú najmä tieto princípy: oddelenie interpretácie zámeru od vykonania vyhľadávania, využitie SearchPlan ako kontraktovej medzireprezentácie, kombinácia deterministických refine operácií s LLM plánovaním, využitie grounding vrstvy pre predbežné zberanie dôkazov a dôraz na observabilitu. Tieto princípy nie sú viazané výlučne na jednu schému bibliografického indexu. Môžu byť adaptované aj na iné knižničné systémy, na digitálne knižnice, repozitáre alebo špecializované informačné portály, pokiaľ disponujú vyhľadávacím backendom a štruktúrovanými metadátami.

Integračný potenciál sa ukazuje aj na úrovni API kontraktov a prevádzkového balenia. FastAPI rozhranie, Pydantic modely, dockerizácia a explicitne dokumentované prevádzkové limity uľahčujú začlenenie do existujúcich infraštruktúr. Riešenie je zároveň navrhnuté tak, aby bolo možné meniť niektoré komponenty bez narušenia celku - napríklad nahradiť sessionstore, upraviť embedding službu alebo rozšíriť parser zámeru o nové doménové vzory. Takáto modulárnosť zvyšuje technologickú životnosť projektu.

Pre prenos do ďalších systémov bude rozhodujúce, ako presne sa podarí namapovaťSearchPlan na konkrétne metadátové polia a aké rankingové signály bude možné využiť. Architektonický základ je však pripravený. To je z vedecko-technického hľadiska podstatné: projekt už nevytvára len jednorazový prototyp, ale ponúka prenositeľný dizajnový vzor pre inteligentné vyhľadávacie rozhrania nad štruktúrovanými dátami.

Budúci rozvoj riešenia možno rozdeliť na tri osi: infraštruktúrnu, dátovo-relevančnú a interakčnú. Na infraštruktúrnej úrovni bude prirodzeným krokom prechod z in-memorysessionstore na perzistentné alebo distribuované úložisko kontextu. Takýto posun odstráni súčasné limity produkčného škálovania, umožní bezpečnejší multiworker režim a otvorí priestor pre robustnejšie dlhšie relácie používateľov. Zároveň by bolo vhodné ďalej rozšíriť monitorovanie, metriky a alerting, aby sa observabilita neobmedzovala iba na diagnostické logy, ale prešla aj do štandardných prevádzkových dashboardov.

Na dátovo-relevančnej úrovni sa ponúka prehĺbenie práce s autoritnými záznamami, riadenými slovníkmi a doménovými synonymickými mapami. Práve bibliografické prostredie poskytuje príležitosť skombinovať klasickú knižničnú expertízu s modernými sémantickými metódami. Rozšírenie o bohatšie signály by mohlo zlepšiť výkon pri odporúčacích dopytoch a pri náročnejších tematických formuláciách. Zaujímavou líniou je aj systematickejšie hodnotenie relevancie na reprezentatívnom sete anotovaných dopytov, ktoré by umožnilo porovnávať režimy lexical, hybrid a semantickvantitatívnejšie než doterajšie overenia.

Na interakčnej úrovni možno odporučiť rozšírenie schopnosti vysvetliť používateľovi, ako bol jeho dotaz interpretovaný, bez toho, aby sa odpoveď stala technicky preťaženou. Vhodne navrhnuté explainability prvky by mohli zvyšovať používateľskú dôveru, najmä pri refine operáciách a pri dopytoch, kde systém využíva viacero indícií. Ďalšou perspektívou je práca s personalizovanými kontextmi, napríklad s preferovaným jazykom používateľa, históriou jeho predchádzajúcich výberov alebo s inštitucionálnym nastavením konkrétnej knižnice. Takéto rozšírenia však musia zostať v súlade s požiadavkou transparentnosti a kontrolovateľnosti.

Z výskumného hľadiska je sľubná aj hlbšia analýza Phase 0 grounding vrstvy. Jej koncepcia naznačuje, že medzi úplne bezprostredným dopytom používateľa a samotným rankingom možno vytvoriť užitočnú vrstvu zberu dôkazov. Ďalší výskum by mohol skúmať, aké typy prieskumných dotazov prinášajú najvyššiu informačnú hodnotu, ako optimálne kalibrovať confidence úroveň a do akej miery možno grounding využívať aj pri adaptívnej voľbe retrieval stratégie. Práve tu sa môže biblio_chat stať nielen produktovým komponentom, ale aj zaujímavým experimentálnym rámcom pre širšie štúdium konverzačného vyhľadávania nad štruktúrovanými kolekciami.

V oblasti biblio_chat boli dosiahnuté výsledky, ktoré presahujú úroveň izolovaného experimentálneho proof-of-conceptu. Vzniklo funkčné backendové riešenie pre dialogické vyhľadávanie nad bibliografickými metadátami, ktoré spája viacotáčkový kontext, deterministické spracovanie štruktúrovaných spresnení, LLM orientovanú interpretáciu zámeru, hybridné vyhľadávanie nad Elasticsearch a explicitnú observabilitu celého toku spracovania. Popri implementácii vznikla aj ucelená dokumentačná základňa, vďaka ktorej je možné riešenie analyzovať, prenášať a ďalej rozvíjať.

Za kľúčový vedecko-technický prínos možno považovať architektúru, v ktorej jazykový model vystupuje ako riadená interpretačná a plánovacia vrstva, nie ako nekontrolovaný generátor výsledkov. Táto voľba je pre bibliografické systémy mimoriadne vhodná, pretože zachováva väzbu na katalógové dáta, umožňuje audit rozhodnutí a vytvára predpoklady pre bezpečnejšie produkčné nasadenie. Rovnako významné je zavedenie SearchPlan ako meta-reprezentácie, Phase 0 grounding vrstvy a interactiontrace mechanizmu, ktoré spolu vytvárajú pevný základ pre transparentné a rozšíriteľné dialogické vyhľadávanie.

Výsledky testovania a integračného overenia potvrdzujú vysokú mieru technickej konzistencie aktuálnej implementácie. Súčasne analytické dokumenty realisticky vyznačujú oblasti, v ktorých systém dosahuje najvyššiu účinnosť, aj tie, kde je žiaduce pokračovať vo výskume a rozširovaní. Biblio_chat tak predstavuje nielen konkrétny softvérový komponent, ale aj premyslený výskumno-vývojový základ pre novú generáciu inteligentných knižničných a bibliografických rozhraní v ekosystéme BIBLIB.

Z tohto pohľadu možno uzavrieť, že dosiahnuté výsledky majú nielen bezprostrednú implementačnú hodnotu, ale aj metodologickú a strategickú relevanciu. Projekt ukazuje, že dialogické rozhranie nad katalógom možno navrhnúť tak, aby zostalo verné princípom informačného vyhľadávania, využilo silu moderných jazykových modelov a súčasne si zachovalo kontrolu, auditovateľnosť a prenositeľnosť. Práve v tejto kombinácii spočíva hlavná hodnota riešenia biblio_chat.