LLM systems · Retrieval · Evaluation · Observability

Local Document Q&A

A configurable document question-answering system where ingestion, lexical and dense retrieval, context selection, generation, evaluation, and tracing can run on infrastructure controlled by the operator.

OpenSearchQdrantHybrid retrievalLocal LLMOpenTelemetryPhoenix

Retrieval is part of answer quality

A plausible answer can still be wrong because the failure happened before generation: a document was not ingested, chunks lost useful context, the right candidate ranked too low, fusion suppressed an exact match, or the final context pack omitted supporting evidence. The project therefore keeps retrieval and QA handoff independently inspectable.

Architecture

Lexical retrieval remains useful for exact terms, identifiers, and rare phrases. Dense retrieval broadens semantic recall. The combination is configurable so changes can be measured against the same fixture rather than assumed to help.

Working interface

Streamlit interface for Local Document Q&A showing the working document question-answering application
Document Q&A interface. The repository also includes pages for ingestion, search, index inspection, duplicates, task administration, and related operational workflows.

Evaluation changed the retrieval configuration

The repository separates retrieval evaluation from final QA handoff. Historical runs record expected-document Hit@k, supporting-document Hit@k, context support, and stage latency. These artifacts are tied to a fixed local fixture and are not presented as general benchmarks.

0.90strict Hit@5, reranker off
0.60strict Hit@5, reranker on
0.80final-context support, reranker off
20-query historical fixtureCross-encoder offCross-encoder on
Strict Hit@19/20 · 0.455/20 · 0.25
Strict Hit@315/20 · 0.759/20 · 0.45
Strict Hit@518/20 · 0.9012/20 · 0.60
Supporting Hit@316/20 · 0.8010/20 · 0.50
Final-context support16/20 · 0.8010/20 · 0.50
Average retrieval time~569 ms~650 ms

The cross-encoder improved one query but regressed seven. On this corpus and configuration it reduced recall/support while adding reranking latency, so it was left disabled and the next experiments moved to context-budget and handoff policy instead.

Scope: one checked-in 20-positive-query evaluation fixture plus three control queries. The numbers describe that historical experiment only.

Failures are separated by stage

Ingestion

Checksums, paths, chunk metadata, and asynchronous worker state make missing or duplicated source material inspectable.

Candidate retrieval

Lexical and dense results can be compared before fusion, MMR, sibling expansion, or reranking changes the candidate set.

Context handoff

Support labels test whether enough evidence reaches the answer stage instead of treating a retrieval hit as equivalent to a grounded answer.

Generation and tracing

Source metadata is retained and OpenTelemetry/Phoenix traces expose the path through retrieval, prompt construction, and generation.

Local-first boundaries

Local deployment improves data control but does not make a system secure by default. Ports, logs, model services, host filesystems, optional third-party providers, and document-level authorization still require explicit decisions. The repository is therefore presented as an evolving local system, not as a production-ready hosted product.