When a private knowledge manager answers questions over PDFs, caching is a retrieval-quality decision before it is a latency trick. A cache hit can return an answer built from a document that was deleted, re-encrypted, or replaced. My default is to cache deterministic retrieval inputs and intermediate results, then re-check document version and access scope before generation. That keeps latency predictable without pretending stale context is harmless.
Short answer: use versioned, scope-aware caches with short-lived result entries; invalidate by document revision, embedding configuration, and permission scope, and measure stale-hit rate alongside latency.
How should a privacy-focused personal knowledge manager cache retrieval results?
Start with the retrieval pipeline as a set of identities. A query is not just text. It includes normalized query text, tenant or user scope, corpus snapshot, embedding model and parameters, ranking settings, and the requested top-k. If any of those inputs changes, the old result is a different computation. A practical key can be a hash of that tuple, with the document revision set represented by a monotonic snapshot identifier.
For a personal system, the scope value is usually a local user identifier, but it still matters. A shared cache keyed only by query text can leak titles or snippets between profiles. Encryption at rest does not fix a bad key; it only protects the wrongly shared value after it has been written.
I keep two caches separate. The first stores embedding vectors for chunks whose content hash is unchanged. The second stores ranked chunk IDs and scores for a particular query snapshot. Generated prose is the least reusable layer because prompt templates, model versions, and citation rules change often. It can be cached, but only with an explicit expiry and a visible snapshot label.
The failure modes that make a fast cache untrustworthy
The common failure is invalidation by timer alone. A ten-minute TTL says nothing about whether a learner removed a PDF ten seconds ago. The opposite failure is invalidating the entire corpus for every edit, which preserves freshness but turns a small note change into a latency spike. Keep it boring.
Here is the trade-off I use when choosing a boundary:
| Cache layer | What it buys | What can go wrong | Suitable invalidation |
|---|---|---|---|
| Chunk embeddings | Avoids repeated vectorization | Old model or chunking scheme remains | Content hash plus embedding-config version |
| Ranked chunk IDs | Fast repeated searches | Deleted or ACL-changed chunks reappear | Corpus snapshot and scope |
| Prompt context | Less assembly work | Context can contain stale citations | Snapshot, prompt version, short TTL |
| Final answer | Lowest perceived latency | Prose outlives its evidence | Snapshot, model version, explicit expiry |
There is a subtle race here. A writer can commit a new PDF revision while a reader is assembling context from the previous snapshot, and the race is easy to miss because each individual operation appears correct in isolation: the index has accepted the new bytes, the retriever has returned valid chunk IDs, and the generator has received text that was once authorized. The reader should finish against one immutable snapshot, then expose that snapshot ID with the answer. Mixing chunks from two snapshots is worse than a slower response because the citations no longer describe one coherent corpus; a user cannot tell which version was searched, and a later audit cannot reliably reconstruct the evidence. I don't treat a cache hit as proof of freshness. It is only proof that a prior computation matched a key.
Treat the cache as a privacy boundary that must survive restarts.
Treat cache contents as sensitive derived data. Store only the minimum needed to recompute an answer: opaque chunk identifiers, scores, and hashes where possible. Keep raw PDF text out of a shared cache unless there is a clear retention policy. A local encrypted store may still need key rotation, secure deletion, and a decision about whether operating-system swap files are in scope.
On restart, do not assume a warm cache is valid. Persist the cache metadata with a schema version and configuration fingerprint. If either changes, discard the affected namespace lazily. Lazy eviction avoids a long startup pause, but it requires every read path to enforce the fingerprint check; a forgotten path quietly serves old vectors.
I also record a privacy-safe cache event: hit or miss, namespace, snapshot ID, and latency bucket. I do not log the query or PDF title by default. This gives enough signal to tune TTLs without turning observability into a second copy of the knowledge base.
A small, testable implementation
The following Python sketch keeps the cache contract explicit. The backing store can be an in-process map for tests and an encrypted local database in production.
from dataclasses import dataclass
from hashlib import sha256
import json
import time
@dataclass(frozen=True)
class RetrievalKey:
scope: str
query: str
snapshot: str
embedding_config: str
rank_config: str
top_k: int
def digest(self) -> str:
payload = json.dumps(self.__dict__, sort_keys=True)
return sha256(payload.encode("utf-8")).hexdigest()
def get_cached(store, key: RetrievalKey, ttl_seconds: int):
item = store.get(key.digest())
if item is None or time.time() - item["written_at"] > ttl_seconds:
return None
return item["chunk_ids"], item["snapshot"]
def put_cached(store, key: RetrievalKey, chunk_ids: list[str]) -> None:
store[key.digest()] = {
"chunk_ids": chunk_ids,
"snapshot": key.snapshot,
"written_at": time.time(),
}
The important behavior is not the dictionary. Tests should prove that changing scope, snapshot, embedding configuration, or ranking configuration produces a miss. Add a deletion test: after a document revision, an old key must not return its chunk ID. Then add a property test for restart metadata, because serialization bugs tend to hide until a real upgrade.
Rollout rules and the limits of caching
Ship this in stages. First measure uncached retrieval latency and stale-result rate with a shadow cache that never changes responses. Next enable embedding-cache reads, then ranked-result reads behind a feature flag. Keep a kill switch that bypasses every layer, and alert on stale-hit rate, cache eviction churn, and the percentage of answers whose snapshot is older than the current corpus.
The catch is that caching is not suitable when every query must reflect external, rapidly changing data or when users cannot tolerate any retained derived content. In those cases, use a shorter-lived cache or skip final-answer caching entirely. Stick with a simple uncached path when the corpus is small enough that measured retrieval latency is already inside the product budget; operational complexity has a cost too.
Your mileage may vary. I am not sure a single TTL can be defended across all document types, because a syllabus, a private journal, and a legal consent form have different freshness expectations. Make that uncertainty a policy input, not a hidden constant.
