A city moves ordinance QA from on-prem DGX to cloud GPUs. What keeps quality deltas attributable to the platform?
Select an answer to reveal the explanation.
Short Explanation
Same exam, two rooms: if you rewrite the ordinance QA prompts on cloud, you cannot blame the score change on the host. Lock prompts and metrics so the delta is about the platform.
Full Explanation
When a city migrates ordinance QA from on-prem DGX to cloud GPUs, the only way to attribute quality deltas to the platform is to hold the evaluation protocol fixed. Identical prompts, scoring rules, exact-match thresholds, and metric definitions on both hosts isolate host, driver, framework, and serving differences as the independent variable. If cloud scores rise after you rewrite prompts to flatter the new environment, the gain is an artifact of the test redesign, not evidence that cloud GPUs are better for municipal ordinance retrieval. Swapping metrics mid-migration to mirror a vendor dashboard likewise breaks longitudinal comparability: you can no longer say whether the ordinance assistant improved or whether you simply changed how success is measured. Disabling exact-match on cloud because latency differs conflates latency SLAs with answer correctness; latency belongs in a separate SLA report, not as an excuse to loosen quality criteria on one side of the A/B. Exam caveat: NCP-GENL expects controlled experiments—change one factor (platform) while freezing prompts and metrics—rather than opportunistic score cosmetics. Operational check: version the eval pack in git, pin prompt templates and metric configs by hash, run the same suite on DGX and cloud, and publish a side-by-side table of quality plus latency so council stakeholders can see which deltas are truly platform-attributable.