arjunisaac/policy-rag

Purpose and Entry Points

Policy-RAG is a local insurance-policy question-answering system. It indexes a policy document library, retrieves relevant content, and uses a locally served Qwen3 model to generate answers and extract policy attributes.

Primary entry points:

• ingest_library.py builds or refreshes the searchable policy corpus.

• main.py launches the Streamlit user interface.

• vllm_env.sh prepares Linux environment settings for the separate vLLM inference server.

Runtime Topology

The application runs as two cooperating processes:

• Streamlit hosts the interactive RAG application via main.py.

• vLLM exposes an OpenAI-compatible API serving Qwen/Qwen3-4B-AWQ, configured externally through the README launch command and vllm_env.sh.

The Python application depends on the model service being available before query processing. Hugging Face authentication may be required to obtain gated model artifacts.

Ingestion and Corpus Boundary

Library ingestion is isolated from interactive querying:

• ingest_library.py

• src/ingestor.py

• src/vector_store.py

The ingestion path loads policy-library content, prepares it for retrieval, and persists/vectorizes it through the vector-store layer. This creates the durable boundary between raw policy documents and query-time retrieval; the Streamlit process should consume the indexed corpus rather than reprocess source documents per request.

Retrieval and RAG Orchestration

Query-time retrieval is split between retrieval infrastructure and policy-specific orchestration:

• src/retrieval.py

• src/vector_store.py

• src/policy_chain.py

retrieval.py and vector_store.py form the document-search boundary. policy_chain.py is the likely composition layer that turns a user question plus retrieved policy context into a model request and final response. It is the primary control-flow boundary between UI interaction, evidence retrieval, and LLM generation.

Attribute Extraction Pipeline

The repository contains a dedicated structured-extraction subsystem rather than relying solely on free-form RAG answers:

• src/extract_attribute/extraction_engine.py

• src/extract_attribute/retrieval_engine.py

• src/extract_attribute/post_processor.py

This subsystem retrieves relevant policy evidence for a target attribute, runs extraction, then normalizes or validates output in post-processing. Supporting strategies include regex extraction and summarization:

• src/extract_attribute/regex_extractor.py

• src/extract_attribute/summary_engine.py

This separation enables deterministic or hybrid extraction for policy fields where generated prose alone is insufficient.

Domain Model and Presentation Boundary

Shared policy concepts, types, and output formatting are centralized outside the UI and retrieval implementations:

• src/concepts.py

• src/datatypes.py

• src/formatting.py

main.py should remain the presentation/controller boundary, coordinating user input with the policy chain and extraction capabilities. styles.css supplies UI styling without participating in core retrieval or model logic.

Key Data Flow

1. ingest_library.py invokes ingestion and vector-store persistence for policy documents.

2. A user submits a question through main.py.

3. The policy chain retrieves relevant indexed policy passages.

4. Retrieved context and the user query are sent to the vLLM-hosted Qwen model.

5. The response is formatted for Streamlit; attribute-oriented requests may pass through the dedicated retrieval → extraction → post-processing pipeline.