How this assistant works
The assistant on this site is a perfect example of RAG (retrieval-augmented generation): an AI that looks things up first, then writes. It runs on my own local server, not in a cloud AI service, and answers only from facts I wrote myself. Here's how that works, and why opening a local server to the internet is safe in this case.
The short version
- It runs on a local server, not in the cloud. An open-weight AI model (one whose files anyone can download and run) does the writing, right on that machine.
- It looks things up before it answers. Every answer is built from notes about me that I wrote and checked, not from the model's memory.
- The server is never directly reachable from the internet. Your question arrives through a one-way, encrypted tunnel to exactly one small program.
What happens when you ask a question
- You ask. Your question leaves this page.
- The traffic gets checked. A security network sits in front of this site. It filters out bots and attacks, and a quick, usually invisible check confirms you're human.
- It travels through a tunnel. The server opened an encrypted connection out to that network, so your question can come back in through it. Nothing can knock on the server's door directly.
- It waits its turn. The server answers one question at a time, first come, first served. If others are asking, you'll see your place in line.
- The system looks up facts about me. It searches a database of my notes for the passages most relevant to your question.
- A local AI model writes the answer using only those passages, with strict instructions to say "I don't know" rather than guess.
- The answer streams back to you word by word, as it's written.
RAG in plain words: an open-book exam
AI models are good at writing, but they know nothing about me. When a model doesn't know something, it tends to make it up. So this assistant doesn't rely on memory. Every answer is an open-book exam: first find the right pages, then write the answer from them.
Step 1 — Indexing (when I update my notes). I write short, factual notes: roles, projects, skills, availability. The system cuts them into small passages and turns each passage into an embedding: a list of numbers that captures what the passage means, so passages about similar things get similar numbers. They're stored in PostgreSQL, a popular open-source database, using an add-on called pgvector that lets it search by meaning instead of exact words.
Step 2 — Retrieval (every time you ask). Your question is turned into numbers the same way. The database finds the passages whose meaning is closest, and also runs a classic keyword search so exact names like a company or a technology aren't missed. The best handful go to the AI model along with your question.
Why this matters:
- Answers stay grounded in what I actually wrote.
- If an answer is wrong, I fix the note, and the next answer is right. No retraining.
- The model never has to "know" me; it only has to read.
Why not just give the AI everything?
The simpler idea would be to paste all my notes into every question and let the model sort it out. On a big cloud AI that sometimes works. On a small model running on a local machine, it falls apart. Before writing a single word, the model has to read everything it's given, every single time.
| Paste in all my notes | Look things up first (this site) | |
|---|---|---|
| What the model reads per question | Everything I've ever written about my work | A handful of short, relevant passages, well under a thousand words |
| Wait before the answer starts | Grows with every note I add, to many seconds | Under a second, however many notes I have |
| Accuracy | Small models lose track in long text and mix up similar roles or dates | The model only sees what matters for your question |
| Room to grow | Stops working once the notes no longer fit the model's memory | A thousand notes cost the same per question as ten |
| Shows where an answer came from | No | Yes: every answer lists the notes it was based on |
| Knows when it doesn't know | Has to guess from a wall of text | If the search finds nothing relevant, it says so |
There's one more reason that matters here: the server answers one question at a time. Every second saved on one answer is a second less for the next person in line.
The trade-off: if the search misses the right passage, the model never sees it. That's why the search combines meaning and exact keywords, and why I test it with a set of real questions whenever I change my notes.
The servers: everything in sealed boxes
The server behind this site is a set of programs on a local machine, each running in its own Docker container: a sealed box that contains one program and only what it needs.
| Box | Job |
|---|---|
| Front desk (API: the program that answers web requests) | The only box that talks to the outside world. Checks every request and hands questions to the queue |
| Queue | Keeps questions in line, first come, first served |
| Worker | Takes the next question, looks up the facts, asks the AI model, streams the answer back |
| Library (PostgreSQL + pgvector) | Stores my notes and their embeddings |
| Tunnel connector | Keeps the encrypted tunnel open |
The AI model itself runs in a separate app on the same machine, outside the boxes. Only the worker is allowed to talk to it.
How the server stays safe
Opening a local server to the internet is usually a risky idea. Here's what makes this setup different:
- No open doors. The server reaches out through an encrypted tunnel. Its network has no open ports (the numbered "doors" a machine can accept connections on), and nothing on the internet can connect to it directly.
- One door, one room. The tunnel leads to exactly one program, the front desk, and nothing else on that machine or its network.
- Sealed boxes. Each program runs locked down: no access to anything else on the machine, no administrator rights, and no ability to change itself. The database box can't even reach the internet.
- An AI with no hands. The model can only produce text. It has no tools: it can't run code, browse the web or touch files. Even if someone tricks it, there's nothing for it to do.
- Bouncers at the door. A security network in front of this site filters bots and attacks before they reach me. A human check comes before chatting, and limits keep any one visitor from hogging the machine.
- Nothing secret inside. The assistant only knows what I chose to publish, so there's nothing private to leak.
Honest trade-offs
- It's only online when the local server is on. If it's off, this page still works; the chat just says it's offline.
- It's a smaller model than the big cloud ones, so it can be wrong. Please confirm anything important with me directly.
- One question at a time, so you may occasionally wait in line.
- Questions are logged for a limited number of days so I can see what people ask and improve my notes. Please don't share sensitive information.
Built with
Open-source software throughout: a small web page, a server and a queue in sealed containers, a database that searches by meaning, and an open-weight AI model. All of it runs on a local server, apart from the page itself and the security network in front of it.