Tudástárak és dokumentumvisszakeresés használata

A tudástár dokumentumokat tárol a kereséshez és az engedélyezett AI-használathoz.

Jelentkezz be, és válassz postafiókot, majd nyisd meg a Tudástár menüpontot. A létrehozáshoz, kezeléshez, kereséshez, megosztáshoz és az automatikus e-mailes használathoz a megfelelő knowledge.* jogosultság kell. A feldolgozáshoz konfigurált tárolás, víruskeresés, kinyerés és beágyazás is szükséges. A deployment-útvonalat a környezeti konfigurációban válaszd ki, majd ellenőrizd a környezeti referenciát.

Az adminisztrátornak be kell állítania az aktív, natív OpenAI beágyazási szolgáltatót és modellt, valamint a csoportod modellhozzáférését a megosztott AI-katalógusban. A tudástár-jogosultságok önmagukban nem adnak modellhozzáférést.

Hozz létre egy tudástárat, válaszd ki a mappáját, és tölts fel egy támogatott fájlt vagy ZIP-et. Figyeld az egyes fájlokat, amíg el nem érik a ready állapotot. Csak ezután használhatja a visszakeresés az indexelt tartalmat. Ha egy archívum eléri a ready állapotot, ez nem jelenti, hogy minden importált gyermekelem (fájl és almappa) már kereshető.

Tulajdonjog és hozzáférés

Az új tudástár a létrehozó postafiókhoz tartozik, és csak ahhoz látszik. Minden mappa és fájl örökli a tudástár hozzáférés-vezérlési listáját (ACL). Mappa- vagy fájlszintű felülírás nincs. A bérlői csoportos megosztások öt, egymástól független jogot adhatnak: read, manage, search, share és useInAutomaticEmail. Mindegyikhez a megfelelő funkciójogosultság is kell. Egy UUID ismerete bérlők között sem ad hozzáférést.

Az olvasási jog nem engedélyezi az automatikus kimenő e-mailt. Az automatikus e-mailes visszakeresés a keresési és a kimenő használati jogot együtt ellenőrzi. A backend újra beolvassa a csoporttagságot és a tudástár állapotát. A modell csak lekérdezéseket és a kiválasztott tudástár- és mappaazonosítókat adja meg. A bérlőt, az actort vagy a postafiók tulajdonjogát nem.

A megosztó nem adhat tovább olyan jogot, amellyel maga nem rendelkezik. Csak a tulajdonos postafiók törölheti a teljes tudástárat. A fájl vagy mappa törlése azonnal kizárja a tartalmat a visszakeresésből. A későbbi Qdrant- és S3-takarítás nem szabályozza a hozzáférést.

Feltöltés és feldolgozás

A böngésző soros feltöltéssel, 512 KiB-os, sorszámozott részekben tölt fel. A backend a feltöltés elején lefoglalja a deklarált tárhelyet. A tulajdonoshoz kötött adatbázis-zárolás megakadályozza, hogy párhuzamos feltöltések túllépjék a postafiók kvótáját. Egy ismételt rész csak azonos SHA-256 hash esetén idempotens. A backend elutasítja az eltérő tartalmat vagy részindexet.

Az alapértelmezett korlátok fájlonként 50 MiB, ZIP-enként 250 MiB. Ezen felül 1 GiB kibontott tartalom, 2000 archívumbejegyzés és postafiókonként 2 GiB engedélyezett. A bérlői szabályzat módosíthatja ezeket a korlátokat. Egyetlen fájl nem lehet nagyobb 256 MiB-nál. A ZIP felső határa 1 GiB, a bejegyzések felső határa 100 000. A felület a tényleges korlátokat jeleníti meg.

A támogatott kiterjesztések: txt, md, csv, htm, html, json, doc, docx, xls, xlsx, ppt, pptx, pdf, png, jpg, jpeg, gif, webp, tif, tiff, bmp és zip.

Az eredeti fájlok ellenőrzött részekként maradnak az S3-ban. Olvasáskor a rendszer újra ellenőrzi a méretet és a hash-t. A ClamAV a kinyerés előtt a teljes adatfolyamot átvizsgálja. Ha a víruskereső hibázik, a kinyerés és a beágyazás blokkolt marad.

A ZIP-importálás egyszerre egy bejegyzést olvas, és megőrzi a relatív mappákat. A névütközés számozott másolatot hoz létre. A bejárási útvonal vagy a szimbolikus link megállítja az importot. A titkosított bejegyzések, a beágyazott ZIP-ek, a nem támogatott formátumok és a túl nagy bejegyzések figyelmeztetést adnak. A bejegyzés- és a kibontott-méret korlátai érvényesek. A tartós bejegyzésazonosító újraindítás után is megakadályozza a duplikációkat.

