An ingestion pipeline
Parsing for PDFs, docs, web pages and database rows, chunking that respects headings and tables, and re-indexing when sources change.
Most RAG systems fail quietly: they retrieve the wrong passage and the model answers confidently anyway. I build retrieval that is measured, cites its sources, and says "I don't know" when your documents don't say.
For companies with knowledge trapped in documents, wikis, tickets or databases that staff or customers keep asking about.
Parsing for PDFs, docs, web pages and database rows, chunking that respects headings and tables, and re-indexing when sources change.
Embeddings plus keyword search (BM25), reranking and metadata filters on pgvector, S3 Vectors, FAISS or a managed vector database.
Every answer cites the passages it used, and the assistant refuses rather than guessing when retrieval comes back empty.
A question set with known answers, scored for retrieval hit rate and faithfulness, so improvements are measured, not felt.
Fifty real questions people ask today, with the answers a good colleague would give. This becomes the test set.
Ingest the sources, then score retrieval on the test set before writing a single prompt.
Chunking, hybrid weights, reranking and query rewriting, changed one at a time against the numbers.
Deploy with feedback buttons and logging, and review the questions it got wrong every week at first.
Often not a new one. If you already run PostgreSQL, pgvector is usually enough. I reach for a dedicated store only when scale or latency demands it.
Yes. Data can stay in your cloud account, access can follow your existing permissions, and models can run through providers with zero data retention or on open-weight models you host.
RAG when the answers live in documents that change. Fine-tuning when you need a consistent style, format or a skill the base model lacks. Many good systems use a little of both.
Yes. It retrieves from this site's own pages and posts using hybrid search, the same approach described here.
Related writing