AI ایجنٹوں کو ان کے اپنے ٹیسٹ جعلی بنانے سے کیسے روکا جائے۔

جیسا کہ تصدیق کی گئی ہے، میں نے ہیلوسینیشن ترمیم پر دستخط کیے ہیں۔ اب جب کہ ہمارے پاس 5 میں سے 0 ہیرا پھیری والے جوابات ہیں، کلین اپ رن مکمل ہو گیا ہے۔

اس کے بعد انہوں نے اسے مزید مشکل حالات میں دوبارہ چلایا اور 66.7 فیصد حاصل کیا۔ جس نمبر پر میں نے کافی بھروسہ کیا کہ اس کے آگے "HUMAN-VERIFIED” لکھنا غلط تھا۔ یہ اس لیے نہیں کہ اس نے جھوٹ بولا، بلکہ اس لیے کہ ایک صاف رن اور ‘تصدیق’ ایک ہی چیز نہیں ہیں۔ میں نے ایک ٹول بھی بنایا ہے جو اس فرق کو پھسلنے سے انکار کرتا ہے، اور تقریباً اسے بہرحال پھسلنے دیتا ہے۔

یہ اپنے آپ میں ایک قابل ستم ظریفی ہے۔

ٹول تصریح کی تصدیق ہے۔ یہ ایک کلاڈ کوڈ تکنیک ہے جو دیے گئے/کب/اگلے قبولیت کے معیار کے مطابق لکھنے والوں کو ٹیسٹوں میں بدل دیتی ہے جو یہ چیک کرتی ہے کہ آیا انہوں نے اسے پہلے ہی بنایا ہے اور اس کا تجربہ کیا ہے۔

یہ ٹیوٹوریل آپ کو دکھاتا ہے کہ spec-verify کو کیسے انسٹال کیا جائے، اسے اصلی کوڈ کے خلاف کیسے چلایا جائے، اور اسے پکڑنے کے لیے بنائے گئے دو فیل موڈز کو کیسے پڑھیں۔ وہ متضاد ہیں، اور ان کے ساتھ ایک جیسا سلوک کرنا پہلی جگہ اس کی تعمیر کے نقطہ کو شکست دیتا ہے۔

انڈیکس

مسئلہ کی وضاحت کرنے والا مصنف حل کرنے میں ناکام رہا۔
ٹریپ: خالی ٹیسٹ
میوٹیشن کی تصدیق کے ٹیسٹ تیار کریں۔
حقیقی کیس
VACUOUS اور UNVALIDATABLE متغیرات نہیں بلکہ متضاد ہیں۔
ساختی جانچیں سچائی کی جانچ نہیں ہیں۔
وضاحتیں چیک کریں تنصیب کا طریقہ
ثبوت خود چلائیں۔
اسے اپنی تصریحات کے مطابق کیسے استعمال کریں۔
جہاں یہ تریی چھوڑ دیتا ہے۔

مسئلہ کی وضاحت کرنے والا مصنف حل کرنے میں ناکام رہا۔

اسپیک رائٹر ایک کلاڈ کوڈ تکنیک ہے جو مبہم خصوصیت کی درخواستوں کو ساختی وضاحتوں میں بدل دیتی ہے اور رہنمائی کے بغیر کیے گئے کسی بھی فیصلے کو جھنڈا دیتی ہے۔ [ASSUMPTION: ...]. اگر آپ سیشن کیپچر فیچر کے لیے 12 الفاظ کی درخواست ٹائپ کرتے ہیں، تو یہ ہے جو آپ دیکھیں گے:

3. Session ID from .jsonl filename is the deduplication key
   Impact: MEDIUM
   Correct this if: session IDs are stored differently in your schema

یہ 12 الفاظ کے پرامپٹ میں چھپا اصل فیصلہ ہے۔ اگر آپ کسی سیشن کی فائل کے نام سے شناخت کرتے ہیں، تو ایک ہی سیشن کی دو کاپیاں اس وقت دو مختلف سیشنز کی طرح نظر آئیں گی جب ان کا نام تبدیل کیا جائے گا۔ (خصوصی مصنفین اس مفروضے پر کیسے پہنچتے ہیں اس کی پوری مشق یہ ہے کہ AI ایجنٹوں کو ضروریات کا اندازہ لگانے سے کیسے روکا جائے۔)

