How nithish-yenaganti/rag_system works
1. Project shape
- This is a small, single-process RAG application centered on Rag_Web.py.
- There is no separate backend service or database layer; the app combines UI, document processing, retrieval, and generation in one Python runtime.
2. Primary runtime boundary
- The user interacts through a Streamlit web UI.
- Streamlit is the presentation layer and triggers the RAG pipeline when a question is submitted.
3. Source data boundary
- The knowledge source is a single local document: Statefarm.pdf.
- That PDF is the only domain corpus described in the repo, so the app is specialized to answering questions about a car insurance policy.
4. Document ingestion pipeline
- PyPDFLoader reads the PDF into text.
- RecursiveCharacterTextSplitter breaks the document into overlapping chunks.
- This chunking step is important because retrieval operates on smaller passages rather than whole pages or the full document.
5. Indexing / retrieval layer
- Each chunk is embedded with OpenAIEmbeddings.
- The embeddings are stored in a FAISS vector index, which acts as the local retrieval store.
- This is the main retrieval boundary: raw document text becomes vectorized chunks that can be searched by similarity.
6. Question answering flow
- A user question enters from Streamlit.
- The retriever fetches the most relevant chunks from FAISS.
- Those chunks, along with the question, are sent to the LLM for answer generation.
7. Generation layer
- ChatOpenAI is used for the answer synthesis step.
- The prompt is constrained to answer strictly from retrieved context, which is the key anti-hallucination control in the architecture.
8. External dependencies
- The application depends on the OpenAI API for both embeddings and chat generation.
- OPENAI_API_KEY is therefore an external runtime requirement and a major infrastructure dependency.
9. Repository contents and role
- *.ipynb notebooks are experimentation and development artifacts for loading docs, splitting, embeddings, retrievers, and model testing.
- They are not the production path, but they show the pipeline was developed step-by-step before being consolidated into the Streamlit script.
10. Operational model
- The app is best understood as a local RAG pipeline with remote model calls:
- local PDF source
- local chunking and FAISS retrieval
- remote OpenAI embedding and chat services
- Streamlit UI as the entry point
- The architecture is simple and linear, with the main data flow running from document → chunks → vectors → retrieved context → LLM response → UI.
11. Key diagram boundaries to show
- User/browser boundary at Streamlit
- Local application boundary around Rag_Web.py
- External API boundary around OpenAI
- Knowledge boundary around Statefarm.pdf and its derived FAISS index
Main entry points: Rag_Web.py Streamlit UI · Statefarm.pdf Statefarm PDF · complete_RAG.ipynb Notebooks
Components 15
Presentation
User-facing Streamlit entry point and response display.
- User · Question sender at the browser boundary.
- Streamlit UI · Web interface that accepts questions and renders answers.
Rag_Web.py - Answer · Returned response shown in the UI.
Rag_Web.py
Local RAG App
Single-process Python pipeline in Rag_Web.py.
- RAG app · Main script that wires ingestion, retrieval, and generation together.
Rag_Web.py - PDF loader · Reads the local PDF into text.
Rag_Web.py - Text splitter · Breaks loaded text into overlapping chunks.
Rag_Web.py - Retriever · Fetches the most relevant chunks for a query.
Rag_Web.py - Context packer · Combines retrieved passages with the user question.
Rag_Web.py
Knowledge Base
Local source document and derived retrieval store.
- FAISS index · Local similarity index over embedded chunks.
Rag_Web.py - Statefarm PDF · Local policy document that is the corpus for Q&A.
Statefarm.pdf
External Services
Remote OpenAI dependencies for embeddings and generation.
- Embeddings · Turns chunks into vectors via OpenAI embeddings.
Rag_Web.py - ChatOpenAI · Synthesizes the final answer from constrained context.
Rag_Web.py - OpenAI API · External service used for embeddings and chat completion.
- API key · OPENAI_API_KEY required at runtime.
Experiments
Notebook-based exploration and prototyping.
- Notebooks · Prototype notebooks for loading, splitting, embeddings, retrievers, and model tests.
complete_RAG.ipynb
Connections 17
- User → Streamlit UI: asks · User submits a question through the web UI.
- Streamlit UI → RAG app: triggers · UI event enters the main RAG workflow.
- RAG app → PDF loader: loads · Initial document ingestion step.
- Statefarm PDF → PDF loader: source · Local PDF is the only knowledge corpus.
- PDF loader → Text splitter: text · Loaded document is segmented into chunks.
- Text splitter → Embeddings: chunks · Chunks are prepared for vectorization.
- Embeddings → OpenAI API: embed request · Embedding calls go to OpenAI.
- Embeddings → FAISS index: stores vectors · Embedded chunks are written to the local vector index.
- FAISS index → Retriever: search space · Retriever queries the FAISS index by similarity.
- Streamlit UI → Retriever: question · The user query is passed into retrieval.
- Retriever → Context packer: top chunks · Most relevant passages are selected for prompting.
- Context packer → ChatOpenAI: prompt · Context and question are sent for answer synthesis.
- ChatOpenAI → OpenAI API: completion request · Chat generation is performed through OpenAI.
- API key → OpenAI API: auth · Runtime secret required for API access.
- ChatOpenAI → Answer: answer text · Generated response is returned to the app.
- Answer → Streamlit UI: renders · Final answer is displayed in the Streamlit page.
- Notebooks → RAG app: prototype lineage · Notebook experiments informed the production script.