Queried the Local Embeddings Store for the First Time

Context: Building the vector store in the last entry was only half the job — the actual point of embeddings is being able to ask a question and get back the right stored document, not just any document. Chroma does this by comparing distances: turn the question into a vector the same way you turned each document into one, then measure how numerically close the question's vector is to each stored vector. Lower distance means more similar in meaning. The real test isn't whether it returns something — it always will — it's whether the distance numbers actually mean anything, i.e. whether relevant matches consistently score lower than irrelevant ones.

Ran: Reconnected to the collection built in Entry 05 (collection.count() confirmed all 3 entries were still there), then ran two queries through the same embed-then-search pattern:

>>> q = ollama.embeddings(model="nomic-embed-text", prompt="how do I check pod status with oc")
>>> results = collection.query(query_embeddings=[q["embedding"]], n_results=2)
>>> results["ids"]
[['02-oc-cli-mentor-system-prompt.md', 'posts_03-1b-vs-3b-memory-comparison']]
>>> results["distances"]
[[437.72, 499.63]]

>>> bad_q = ollama.embeddings(model="nomic-embed-text", prompt="what's the best pizza topping")
>>> bad_results = collection.query(query_embeddings=[bad_q["embedding"]], n_results=2)
>>> bad_results["distances"]
[[542.33, 585.48]]

Result:

Two things worth calling out. First, the on-topic question correctly surfaced the oc-mentor file as the closest match — the system found the right document, not just a document. Second, and more convincing: every distance for the real question was lower than every distance for the pizza question — even the worst on-topic match (499.63) beat the best off-topic match (542.33). That's a real, if small, sample showing the distance metric isn't just noise; it's actually tracking relevance.

One loose thread: the third stored document — the long draft article that got truncated by 57% in Entry 05 — never showed up in either top-2 result, including for queries that might plausibly relate to it. Can't tell yet whether that's because it's genuinely less relevant to these two test questions, or because truncating away more than half its content damaged what got embedded. Worth testing directly once chunking replaces truncation.

Takeaway: The retrieval loop works — real semantic discrimination, not just returning whatever's closest by default. But this was a 3-document store and 2 test questions; that's a proof of concept, not a rigorous eval. The next real fix is still the chunking work flagged in Entry 05 — and specifically checking whether it changes how the long truncated document performs in queries like this one.