اسپیک رائٹر کی پوری قدر یہ ہے کہ کوڈ لکھے جانے سے پہلے ان مفروضوں کو پکڑ لیا جائے۔ لیکن کہتے ہیں کہ آپ اسے پکڑیں گے اور اسے ٹھیک کریں گے۔ ایجنٹ سے کہو، "نہیں، مواد کو ہیش کریں، فائل کا نام نہیں۔” ایجنٹ اصلاح کرتا ہے۔ ہم ٹیسٹ بھی لکھتے ہیں کیونکہ یہ وہ چیز ہے جس کے لیے صارف نے پوچھا ہے یا ایجنٹ فی الحال کچھ کر رہا ہے۔

یہ وہ حصہ ہے جو کسی بھی چیز کی جانچ نہیں کرتا ہے: کیا وہ ٹیسٹ حقیقت میں درست کی تصدیق کرتے ہیں؟ یا کیا میں صرف ڈیڈ اپ فنکشن کو کال کرتا ہوں، ایک فہرست حاصل کرتا ہوں، اس بات پر زور دیتا ہوں کہ فہرست ایک فہرست ہے، اور پاس کرتا ہوں، قطع نظر اس کے کہ بنیادی بگ اب بھی موجود ہے؟

دیا گیا/جب/اگلا وہ نثر ہے جسے انسان پڑھتے ہیں۔ یہ مشین سے چلنے والا ٹیسٹ نہیں ہے۔ دونوں کے درمیان فرق یہ ہے کہ ترمیم شدہ مفروضہ خاموشی سے ایک حقیقی بگ کی طرف لوٹ جاتا ہے اور جب تک سیشن کا نام پروڈکشن میں تبدیل نہیں ہوتا کوئی بھی اس پر توجہ نہیں دیتا ہے۔

ٹریپ: خالی ٹیسٹ

اس کا واضح حل یہ ہے کہ ایجنٹ ہر ایک Give/When/Then بلاک میں ایک ٹیسٹ تیار کرے۔ بہت سے اوزار صرف یہ کرتے ہیں. ٹریپ یہ ہے کہ "ایک ایجنٹ نے ایک ٹیسٹ لکھا” اور "ایک ایجنٹ نے ایک ٹیسٹ لکھا جس کا مطلب ہے کچھ” ایک ہی دعوی نہیں ہیں۔ بدقسمتی سے، LLM پیدا کرنے والے ٹیسٹ پہلے ٹیسٹ میں آپ کی توقع سے زیادہ کثرت سے کم ہو جاتے ہیں۔ یعنی، ایک ٹیسٹ جو چلتا ہے اس سے قطع نظر کہ کوڈ اصل میں کیا کرتا ہے، ایک معمولی حقیقت پر زور دیتا ہے، اور پاس ہو جاتا ہے۔ ایسا لگتا تھا کہ اس کی کوریج اچھی ہے۔ ایک سبز نشان نشان سرخ نشان سے کوئی فرق نہیں ظاہر کرتا ہے۔ کیونکہ دونوں میں سے کوئی بھی ممکن نہیں تھا۔

سب سے بری بات یہ ہے کہ یہ ٹیسٹ صرف اصل بگ کو پکڑنے میں ناکام نہیں ہوتے۔ حفاظتی رویے کے ایک سیکنڈ، غیر متعلقہ وجہ سے بند ہونے کے بعد بھی وہ گزرتے رہتے ہیں۔ کسی چیز کی تصدیق نہیں ہوتی۔ ٹیسٹ بالکل سویٹ میں ہر دوسرے پاس ہونے والے ٹیسٹ کی طرح لگتا ہے۔

لہذا ترمیم "جنریٹ ٹیسٹ” پر نہیں رک سکتی۔ یہ تعین کرنا ضروری ہے کہ آیا ٹیسٹ یہ ظاہر کر سکتا ہے کہ آیا یہ جس چیز کی حفاظت کر رہا ہے وہ درحقیقت ٹوٹ گیا ہے۔

میوٹیشن کی تصدیق کے ٹیسٹ تیار کریں۔

ہر Give/When/پھر بلاک کے لیے، spec-verify چار چیزیں کرتا ہے:

