ADORSYS-GIS / ADORSYS-GIS/ai-helm

[Ticket]: 5 — Design & Implement Mitigation Strategies (Days 9–10)

Aperta
#1,067 0 commenti 0 reazioni 1 assegnatario Rivendicata da @rustnew Vedi su GitHub
ticket
Lingua principale
Go Template
Stelle
3
Fork
1
Merge medio
19h 24m
PR unite (30g)
80

Descrizione

### Type
Feature

### Summary
We need to design and implement mitigation strategies **directly derived from the root causes** identified in Ticket 4, because the epic's goal is not to describe the problem but to reduce it. Expected result: implemented mitigation prototypes (decoding, prompt, evidence grounding, verification, abstention, combined), their experimental configurations, and initial mitigation results compared to baseline.

### Intent
We must answer "how can we reduce the hallucinations?" with working prototypes, each traceable to a Ticket 4 root cause, so Ticket 6 can compare them and pick the best trade-off.

### Source of truth (links)
- Epic #1062 — Deep Analysis & Mitigation of Qwen3.5-2B Hallucinations (this ticket is its Ticket 5).
- Requester-provided epic specification (2026-08-31), Ticket 5 — "Design & Implement Mitigation Strategies".
- Ticket 4 — Root Cause Matrix (what each mitigation must target).
- Ticket 3 — baseline metrics (comparison reference).
- `impl.md` — frozen deployment configuration (mitigations may alter sampling params / prompts, not serving infra).

### Current Behavior
- The model runs at baseline; no mitigation exists.

### Expected Behavior
- **Prototype 1 — Decoding optimization**: temperature, top-p, top-k, decoding strategy.
- **Prototype 2 — Prompt optimization**: uncertainty awareness, evidence-based answering, anti-fabrication instructions, abstention behavior.
- **Prototype 3 — Evidence grounding (RAG-style)**: Question → Evidence → Qwen3.5-2B → Grounded Answer.
- **Prototype 4 — Verification**: Answer → Claim extraction → Verification → Supported / Unsupported → Keep / Regenerate.
- **Prototype 5 — Abstention**: Enough evidence? → YES: answer; NO: abstain.
- **Prototype 6 — Combined**: the best combination of the above.
- Each prototype has an **experimental configuration** (parameters/prompt/flow) and **initial results** on a shared evaluation subset vs baseline.

### Acceptance Criteria
- [ ] Given the Root Cause Matrix (Ticket 4), when a mitigation is implemented, then it demonstrably targets at least one documented root cause.
- [ ] At least one prototype exists per strategy family (decoding, prompt, evidence, verification, abstention) plus a combined one.
- [ ] Each prototype's experimental configuration is recorded (reproducible).
- [ ] Initial results are reported for each prototype against the baseline (hallucination rate delta).
- [ ] Prototypes are compatible with the existing endpoint (no serving-infra change required, or a documented, approved exception).
- [ ] Error cases handled safely (abstain/regenerate loops bounded).
- [ ] Verification evidence is provided (prototype configs, initial results).

### Out of Scope
- Production rollout of any prototype (Ticket 7 recommendation; rollout is a follow-up).
- Model fine-tuning.
- Serving-infrastructure changes (vLLM source, engine profiles).

### Technical Context
- Endpoint: OpenAI-compatible; sampling knobs available (temperature, top_p, top_k, `enable_thinking`).
- Evidence grounding requires a retrieval step; for the benchmark, evidence can be supplied explicitly per case (ground-truth context) rather than building a retrieval system — keep the prototype minimal and testable.
- Verification can reuse the same model or a deterministic checker (string/assertion-based) for code claims; document the method.
- Abstention behavior must be measurable with the Ticket 3 "abstention accuracy" metric.

### Risks
- Mitigations reduce hallucinations at the cost of usefulness/quality. Mitigation: also track accuracy and abstention; evaluate trade-off in Ticket 6.
- Verification/regeneration loops add latency. Mitigation: bound iterations; measure latency.
- Prompt mitigations overfit the benchmark. Mitigation: keep prompts generic, validate on unseen data in Ticket 7.

### Test Plan
- Run each prototype on a shared evaluation subset (e.g. 50 cases) with the same seed as baseline.
- Report hallucination rate delta, factual accuracy, abstention rate, and latency per prototype.
- Re-run twice to confirm stability.

### Verification evidence
- Prototype code/configs checked into the repo (`tools/hallucination-benchmark/mitigations/` or equivalent).
- Initial results table (prototype → HR delta, accuracy, abstention, latency).
- Traceability: each prototype → root cause(s) from the Ticket 4 matrix.

### Human accountable owner
@stephane-segning

### AI Usage Declaration
Drafting the ticket, Proposing implementation

### Human verification completed
- [ ] I understood the intent
- [ ] I checked the source of truth
- [ ] I reviewed all AI-generated text/code
- [ ] I verified the implementation manually
- [ ] I verified the tests
- [ ] I checked for hallucinated assumptions
- [ ] I documented remaining risks
- [ ] I am the accountable owner and accept responsibility for this ticket.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Start with Ticket 4's Root Cause Matrix, Ticket 3's baseline metrics, and impl.md to define traceable, compatible experiments. Inspect tools/hallucination-benchmark/mitigations/ or its repository equivalent, then run the shared evaluation subset described in the Test Plan. Done means six reproducible prototype configurations, initial comparison results, bounded failure handling, and evidence linking each strategy to a root cause.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Ambito
ai, machine-learning, testing
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Attiva
Chiarezza
Abbastanza chiara
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.