What I Built
I built a Customer Support AI System to help a friend who was practicing customer-support workflows and needed a faster way to find accurate answers from support documentation.
A common problem in customer support is that the information already exists, but finding the right piece of information can take time.
Support teams may have FAQs, refund policies, account policies, payment documentation, and other reference documents spread across multiple files.
Instead of manually searching through those documents, I built a system that allows support knowledge to be uploaded and searched using semantic similarity.
The system can:
Upload FAQ, support, policy, PDF, TXT, and Markdown documents
Extract document text
Clean and split the text into overlapping chunks
Generate embeddings
Store embeddings in ChromaDB
Perform semantic search
Return relevant chunks with source metadata
Track the original document and page for retrieved information
The goal is simple:
Help a support agent find the right information faster.
Demo
The project includes a Streamlit demonstration interface for interacting with the knowledge base.
Example questions
The system can be tested with questions such as:
How long do customers have to request a refund?
What should I do if my account is locked?
How quickly are password reset emails sent?
Which payment methods are supported?
Can a refund be requested after 30 days?
The repository also provides a FastAPI backend and Swagger documentation for interacting with the API.
Demo:
https://github.com/Sinjini1803/Customer-Support-System
Code
The complete source code is available here:
GitHub:
https://github.com/Sinjini1803/Customer-Support-System
The repository contains the application code, sample data, tests, Docker configuration, ingestion pipeline, and demonstration interface.
How I Built It
The system is built around a Retrieval-Augmented Generation-style knowledge pipeline, with the current implementation focusing on the retrieval stage.
The architecture is:
Support Documents
|
v
Upload API
|
v
PDF / Text Extraction
|
v
Text Cleaning
|
v
Chunking + Overlap
|
v
Sentence Embeddings
|
v
ChromaDB
|
v
User Query
|
v
Query Embedding
|
v
Semantic Similarity Search
|
v
Top-K Relevant Chunks
|
v
Source Metadata
The repository implements PDF/text extraction using PyMuPDF, creates overlapping chunks, generates normalized embeddings using Sentence Transformers, and persists those vectors in ChromaDB.
- Document Ingestion
A support document can be uploaded through the API.
For example:
curl -X POST http://localhost:8000/ingest \
-F "file=@data/sample_documents/refund_policy.pdf"
The system extracts the document content and divides it into manageable chunks.
Each chunk retains metadata such as:
Document ID
Document name
Document type
Page number
Chunk number
Source filename
Upload timestamp
This means that a search result can be traced back to its original document and page.
- Embeddings
After the document is processed, the text chunks are converted into numerical vector representations using a Sentence Transformer model.
This allows the system to compare the meaning of a user's question with the meaning of stored support information rather than relying only on exact keyword matches.
- ChromaDB
The generated embeddings are stored in ChromaDB.
When a user asks a question, the question is also converted into an embedding.
The system then performs semantic similarity search and retrieves the most relevant chunks.
User Question
|
v
Query Embedding
|
v
ChromaDB Search
|
v
Top-K Relevant Chunks
|
v
Document + Page Metadata
The current API returns the chunk text, similarity score, document information, page number, chunk ID, and source filename.
- FastAPI Backend
The backend is implemented using FastAPI.
The project provides endpoints for:
Health checking
Document ingestion
Semantic search
It also exposes Swagger documentation through:
when running locally.
- Streamlit Demo
A Streamlit interface provides a simple way to interact with the knowledge base without having to manually call API endpoints.
The project can be started with:
streamlit run demo/streamlit_app.py
The repository also includes Docker and Docker Compose support.
Why Does Open Innovation Matter?
Open innovation mattered to this project because I wanted to understand how much of an AI-powered support workflow could be built using open tools rather than relying entirely on a closed AI API.
The project uses open-source components for the core retrieval pipeline:
Sentence Transformers for embeddings
ChromaDB for vector storage
FastAPI for the backend
Streamlit for the demonstration interface
This gives developers more control over the individual parts of the system.
Flexibility
The embedding model can be changed independently from the vector database and API layer.
The retrieval system is therefore not tied to one proprietary provider.
Transparency
Because the retrieval pipeline is built from separate components, it is easier to understand how documents are processed, embedded, stored, and retrieved.
Privacy and Control
Customer-support documentation can contain information that organizations may not want to send to an external service for every search.
Using locally controllable components gives developers more flexibility when designing a privacy-conscious system.
Learning
Building the project also helped me understand that an AI application is not just about generating text.
A useful system needs:
Good document processing
Good chunking
Meaningful embeddings
Efficient retrieval
Source tracking
Testing
A usable interface
A Small but Important Design Choice
One thing I wanted to preserve was source traceability.
When a support agent gets a search result, simply returning a piece of text is not enough.
The system stores metadata that can identify the original document and page.
For example:
Document: refund_policy.pdf
Page: 3
Chunk: 2
Similarity: 0.XX
This makes the retrieved information easier to verify.
For customer support, that matters because an answer should ideally be backed by the actual support documentation.
What I Learned
The biggest lesson from building this project was that retrieval quality is extremely important in AI applications.
Before working on this project, it was easy to think of an AI system mainly as a model that generates an answer.
But building the retrieval pipeline showed me that the quality of the information supplied to an AI system matters just as much.
If documents are poorly extracted, badly chunked, or difficult to retrieve, even a powerful language model would have difficulty producing a reliable answer.
This project therefore helped me understand the foundation behind RAG systems:
Documents → Chunks → Embeddings → Vector Search → Relevant Context
The current implementation intentionally separates retrieval from answer generation. The repository documents how an LLM could be added after semantic search to generate a grounded support answer with citations in a future iteration.
My Agent Session
Optional: I did not include a DevRelay session for this submission.
Prize Categories
This submission is primarily for the Hacktoberfest Weekend Challenge: Build for a Friend.
I am only entering additional partner categories when the required partner technology is actually used in the project.
Final Thoughts
I started this project with a simple problem:
Customer-support information is useful only when people can find it quickly.
That led me to build a searchable knowledge system that turns support documents into a semantic knowledge base.
What began as a way to help someone practice customer-support workflows became a practical exploration of document processing, embeddings, vector databases, semantic search, APIs, and AI application architecture.
The most important lesson for me was that building useful AI is not always about creating the biggest model.
Sometimes it is about building a better path between a person's question and the information they actually need.
That is what I wanted to build for my friend.
Top comments (0)