ایک ٹیسٹ بنائیں۔ کہ Then ایک شق واپسی کی قیمت، حالت، یا ضمنی اثر کے بارے میں ایک مخصوص دعویٰ ہو سکتی ہے۔ آپ کبھی بھی "پھینکے بغیر نہیں بھاگتے”۔
ایک ھدف شدہ تغیر پیدا کریں۔ یہ ایک عام اتپریورتن ٹیسٹ نہیں ہے، بلکہ ایک واحد، جان بوجھ کر، مخصوص رکاوٹ کو معیار کے ایک جوڑے کے ذریعہ مطلع کیا گیا ہے۔ [ASSUMPTION: ...] ٹیگ اگر کوئی مفروضہ کسی خطرے کا نام دیتا ہے، تو تبدیلی بالکل اسی خطرے کو دوبارہ پیش کرتی ہے۔
تغیرات کے لیے ٹیسٹ چلائیں۔ اگر یہ اب بھی گزر جاتا ہے، تو ٹیسٹ اصل میں اس بات کی تصدیق نہیں کرتا ہے کہ یہ کیا دعویٰ کرتا ہے۔ یہ ایک خالی ٹیسٹ ہے اور اسے ناقابل اعتبار کے طور پر نشان زد کیا گیا ہے۔
ناکامی کی آخری تاریخ: اس طرح، وہ معیار جو ٹیسٹ کو ناقابل تصدیق بناتے ہیں خاموشی سے جائزہ لینے کے بجائے اسے نام اور وجہ کے ساتھ "ہونے” سے روک دیں گے۔

حقیقی کیس

اوپر دی گئی اسپیک بلڈر کی مثال سے صحیح مفروضے لیں۔ یعنی ڈپلیکیشن کلید فائل کے مواد کی بجائے فائل کے نام سے اخذ کی گئی ہے۔ صحیح امتحان ہے:

def test_dedup_sessions_runs(tmp_path):
    result = dedup.dedup_sessions([str(f)])
    assert result is not None

آپ فنکشن کو کال کریں، فہرست واپس حاصل کریں، اور اسے پاس کریں۔ اسے اگلے ورژن کے لیے بھی دیا جائے گا۔ dedup_sessions میں نے فائل کا نام کلید کے بطور استعمال کیا کیونکہ یہ چیک نہیں کرتا ہے (میرے مفروضے میں دکھایا گیا عین بگ)۔ کوئی بھی سیشن نقل سے بچ گیا، لیکن کچھ دوبارہ ظاہر ہوا۔

یہ ہے جو واقعی معیار کو چیک کرتا ہے:

def test_renamed_session_still_deduped(tmp_path):
    original = tmp_path / "session_abc123.jsonl"
    original.write_bytes(content)
    renamed = tmp_path / "session_abc123_renamed_by_sync_tool.jsonl"
    renamed.write_bytes(content)  # same content, different name

    result = dedup.dedup_sessions([str(original), str(renamed)])

    assert result == [str(original)]

درست نفاذ کے لیے دونوں کو چلائیں، اور پھر ان کو اتپریورتن کے لیے چلائیں جہاں ڈپلیکیشن کلید کو فائل کے نام میں واپس تبدیل کیا جاتا ہے (درست طریقے سے درست مفروضہ، واپس کیا گیا)۔

test                             baseline   mutant     verdict
test_dedup_verified.py           pass       FAIL       VERIFIED
test_dedup_vacuous.py            pass       pass       VACUOUS

PROOF PASSED: mutation check correctly told VERIFIED from VACUOUS.

جس لمحے بگ دوبارہ ظاہر ہوتا ہے، ایک ٹیسٹ ناکام ہوجاتا ہے۔ کوئی اور نہیں دیکھتا کہ کچھ نہیں ہوا ہے۔ اس سے پہلے کہ ہم قریب سے دیکھیں یہ وہی معیار ہے جو سبز چیک مارک کا ہے۔ تاہم، یہ تحفظ کی ایک بالکل مختلف سطح ہے۔

`VACUOUS` اور `UNVALIDATABLE` یہ میوٹیشن نہیں ہے، یہ اس کے برعکس ہے۔

