Problem
Insurance policy answers are often spread across clauses, exclusions, limits, waiting periods, and conditions. A simple answer without evidence is not enough.
AI/RAG Case Study
InsureSense AI — Insurance Policy Document Intelligence
A practical RAG case study where users upload insurance policy PDFs, ask natural-language questions, and verify answers through citation-backed source excerpts.
Next.js App Router • TypeScript • PostgreSQL • pgvector • Drizzle • PDF Parsing • Hybrid Retrieval • LLM APIs • Vercel Serverless
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 retrieval. It is retrieving enough evidence, grounding the answer, and helping users trust 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 citation-backed answers
7Show 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.
Hybrid retrieval
Combined semantic retrieval with lexical/contextual signals so the system is not dependent on vector similarity alone.
Answer generation
Generated answers only from retrieved evidence, with source excerpts and citations shown back to the user.
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
Kept the answer generation layer dependent on retrieved evidence, instead of letting the LLM answer from general knowledge.
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.
Hybrid search mindset
Used retrieval thinking that combines semantic similarity with keyword and context matching to improve recall on clause-heavy documents.
Scoped document handling
Designed the demo around scoped workspaces/sessions and temporary document retention so user documents are not treated casually.
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 citations, not just answers
Users should be able to inspect the exact source excerpts used to generate an answer.
Avoid overconfident responses
When retrieved evidence is weak or incomplete, the product should avoid pretending it knows the 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.
What I would measure
A serious RAG system needs evaluation beyond “the answer looks good.” These are the signals I would track as the product matures.
- Retrieval recall for clause-heavy questions
- Citation accuracy against source PDF pages
- Answer groundedness: whether every claim is supported by retrieved evidence
- Unknown-answer handling when the document does not contain enough information
- Chunk quality across exclusions, waiting periods, limits, and definitions
- Latency from question to answer
- User 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, hybrid retrieval, pgvector, and LLM integration as separate architectural concerns.
- I can design AI product UX around trust, verification, and user confidence.
- I can turn learning into a working product case study and explain the engineering trade-offs clearly.
Exploring practical AI workflows?
I’m open to meaningful conversations around document AI, RAG workflows, retrieval quality, citation-grounded answers, and trust-first AI product experiences.
Start a Conversation