← All workEntry 4 of 6
  • .NET
  • Query routing
  • Azure AI Document Intelligence

DeltaCore AI Knowledge Hub

Turn a company's documents into a knowledge corpus once, then build modules on top of it. The first module answers questions, and spends only the tokens each question needs.

§1

The problem

The client wanted one knowledge corpus built from their documents, with an AI core that answers questions with sources and performs actions, and room to add more modules on top later. The documents weren't just clean PDFs: many were scanned, rasterized images. And running the heaviest retrieval and reasoning on every question burns tokens, while a simple lookup can't answer a multi-hop or relational question. The system had to read everything, and choose how hard to work.

§2

How it works

  1. Questionfrom a user or agent
  2. Classifywhat does it need?
  3. Strategies
    • Hybrid + rerank
    • Retrieve by ID
    • Graph lookup
    • Decompose ↻
    compose and recurse
  4. AnswerQwen, with citations
Fig. 1  Each question is classified and handed to a strategy. Strategies compose: a multi-hop question is decomposed into sub-queries, each sub-query picks its own strategy (retrieving by ID, for example), and the results feed the next reasoning step.
  1. DocumentsPDFs, scanned images
  2. Doc Intelligencecustom Azure models
  3. Outboxcrash-safe handoff
  4. Indextext, vectors, graph
Fig. 2  Ingestion: custom Azure AI Document Intelligence models turn rasterized images into structured text, and a transactional outbox makes sure each document is indexed once, even through crashes and retries.

The corpus is the foundation: documents are parsed, embedded and linked into a knowledge graph once, and every module reads from it. For question answering, which grew out of my Python RAG experiments, a classifier picks from a set of retrieval strategies: combining and reranking BM25 and vector results, retrieving records by ID, looking up relationships in a knowledge graph, or fetching a larger result set and reasoning over it. Strategies are composable and can call each other recursively, so a multi-hop question becomes a tree of small, cheap queries instead of one huge prompt. Underneath is a containerized .NET application with clean boundaries; text, vectors and the graph live in PostgreSQL with pgvector, and an open-weight Qwen model reframes questions and performs actions through an MCP endpoint.

§3

Results

−60%token costs, by spending tokens only where a question needs them

Question typeHow it's answered
Direct, factualHybrid search (BM25 + vectors), merged and reranked
About relationshipsKnowledge-graph lookup
Multi-hopSplit into sub-queries, each with its own strategy (e.g. retrieve by ID); results feed the reasoning

← a few of the strategies: they compose, and can call each other

§4

What I learned

  • The cheapest correct answer wins: classify first, then spend tokens
  • Recursive, composable strategies beat one giant prompt for multi-hop questions
  • Real documents are messy: scanned images need their own models, not just a PDF parser
  • Build the corpus as a platform, not a feature: modules come and go, the knowledge stays
  • Ideas proven in a small Python experiment carried over cleanly to production .NET