Skip to content

fix(compose): forward RETRIEVER_ARANGO_* query params from chatqna + prod-tested defaults

Jérôme Revillard requested to merge fix/compose-retriever-query-params-chatqna into main

Problem

chatqna reads RETRIEVER_ARANGO_K / FETCH_K / SCORE_THRESHOLD / LAMBDA_MULT / SEARCH_START / TRAVERSAL_* from its own env at import time and forwards them in the HTTP request body to the retriever. The retriever's own env block was the only place these were defined, so when chatqna's env was missing them (recent RAG regression: recall 0.396) chatqna silently fell back to k=4. Took days to diagnose.

Changes

  • chatqna env block: adds the 10 query-param RETRIEVER_ARANGO_* vars so chatqna is the authoritative source for per-query retrieval tuning.
  • Contract comments in BOTH blocks documenting that the retriever env fallback is OPEA-vendored inert code (only reached on direct retriever API calls that bypass chatqna) and that defaults must stay aligned across blocks.
  • Prod-tested defaults in both blocks, matching deploy/ansible/group_vars/itu_rtx_el_salvador/vars.yml: k=20, fetch_k=30, score_threshold=0.2, traversal enabled/2/5/0.7/10. Default k=4 was the regression root cause.

Why duplicate rather than remove the retriever block

Decision (discussed): keep both blocks, align defaults. Zero code change = zero OPEA upstream divergence (critical for future upstream syncs). Retriever block stays as OPEA-native fallback for direct API probes. Parity verified: DRIFT NONE.

No code change

1 file changed, 28 insertions(+), 7 deletions(-)

  • YAML validated
  • No Python touched -> no test impact

Merge request reports