اتپریورتنوں کے لئے تمام معیارات کی جانچ نہیں کی جاسکتی ہے۔ جب اس آرٹیکل کے اوپر ذکر کیا گیا فکس (ایک ہستی پر مبنی اصول جو ماڈل کو کسی دوسرے فراہم کنندہ کے نام کے ساتھ ادائیگی فراہم کرنے والے سے دستاویزات میں ہیرا پھیری نہ کرنے کا بتاتا ہے) پہلے جاری کیا گیا تھا، یہ مکمل طور پر سسٹم پرامپٹ میں تھا۔ ایل ایل ایم کے لیے سادہ زبان کی رہنمائی۔ کال کرنے اور دعوی کرنے کے لئے کوئی فنکشن حدود نہیں ہیں۔ معلوم کرنے کا واحد طریقہ یہ ہے کہ ماڈل ٹرک کے سوالات پوچھیں اور پڑھیں کہ یہ کیا کہتا ہے۔ میوٹیشن ٹیسٹنگ ہمیں وہاں تک نہیں پہنچائے گی۔

تفصیلات کی توثیق اس کو کہتے ہیں: UNVALIDATABLEاور یہ ایک خالی امتحان کی طرح علاج کرنے کے لئے پرکشش ہے. دوسرے الفاظ میں، یہ اتنا اچھا نہیں ہے کہ فکسنگ کی ضرورت ہو۔ یہ سچ نہیں ہے۔ خالی ٹیسٹ ایک عیب ہے۔ ٹیسٹ خراب ہیں اور اصلاحات ہمیشہ ایک جیسی ہوتی ہیں۔ بہتر ٹیسٹ لکھیں۔ UNVALIDATABLE مطلب معیاری عام طور پر ایسا نہیں ہوتا ہے کہ کسی نے کچھ غلط کیا ہے، لیکن یہ کہ رویہ غیر فیصلہ کن ہے اور اس وجہ سے یہ تکنیک بالکل طے کر سکتی ہے۔

ان کے ساتھ یکساں سلوک کرنے سے دو میں سے ایک برے نتائج برآمد ہوں گے۔ یا تو آپ خالی ٹیسٹوں کو روک دیتے ہیں کیونکہ "کچھ چیزیں ناقابل برداشت ہیں” (آپ کر سکتے تھے، لیکن یہ ٹیسٹ نہیں لکھے گئے تھے)، یا آپ ہمیشہ کے لیے غیر متعین اشیاء کو روک دیتے ہیں، جو اکثر حقیقی کوڈ بیس میں ہوتا ہے۔ نہ ہی درست ہے۔

تو گیٹ کے دو راستے ہیں۔

VACUOUS اور BROKEN-TEST: کبھی ہمت نہ ہاریں۔ ناقص امتحان پاس کرنے کا واحد طریقہ بہتر امتحان ہے۔
UNVALIDATABLE: ہٹانا صرف ریکارڈ والے شخص کی واضح منظوری کے ساتھ ہوتا ہے، اس بات کی تحریری وضاحت کہ اس شخص نے حقیقت میں اس کی تصدیق کیسے کی۔

آئیے دوبارہ افتتاح کی طرف آتے ہیں۔ میں نے ہستی پر مبنی معیار پر غلطیوں کا حوالہ دیتے ہوئے ایک نوٹ کے ساتھ دستخط کیا (5 میں سے 0 ہیرا پھیری والے جوابات)۔ نوٹ نے spec-verify کے ساختی چیک کو پاس کیا ہے۔ یہ خالی یا ایک لفظی مہر نہیں ہے، اور اصل طریقہ کا نام ہے۔

یہ ایک پرامید سنگل رن بھی نکلا۔ مقررہ بیجوں کے بغیر مقررہ درجہ حرارت پر آزادانہ دوبارہ جانچ کے نتیجے میں 100% کی بجائے 66.7% کی مکمل کمی واقع ہوئی۔ کچھ فراہم کنندگان کے جوڑوں نے تقریباً ایک جیسے ٹکڑوں کی تلاش کی اور پہلے رن کی تجویز سے زیادہ کثرت سے اپنے چیک کو بیوقوف بنایا۔

ایک ایماندارانہ اصلاح بہتر کی منظوری نہیں تھی۔ یہ اس کا متبادل تھا جسے منظور کیا گیا تھا۔ معلوم مسئلہ کے معاملات کے لیے ڈیٹرمنسٹک کوڈ لیول گیٹس کو معمول کے مطابق جانچا جا سکتا ہے، باقی ہر چیز کی فوری بنیاد پر جانچ کے ساتھ۔ UNVALIDATABLE یہ کوئی مستقل شرط نہیں ہے۔ یہ اس بات کی علامت ہے کہ کسی چیز کو انسانوں کی ضرورت ہے، یا مثالی طور پر، کوئی انسان نہیں ہے۔

