v0.3.2 — Qdrant & Retrieval Observability

v0.3.2 — Qdrant & Retrieval Observability

v0.3.2 adds an optional production-oriented Qdrant vector backend and a
retrieval operations loop without changing the fresh-clone default. SQLite
remains the knowledge system of record, the in-memory index remains the
zero-infrastructure default, and the existing chat SSE contract is unchanged.

Product outcome

Administrators now have a bilingual Retrieval Operations workspace where
they can:

• inspect the configured backend, Qdrant health, active alias/collection,
  vector count, dimension, and synchronization state;
• build a versioned Qdrant collection from current SQLite knowledge and resume
  an interrupted job when its knowledge fingerprint is unchanged;
• compare memory and a ready Qdrant index in Quality Lab with the same dataset,
  policy, and query embeddings;
• activate an eligible collection through an atomic alias switch, explicitly
  acknowledge a P95 latency warning above 25%, and roll the alias back to the
  previous verified collection;
• filter retrieval traces and inspect the fixed eight-stage timeline without
  storing duplicate customer questions or knowledge content.

Engineering boundary

• VectorStore is asynchronous. InMemoryVectorStore preserves the local
  path; QdrantVectorStore uses @qdrant/js-client-rest 1.18.0.
• Qdrant point IDs are stable UUIDv5 values. Payloads contain only knowledge
  ID, knowledge type, version, and embedding profile.
• Qdrant candidates are batch-hydrated from SQLite and rejected when the
  knowledge is missing, disabled, stale, or attached to an inactive source.
• Qdrant timeout or unavailability produces a degraded trace and keeps
  keyword/structured recall available. It never silently rebuilds an
  in-memory vector index.
• Index jobs use fixed states and checkpoints. Readiness verifies profile,
  dimension, point count, and the current knowledge fingerprint.
• Activation and rollback require idempotency keys and expected-current
  collection values. Old collections are not automatically deleted.
• Retrieval traces retain safe stage metadata for 30 days by default, cascade
  with deleted sessions, and are cleaned at startup and daily.

Running Qdrant

The default command still starts the memory-backed application:

docker compose up --build

Start the pinned Qdrant 1.18.2 Compose profile and select it at deployment
time:

VECTOR_STORE_PROVIDER=qdrant \
QDRANT_URL=http://qdrant:6333 \
docker compose --profile qdrant up --build

Changing VECTOR_STORE_PROVIDER requires an application restart. The admin
workspace can switch the configured collection alias, but it cannot change
infrastructure credentials or the primary backend.

Non-goals and limits

This release does not add runtime memory/Qdrant switching, automatic backend
failover, production-traffic shadow queries, Qdrant sparse/hybrid retrieval,
snapshots, clustering, automatic old-collection deletion, OpenTelemetry, or
Agentic Retrieval.

See v0.3.2 implementation evidence for the verification
matrix, screenshots, benchmark results, and local environment limitation.

---

中文说明

v0.3.2 在不改变 fresh-clone 默认行为、SQLite 权威数据源和聊天 SSE 契约的
前提下，增加可选生产向 Qdrant 向量后端与完整检索运维闭环。

管理员可以在独立的双语“检索运维”页面查看后端健康、alias/collection、
点数、维度和同步状态；从 SQLite 构建可恢复的版本化索引；在 Quality Lab
中用同一数据集、策略和查询 embedding 对比 memory/Qdrant；通过质量门禁后
原子激活 alias，并在需要时回滚到上一已验证 collection；还可以按状态、后端、
会话和时间筛选检索 Trace，查看固定八阶段时间线。

Qdrant 命中必须回查 SQLite，孤儿、旧版本、停用知识或失效来源不会成为证据。
Qdrant 超时或不可用时会记录 degraded Trace，并继续关键词/结构化检索，
不会静默重建内存向量。部署配置决定主后端并在重启后生效；后台只能切换
collection alias，不能修改凭据或运行时切换后端。

本版本不包含自动 failover、真实客服流量影子查询、Qdrant sparse/hybrid、
快照/集群、旧 collection 自动清理、OpenTelemetry 或 Agentic Retrieval。