Problem
Insurance policy answers are often spread across clauses, exclusions, limits, waiting periods, and conditions. A simple answer without evidence is not enough.
05 / Case Study · AI / RAG
InsureSense AI
A practical RAG product where users upload insurance policy PDFs, ask natural-language questions, and verify generated answers against supporting source excerpts.
Next.jsTypeScriptPostgreSQLpgvectorRetrieval QualityLLM APIsCitationsVercel Serverless
Build Scope
Built end-to-end as a practical document-AI product.
I built InsureSense AI as an end-to-end RAG product: document upload and parsing, chunking, embedding storage with PostgreSQL and pgvector, retrieval, LLM integration, citation rendering, and the UX around processing and answer verification.
The goal was not to present a production-scale insurance platform. It was to explore the engineering decisions that make document AI useful: retrieval quality, grounding, evidence visibility, failure boundaries, and user trust.
Approach
I built a RAG workflow where users upload a policy PDF, ask natural-language questions, and verify answers through citation-backed source excerpts.
Learning
The hard part in document AI is not only finding a relevant chunk. It is retrieving enough supporting context, constraining generation around that evidence, and helping users verify what the system says.
Product flow
The product flow is intentionally guided. Users should know when the document is uploaded, processed, searchable, and ready for citation-backed questions.
1Upload policy PDF
2Parse and normalize document text
3Split clauses into searchable chunks
4Store embeddings and retrieval metadata
5Retrieve evidence for user questions
6Generate answers grounded in retrieved context
7Show supporting source excerpts for verification
RAG architecture
I treated the system as a pipeline with clear responsibilities: ingestion, parsing, chunking, embedding storage, retrieval, answer generation, and citation rendering.
Document ingestion
Handled policy PDF upload, text extraction, document processing states, and preparation for downstream retrieval.
Chunking strategy
Split document text into searchable chunks while trying to preserve clause-level meaning and enough surrounding context.
Embedding storage
Stored embeddings and retrieval metadata in PostgreSQL with pgvector so policy content could be searched semantically.
Retrieval strategy
Used semantic retrieval with document metadata and contextual filtering, while treating lexical or hybrid retrieval as an extension point where exact policy terminology needs stronger matching.
Answer generation
Constrained answer generation around retrieved context and surfaced supporting source excerpts so users could verify the answer against the policy.
Trust-first interface
Designed the UX so users can inspect the supporting clauses instead of blindly trusting a generated answer.
Engineering decisions
The goal was not to build a generic chatbot over a PDF. The goal was to make document intelligence useful in a domain where correctness, citations, and user trust matter.
Citation-first answer design
Focused on showing source excerpts with answers because insurance is a trust-sensitive domain where users need to verify the reasoning.
Retrieval before generation
Structured the answer-generation step around retrieved document context rather than treating the model as a general-knowledge chatbot.
Clause-aware chunking
Treated chunking as a product and retrieval decision, not only a text-splitting task, because policy meaning often depends on nearby clauses.
Retrieval quality over vector similarity
Treated retrieval as more than nearest-neighbor search: chunk boundaries, document metadata, exact terminology, and surrounding context all affect whether the right evidence reaches the model.
Scoped document handling
Kept document access scoped to the active product context and designed the workflow so uploaded policy files are handled as user data rather than reusable model knowledge.
Modular RAG pipeline
Kept ingestion, parsing, chunking, retrieval, answer generation, and citations as separate concerns so each layer can evolve independently.
Trust-first UX decisions
In document AI, a relevant chunk is not always enough. The answer needs enough evidence, clear citations, and honest boundaries when the document does not contain enough information.
Show evidence, not just answers
Users should be able to inspect the supporting source excerpts returned with an answer instead of relying on generated text alone.
Handle insufficient evidence explicitly
When retrieval does not surface enough supporting context, the product should communicate uncertainty rather than manufacture a confident answer.
Make processing visible
The upload → parse → ready-to-query flow helps users understand when the document is actually prepared for questions.
Support comparison-style thinking
Policy questions often require comparing limits, waiting periods, exclusions, and conditions rather than reading one isolated line.
How I would evaluate the RAG system
A useful RAG system needs evaluation beyond “the answer looks good.” These are the signals I would use to evaluate retrieval quality, grounding, and the user's ability to verify answers as the product matures.
1Retrieval recall for clause-heavy questions
2Citation accuracy against source PDF pages
3Answer groundedness: whether material claims are supported by retrieved evidence
4Unknown-answer handling when the document does not contain enough information
5Chunk quality across exclusions, waiting periods, limits, and definitions
6Latency from question to answer
7User ability to verify the answer through citations
What this case study shows
- ·I can build a practical RAG workflow end-to-end, from document ingestion to retrieval and answer generation.
- ·I understand that document AI needs evidence, citations, and honest boundaries — not only fluent answers.
- ·I can reason about parsing, chunking, embeddings, retrieval quality, pgvector, and LLM integration as separate architectural concerns.
- ·I can design AI product UX around trust, verification, and user confidence.
- ·I can turn an AI product idea into a working end-to-end system and explain the engineering trade-offs clearly.
Exploring practical AI workflows?
I'm open to meaningful conversations around document AI, RAG workflows, retrieval quality, grounded answer generation, evaluation, and trust-first AI product experiences.