duembi/silsilsilsils

Purpose and Entry Points

This repository implements an AI-assisted retrieval workflow over parcel-table Excel data, with data imputation, retrieval setup, RAG answering, QA evaluation, and a server-facing conversation layer. The primary application entry point is rag_with_ai/src/api/main.py; Windows server startup is provided by rag_with_ai/scripts/run_server.ps1. Workflow orchestration appears centered on rag_with_ai/src/graph.py.

Source Data and Persistence

The domain source is quarterly Turkish parcel-table workbooks, including an imputed variant: rag_with_ai/2026-2__Çeyrek__Nisan-Mayıs-Haziran__Parsel_Tablosu (4).xlsx and rag_with_ai/2026-2__Çeyrek__Nisan-Mayıs-Haziran__Parsel_Tablosu_Imputed.xlsx. Raw copies are maintained under rag_with_ai/data/raw/. Structured parcel data persists in rag_with_ai/data/parsel.sqlite; conversation history persists separately in rag_with_ai/data/conversations.sqlite.

Graph-Orchestrated Processing

rag_with_ai/src/graph.py and rag_with_ai/src/graph_state.py define the control-flow boundary between stages. Routing tests indicate that graph decisions select among processing paths rather than exposing every agent directly. The graph likely carries request, retrieval, and response state through specialized agents, isolating orchestration from API transport and individual AI/data operations.

Data Quality and Imputation

rag_with_ai/src/agents/data_imputation_agent.py owns completing or correcting missing source values before downstream use. Its output is represented by the imputed workbook and is validated independently. This forms an important boundary: retrieval and QA should consume the normalized/imputed dataset rather than mutating the raw Excel input.

Retrieval Index Construction

rag_with_ai/src/agents/retrieval_setup_agent.py prepares searchable retrieval assets from parcel data. The persisted Chroma store is under rag_with_ai/data/chroma_index/, with catalog metadata in rag_with_ai/data/chroma_index/chroma.sqlite3 and multiple binary vector-index segments. This is a durable local retrieval boundary: indexing can be performed separately from request-time answering.

RAG Answering and Runtime Resource Control

rag_with_ai/src/agents/rag_pipeline_agent.py is the request-time retrieval-and-generation stage. It should obtain relevant indexed context, then produce an answer for the graph/API layer. rag_with_ai/src/vram_manager.py is architecturally material because it suggests local model or embedding inference with explicit GPU-memory lifecycle management; model-runtime resource handling is separated from RAG business flow.

API and Conversation Boundary

rag_with_ai/src/api/main.py exposes the application-facing interface, while rag_with_ai/src/api/conversation_store.py isolates durable chat/session persistence. rag_with_ai/src/api/static/index.html provides a bundled browser client, but the API remains the key integration boundary. Request flow is therefore: client/API → graph routing → retrieval/RAG or related agent → persisted conversation and response.

Evaluation and Operational Verification

rag_with_ai/src/agents/qa_eval_agent.py evaluates answer quality against curated expectations. Golden questions are stored in rag_with_ai/tests/golden/qa_pairs.json; evaluation execution is available through rag_with_ai/scripts/run_golden_eval.py. Spreadsheet correctness and end-to-end QA are additionally represented by rag_with_ai/scripts/verify_against_excel.py and reports in rag_with_ai/docs/, providing a separate validation boundary for source fidelity versus generated-answer quality.