Private LLM / RAG

Jazmine — Private Enterprise RAG Assistant

A sanitized case study of a private enterprise knowledge assistant built around local LLMs, RAG, department-aware retrieval, and source-grounded answers.

Production-inspired / sanitizedMay 30, 2026

Jazmine is a private enterprise knowledge assistant designed for secure internal document search, grounded answers, and department-aware retrieval under on-prem deployment constraints.

FastAPIReactPostgresDockerLocal LLMVector SearchEmbeddings

Problem

Internal knowledge was spread across documents, folders, teams, and repeated handoffs. Users knew the answer probably existed somewhere, but finding the right source and confirming whether it still applied took too long.

The AI problem was not simply "chat with documents." The real problem was secure knowledge access: finding relevant source material, answering with citations, and respecting department boundaries.

Users

The primary users were internal business and technical teams who needed faster access to operational policies, internal documentation, process notes, and reference material.

They did not need a general-purpose chatbot. They needed a constrained assistant that could help them locate, summarize, and verify internal knowledge without leaking data across teams.

My role

Constraints

  • Sensitive internal documents could not be sent to an uncontrolled external service.
  • Access needed to respect department-level boundaries.
  • Local model quality, latency, and hardware limits shaped the UX.
  • Documents had inconsistent structure, naming, dates, and metadata.
  • Users needed source citations before they would trust answers.
  • The system had to be deployable in an enterprise environment, not only in a notebook.

System built

The system used a RAG workflow: document ingestion, parsing, chunking, embeddings, vector search, metadata filters, context assembly, local LLM answer generation, and source-grounded response display.

Jazmine RAG architecture
  1. 01Document intake
  2. 02Parsing and cleanup
  3. 03Chunking with metadata
  4. 04Embedding generation
  5. 05Vector retrieval
  6. 06Department-aware filtering
  7. 07Context assembly
  8. 08Local LLM answer
  9. 09Source citations
  10. 010User feedback

Architecture snapshot

The core architecture separated ingestion from answer generation. Ingestion prepared documents into searchable chunks. Query-time retrieval selected candidate chunks, applied access filters, and assembled a context package for the model.

The interface made source visibility a first-class product behavior. Answers were expected to show where they came from, not just sound confident.

AI/ML approach

The AI workflow used embeddings for semantic retrieval and a local LLM for grounded answer generation. Prompt structure emphasized source use, uncertainty, and refusal when the retrieved context did not support an answer.

The key design choice was to treat the LLM as one part of a governed system. Retrieval quality, metadata, access filtering, citations, and feedback mattered as much as the model.

Product decisions

  • Require citations for answers that reference internal documents.
  • Make department filters part of retrieval, not a cosmetic UI filter after generation.
  • Prefer conservative answers over unsupported fluent responses.
  • Show document metadata so users can judge recency and source quality.
  • Keep the chat UX simple enough for non-technical users.

Evaluation & reliability

01 · Grounding

Answers were evaluated by checking whether claims could be traced to retrieved source chunks.

02 · Failure modes

Key risks included stale documents, incomplete retrieval, ambiguous questions, chunk boundary issues, and unsupported model synthesis.

03 · Human review

Users remained responsible for validating important answers against source documents.

04 · Operational risk

The system needed graceful behavior when retrieval was weak, the model was slow, or documents were missing.

05 · Adoption

Trust depended on source visibility, latency, and whether the tool reduced repeated lookup work.

06 · Production readiness

Deployment required access control, observability, rollback thinking, and a clear data boundary.

Impact

Manual review reduction

Estimated

80%+

Estimated reduction in selected repeated document lookup and manual review workflows after introducing source-grounded retrieval.

The broader impact was improved access to internal knowledge and a practical pattern for private LLM deployment inside enterprise constraints.

Limitations

What I learned

The strongest RAG systems are product systems, not just retrieval pipelines. Users trust them when they can see sources, understand boundaries, recover from uncertainty, and fit the tool into existing work.

What I would improve next

  • Add a structured evaluation suite for retrieval relevance and answer grounding.
  • Add feedback loops that collect weak-query examples.
  • Improve document metadata quality and freshness signals.
  • Introduce reranking for high-value queries.
  • Add deeper observability around latency, empty retrieval, and citation behavior.

Confidentiality note