De uitdaging
Orchestrator-core is een open-source framework voor het beheren van productlevenscycli en workflows voor netwerkinfrastructuur. Het is gebouwd door en voor de NREN-community: National Research and Education Networks zoals SURF, dat er subscriptions, diensten en configuraties mee beheert voor meer dan 100 Nederlandse onderwijs- en onderzoeksinstellingen, en GÉANT, de pan-Europese backbone die ze allemaal verbindt.
Het probleem was zoeken. De domeinmodellen van orchestrator-core zijn door gebruikers gedefinieerd: operators stellen producten samen uit herbruikbare product blocks, die willekeurig diep kunnen nesten. Eén subscription kan honderden attributen bevatten, verspreid over diep geneste structuren. Het schema ligt niet vast. Het evolueert zodra iemand een nieuw producttype definieert.
Traditioneel zoeken werkt hier niet. Elasticsearch heeft een bekend schema nodig. Statische kolomindexen kunnen geen structuur volgen die pas op runtime bestaat. Simpele LIKE-queries begrijpen geen betekenis. Voor operators die duizenden subscriptions beheren, betekende iets vinden: handmatig doorklikken door geneste pagina's.
De samenwerking
SURF initieerde het project en regelde financiering via het GÉANT GN5-2 Incubator-programma. Tim Fröhlich ontwierp en bouwde het kern-zoeksysteem. Virge leverde de AI-agentlaag: de type-safe query-DSL, de PydanticAI-integratie en de driefasige agentarchitectuur die zoeken in natuurlijke taal productieveilig maakt.
Klein team. Zes maanden. Geleverd in orchestrator-core v5.0 onder Apache 2.0.
De oplossing
Alles draait op PostgreSQL. Geen Elasticsearch-cluster, geen aparte vectordatabase, geen extra infrastructuur om te beheren of te schalen.
De basis is Entity-Attribute-Value-indexering met hiërarchische paden. In plaats van dynamische schema's op vaste kolommen te mappen, krijgt elk attribuut een eigen indexrij: een pad (opgeslagen met PostgreSQL's ltree-extensie), een getypeerde waarde en optioneel een embedding-vector. Een veld als product.interface.speed wordt een doorloopbaar pad. Nieuwe producttypes zijn doorzoekbaar zodra ze gedefinieerd zijn. Geen migraties, geen herindexering.
Drie retrievers draaien parallel bovenop die index:
- pgvector: semantisch zoeken. Vindt resultaten op betekenis, niet alleen op overeenkomende tekst.
- pg_trgm: fuzzy tekstmatching. Vangt typefouten, gedeeltelijke matches en exacte ID-zoekopdrachten op die semantisch zoeken zou missen.
- Gestructureerde filters: getypeerde predicaten op datums, enums, booleans en UUID's.
Reciprocal Rank Fusion voegt alle drie samen tot één ranking. Elke retriever levert zijn eigen ordening; RRF combineert ze zonder scorenormalisatie. Het resultaat: een zoekfunctie die "amsterdam network" en "sub-550e8400" even goed aankan.
Zoekarchitectuur PostgreSQL-native · geen externe services
EAV-index ltree · getypeerde waarden · embeddings
🧠 pgvector semantische gelijkenis
🔍 pg_trgm fuzzy tekst
🏷 filters getypeerde predicaten
RRF Reciprocal Rank Fusion
Gerangschikte resultaten cursor-gepagineerd
Veilig voor AI-agents
Ruwe SQL laten genereren door een LLM is een slecht idee. Eén gehallucineerde DROP TABLE en de dag is verpest. We bouwden een Pydantic-gebaseerde query-DSL die compileert naar gevalideerde SQL. De agent raakt querystrings nooit direct aan.
Dezelfde Pydantic-modellen die de DSL definiëren, dienen als getypeerde toolparameters voor PydanticAI. De agent vult een gestructureerd formulier in; het systeem compileert en valideert het voordat er iets de database bereikt. De agent kan filters, sortering, aggregaties en paginering opbouwen, zonder ook maar één regel SQL te genereren.
De agent-workflow verloopt in drie fasen:
Agent-workflowOntdekken · Bouwen · Uitvoeren
1
AgentOntdekkenBevraagt geldige geïndexeerde paden die aansluiten op de intentie van de gebruiker. Signaleert ontbrekende velden. Lost ambiguïteit op vóórdat de query wordt gebouwd.
2
AgentBouwenStelt een getypeerd query-object samen: filters, sortering, aggregaties. Structureel geldig by construction. Er wordt geen SQL gegenereerd.
3
SysteemUitvoerenCompileert de query naar gevalideerde SQL en voert die uit. Geeft een stabiele cursor terug voor paginering, ook als de data tijdens de sessie verandert.
Dat betekent dat een operator kan vragen "toon alle 10Gbps-interfaces in Amsterdam die vorige maand zijn opgeleverd" en accurate, gepagineerde resultaten terugkrijgt. Zonder dat er een ruwe query aan te pas komt.
Het resultaat
Hybrid search is geleverd in orchestrator-core v5.0, onder Apache 2.0. Elke organisatie die orchestrator-core draait, krijgt het out of the box. Geen configuratie, geen extra infrastructuur. SURF's operators doorzoeken nu in seconden duizenden subscriptions en workflows.
Incrementele indexering gebruikt SHA-256 content-hashing om het opnieuw embedden van ongewijzigde velden over te slaan, zodat de index actueel blijft zonder volledige rebuilds. Keyset-paginering verwerkt een (score, entity_id, query_id)-cursor in de resultaten, zodat resultsets stabiel blijven, zelfs als de onderliggende data tijdens de sessie verandert. De EAV-aanpak schaalt naar miljoenen geïndexeerde attributen over diep geneste schema's.
Voor de volledige technische uitwerking (EAV-implementatie, retriever-routing, keyset-paginering en agentarchitectuur), zie de post van Tim Fröhlich: Building a Schema-Agnostic Hybrid Search System in PostgreSQL ↗
