As of June 2025 / build note
In a RAG system, similarity search is the easy part. The document lifecycle - adding, deleting, and keeping corpora separate without a full reindex - is the real engineering.
A build note from a document-processing pipeline I put together while working toward GenAI certification. I wanted it to handle real documents, not a clean demo dataset, so I tested it on Federal Reserve reports and AI research papers.
Most RAG tutorials stop at “embed the docs, search the vectors, return the chunks.” That gets you a demo. It does not get you something you can keep feeding new documents without rebuilding everything each time. So start with the system end to end, then look at the three parts that actually took the design time.
Pipeline (June 2025)
The flow end to end, and the three things that took the most design time - none of which is the vector search itself.
Pipeline (June 2025)
The system processes about 10,000+ text chunks and lets you search across different document types while keeping them separate, so an AI query about financial reports does not accidentally pull in unrelated research content. That separation sounds simple and was not.
Where the time actually went
The first lesson was that incremental updates are a feature, not a given. Adding a document through the UI automatically creates its chunks, embeddings, and vector-database entries. Deleting one removes just those chunks and embeddings without touching the rest of the index. Getting delete to be surgical - no full rebuild, no orphaned vectors - took more thought than the initial ingestion did.
The second was domain separation. Keeping document types in separate retrieval spaces is what stops a query from returning plausible-but-wrong context from the wrong corpus. In a banking setting that is not a nicety; it is the difference between a useful answer and a compliance problem.
The retrieval is easy. The lifecycle - selective updates, clean deletes, domain isolation - is where the engineering actually lives.
The architecture lesson
The interesting comparisons were not “which model” but “which vector store and why.” FAISS gave fast search; the trade-offs against ChromaDB were worth exploring rather than assuming. Adjustable relevance filtering that updates in real time, and report generation in Word for documentation, rounded out something usable rather than just demonstrable.
Corpus
~10,000+ chunks
Tested on real content - Federal Reserve reports and AI research papers - rather than a toy dataset, so the retrieval behavior reflects messy real documents.
Vector store
FAISS
Fast similarity search, with the FAISS-vs-ChromaDB performance trade-offs being the part most worth exploring.
The hard part
The lifecycle
Incremental add/delete and domain separation - not the search itself - were trickier than expected and where the design time went.
The honest framing: this was a learning project on the way into AI engineering, and the parts I expected to be hard (embeddings, search) were well-trodden, while the parts I underestimated (selective updates, separation) were where the real work sat.
