kovacs-muhely

kovacs-muhely

A tudástárak builder-oldali eszköztára — pipeline-forge engine, tenantonkénti ingest-pipeline-ok, üzemeltetői szkriptek

2026. októberéles szerver · GPU-poolBuilder ↔ végfelhasználótenantok: iier2 · kmtr
Pozicionálás

Két oldal, egy adatbázis — ki mit tesz?

A toolkit — ez a repo

  • Builder/üzemeltető használja
  • Ingest, újraépítés, retrieval-QA a bin/pf-fel
  • Nincs saját MCP szervere — a QA közvetlenül a kereső pipeline-t futtatja

A végfelhasználói oldal — iier-tudastar

  • Távoli pf-mcpd tenant-útvonalak, nincs helyi szerver
  • /mcp/iier2 — 7 tool · /mcp/kmtr — 6 tool
  • Csak olvas, AD-csoport kapuval

A közös backend

  • Tenantonként saját adatbázis az éles szerveren
  • Minden chunk hordozza a projects[] ACL-t
  • Builder ír, végfelhasználó csak olvas
A toolkit tartalma

Mi van a dobozban?

Engine

  • bin/pf + bin/pf.exe — a pipeline-forge CLI
  • Mindkettő ugyanabból a pipeline-forge commitból épül, commitolva
  • A deploy-hosztnak nem kell Go

Pipeline-ok

  • 86 pipeline .md fájl, tenantonként mappában
  • Ingest · kereső · wiki · eljárás-gráf · QA tool-ok
  • Mind szerkeszthető, verziózott dokumentum

Nincs Python

  • A repóban egyetlen .py fájl sincs
  • SharePoint, compact, LDAP: natív pf-adapterek
  • Egy nyelv: a pipeline .md

Üzemeltetői szkriptek

  • run_embed.sh — egy pipeline futtatása a tenant env-jével
  • rag_status.sh · rag_counts.sh — futások és chunk-számok
  • pre_deploy_check.sh · post_deploy_smoke.sh

Ütemezés

  • A pipeline fejlécének schedule: kulcsa a forrás
  • A pf-worker az éles szerveren ütemez
  • Éjszakai ablak, tenantonként eltolt idősávban

Retrieval-QA

  • /km-search-iier2 — a kereső pipeline-t futtatja
  • Embed után: „visszakereshető-e?”
  • Builder-oldali ellenőrzés, nem éles felület
Multi-tenancy

Tenantok — kik élnek ma?

Tenant Mit tárol Állapot
iier2 Confluence, JIRA, SharePoint, wiki, eljárás-gráf éles
kmtr ugyanaz a felállás, a iier2 mintájára éles — bevezetés lezárva 2026-10-04
belső IT-tudásbázis Confluence, JIRA, web, GitLab, munkanapló éles, saját adatbázissal
DWH-dosszié felhasználói és leltár-dossziék heti embed
iier (régi) — kivezetve, az útvonal lekapcsolva 2026-10-03

Egy tenant = egy saját adatbázis + egy pipelines/<tenant>/ mappa + egy pf-mcpd útvonal. Új tenant adat és másolat, nem kód (lásd később).

Pipeline-állomány

Egy tenant pipeline-jai — iier2 / kmtr

forge_ldap

AD-tükör: a jogosultság-feloldó bemenete — ki melyik csoport tagja

forge_jira

Issue-ok delta-embed, projektenként projects[] scope

forge_confluence

Registry-vezérelt oldalak, tér-szintű scope

SP-crawl_site

SharePoint v2: docx + xlsx, táblák EAV-ba, hierarchia-élek

forge_compact

Hasonló témák klaszterei — a projects[] a tagok uniója

forge_cross_source_links

SharePoint ↔ Confluence same_as élek — kalibrálásig kikapcsolva

search_rag · search_compact

ACL-szűrt keresés a hívó felhasználó nevével

WIKI · ELJ · TOOL

Generált enciklopédia, eljárás-gráf, builder-QA tool-ok

ACL

Hozzáférés — a jog a sorban él, nem az alkalmazásban

A forrás a manifest

  • A jogokat az admin rendszere exportálja — mi csak alkalmazzuk
  • Az ACL-load éjszakánként betölti, saját, szűk loader-szerepkörrel

A szűrés az adatbázisban

  • Minden chunk viszi a projects[] listát
  • A keresés a hívó AD-csoportjaiból számolja a láthatót
  • Ismeretlen hívó: csak a _public — zárt alapállás

Nincs alapértelmezett scope

  • Ismeretlen tér vagy projekt: a futás hibát ad, nem talál ki scope-ot
  • A grant tulajdonosi döntés, adatként rögzítve
Forrás-mélyfúrás

SharePoint v2 — registry-vezérelt crawl, táblák mint adat

Mit csinál

  • A könyvtárakat a registry adja (a manifestből vetítve), nincs beégetett lista
  • docx és xlsx; a táblázat-sorok rag.document_eav-ba kerülnek, a szövegben horgony jelöli a helyüket
  • xlsx-lapok vékony összefoglalóként embedelődnek
  • Hierarchia-élek a mappaszerkezetből — LLM-hívás nélkül

