suganth1704/rag_app_backend

1. What this repo is

- RAG_APP is a retrieval-augmented generation backend: it ingests documents, turns them into embeddings, stores them in a vector database, retrieves relevant chunks for a query, and sends that context to an LLM for answer generation.

2. Top-level runtime entrypoint

- main.py is the application bootstrap. It is the likely place where the FastAPI app is created and the API routes are mounted.

- This is the handoff point from process startup into the request-serving layer.

3. API boundary

- api/route.py contains the HTTP endpoints and request handling.

- api/schema.py defines the API contract, likely using Pydantic models for typed input/output payloads.

- This layer should be treated as thin orchestration: validate requests, call ingestion/retrieval/chat services, return responses.

4. Ingestion subsystem

- ingestion/ingest.py is responsible for document processing.

- Based on the README, the ingestion flow is: load document → chunk text → create embeddings → persist vectors.

- The chunking settings are part of the architecture: chunk_size=700, chunk_overlap=150.

5. Embedding and indexing flow

- The README states embeddings are created with all-MiniLM-L6-v2.

- Those embeddings become the durable search index stored in ChromaDB, not the raw documents themselves.

- This means the key persisted artifact is the vectorized chunk representation plus any associated metadata.

6. Vector store boundary

- vector_store/chroma_client.py encapsulates ChromaDB access.

- This module is the persistence/search boundary for retrieval operations, isolating the rest of the app from Chroma-specific calls.

- Retrieval uses similarity search and MMR-style selection according to the README, so the vector store is not just storage; it also drives candidate ranking.

7. LLM / chat subsystem

- llm/groq_client.py is the integration point to Groq-hosted models.

- llm/chat.py likely composes the prompt, retrieved context, and user query into the final chat response.

- The model called out in the README is llama-3.3-70b-versatile, which is the generation endpoint for the response stage.

8. End-to-end data flow

- Ingestion path: documents enter through the backend, are chunked and embedded, then stored in ChromaDB.

- Query path: a user query arrives via the API, is embedded, used to retrieve relevant chunks from ChromaDB, and those chunks are passed into the LLM as context.

- The final answer is returned through the API layer to the client.

9. Cross-cutting concerns

- config/logging.py centralizes logging setup, which is important for tracing ingestion, retrieval, and generation failures across the pipeline.

- config/__init__.py suggests additional runtime configuration may be loaded here, likely environment-driven via .env as noted in the README.

10. External dependencies that matter architecturally

- FastAPI provides the HTTP interface.

- ChromaDB is the vector persistence/retrieval engine.

- Groq is the external model provider for generation.

- The README also mentions LangChain/LangGraph as orchestration frameworks; even though they are not visible as dedicated modules in the tree, they likely influence how retrieval and prompt workflows are structured.

11. Likely system boundaries for a diagram

- Client/UI → FastAPI API → ingestion or chat orchestration → vector store / LLM service.

- Persistence is split: vector data in ChromaDB, operational concerns in logs/config, and no relational database layer is present in the tree.

12. What is not present

- There is no dedicated database model layer, task queue, or separate worker service in the repository tree.

- If Redis is used, it is only mentioned in the README and not represented by a visible module here, so it should be treated as optional auxiliary infrastructure rather than a core subsystem.