01
Upload
A user uploads a PDF. The backend extracts text, preserves hierarchy, and attaches page-level metadata.
Production case study
AI Internal Knowledge Copilot
Enterprise RAG System
Enterprise RAG that turns scattered PDFs, wikis, and internal documentation into grounded answers with source citations.
Next.jsFastAPIPostgreSQLpgvectorVoyageAI
- Role
- Full Stack + AI Engineer
- Domain
- Enterprise Knowledge / Legal Ops
- Users
- Knowledge workers
- Market
- Colombia
- Stack
- Next.js - FastAPI - PostgreSQL - pgvector - VoyageAI - OpenAI
Product demo
Problem
Internal knowledge is valuable, but most teams still lose it across PDFs, wikis, drives, and threads.
Knowledge workers need answers from internal documentation, but the information is scattered across PDFs, shared drives, stale wikis, presentations, and long email chains.
The user problem
One mental model for the user problem — not scattered symptoms across tools.
Generic chatbots are not enough because they do not know the organization's proprietary documents. Teams need answers grounded in their own corpus, with citations they can verify.
The product challenge was not just adding an LLM. It was building a trustworthy retrieval layer: ingestion, chunking, embeddings, access boundaries, streaming UX, and a no-answer path when confidence is too low.
Understand the painThen see the product response
Solution
The solution is a guided knowledge retrieval loop, not a chatbot wrapper.
The product turns static documents into a searchable knowledge layer: upload, structure, index, retrieve, and answer with citations.
02
Index
The system chunks the document, generates embeddings, and stores vectors plus metadata in PostgreSQL with pgvector.
03
Ask
The user asks a natural-language question. The query is embedded and matched against the most relevant chunks.
04
Answer
The answer streams back with source citations, so the user can verify where the information came from.
Capabilities behind the journey
Structured PDF ingestion
PDFs are converted into Markdown-like structure so headings, hierarchy, and page context survive retrieval.
Two-step chunking
Content is split first by document structure, then by token limits with overlap so chunks keep semantic context.
Vector retrieval
Queries and chunks are embedded, stored in PostgreSQL with pgvector, and retrieved with metadata-aware similarity search.
Grounded generation
The LLM receives retrieved context and a citation contract, producing answers mapped back to source chunks and pages.
Streaming experience
Server-Sent Events show answers token by token, reducing perceived wait time and making the product feel responsive.
No-answer guardrail
When retrieval confidence is not enough, the system should refuse instead of inventing internal knowledge.
Impact
Potential to recover 9,360 hours/year for a 100-worker team.
Illustrative scenario with a conservative 20% reduction in daily search time — supporting benchmarks below.
01 - Friction
Knowledge workers lose hours searching scattered PDFs, wikis, and internal docs.
02 - Intervention
The product turns documents into a searchable knowledge layer with cited answers.
03 - Outcome
9,360 hours/year — Potential productive time recovered in a 100-worker scenario with a conservative 20% reduction in search time.
Supporting signals
1.8 h/day
Search benchmark
McKinsey's estimate for daily time knowledge workers spend searching or gathering internal information.
62%
Employee signal
Microsoft Work Trend Index respondents who say they spend too much time searching for information.
~30 sec
Manual indexing example
Approximate processing time for indexing a 100-page manual in the source scenario.
Information retrieval bottleneck
The product reframes static documentation as an answerable knowledge system instead of another place to search manually.
Architecture
How the system is built.
Six views — stack, containers, security, runtime flow, data model, and where it runs.
System Overview
A browser question flows through the frontend, API, database, and LLM — with citations mapped back to source chunks.
Browser
Next.js
FastAPI
Postgres
S3
LLM
| Layer | Role | Stack |
|---|---|---|
| Browser | Upload PDFs, ask questions, read cited answers. | React |
| Next.js | Chat UI, streaming responses, citation display. | Next.js · TypeScript |
| FastAPI | Auth, ingestion, retrieval, and chat orchestration. | FastAPI · Python |
| Postgres | Documents, chunks, vectors, and sessions. | PostgreSQL · pgvector |
| S3 | PDF files and generated artifacts. | S3 |
| LLM | Grounded generation with citation rules. | OpenAI · VoyageAI |
Next.jsFastAPIPostgreSQLpgvectorS3VoyageAIOpenAI
Decisions
Lessons
Repeat
What is worth carrying into the next product.
- Preserving document structure before embedding made retrieval more useful than plain text extraction.
- pgvector kept the product operationally simple while still supporting semantic search.
- Streaming responses made the assistant feel responsive before the full answer was complete.
Refine
What deserves another iteration.
- Add reranking to improve top-K retrieval precision on ambiguous questions.
- Support scanned PDFs, tables, and images with OCR or multimodal ingestion.
- Add hybrid search that combines semantic retrieval with keyword matching.
Transfer
What changed my engineering judgment.
- RAG quality depends more on ingestion, chunking, metadata, and retrieval than on the model name alone.
- Citations must be designed as a product trust feature, not added as an afterthought.
- Clean boundaries matter when debugging hallucinated answers, retrieval failures, or model swaps.
Next step
Want the implementation details?
Explore the repository, try the live flow, or reach out if you want to talk through the architecture behind it.
Keep exploring