ساختی جانچیں سچائی کی جانچ نہیں ہیں۔

یہ ویکیوم ٹیسٹنگ کے عین مطابق مسئلہ کا ایک معتدل ورژن ہے۔ HUMAN-VERIFIED آپ اتنے ہی ایماندار ہوسکتے ہیں جیسے میں تھا اور اب بھی غلط ہوں۔ منظوری کے نوٹوں پر spec-verify کے سٹرکچرڈ چیکس (خالی نوٹوں کو مسترد کرنا، کسی جملے سے مماثل متن کے نیچے موجود ہر چیز کو مسترد کرنا، بنیادی نحوی بلاک لسٹ جیسے "looksfine” یا "lgtm” کو مسترد کرنا) اس بات کی تصدیق نہیں کر سکتے کہ انسان نے حقیقت میں وہی کیا جو اس نے دعویٰ کیا تھا۔ یہ صرف سست ترین ربڑ سٹیمپ کی قیمت میں اضافہ کرے گا۔ ایک پرعزم شخص اب بھی جعلی کہانیاں شامل کرسکتا ہے۔

ٹیم کی ترتیبات کے لیے، ایک زیادہ طاقتور ورژن ہے۔ JSON فائلوں میں مفت ٹیکسٹ فیلڈز پر بھروسہ کرنے کے بجائے، چیک کریں کہ کس نے دستخط کیے اور کب انہوں نے گٹ کمٹ کے اصل مصنف اور ٹائم اسٹیمپ سے دستخط کیے ہیں۔ ایک من گھڑت منظوری کے لیے کسی کی حقیقی شناخت پر مبنی حقیقی عزم کی ضرورت ہوتی ہے۔ اس کا مطلب یہ ہے کہ آپ کی ترامیم آپ کی سرگزشت میں دکھائی دیں گی نہ کہ ان فائلوں میں جنہیں کوئی نہیں دیکھ رہا ہے۔ سولو پروجیکٹ کے لیے، یہ ضرورت سے زیادہ ہے۔ یہ اس وقت درست فیصلہ ہے جب بہت سے لوگوں کے پاس آپ کو دھوکہ دینے کی وجہ ہو سکتی ہے۔

وضاحتیں چیک کریں تنصیب کا طریقہ

spec-writer کی طرح، spec-verify کلاڈ کوڈ تکنیک ہے۔ یہاں مارک ڈاون فائلیں اور چند قابل عمل مثال ڈائریکٹریز ہیں، انسٹال کرنے کے لیے کوئی پیکجز نہیں، اور کوئی API کیز نہیں ہیں۔

mkdir -p ~/.claude/skills/spec-verify
git clone https://github.com/dannwaneri/spec-verify.git ~/.claude/skills/spec-verify

ونڈوز پاور شیل میں:

New-Item -ItemType Directory -Force -Path "$HOME\.claude\skills"
git clone https://github.com/dannwaneri/spec-verify.git "$HOME\.claude\skills\spec-verify"

ثبوت خود چلائیں۔

مت لو VERIFIED/VACUOUS عقائد کی مندرجہ بالا جدول: ذخیرہ اس مضمون میں قابل عمل کوڈ کے طور پر دونوں مثالیں فراہم کرتا ہے۔

cd ~/.claude/skills/spec-verify/example
python run_proof.py

یہ درست طریقے سے ڈپلیکیشن ٹیبل کو دوبارہ تیار کرتا ہے۔ مضبوط منظوری کی پرت:

cd git_attributed_signoff
python build_demo_repo.py
python check_signoff.py demo_repo entity_grounding
python tamper_demo.py

tamper_demo.py یہ صرف پڑھنے کے قابل نہیں ہے، بلکہ خود کرنا ہے۔ ارتکاب کیے بغیر، ورک ٹری میں منظوری کے نوٹ میں ترمیم کریں اور پھر دوبارہ چیک کریں۔ چھیڑچھاڑ شدہ نوٹ کو پڑھنے سے پہلے، اسکین فائل پر بالکل بھروسہ نہیں کرے گا کیونکہ کام کرنے والا درخت اب کمٹ سے میل نہیں کھاتا۔

