Fluency evidence नहीं है

Documentation में dangerous AI error अक्सर grammar नहीं होता। वह plausible लेकिन unsupported statement होता है: default timeout, undocumented parameter, compatibility promise या गलत citation।

जब तक workflow यह न दिखाए कि important facts कहाँ से आए, generated prose को unknown-provenance draft मानें।

Claims को पहले classify करें

Product behavior, numeric limits, commands और configuration को editorial explanation से अलग करें। Facts को code, tests, schemas, approved specifications, release artifacts या named owner तक trace होना चाहिए।

General explanation normal editorial review से गुजर सकती है, लेकिन उसमें नया product promise छिपा नहीं होना चाहिए।

जो execute हो सकता है उसे execute करें

Commands run करें, JSON/YAML validate करें, code samples compile करें और links check करें। APIs के payload contract से validate करें और practical हो तो test environment use करें।

अगर result version या environment पर depend करता है तो उसे record करें।

Uncertainty visible रखें

Sources disagree करें तो publishing रोकें। Model से “most plausible” answer चुनने को न कहें। Owner identify करें और product decision के रूप में resolve करें।

Security, billing, data retention, destructive operations और compatibility में यह खास महत्वपूर्ण है।

Lightweight verification trail रखें

हर paragraph के लिए forensic report जरूरी नहीं। Sources, review metadata और tested examples अक्सर काफी हैं।

AI drafting सस्ता करता है; इसलिए verification और अधिक valuable हो जाती है।

व्यावहारिक उदाहरण

“Fluent mistakes publish होने से पहले AI-assisted documentation fact-check करें” को production workflow बनाने से पहले controlled sample पर जाँचें। दस छोटे documentation fragments लें जिनकी सही स्थिति आपको पहले से पता हो—कुछ सही, कुछ पुराने, कुछ ambiguous और कुछ जानबूझकर गलत। Instructions स्थिर रखें और सही decisions के साथ confident mistakes भी दर्ज करें।

Editor की तरह जाँचें:

  • क्या model evidence और inference अलग करता है;
  • क्या terminology और product constraints बची रहती हैं;
  • क्या missing facts invent होते हैं या uncertainty छिपती है;
  • क्या human reviewer देख सकता है कि क्या बदला और क्यों।

मुख्य प्रश्न fluency नहीं, बल्कि यह है कि workflow publication से पहले errors को visible बनाता है या नहीं। स्पष्ट boundaries, inputs और human review points ही भरोसा बनाते हैं।

त्वरित संपादकीय जाँच

  • Fluency evidence नहीं है. Documentation में dangerous AI error अक्सर grammar नहीं होता। वह plausible लेकिन unsupported statement होता है: default timeout, undocumented parameter, compatibility promise या गलत citation।
  • Claims को पहले classify करें. Product behavior, numeric limits, commands और configuration को editorial explanation से अलग करें। Facts को code, tests, schemas, approved specifications, release artifacts या named owner तक trace होना चाहिए।
  • जो execute हो सकता है उसे execute करें. Commands run करें, JSON/YAML validate करें, code samples compile करें और links check करें। APIs के payload contract से validate करें और practical हो तो test environment use करें।
  • Uncertainty visible रखें. Sources disagree करें तो publishing रोकें। Model से “most plausible” answer चुनने को न कहें। Owner identify करें और product decision के रूप में resolve करें।

संबंधित सामग्री