Skip to content
← Back to explorer

DQA: Diagnostic Question Answering for IT Support

Vishaal Kapoor, Mariam Dundua, Sarthak Ahuja, Neda Kordjazi, Evren Yortucboylu, Vaibhavi Padala, Derek Ho, Jennifer Whitted, Rebecca Steinert · Apr 7, 2026 · Citations: 0

How to use this paper page

Coverage: Recent

Use this page to decide whether the paper is strong enough to influence an eval design. It summarizes the abstract plus available structured metadata. If the signal is thin, use it as background context and compare it against stronger hub pages before making protocol choices.

Best use

Background context only

Metadata: Recent

Trust level

Provisional

Signals: Recent

What still needs checking

Structured extraction is still processing; current fields are metadata-first.

Signal confidence unavailable

Abstract

Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause. While retrieval-augmented generation (RAG) provides grounding through historical cases, standard multi-turn RAG systems lack explicit diagnostic state and therefore struggle to accumulate evidence and resolve competing hypotheses across turns. We introduce DQA, a diagnostic question-answering framework that maintains persistent diagnostic state and aggregates retrieved cases at the level of root causes rather than individual documents. DQA combines conversational query rewriting, retrieval aggregation, and state-conditioned response generation to support systematic troubleshooting under enterprise latency and context constraints. We evaluate DQA on 150 anonymized enterprise IT support scenarios using a replay-based protocol. Averaged over three independent runs, DQA achieves a 78.7% success rate under a trajectory-level success criterion, compared to 41.3% for a multi-turn RAG baseline, while reducing average turns from 8.4 to 3.9.

Use caution before copying this protocol

Use this page for context, then validate protocol choices against stronger HFEPX references before implementation decisions.

  • Structured extraction is still processing; current fields are metadata-first.

HFEPX Relevance Assessment

Signal extraction is still processing. This page currently shows metadata-first guidance until structured protocol fields are ready.

Best use

Background context only

Use if you need

A provisional background reference while structured extraction finishes.

Main weakness

Structured extraction is still processing; current fields are metadata-first.

Trust level

Provisional

Eval-Fit Score

Unavailable

Eval-fit score is unavailable until extraction completes.

Human Feedback Signal

Not explicit in abstract metadata

Evaluation Signal

Weak / implicit signal

HFEPX Fit

Provisional (processing)

Extraction confidence: Provisional

What This Page Found In The Paper

Each field below shows whether the signal looked explicit, partial, or missing in the available metadata. Use this to judge what is safe to trust directly and what still needs full-paper validation.

Human Feedback Types

provisional

None explicit

Confidence: Provisional Best-effort inference

No explicit feedback protocol extracted.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Evaluation Modes

provisional

None explicit

Confidence: Provisional Best-effort inference

Validate eval design from full paper text.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Quality Controls

provisional

Not reported

Confidence: Provisional Best-effort inference

No explicit QC controls found.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Benchmarks / Datasets

provisional

Not extracted

Confidence: Provisional Best-effort inference

No benchmark anchors detected.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Reported Metrics

provisional

Not extracted

Confidence: Provisional Best-effort inference

No metric anchors detected.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Rater Population

provisional

Unknown

Confidence: Provisional Best-effort inference

Rater source not explicitly reported.

Evidence snippet: Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Human Data Lens

This page is using abstract-level cues only right now. Treat the signals below as provisional.

  • Potential human-data signal: No explicit human-data keywords detected.
  • Potential benchmark anchors: No benchmark names detected in abstract.
  • Abstract highlights: 3 key sentence(s) extracted below.

Evaluation Lens

Evaluation fields are inferred from the abstract only.

  • Potential evaluation modes: No explicit eval keywords detected.
  • Potential metric signals: No metric keywords detected.
  • Confidence: Provisional (metadata-only fallback).

Research Brief

Metadata summary

Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.

Based on abstract + metadata only. Check the source paper before making high-confidence protocol decisions.

Key Takeaways

  • Enterprise IT support interactions are fundamentally diagnostic: effective resolution requires iterative evidence gathering from ambiguous user reports to identify an underlying root cause.
  • While retrieval-augmented generation (RAG) provides grounding through historical cases, standard multi-turn RAG systems lack explicit diagnostic state and therefore struggle to accumulate evidence and resolve competing hypotheses across turns.
  • We introduce DQA, a diagnostic question-answering framework that maintains persistent diagnostic state and aggregates retrieved cases at the level of root causes rather than individual documents.

Researcher Actions

  • Compare this paper against nearby papers in the same arXiv category before using it for protocol decisions.
  • Check the full text for explicit evaluation design choices (raters, protocol, and metrics).
  • Use related-paper links to find stronger protocol-specific references.

Caveats

  • Generated from abstract + metadata only; no PDF parsing.
  • Signals below are heuristic and may miss details reported outside the abstract.

Recommended Queries

Related Papers

Papers are ranked by protocol overlap, extraction signal alignment, and semantic proximity.

No related papers found for this item yet.

Get Started

Join the #1 Platform for AI Training Talent

Where top AI builders and expert AI Trainers connect to build the future of AI.
Self-Service
Post a Job
Post your project and get a shortlist of qualified AI Trainers and Data Labelers. Hire and manage your team in the tools you already use.
Managed Service
For Large Projects
Done-for-You
We recruit, onboard, and manage a dedicated team inside your tools. End-to-end operations for large or complex projects.
For Freelancers
Join as an AI Trainer
Find AI training and data labeling projects across platforms, all in one place. One profile, one application process, more opportunities.