Hol fut

  • Saját idősávban, nem az éjszakai fő folyamatban
  • Ok: a hosszú crawl kiéheztette a compact lépést — ezért külön vált
  • Delta-alapú: változatlan dokumentum nem embedelődik újra

Az első teljes crawl mérlege (iier2, 2026-08-05):

21 432

dokumentum

437 110

hierarchia-él

Éjszakai menetrend

Ütemezés — a pf-worker kezeli

Idő Pipeline Tenant
22:45 · 23:00 acl_load kmtr · iier2
23:15 · 23:30 SP-crawl_site kmtr · iier2
01:30 éjszakai embed — belső IT-tudásbázis belső
02:30 ops_iier2_nightly_embed iier2
03:30 ops_kmtr_nightly_embed kmtr
06:00 ops_nightly_status_all — reggeli összesítő mind
07:20 ops_nightly_watchdog_iier2 iier2 + kmtr

Az éjszakai folyamat forrásai delta-alapúak és egymást nem blokkolják: egy forrás hibája nem állítja meg a többit, sem a compact lépést. A worker életjelét egy 15 perces időzítő figyeli, a workeren kívül.

A modell

Embedding és keresés

Egy modell

  • snowflake-arctic-embed2 — az egyetlen embedding-modell
  • A modellt a gyűjtemény adja (rag.collection_model()), nem a pipeline

GPU-pool

  • Több GPU-példány közös pool-ban, átállással
  • Ugyanaz a pool szolgálja az embedet és az LLM-hívásokat

Magyar előtagok

  • [CÍM:][FEJEZET:] · [OLDAL:][TÉR:] a chunk elején
  • A cím és a hely a vektor része lesz

Reranker — opcionális

  • Cross-encoder, rerank_provider argumentummal kapcsolható
  • Ha nem érhető el, a vektorsorrend marad — a keresés nem áll le
Üzemeltetői munkamenet

Mindennapi munka

Futtatás

# egy forrás újraépítése a tenant env-jével
./run_embed.sh forge_confluence_iier2
./run_embed.sh forge_jira_iier2
./run_embed.sh SP-crawl_site

# állapot és számok
./scripts/rag_status.sh
./scripts/rag_counts.sh

Skill-ek a Claude Code-ban

  • /km-embed · /km-status — futtatás és állapot
  • /km-nightly-status · /km-nightly-check — az éjszaka eredménye
  • /km-search-iier2 — retrieval-QA
  • /km-deploy — telepítés a manifest alapján
  • /km-ops-watch · /km-ops-bugs · /km-ops-test — tenantonkénti monitorozás
Esettanulmány

Végfelhasználói kérés — egy forrástól a találatig

„Ezt a teret is kereshetővé tennétek?” — a válasz adat, nem kódváltozás.

  1. Kérés

    A felhasználó jelzi, mit keresne

  2. Manifest

    Az admin felveszi a jogosultság-manifestbe

  3. Registry

    Az acl_load kivetíti a rag.crawl_sources-ba

  4. Éjszaka

    A következő futás felveszi, delta-alapon

  5. Ellenőrzés

    rag_counts.sh · /km-search-iier2

Idempotens. A változatlan oldal tartalom-hash-e egyezik, újra nem embedelődik — csak az új tartalom kerül chunkolásra és GPU-hívásra.

Multi-tenancy

Új tenant — adat és másolat, nem kód

A kmtr így készült 2026 októberében — a iier2 felállásának másolataként.

  1. Grant + routing

    Egy migráció: tenant_grants, scope_map sorok

  2. Pipeline-mappa

    pipelines/<tenant>/ — a iier2 másolata

  3. Env-kulcsok

    Tenant-névtérrel, a vaultban

  4. Menetrend

    Éjszakai embed + watchdog listába

  5. MCP-útvonal

    Új pf-mcpd tenant-route

  6. Manifest-csomag

    A jogosultság-export új csomagja

Mérés

Számok — a kmtr az első héten

4 717

JIRA issue · 9 060 chunk (2026-10-02)

313

Confluence-oldal · 658 chunk (2026-10-02)

23 509

SharePoint-chunk 150 dokumentumból (2026-10-03)

30

AI-vázlat wiki-cikk (2026-10-02)

Setup

Telepítés és migráció

Deploy

  • ./deploy.sh <profil> — a deploy.manifest.yaml alapján
  • A telepítés is pipeline: ops_deploy_km.md
  • Előtte pre_deploy_check.sh, utána post_deploy_smoke.sh

Migráció

  • Számozott SQL-fájlok, élő adatbázisra egyszerre egy
  • A migrációs szkript --dry-run módja előbb
  • Az apply.sh csak friss telepítésre — élő DB-t elutasít

A pf-bináris

  • pipeline-forge-változás után mindkét binárist újra kell építeni
  • Ugyanabból a commitból, a commit-üzenetben rögzítve
Összefoglalás

Mit ad a builder-oldali toolkit?

Minden lépés dokumentum

Pipeline .md-ben — nem kell Go- vagy Python-kódot módosítani

A jog az adatban

Soronkénti projects[] ACL, az admin manifestjéből

Új tenant másolattal

Hat adat-lépés, nulla új kód — a kmtr a bizonyíték

Reggel minden látszik

Összesítő + watchdog: ami éjjel nem futott, az reggel már jelez