ChromaDB + bge-m3 — Embeddings That Never Leave Home

Why at home

Memory operations never leave the family's own machines. Embeddings come from bge-m3 (multilingual, 1024 dimensions), served since 2026-06-03 by oMLX, an OpenAI-compatible MLX server on the server Mac, as bge-m3-mlx-fp16. ChromaDB stores the vectors in <app-data>/chroma/. No memory operation goes out to a vendor API.

Until June the same model ran through Ollama. The move was not a preference: an Ollama update broke its embedding path, staying would have cost us the model, and retrieval moved to oMLX to keep it. The code's defaults still name Ollama. The live choice is environment config on office, and the collection names say which is which, since the live pair carries its provider, model, and dimension in the name.

Two collections

• messages — user and assistant messages, embedded as each one is saved. Used for 'where did we talk about X?' search and for RAG.
• vault — a soul's core/, memory/, principles/, index/ and library/ trees plus Pippa.md and instructions.md, re-indexed by a brain-free job every 30 minutes that only touches files whose modification time changed. Since 2026-09-13 the shared vault has its own partition beside each soul's (lesson 8).

One tree stays out on purpose: playbook/ was never in the walk and remains a Read away. library/ has a history of its own. On 2026-07-25 it stopped being embedded, because it then held the imported claude.ai and ChatGPT exports, 96% of all vault chunks, which retrieval had been discarding at the gate since May. Once those imports moved out of the vault, Dad ruled on 2026-10-01 that a soul's library references are memory like any other, so the walk takes each soul's and the shared library/ again, under the same relevance threshold and scoping.

Why bge-m3 specifically

It's multilingual — handles Korean and English in the same vector space. Pippa's vault has both. Most English-only embeddings break down on Korean entries.

An embedding hit is a candidate, not a memory. A close vector distance does not guarantee an answer to the current question, so keep the source path and chunk boundary with every hit and read the original, even after reranking. A retrieval score must never stand in for the truth of a memory.

Keeping embeddings at home is not only about cost. The family's conversations and vault chunks never leave for an outside API to be searched, and if the provider stalls, the memory itself is untouched: the index is a rebuildable mirror, and the Markdown and JSONL are the source.