Personal project · 2026 – present
Personal AI Platform
En pipeline, der siger fra
- Problemet
- En datapipeline, der udfylder huller med nærliggende værdier, giver et resultat, der ser komplet ud, og bagefter kan ingen skelne målte data fra gæt.
- Hvornår det er relevant
- Når fotometadata skal blive til steder på et kort, eller i enhver pipeline, hvor manglende input skal rapporteres i stedet for at blive opfundet.
- Det viser demoen
- I geocode.py returnerer locate() to lister: placerede fotos og sprungne fotos, hver med en begrundelse (ingen GPS, en koordinat uden for gyldigt område, intet svar fra geokoderen). summarise() tager antallet af sprungne fotos med i sin ene linje output, og opslag caches på koordinater afrundet til cirka 100 meter.
Ukendt er også en værdi
- Problemet
- Når et tal ikke kan udledes af kilderne, returnerer koden ofte et plausibelt tal alligevel. Det havner så i grafer og rapporter, uden at nogen kan se, at det var et gæt.
- Hvornår det er relevant
- Når man bygger rapporter eller dashboards på ufuldstændige data, fx en lønsammenligning, hvor én kilde inkluderer pension, mens en anden ikke siger noget om det.
- Det viser demoen
- Åbn maybe.ts og salary.ts. En beregning returnerer enten en kendt værdi eller unknown med en obligatorisk begrundelse, og TypeScript lader ikke kalderen bruge tallet, før det ukendte tilfælde er håndteret. Se på change(): den afviser af to forskellige grunde, manglende oplysning om pension og forskelligt ugentligt timetal.
En ratchet-gate
- Problemet
- Slår man en lint-regel til i en kodebase, der allerede bryder den tusindvis af gange, står valget mellem at blokere alle builds eller nøjes med advarsler, som ingen reagerer på.
- Hvornår det er relevant
- Et team, der indfører en ny regel i en eksisterende kodebase og vil have, at ny kode følger den fra første dag, mens den gamle kode bliver bedre over tid.
- Det viser demoen
- Invoke-RatchetGate.ps1 læser en ESLint-rapport i JSON, tæller overtrædelser pr. regel mod en baseline i repositoriet og fejler kun, når et tal stiger. Baselinen sænkes kun automatisk; at hæve den kræver et commit, som en reviewer kan se.
A production-grade AI lab run at home: local LLMs behind an API gateway, retrieval-augmented generation over a PostgreSQL + pgvector knowledge vault, agent pipelines through custom MCP servers, and measurement around all of it.
Most personal AI projects are demos. This one is infrastructure: a platform I use every day, operated with the same discipline I bring to client systems, because a tool I cannot trust is a tool I will not use. Everything below runs locally, on hardware I own, and nothing in it earns a place until it has been measured.
The knowledge vault
The core is a personal knowledge base with a deliberate architecture: Git as the source of truth, PostgreSQL 16 with pgvector for semantic retrieval and Apache AGE for graph queries, and a FastAPI write-through service in front so nothing writes to the database behind the version history's back. AI agents reach it through an MCP server I wrote, which is loaded into every working session. Writes follow a propose-and-confirm protocol and are verified by re-query, because an unverified write is how a knowledge base quietly rots. Retrieval quality is benchmarked, not assumed: the current retrieval configuration won its place in a measured comparison, and it gets re-challenged when the setup changes.
The model fleet
Inference runs on a local Ollama fleet, 30B-class open models on a single RTX 5090, with cloud lanes (DeepSeek, Claude) for work that outgrows local context. Which model gets which task is not a matter of taste: dispatch follows execution-graded rules derived from my own benchmark corpus, currently 34 recorded batches of model R&D. Some findings that shaped the platform: reordering a mixed batch by model is a 71.5% throughput gain that costs nothing; running two different models concurrently on one GPU is a net loss (0.87x); and a vision model's text benchmark rank says nothing about whether it can actually see, which you only learn by testing images yourself.
Agents and automation
Agent pipelines connect the models to real systems: research and harvesting flows, browser automation for work that public APIs cannot do, and batch dispatch for mechanical transforms where the output is verifiable. The standing rule is a verifiability test: local models get work whose results can be checked without re-reading the source, and judgment-heavy work stays with stronger models or with me. Delegation that destroys the evidence needed to review it is not delegation, it is risk.
Observability and operations
The stack is boring on purpose: Docker Compose services with health probes, tiered autostart, Prometheus and Grafana for metrics, OpenTelemetry and Tempo for traces, and token-and-cost telemetry so AI usage is a graph, not a feeling. A wiring gate checks that every kept service is up on the right bind and every decommissioned one is actually gone. The failure modes I have hit and documented, from silent GPU memory hoarding to benchmarks that misread truncation as failure, are recorded as operating knowledge; the platform's most valuable artifact is the written record of what went wrong and why.
By the numbers
- 34 batches of recorded, repeatable model benchmarking behind the dispatch rules.
- 17 local models evaluated head-to-head on real task shapes, not leaderboard proxies.
- 37 candidate tools audited in Docker sandboxes before adoption; 7 written decision records for the ones that did not make it.
- 16 health probes across the service estate, gating a tiered autostart.
- One consolidation: the estate was deliberately reduced to two repositories, one PostgreSQL instance, and two MCP servers, because sprawl is the default failure state of home labs.
What it transfers
The lab is where I learn what production AI actually costs: what retrieval quality means when you query your own knowledge daily, what model routing means when the GPU budget is real, and what governance means when an agent can write to systems you care about. That experience maps directly onto professional AI-engineering work: LLM integration, RAG, agent design, evaluation, and the discipline of measuring before trusting.