اسے اپنی تصریحات کے مطابق کیسے استعمال کریں۔

ایک بار انسٹال ہونے کے بعد، اس کو ان فنکشنز کو لاگو کرنے کے بعد کال کریں جو سپیک رائٹر کو پاس کر چکے ہیں، لیکن ٹاسک کو مکمل کرنے سے پہلے کال کریں۔ مجھے اسپیک بلڈر آؤٹ پٹ کی ضرورت ہے (دیئے گئے/جب/پھر بلاکس اور متعلقہ بلاکس)۔ [ASSUMPTION: ...] ٹیگ) اور اسے چیک کرنے کے لیے عمل درآمد۔ یہ تصدیق کے لیے قبولیت کا معیار نہیں بناتا ہے۔ اگر آپ کے پاس اسپیک رائٹر آؤٹ پٹ سے منسلک کرنے کے لیے نہیں ہے، تو آپ کچھ نہیں کر سکتے۔

رپورٹ کو اس طرح پڑھیں جس طرح آپ مخصوص مصنف کے مفروضوں کا خلاصہ پڑھیں گے۔ VERIFIED پہلے VACUOUS یا BROKEN-TEST اس کا مطلب ہے جاؤ اور ٹیسٹ ٹھیک کرو۔ شپنگ کے لیے موزوں کوئی نتیجہ خیز ورژن نہیں ہیں۔ UNVALIDATABLE اس کا مطلب یہ ہے کہ انسان اسے براہ راست چیک کرے اور ریکارڈ پر ایسا کہے، یا واضح طور پر یہ فیصلہ کرے کہ آیا پہلے سے طے شدہ رویے کو ایسی جگہ منتقل کرنے کی ضرورت ہے جہاں یہ قابل آزمائش ہو، جیسا کہ ہستی پر مبنی ترمیم نے بالآخر کیا تھا۔

جہاں یہ تریی چھوڑ دیتا ہے۔

اسپیک رائٹر غلط وجوہات کی بنا پر بنائی گئی خصوصیات کو پکڑتا ہے۔ spec-verify ایسے ٹیسٹ کیچ کرتا ہے جن کے بارے میں آپ جانتے ہیں لیکن نہیں۔ دونوں کے درمیان: مفروضے دکھائے جاتے ہیں، کوڈ کو جاری ہونے سے پہلے طے کر لیا جاتا ہے، اور آپ کے پاس ایسے ٹیسٹ ہوتے ہیں جو درحقیقت ناکام ہو جائیں گے اگر کوئی جس نے اصل قیاس کو نہیں پڑھا وہ اب سے چھ ماہ بعد فکس کو کالعدم کر دیتا ہے۔

اس میں سے کوئی بھی فیصلے کا متبادل نہیں ہے۔ یہاں تک کہ اگر آپ کی قیاس آرائی اچھی طرح سے ہے، تب بھی آپ اس بارے میں غلط ہو سکتے ہیں کہ کیا بنانا ہے۔ اعترافات ایماندارانہ ہو سکتے ہیں، لیکن ہو سکتا ہے کہ آپ پھر بھی ایسے مواد سے محروم رہ جائیں جو زیادہ مشکل دوبارہ ٹیسٹ کے ذریعے دریافت کیا جا سکتا ہے۔ دونوں ٹولز جو کچھ کرتے ہیں وہ جان بوجھ کر "کیسا لگتا ہے” اور "ہو گیا” کے درمیان فرق کو چھوڑ دیتے ہیں اور اس کی وجوہات لکھتے ہیں، نہ کہ صرف اس وجہ سے کہ آپ نے کچھ چیک نہیں کیا ہے۔

spec-verify ذخیرہ github.com/dannwaneri/spec-verify پر ہے۔ اسے مکمل کے طور پر نشان زد کرنے سے پہلے، مندرجہ ذیل خصوصیات کو آزمائیں جو اسپیک رائٹر تخلیق کرتا ہے: اگر وہاں ٹیسٹنگ خالی ہے، تو آپ میوٹیشن میں تلاش کرنا چاہیں گے، پروڈکشن میں نہیں۔