All committers have signed the CLA.

Failed to generate code suggestions for PR

Thanks for this PR! The fix itself looks reasonable, but we would like to dig deeper into the root cause to determine whether additional safeguards are needed at the embedding pipeline level. A few questions:

1. Discovery: How did you encounter this issue? Was it sporadic during normal usage, or consistently reproducible with specific operations?
2. Embedding model: You mentioned using Ollama qwen3-embedding:0.6b (1024d). Have you always used this model, or did you switch from a different embedding model/provider at some point? If you switched, did you rebuild the vector index afterward?
3. Source of inf: Were you able to identify which specific resources/memories produced inf scores? For example, do any of them have all-zero embedding vectors, or could there be a dimension mismatch between the embeddings and the index?
4. Reproduction scope: Does every query trigger this, or only specific ones? Can you reproduce it with a fresh database and newly ingested content?

This context will help us understand whether the inf originates from the embedding model itself, a dimension mismatch after switching models, or a bug in the vector ingestion pipeline.

Thanks for the review! Here are answers to your questions:

1. Discovery:
It was sporadic during normal usage — not every query triggered it. I first noticed it when doing memory search operations on committed session memories. It seemed to happen intermittently rather than consistently.

2. Embedding model:
I have been using qwen3-embedding:0.6b consistently since setting up OpenViking. The vector index was built from scratch with this model. No switching occurred.

3. Source of inf:
I was not able to pinpoint the exact resources producing inf scores. My suspicion is that very short text content (like single-word memories or extremely short session summaries) might produce embeddings that are close to zero, leading to anomalous similarity scores during vector search. I did not check the raw embedding vectors in sqlite-vec to confirm this.

4. Reproduction scope:
Not every query triggers this. I would estimate it happens in roughly 1 in 20-30 search queries. It does not seem related to a fresh vs. existing database — both seem susceptible if the query matches certain content patterns.

Additional context:
My setup uses Ollama with qwen3-embedding:0.6b for embedding and qwen2.5:7b for summarization, all running locally on a RTX 4060. The inf scores appear to originate in the blend scoring step in hierarchical_retriever.py rather than at the raw vector retrieval level.

Would it help if I tried to capture a specific inf-producing query and its associated vector data from sqlite-vec?

Thanks for the detailed answers! This is very helpful.

Since the model was never switched and the issue is sporadic with short text content, the most likely root cause is near-zero embedding vectors leading to inf during cosine similarity computation. Your two-layer defense approach (clamping at retriever + sanitizing at API) is a solid fix for the immediate problem.

Let's go ahead and merge this. If you're able to reproduce the issue and capture the specific query along with its associated vector data from sqlite-vec, that would be great for a follow-up investigation into the embedding pipeline — but it's not a blocker for this PR.

Thanks for the contribution!