Plugin-architektúra és izoláció

A plugin a csomagolási egység: JAR-fájlként töltődik be, futás közben, a rendszer leállítása nélkül (hot reload), és ugyanígy távolítható el. Egy plugin egy vagy több tool-t (agentet) tartalmazhat. Minden plugin szigorúan a saját domainjének hatáskörén belül működik, a hatáskörén kívüli adathoz a platformon keresztül sem fér hozzá. Az SDK elfedi a keresési réteget, a modellkommunikációt és a munkamenet-kezelést, a fejlesztőnek csak azt kell megválaszolnia, mit csináljon a plugin.

Az SDK alap absztrakt tool-okat ad (például webes keresés, összefoglaló-készítés). Ezek leszármaztatással és domainhez rendeléssel aktiválhatók, az alap chatbot pipeline viszont nem használja őket, így ami nincs telepítve és hozzárendelve, az nem fut.

SDK-dokumentáció

A plugin-fejlesztés részletes leírása, az API-k és a példák a külön SDK-dokumentációban érhetők el.

SDK-dokumentáció megnyitása →

Négy bővítési irány

Kérdés-vezérelt tool: a rendszer a felhasználó szándéka alapján választja ki, például külső API vagy adatbázis-lekérdezés.
Koordinátor-vezérelt tool: prioritás szerint sorba rendezett, akár párhuzamosan futó lépések, például oldalelemzés vagy összefoglalás.
Domain-szintű koordináció: minden domain saját vezérlési logikát kaphat, vagy támaszkodhat a beépített alapértelmezett működésre, egyedi fejlesztés nélkül.
Offline tudásfeltöltés: a tudásbázis bővítése és karbantartása a valós idejű forgalomtól elkülönítve, akár külső rendszerből vagy scraperből.

Plugin fejlesztésével saját ingestion pipeline is kialakítható: a szervezet saját adatforrásaiból (külső rendszer, scraper, egyedi formátum) ugyanabba a feldolgozási láncba tölthető be tudás, mint a kézzel feltöltött dokumentumok, beleértve a tudásgráf építését.

A tool-ok egymásra épülhetnek, összetett feldolgozási láncokat alkotva, és nemcsak válaszolnak, hanem új tudást is betölthetnek a domain számára.

Platform API

A teljes intelligencia-réteg REST és streaming API-n keresztül is elérhető, chatfelület nélkül, meglévő vállalati rendszerekbe integrálva. A válasz szinkron vagy streamelt (SSE, NDJSON), a kimenet Markdown, strukturált JSON (az Ön által megadott sémával) vagy letölthető PDF lehet. A hívás megadhatja a domaint, a system-szűrőket és a kontextus méretét. A hitelesítés OAuth2, külön jogosultsági körrel.

Hosszú futású feladatok aszinkron módon indíthatók és követhetők.

MCP-integráció

Külső rendszerek adatai egyedi API-konnektorokon vagy szabványos MCP-szerveren keresztül érhetők el, így nem kell mindent előre feltölteni a tudásbázisba. Hogy mikor melyik rendszerből kér a platform adatot, azt a plugin fejlesztője dönti el. A platform a felhasználótól megerősítést kér, ha a hívás ezt igényli, és a külső szervernek küldött adatokat kiszivárgás-szempontból is ellenőrzi. Az eszközhívások naplózottak és auditálhatók.

Modellek

A nyelvi modell vLLM-en keresztül, OpenAI-kompatibilis interfésszel csatlakozik, ezért nyílt modellek között szabadon váltható.

Technológiai alap

Java és Spring Boot, Apache Spark, ArangoDB (vektor, gráf és dokumentum egyben), Redis, Angular és vLLM. A platformhoz saját identitáskezelő tartozik, amely bármely OAuth2 identity providerrel kompatibilis.

A technológiai alap kialakításakor az volt a cél, hogy minél több réteg saját kézben legyen: a retrieval-réteg, a pontszám-összevonás, az orchestráció és az LLM API kliens saját fejlesztés. Így a rendszer kevesebb külső komponens kompatibilitásától függ, a verziófrissítések és a modellcserék pedig kiszámíthatóbbak. A Java/Spring Boot alap kiszámítható verziózást, teljes JVM monitoringot és visszafelé kompatibilitást ad.

Üzemeltetés

A platform konténerekben fut, és a telepítés formája a szervezethez igazodik: Docker Compose, igény esetén Kubernetes cluster, skálázáshoz több példány. A frissítés leállásmentesen megoldható, például szkripttel, amely a csere idejére ideiglenes példányt futtat, és ha az új verzió nem indul el, a régi verzió fut tovább.

Egyeztessünk az integrációról.

Ismertesse a meglévő rendszereket, és közösen megtervezzük a csatlakozást.

Frissítve: