How RAG Proxy Works

The setup: proxy in the middle, search, pins, harness, brain UI, Faculty hardware. Same idea as the talks, written out.

Two layers. The Perl files on the code page are the May 2026 snapshot: proxy, brain, ingest. Production on Faculty hardware also has pins, the harness, a brain web UI, and two NVIDIA DGX Sparks. Those are not in the download.

Request flow (production)

User  →  chat client  →  RAG Proxy  →  local model on Faculty Sparks
                              |
                   1. Search the dental brain
                   2. Pin a cheat sheet if the topic matches
                   3. Inject the retrieved policy chunks
                   4. Model writes an answer
                   5. Harness checks policy numbers
                   6. Invented number? retry. Real list? pass

The stack

💻
The proxy
Sits in the middle
🧠
Brain.pm
Vector search library
📊
SQLite + PDL
Chunks and cosine math
🎯
BGE-M3
Embeddings, 1,024 dimensions
💬
Chat client
Open WebUI, or any OpenAI-compatible app
Two DGX Sparks
Faculty generation, on premises
📌
Pins
Cheat sheets the proxy injects
🛡️
Harness
Policy-number check after the answer
📥
Brain web UI
Drag-and-drop. Indexes immediately

Key pieces

🔌
The proxy

RAG Proxy

A server that sits between the chat interface and the language model. It speaks the usual chat APIs, so you change the URL, not the app.

Every question is searched, optionally pinned, then forwarded. Streaming and non-streaming both work.

Model-name routing picks the brain: dental/… means search the dental library, then generate with the named model. Several knowledge domains can share one proxy.

🧠
The brain

Brain.pm

Ingest, chunk, embed, search. Each brain is one knowledge domain: SQLite for text, a PDL matrix for vectors, plus a system prompt.

Chunks are about two paragraphs. Each becomes a 1,024-number fingerprint via BGE-M3. A question gets the same treatment. Cosine similarity ranks the library. Top chunks come back in milliseconds.

The dental brain holds the Faculty clinic policies (94 documents in the May snapshot). Knowledge stays in that folder, so dental never answers HR.

🔍
The search

Semantic search, not keywords

Ask “I pricked my finger on a needle.” Keyword search misses Policy H.03 because the word percutaneous is not in the question. Vector search finds it. Same meaning, different words.

That is still an educated guess. Search can grab the wrong file. That is why pins exist.

📌
Pins

Cheat sheets the proxy injects

A pin is not a search ranking score. When a question matches a topic, the proxy pastes a short, known-good file into the prompt. Search still runs on the rest of the library.

If search missed, the model still sees the right sheet. Reranking cannot invent a document that was never retrieved. The pin is there every time.

Came after the first public code snapshot. More on pins.

🛡️
Harness

Software after the model talks

The model cannot sweet-talk it. For clinic policies we keep the real list of policy numbers. If the answer cites a number that is not on that list, the check fails. The model gets a short reason and has to try again.

Same idea as perl -c: you do not trust the author because they sound sure. You run the checker.

Also: if the question names a policy id the brain does not have, the proxy tells the model not to invent one. Came after the first public code snapshot. More on the harness.

📥
Brain UI

Drag-and-drop, not a rebuild

Our own web UI for the brains. Drop a markdown file, it indexes immediately. You are not rebuilding a chat app to update a policy. You can stand up another brain (clinic, IT help desk, whatever) in the same proxy.

This is in production on Faculty hardware. It is not in the three Perl files on the code page.

🔗
The interception

Transparent proxy

The chat client thinks it is talking to a normal model server. The model thinks it received a normal prompt. RAG, pins, and the harness sit in the middle.

Swap the chat app, the model, or the proxy without rewriting the others. No vendor plugin. No cloud API for clinic content.

Hardware

Faculty Sparks, not a laptop demo

The May snapshot ran generation through Ollama on a Mac Studio. Production is two NVIDIA DGX Sparks in the building: proxy and embeddings on the front box, generation on the other, private interconnect.

PHIPA / FIPPA is why it stays on premises. See the changelog for the dates.

Brain folder

Each brain is a small folder. The May dental library (94 policy documents) fits in under 1 MB.

# Each brain folder: data/dental-brain/ brain.db # SQLite: chunks, metadata, sources brain_vectors.pdl # PDL matrix: 1024-dim vectors system-prompt.txt # Instructions when answering config.json # Chunk size and related settings sources/ # Original markdown

How indexing works

# Command line (May snapshot, still on the code page): ragproxy-ingest --brain dental --source corpus/dental/ # Production also: drop a .md file on the brain web UI. Indexed immediately. # Under the hood: # 1. Split each document into ~500-token chunks # 2. Embed each chunk with BGE-M3 # 3. Store the 1024-number vector in the PDL matrix # 4. Store chunk text + metadata in SQLite

Sample query

# 1. User asks: "What do I do after a needlestick injury?" # 2. Proxy reads the model name, e.g. dental/… # brain = dental # 3. Pin: if this matches a pinned topic, inject that cheat sheet # 4. Brain.pm embeds the question, cosine against the library # 5. Top chunks (usually Policy H.03) go into the prompt # 6. Local model on Faculty Sparks writes an answer # 7. Harness: every cited policy number vs the real list # Invented id -> fail, retry with the reason # Real id -> pass # 8. Answer goes back to the chat client

View the code

First public snapshot. Pins, harness, and the brain UI are not in these files.

ragproxy.pl Brain.pm ragproxy-ingest.pl Code note
See the talks →