Phase 2 — Retrieval quality and production-ready server
Status: Planned
Phase 2 focuses on two things: making the retrieved context richer and more accurate, and making the server fit for real users (auth, frontend, streaming, production security).
Retrieval improvements
Neighbor expansion
The Phase 1 index only covers nodes that have a text property. Most nodes in Reactome carry descriptive text, but the context available to the LLM is limited to the text of the directly retrieved nodes.
Phase 2 will add neighbor expansion: after the initial vector search returns top-k nodes, the agent will follow edges to adjacent nodes and include their labels, properties, and text in the retrieved context. This gives the LLM a richer picture of the local graph structure without requiring extra tool calls.
node2vec enrichment
Phase 2 will optionally pre-compute node2vec embeddings to capture structural similarity (nodes connected similarly in the graph) alongside semantic similarity (nodes with similar text). This allows retrieval that reflects both textual and topological relevance.
Publication enrichment
Reactome nodes are linked to PubMed publications. Phase 2 will enrich retrieved nodes with their associated publication abstracts, giving the LLM access to primary literature context when answering biological questions.
Frontend replacement
The Streamlit UI used in Phase 1 has fundamental limitations:
- No native cookie support (requires manual header parsing)
- No authentication
- Not suited for external users or multi-tenant deployment
Phase 2 will replace Streamlit with a React / Next.js frontend. The FastAPI server is already frontend-agnostic — the same endpoints serve any client without changes.
Per-request LLM overrides
Phase 1 requires a server restart to switch LLM providers. Phase 2 will support per-request overrides via an X-LLM-Provider header, allowing the frontend to select the provider for each request without restarting the server.
SSE streaming
Phase 2 will add Server-Sent Events (SSE) streaming so the client can display:
- Intent router reasoning (which route was chosen and why)
- Per-step latencies for each tool call in the agent loop
- Incremental LLM output as it is generated
The /build/stream endpoint already streams build progress via SSE; the same pattern will be extended to chat.
User accounts and persistent history (PostgreSQL)
Phase 1 stores sessions in Valkey with a 7-day TTL. Long-term conversation history and user accounts require a persistent store.
Phase 2 will add PostgreSQL for:
| Table | Purpose |
|---|---|
users | User accounts linked to anon_id cookies |
anon_ids | Mapping of anonymous IDs to user IDs |
chat_sessions | Persistent session metadata (title, created_at, user_id) |
chat_summaries | Summarised history for long sessions (context compression) |
Valkey continues to serve as the session cache; PostgreSQL is the durable store.
Production security hardening
| Item | Change |
|---|---|
| CORS | Restrict cors_origins from ["*"] to known frontend origins |
Cookie secure flag | Set secure=True on the anon_id cookie (requires HTTPS) |
| Nginx / Caddy reverse proxy | Add TLS termination and request routing in front of FastAPI |
| Valkey persistence | Document and enforce appendonly / save settings so sessions survive restarts |
| Session list cap | LTRIM user:{user_id}:sessions after each LPUSH to prevent unbounded growth |
| User key TTL | Add expiry or archival policy for permanent user:{user_id} keys |