Skip to main content

Abby 2.0 Phase 1: Building the Memory Foundation — ChromaDB Migration and Research Profile Context

· 5 min read
Dr. S.M. Udoshi
Creator, Parthenon
Claude (AI Pair Programmer)
AI Development Assistant

Today marked a significant architectural milestone for Abby, Parthenon's AI research assistant: the completion of Phase 1 of the Abby 2.0 memory overhaul. Eighty-six commits landed today, all focused on one goal — giving Abby a durable, queryable memory backed by PostgreSQL rather than ChromaDB, and surfacing user research context directly in the chat interface.

Why This Matters: The Case for Moving Off ChromaDB​

Abby has always had access to conversation history, but the vector storage layer has been a pain point. ChromaDB worked well as a prototype store for conversation embeddings, but running a separate vector database process alongside PostgreSQL introduced operational overhead, a second backup surface, and an inconsistent data locality story. Since PostgreSQL 16 with pgvector gives us first-class vector similarity search within the same database Parthenon already owns, the decision to migrate was straightforward.

Phase 1 is the migration scaffolding and bridge layer. Phase 2 will be the full cutover.

ChromaDB → PostgreSQL Migration Infrastructure​

The centerpiece of today's work is the migration script (849f6b792) that moves existing conversation embeddings from ChromaDB collections into the abby_messages table in PostgreSQL. The script is designed to be idempotent — safe to run multiple times — and handles the translation of ChromaDB's document/metadata structure into the normalized embedding fields we added directly to the AbbyMessage model (ed9bd240a).

Alongside the migration script, a dual-read bridge (3a00c949f) was implemented. During the transition window, Abby's retrieval pipeline reads from both ChromaDB and PostgreSQL, merges results by relevance score, and deduplicates. This means zero downtime during the migration: existing deployments keep working while the background migration job populates the new store. Once the migration completes and is verified, the ChromaDB read path can be disabled with a single feature flag.

Integration tests (ebe6683c5) cover the full pipeline — embedding insertion, similarity search via pgvector, the dual-read merge logic, and migration script idempotency — so we have a solid safety net before the Phase 2 cutover.

Research Profile Context in the Chat Interface​

The second major theme today was wiring up user research profile context so that Abby can give more relevant, personalized responses based on who is asking.

This touched every layer of the stack:

  • TypeScript types (959bf1165): New interfaces for ResearchProfile and memory-related payloads, living in the Abby feature types directory. Having these defined upfront makes the frontend/backend contract explicit.
  • Frontend hook and service (7f48882fe): A useAbbyProfile React hook and accompanying service functions that fetch the user's research profile from the Laravel API. The hook handles loading/error states and caches the profile for the session.
  • My Research Profile panel (9372a9fed): A collapsible side panel in the Abby chat interface showing the user's current profile attributes — therapeutic areas, cohort preferences, preferred OHDSI tools. This gives users transparency into what context Abby is working with, and will eventually be editable in place.
  • Laravel passthrough (aabda7551): The Laravel backend now reads the authenticated user's profile data and forwards it on every request to the Python AI service. The profile controller received an api_group attribute fix (ed9bd240a) to correctly scope profile data to the user's tenant.
  • Extended ChatRequest (653600113): The Python AI service's ChatRequest schema now accepts ResearchProfile and conversation_id as first-class fields. Abby's prompt assembly pipeline uses the profile to prime the system context before any user message is processed.

The practical result: when a cardiovascular outcomes researcher opens Abby, she's no longer starting from a blank context. Abby knows her domain, her typical cohort constructs, and can bias vocabulary suggestions and analysis recommendations accordingly.

Documentation​

A Phase 1 devlog blog post was committed alongside the code (4b365ae9d), capturing the architectural rationale for the ChromaDB-to-PostgreSQL move, the dual-read bridge design, and the embedding schema decisions. This joins the growing phases/ devlog archive and will serve as the primary reference when Phase 2 cutover work begins.

What's Next​

With Phase 1 infrastructure in place, the near-term priorities are:

  1. Phase 2 cutover: Once the background migration has been validated against a production-scale dataset, disable the ChromaDB read path and remove the dependency entirely. Target: end of sprint.
  2. Profile editing in-panel: The "My Research Profile" panel is currently read-only. Making it editable — with changes persisting to the user profile API — is the next frontend milestone.
  3. Embedding-aware retrieval tuning: Now that embeddings live in PostgreSQL, we can experiment with hybrid search (vector + keyword BM25) using pg_search alongside pgvector. Early benchmarks look promising for improving Abby's long-context recall.
  4. Conversation threading: The conversation_id field is now flowing through the full stack. The next step is exposing conversation history management in the UI — listing past threads and resuming them.

Today was a strong foundation day. The plumbing isn't glamorous, but getting memory architecture right is what makes the difference between an AI assistant that feels stateless and one that actually knows your work.