Az izolált Apache Tika 4 endpoint a PUT /tika/json/html. A kinyerés a tk:content kulcsot használja, nem a régi X-TIKA:content kulcsot. Az OCR a hun+eng nyelvet használja. A dokumentum-, oldal-, munkalap- és címsorhivatkozások a kinyert struktúrából származnak, nem a modell találgatásából. A részleges vagy üres kinyerés hiba.

Az IUDG külön Node-szolgáltatás nélkül, egyszerre egy tartós feladatot dolgoz fel. A lease-ek és a heartbeat-ek védik a párhuzamos folyamatokat. A maximális kísérletszám három. Az újrapróbálkozási késleltetés 30, majd 60 másodperc. A hibák láthatók maradnak, és kifejezett újrapróbálkozást engednek.

Beágyazás és visszakeresés

A beágyazás szöveget numerikus vektorokká alakít a hasonlóságkereséshez. A beállított modell a text-embedding-3-small, 1536 dimenzióval. Aktív bérlői OpenAI-katalógusmodell/-szolgáltató és alkalmazható csoportos modelljogosultság kell a felhasználónak. A modellnek apiType: embedding típusúnak, 1536 dimenziósnak és default reasoning beállítással kell lennie. A szolgáltatónak a natív api.openai.com címre kell feloldódnia. Tetszőleges OpenAI-kompatibilis endpoint nem felel meg ennek az útvonalnak.

A hitelesítő adatok a titkosított szolgáltatókonfigurációból származnak.

A beágyazás a szokásos modell-befogadást, a kontextuskorlátokat, az ellenőrzött HTTPS-átvitelt és a knowledge.embedding forrású használati nyilvántartást használja. A Qdrant azonosítókat tárol, nem dokumentumszöveget. A PostgreSQL friss hozzáférés- és állapotellenőrzés után adja a találatok szövegét és hivatkozásait. A régi vektorok nem tehetnek láthatóvá visszavont vagy törölt tartalmat. A searchKnowledge(input, "automatic-email") a szigorúbb kimenő belépési pont.

API-referencia

Endpoint	Szerződés
GET /knowledge?libraryId=…&cursor=…	Elérhető tudástárak, mappák, oldalanként 100 fájl, nextCursor, megosztások, kiválasztható bérlői csoportok és korlátok.
POST /knowledge	library.save/delete, folder.save/rename/delete, share.save/delete, upload.start/part/finish, file.rename/delete/retry és search.
GET /knowledge/file?id=…	Újraellenőrzött eredeti letöltés egy kész fájlhoz, csatolmány-típusú Content-Disposition és no-store fejléc használatával. Nem szolgál ki beágyazott HTML-t.
AdminService GET/PUT knowledge-limits	A bérlő knowledge.limits beállításainak olvasása és kezelése az admin.ai.models.read/manage jogosultsággal.

A szigorú műveleti szerződések a backend src/lib/knowledge/contracts.ts fájlban és a kapcsolódó típusmodulokban vannak. A keresés {query, results} objektumot ad vissza. Minden találat tartalmazza a chunkId, fileId, libraryId, path, text, score és citation mezőt.

Működés és hibaállapotok

A helyi Compose-deploymentben a qdrant szolgáltatás a privát knowledge hálózatot, a knowledge-extractor pedig az izolált extraction hálózatot használja. Egyik sem tesz közzé gazdagépi portot. Az IUDG éri el őket. A böngésző csak az alkalmazás API-it használja.

A kinyerő konténerének írásvédett fájlrendszere van, korlátozott /tmp tmpfs-sel, CPU-, PID- és memóriakorlátokkal, és nincs képessége (capability). Konfigurációja a docker/knowledge/tika-config.json fájl. Image-definíciója a docker/images/knowledge-extractor.Dockerfile fájl.

Az IUDG a konfigurált szolgáltatásokhoz a QDRANT_URL, a QDRANT_API_KEY és a KNOWLEDGE_EXTRACTOR_URL változókat használja. A meglévő objektumtároló-konfiguráció biztosítja az S3-hozzáférést. A víruskereső átvitelnek két támogatott útja van:

• TCP: a CLAMAV_HOST és a CLAMAV_PORT választja ki a víruskeresőt. Az alapértékek clamav és 3310.
• Hitelesített HTTPS: állítsd be a CLAMAV_SCAN_URL és a CLAMAV_SCAN_TOKEN változót is. Az URL a /scan endpointra mutasson.

