Skip to content

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