Bármelyik HTTPS-változó megadása kiválasztja ezt az átvitelt. Hiányos pár, kapcsolódási hiba vagy érvénytelen ítélet TCP-visszalépés nélkül sikertelen vizsgálatot jelent. Csak a pontos tiszta ítélet engedélyezi a kinyerést. A megfelelő átvitelt a környezeti referenciában válaszd ki. A víruskereső tokenjét ne írd nyilvános példákba.

A Qdrant-kulcs soha nem jut el a böngészőbe. Az első indexelés létrehozza az ecas_knowledge_small_1536 gyűjteményt. A modell vagy a dimenziók megváltoztatása újraindexelést igényel.

A feldolgozási lánc: uploading → queued → scanning → extracting → indexing → ready. A ZIP-gyermekek külön feladatot kapnak. A warnings rögzíti a kihagyott bejegyzéseket. A skipped a titkosított dokumentumokat jelöli. A failed a leállt feldolgozást jelöli. A nyilvános hibák nem tartalmaznak hitelesítő adatot, és nem tartalmazzák az eredeti tartalom teljes szövegét.

A munkavégző 5 másodpercenként ellenőriz, 15 másodpercenként heartbeat-et ír, és a 180 másodperces lease-t elhagyottnak tekinti. A lefoglalás növeli a kísérletszámot, a folyamatkudarcokat is beleértve. A file.retry újraindítja a teljesen feltöltött, sikertelen fájlt friss actor-kontextussal, és beágyazási költséget okozhat.

A 24 órán át inaktív uploading fájl deleted állapotba kerül, cleanupPending jelöléssel. Ez azonnal felszabadítja a lefoglalt postafiók-kvótát. A takarítás törli az eredeti S3-részeket és a részmetaadatokat. Minden feltöltött rész frissíti az aktivitást. Ez a lejárat nem érinti a sorban álló, feldolgozás alatt lévő vagy kész fájlokat. A visszakeresés nem indexel újra automatikusan.

Tünet	Ellenőrzés
Az állapot uploading marad	Minden sorszámozott résznek és az upload.finish hívásnak meg kell érkeznie. A receivedBytes értékének meg kell egyeznie a size értékével.
Víruskeresési hiba	A ClamAV elérhetősége, az aláírások és az INSTREAM-korlát. A vizsgálat kihagyása nem támogatott.
Kinyerési hiba	A kinyerő naplói, az OCR-csomagok, az időtúllépések, a tmpfs és a kimeneti korlátok. A titkosított vagy részleges dokumentumok nem indexelhetők.
Beágyazási hiba	Aktív OpenAI-szolgáltató, katalógusmodell, modelljogosultság, kontextuskorlát és a használati nyilvántartás.
Nincs találat	A fájl ready állapotú, a kiválasztott hatókör tartalmazza, és az aktuális funkciójogosultságok és az ACL engedélyezik a keresést.
Halasztott takarítás	A Qdrant és az S3 elérhetősége. A törölt metaadat már blokkolja az olvasást és a visszakeresést.

A mentéseknek együtt kell tartalmazniuk a PostgreSQL-metaadatokat, az S3-ban lévő eredeti részeket és a Qdrant-tárolót. A Qdrant önmagában nem tartalmaz dokumentumszöveget. A tudástár törlése tombstone-t ír, mielőtt a takarítás eltávolítaná a vektorokat, az eredeti fájlokat és a darabokat. A sikertelen takarítás egy későbbi ellenőrzésnél újrapróbálkozik. A tombstone-t ne távolítsd el addig, amíg a takarítás be nem fejeződik.

Kinyerő erőforráskorlátai

Egy elemző-folyamat legfeljebb 768 MiB Java-kupacot és két logikai CPU-t használ. A szerver kupac-korlátja 256 MiB. A konténer memóriája 2 GiB, a /tmp tmpfs pedig 512 MiB. A dokumentum-puffer és az elemző ideiglenes fájljai ugyanazon a tmpfs-en osztoznak.

A fájlonkénti szabályzati felső határ és a HTTP-kérés felső határa is 256 MiB. Az alapérték 50 MiB marad. Ez nem garantálja minden tömörített, 256 MiB-os dokumentum kinyerését. A túl nagy ideiglenes adat, OCR-kimenet vagy válasz látható hibát okoz. Az archívum-munkavégző minden gyermekre alkalmazza a fájlonkénti korlátot.

A készenléti ellenőrzés tíz bájtos ecas-ready szöveget küld a /tika/text endpointra Bash TCP-támogatással. HTTP 200 választ és azonos kimenetet vár. Ez az elemzési útvonalat ellenőrzi, nem csak a nyitott portot. Nincs szükség extra curl-függőségre. A healthcheck konfigurációja a konténer újralétrehozásakor lép érvénybe, az engedélyezett deployment folyamaton keresztül.