تعیناتی simulate کر کے release سے پہلے ماڈل کے behavior کی پیش گوئی
Release سے پہلے undesired ماڈل behavior کا بہتر اندازہ لگانے کے لیے realistic conversation contexts کا استعمال.
نیا ماڈل جاری کرنے سے پہلے، labs کو صرف یہ نہیں سمجھنا ہوتا کہ وہ کیا کر سکتا ہے، بلکہ یہ بھی کہ حقیقی دنیا کے استعمال میں اس کا رویہ کیسا ہونے کا امکان ہے، بشمول یہ کہ وہ کہاں نئے خطرات پیدا کر سکتا ہے. صلاحیتیں بڑھنے کے ساتھ یہ اور بھی اہم ہو جاتا ہے. تعیناتی سے پہلے اپنے حفاظتی جائزے کے حصے کے طور پر، ہم ماڈل کے رویے کو سمجھنے کے لیے targeted evaluations، red-teaming، اور دیگر checks استعمال کرتے ہیں. ہم نے اب ماڈل deployments کو ان کے ہونے سے پہلے simulate کرنے کا ایک طریقہ استعمال کرنا شروع کیا ہے، جو ایک تکمیلی signal شامل کرتا ہے: candidate ماڈل کے users تک پہنچنے سے پہلے اس کے ممکنہ رویے کا deployment-like preview.
تعیناتی سمولیشن ایک future deployment کو اس کے ہونے سے پہلے simulate کرنے کا طریقہ ہے. ہم ایسا پچھلی conversations کو privacy-preserving انداز میں نئے candidate ماڈل کے ساتھ دوبارہ چلا کر کرتے ہیں. اس سے ہمیں release سے پہلے realistic contexts میں یہ مطالعہ کرنے میں مدد ملتی ہے کہ نیا ماڈل کیسے جواب دیتا ہے، بشمول یہ کہ آیا نئے undesired behaviors سامنے آتے ہیں اور وہ کتنی بار ظاہر ہو سکتے ہیں.
GPT‑5‑series Thinking کی متعدد deployments میں، تعیناتی سمولیشن نے undesired ماڈل behavior rates کے ہمارے اندازوں کو بہتر کیا، release سے پہلے misalignment کی نئی شکلیں سامنے لانے میں مدد دی، اور یہ خطرہ کم کرنے میں مدد کی کہ ماڈلز جان سکیں کہ ان کا test ہو رہا ہے. ہم نے یہ طریقہ challenging agentic rollouts پر بھی لاگو کیا، جس سے ظاہر ہوا کہ یہ standard chat سے آگے tool use والے زیادہ complex agent settings تک پھیل سکتا ہے، اور internal ماڈل deployments سے پہلے risk assessment کے لیے بھی استعمال ہو سکتا ہے.
ہم پہلے ہی ماڈل development کے دوران تعیناتی سمولیشن سے حاصل insights کو traditional evaluations میں blind spots شناخت کرنے اور mitigations و deployment decisions سے آگاہ کرنے کے لیے استعمال کر چکے ہیں. جیسے جیسے ہم pipeline کو چلانا آسان بنائیں گے، ہمیں توقع ہے کہ یہ مستقبل کے ماڈل development process میں بڑا کردار ادا کرے گی.
صنعت بھر میں استعمال ہونے والی pre-deployment evaluations عموماً synthetic، manually written، یا production prompts کے mix پر مشتمل ہوتی ہیں جنہیں جان بوجھ کر difficult، high severity، یا adversarial ہونے کے لیے منتخب کیا جاتا ہے. ان evaluations کے عموماً دو باہم جڑے goals رہے ہیں: یہ assess کرنا کہ stress-tested situations میں ماڈل کیسے respond کرتا ہے جن کے deployment traffic میں واقع ہونے کا امکان بہت کم ہوتا ہے، اور undesired ماڈل behaviors کی عمومی سمجھ حاصل کرنا، بشمول نئے undesired behaviors ڈھونڈنا اور deployment-time frequencies کی پیش گوئی کرنا.
اگرچہ traditional evaluations پہلے goal کے لیے crucial رہتی ہیں، تعیناتی سمولیشن دوسرے goal کے حوالے سے non-tail risks کے لیے ایک اہم پیش رفت ہے (ہمارے experiments میں، ہمارے approach سے ایسے behaviors ناپنے کی توقع نہیں کی جا سکتی جو 200,000 messages میں 1 سے کم frequency سے ہوتے ہیں). تعیناتی سمولیشن کی طاقت traditional evaluations کے کچھ بنیادی challenges سے بچنے سے آتی ہے:
- Coverage: یہ اعتماد کرنا مشکل ہے کہ evaluation prompts undesired ماڈل behavior کی تمام ممکنہ types کو cover کریں گے. ناپسندیدہ رویّوں کی نئی اقسام کا جائزہ لینے کے لیے نئے جائزاتی معیار (Evaluations) تیار کرنا اور یہ جاننا ضروری ہوتا ہے کہ کن نقصانات یا منفی اثرات کی پیمائش کی جائے۔ اور وقت گزرنے کے ساتھ یہ جائزاتی معیار (Evaluations) اپنی افادیت یا حساسیت کھو سکتے ہیں۔
- Selection biases روایتی جائزے عموماً specific undesired ماڈل behaviors کو ذہن میں رکھ کر بنائی جاتی ہیں، ایسے طریقوں سے selected جو پہلے واقع ہو چکے contexts کی طرف bias کرتے ہیں. اس سے deployment distribution کی پوری وسعت میں ایسے behaviors کی incidence کے بارے میں ان کے estimates کم informative ہو سکتے ہیں.
- ماڈلز کے لیے tests کے طور پر پہچانے جانا: ماڈلز بڑھتے ہوئے یہ determine کرنے کے قابل ہوئے ہیں کہ ان کا test ہو رہا ہے، جو ان کے behaviorد اور safety کی ہماری downstream measurements کو distort کر سکتا ہے. اگرچہ OpenAI میں استعمال ہونے والی بہت سی traditional evaluations بھی production traffic سے لی جاتی ہیں اور اس issue کا شکار نہیں ہوتیں، مگر صنعت بھر میں استعمال ہونے والی بہت سی traditional evaluations کے لیے یہ ایک common concern ہے.
تعیناتی سمولیشن کے پیچھے main technique سادہ ہے: ہم deployment سے recent conversations لیتے ہیں، older ماڈل کا original assistant response ہٹاتے ہیں، اور اسے release کیے جانے والے candidate ماڈل سے regenerate کرتے ہیں. ہم completions کو نئے failure modes تلاش کر کے evaluate کرتے ہیں، اور اس deployment-like distribution میں frequency کی بنیاد پر deployment-time undesired behavior frequency کا estimate لگاتے ہیں. ہم release کے بعد real deployment traffic پر یہی measurements انجام دے سکتے ہیں، جس سے ہمیں اپنی pre-deployment forecasts validate کرنے میں مدد ملتی ہے.
تعیناتی سمولیشن اوپر درج تین limitations کو نمایاں طور پر mitigate کرتی ہے: sampling bias کو recent usage کی نمائندہ evaluation prompts کی distribution استعمال کر کے address کیا جاتا ہے. Representative prompts کے ساتھ تعیناتی سمولیشن coverage کے concerns کو بھی mitigate کر سکتی ہے: ہم simply زیادہ traffic simulate کر کے undesirable ماڈل behaviors کی greater coverage حاصل کرتے ہیں. Compute اور coverage کے درمیان یہ tradeoff اہم ہے، کیونکہ یہ risk assessment کے اس axis کی quality کو زیادہ evaluations بنانے کے لیے درکار manual effort کے بجائے compute کے ساتھ scale کرتا ہے. ماڈلز بھی deployment simulation کے ذریعے حاصل conversations اور real deployment traffic میں فرق کرنے کے قابل نظر نہیں آتے.
شکل 1: ہماری تعیناتی سمولیشن pipeline کا overview
علاقہ | روایتی تشخیص | تعیناتی سمولیشن |
کوریج | کم پھیلاؤ لیکن زیادہ شدت کے خطرات کے لیے بہتر ہے کہ ہم یہ یقینی بنانا چاہتے ہیں کہ ہمارے پاس کوریج ہے۔ | خطرات کے اسپیکٹرم کو سمجھنے کے لیے بہتر ہے جو ہم تعیناتی ٹریفک میں دیکھ سکتے ہیں۔ |
نمائندگی/تعصب | ھدف بنائے گئے ماضی یا پیشین گوئی شدہ خطرات کا جائزہ لینے پر توجہ مرکوز کی گئی، یہاں تک کہ ان طرز عمل کے لیے جن کی تعیناتی میں بہت کم پھیلاؤ ہے۔ | خطرات کا نمائندہ جو موجودہ تعیناتی ٹریفک میں ایک خاص پھیلاؤ سے اوپر ہوتا ہے۔ |
تشخیص سے آگاہی | ممکنہ طور پر واضح ٹیسٹ اشارے (مثال کے طور پر، مصنوعی ڈیٹا کے ساتھ) جب تک کہ تعیناتی ڈیٹا کے ساتھ evals نہ بنائے جائیں | ایسا لگتا ہے کہ تعیناتی جیسا سیاق و سباق evals بیداری کو نمایاں طور پر کم کرتا ہے |
کوشش | حسبِ ضرورت تیار کی گئی پرامپٹ تقسیمات (Custom Prompt Distributions) اور سیٹ اپس کے لیے نمایاں طور پر زیادہ دستی محنت درکار ہوتی ہے | ایک وقتی بنیادی ڈھانچے کی لاگت کی ضرورت ہوتی ہے، اور پھر تعیناتی سے سابقے اور معلوم ناپسندیدہ طرز عمل سے گریڈرز کو دوبارہ استعمال کرتا ہے |
Traditional evaluations اور تعیناتی سمولیشن کے درمیان high level comparison
تعیناتی سمولیشن کو evaluate کرنے کے لیے، ہم نے GPT‑5.4 Thinking کے لیے 20 types کے undesirable behavior کی deployment-time frequency کے predictions pre-register کیے. ہم نے GPT‑5‑series کے Thinking ماڈلز کی دیگر deployments پر retrospective studies بھی چلائیں. جن ماڈل behaviors کا ہم analyze کرتے ہیں وہ misalignment اور disallowed content categories دونوں کا احاطہ کرتے ہیں جن کی ہم system cards میں رپورٹنگ کرتے رہے ہیں (مثلاً ماڈل کا tools کے بارے میں جھوٹ بولنا، یا disallowed sexual content آؤٹ پٹ کرنا). اگرچہ ان results کے لیے ہم undesired ماڈل behavior کی صرف 20 کیٹیگری track کرتے ہیں، اور صرف novel misaligned behaviors تلاش کرتے ہیں، تعیناتی سمولیشن ایک general technique ہے جسے کسی بھی deployment-time ماڈل property کو simulate کرنے کے لیے apply کیا جا سکتا ہے.
ہم نے جو production traffic استعمال کیا وہ بھی GPT‑5‑series کے Thinking ماڈلز سے تھا. اپنی evaluations چلانے سے پہلے، ہم نے account-linked identifiers اور identifiable information خودکار طور پر remove کر دی. اپنی پرائیویسی پالیسی کے مطابق، ہم نے صرف ان users کا ChatGPT traffic کا تجزیہ کیا جو اپنے data کو ماڈل improvements کے لیے استعمال کرنے کی اجازت دیتے ہیں. ہم ان evaluations سے صرف aggregate findings رپورٹ کرتے ہیں. مجموعی طور پر، ہم نے GPT‑5 Thinking سے GPT‑5.4 deployments تک تقریباً 1.3 million de-identified conversations کا analyze کیا، جو August 2025 سے March 2026 تک پھیلی ہوئی تھیں.
ہم تعیناتی سمولیشن سے پیدا pre-deployment risk-assessment کی quality کو تین main طریقوں سے evaluate کرتے ہیں:
- Taxonomy coverage: کیا post-release auditing نے ہماری initial bad behavior taxonomy سے missing کوئی important misaligned behaviors سامنے لائے؟
- Directional accuracy: کیا simulation نے درست predict کیا کہ known behaviors کے لیے deployment prevalence بڑھے گی یا گھٹے گی؟
- Rate calibration: کیا ہمارے pre-deployment estimates ان rates کے قریب تھے جو ہم نے بعد میں deployment میں observe کیں؟ اچھی rate calibration حاصل کرنے کے لیے directional accuracy سے زیادہ درکار ہوتا ہے، جس سے یہ سب سے اعلیٰ ممکن quality standard بنتا ہے.
ہم یہ بھی measure کرتے ہیں کہ تعیناتی سمولیشن کے دوران ماڈلز کس حد تک بتا سکتے ہیں کہ وہ evaluation میں ہیں، اور test کرتے ہیں کہ method deployment traffic کی مختلف forms اور challenging tool use settings کے لیے کتنا robust ہے.
GPT‑5‑series Thinking deployments میں، تعیناتی سمولیشن نے actual risk rate طے کرنے میں challenging-prompt baselines سے بہتر کارکردگی دکھائی، release سے پہلے calculator hacking سامنے لانے میں کامیاب رہی، اور ماڈل کے لیے deployment سے ممکنہ طور پر indistinguishable نظر آئی.
ہماری predictions کا مختصر جائزہGPT‑5‑series کے Thinking ماڈل deployments کے لیے تمام predictions کی visualization کے لیے، Figure 2 دیکھیں. GPT‑5.4 Thinking کے لیے predictions pre-registered تھیں، جبکہ دیگر retroactive predictions تھیں. Aggregate میں، ہماری predictions کا median multiplicative error 1.5x تھا (مثلاً اگر undesirable behavior rate 100k میں 10 ہے، تو یہ 100k میں 15 یا 6.67 کی rate estimate کرنے کے برابر ہوگا). اگرچہ ہمارے method کے tail errors تقریباً 10x بڑے ہو سکتے ہیں، ہمیں توقع ہے کہ simulation pipeline میں مزید improvements سے انہیں significantly reduce کیا جا سکتا ہے، جیسا کہ نیچے discuss کیا گیا ہے.
شکل 2. تعیناتی سمولیشن میں سابقہ تعیناتی ڈیٹا کی بنیاد پر تعیناتی کے وقت ناپسندیدہ رویے کی تعدد کی پیش گوئیاں. علامت 5.1 → 5 کا مطلب ہے کہ ہم GPT‑5 سے لیے گئے prefixes کو GPT‑5.1 کے ساتھ دوبارہ نمونہ بنا رہے ہیں، یعنی GPT‑5 کے ڈیٹا کی بنیاد پر GPT‑5.1 کی تعیناتی کو simulate کر رہے ہیں. GPT‑5.1 میں misaligned رویے کی سب سے زیادہ شرح “calculator hacking” تھی، جس پر ہم پہلے(نئی ونڈو میں کھلتا ہے) گفتگو کر چکے ہیں.
تعیناتی سمولیشن predictions کا baselines سے موازنہ. Pre-deployment risk-assessments کے لیے درست estimate کرنے کی سب سے important categories وہ ہیں جن میں ماڈل کی deployment کے بعد incidence میں large changes ہوتے ہیں (مثلاً >= 1.5x). اس subset پر، تعیناتی سمولیشن baselines سے کافی بہتر ہے، دونوں میں: یہ predict کرنا کہ کوئی certain undesirable behavior ماڈل کی deployment کے ساتھ prevalence میں بڑھے گا یا گھٹے گا (Figure 3, left)، اور اس کی exact deployment-time incidence estimate کرنا (Figure 3, right). ہم دو main baselines استعمال کرتے ہیں: Challenging Prompts baseline جسے ہم currently system cards اور launch decisions کے لیے use کرتے ہیں، اور previous deployment کی rates کو نئے ماڈل کے estimates کے طور پر use کرنے کی naive baseline.
شکل 3. تعیناتی سمولیشن incidence changes کی direction (left) اور exact production rates (right) دونوں کو static evals سے بہتر predict کرتی ہے.
ہماری pipeline میں simulation error کے sources. ہم نے اپنی pipeline میں error کے current sources کا بھی مطالعہ کیا. خاص طور پر، large tail errors پائپ لائن کو deployment decisions کے لیے کم trustworthy بناتے ہیں: مثلاً کسی certain type کے undesirable behavior میں large predicted increase دیکھتے وقت، اگر pipeline کے occasional large errors بھی معلوم ہوں، تو شک پیدا ہوتا ہے کہ آیا یہ reliable estimate ہے یا pipeline کا artifact. ممکنہ error کے دو main sources ہیں:
- Resampling environment fidelity error: پروڈکشن rates کو accurately estimate کرنے کے لیے، ہماری simulation pipeline کو جتنا ممکن ہو realistic ہونا چاہیے. یہ جزوی طور پر ایک engineering problem ہے (ماڈل سے اسی pipelines کے ذریعے sampling کرنا جو production traffic کے لیے use ہوتی ہیں)، اور جزوی طور پر tools کے لیے ایک interesting challenge ہے جنہیں external resources تک read/write access چاہیے جو مسلسل بدل رہے ہوتے ہیں (مثلاً web searches یا local files کے ساتھ interaction). ہم actual deployment اور اس کی simulation کی predictions کا موازنہ کر کے simulation fidelity error الگ کر سکتے ہیں (یعنی already deployed ماڈل کی deployment simulate کرنا).
- Prompt distribution shift error: تعیناتی سمولیشن کے ساتھ ایک major concern یہ ہے کہ کسی بھی ماڈل کی deployment inputs میں distributional shift پیدا کرے گی، خاص طور پر اگر users نئے ماڈل affordances کے مطابق adapt کریں. ہم prompt distribution error کو recent prompts بمقابلہ realized deployment کے prompts استعمال کر کے deployment simulate کرتے وقت estimates کا موازنہ کر کے isolate کرتے ہیں.
جیسا کہ Figure 4 میں دیکھا گیا، ہم پاتے ہیں کہ ہماری pipeline میں error کا بڑا حصہ، خاص طور پر tail errors کے لیے، currently simulation fidelity کی وجہ سے ہے. یہ اچھی خبر ہے، کیونکہ ہمیں توقع ہے دکہ simulation fidelity کو بہتر بنانا prompt distribution shift کم کرنے کے مقابلے میں عموماً آسان ہوگا. ہم یہ بھی پاتے ہیں کہ prompt distribution shift error کو previous deployment کے most recent data استعمال کر کے reduce کیا جا سکتا ہے. مزید detail research paper میں مل سکتی ہے.
شکل 4: Resampling environment fidelity ہمارے estimates میں error کا سب سے بڑا source لگتا ہے، خاص طور پر انتہائی errors کے لیے.
Automated auditing نے ان deployments میں introduce ہونے والی ایک نئی misalignment تلاش کی. ہم نے جس deployment window کا مطالعہ کیا، اس میں simulated deployments پر مبنی ہماری automated auditing pipeline release سے پہلے ‘calculator hacking’ سامنے لے آتی، جو analyzed ChatGPT traffic میں identified واحد novel misalignment تھی. Calculator hacking reward hacking کی ایک form ہے جس میں ماڈل browser tool کو calculator کے طور پر use کرتا ہے جبکہ action کو search کے طور پر پیش کرتا ہے. اس کا مطلب یہ نہیں کہ large-scale auditing ہر نئی failure پکڑ لے گی، لیکن یہ دکھاتا ہے کہ realistic contexts کیوں matter کرتے ہیں: وہ ایسے behaviors elicit کر سکتے ہیں جنہیں narrower eval sets کبھی directly surface نہ کریں، حتیٰ کہ اگر وہ simulation seed کرنے کے لیے استعمال original traffic میں موجود نہ تھے.
Deployment-like contexts استعمال کرنے کا ایک اور advantage یہ ہے کہ وہ ان distortions کو کم کر سکتے ہیں جو تب پیدا ہوتی ہیں جب ماڈلز recognize کرتے ہیں کہ ان کا test ہو رہا ہے. Previous research میں، ہم نے اور دوسروں نے(نئی ونڈو میں کھلتا ہے) پایا ہے کہ ماڈلز اکثر aware ہوتے ہیں کہ ان کا test کب ہو رہا ہے. مثال کے طور پر، ماڈلز اپنی چین-آف-تھاٹ میں reason کر سکتے ہیں کہ ان کا test کس چیز پر ہو رہا ہے، evaluator کو کیا پسند آ سکتا ہے، اور – اگر وہ misbehave کر رہے ہوں – کیا وہ پکڑے جائیں گے. یہ alignment evaluations کے لیے problem پیدا کرتا ہے: اگر کوئی ماڈل صرف اس لیے well behaved ہے کہ اسے لگتا ہے کہ اس کا test ہو رہا ہے، تو ہم کیسے confidence بنائیں کہ deployed ہونے کا علم ہونے کے بعد وہ safely behave کرے گا؟
ہم دکھاتے ہیں کہ تعیناتی سمولیشن traditional evaluations کے مقابلے میں، جو real deployment data پر based نہیں ہیں، ماڈلز کی دکھائی evaluation awareness levels کو substantially reduce کرتی ہے. ہم evaluation awareness کو تین ways میں measure کرتے ہیں: ایک ماڈل سے classify کرانا کہ trajectory production سے آئی یا evaluation سے، chain-of-thought کو alignment کے لیے evaluate کیے جانے کے explicit statements کے لیے monitor کرنا، نیز metagaming(نئی ونڈو میں کھلتا ہے) کے لیے: oversight کے بارے میں کوئی بھی ریزننگ. Simulated deployment traffic تینوں measures میں real deployment traffic سے قریب سے matched تھا. مثلاً، GPT‑5.2 نے real production traffic کو 5.4% وقت evaluation-like label کیا اور simulated traffic کو 5.1% وقت، جبکہ traditional evaluations (جیسے SWE-Bench یا MonorepoBench، جو بنیادی طور پر synthetic examples پر مشتمل ہیں) کو تقریباً 100% وقت evaluations کے طور پر classify کیا گیا.
شکل 5۔ جائزہ آگاہی (Evaluation Awareness) کا تقابلی جائزہ: حقیقی پروڈکشن ٹریفک اور مصنوعی (Simulated) ٹریفک میں جائزے کی شناخت (Eval Detection)، زبانی طور پر ظاہر کی گئی الائنمنٹ جائزہ آگاہی (Verbalized Alignment Evaluation Awareness)، اور میٹاگیمنگ (Metagaming) کی شرحیں تقریباً یکساں دکھائی دیتی ہیں، جبکہ روایتی جائزاتی ڈیٹا سیٹس میں ان کی شرحیں نمایاں طور پر زیادہ رپورٹ کی گئی ہیں۔
یہ test کرنے کے لیے کہ method standard chat modes سے آگے بڑھ سکتا ہے یا نہیں، ہم نے challenging agentic coding settings کے لیے deployments simulate کرنے کا بھی مطالعہ کیا. خاص طور پر، ہم GPT‑5.4 سے 120,000 internal employee agentic trajectories استعمال کرتے ہیں تاکہ GPT‑5.5 پر based coding agents کی internal deployment simulate کی جا سکے. یہ دو purposes serve کرتا ہے: یہ دکھاتا ہے کہ deployment simulation internal deployments کے risk-assessment کے لیے بھی use ہو سکتی ہے، اور demonstrate کرتا ہے کہ careful tool simulation کے ذریعے agentic settings میں بھی simulation fidelity high بنانا possible ہے.
اوپر ہم نے discuss کیا کہ simulation fidelity ہماری current pipeline میں error کے main sources میں سے ایک ہے. Deployment simulations کو realistic بنانے کا ایک challenge یہ ہے کہ tools کو realistic طریقوں سے act کرنا چاہیے، حتیٰ کہ جب انہیں external resources تک read/write access چاہیے جو مسلسل بدل رہے ہوتے ہیں (مثلاً web searches یا local files سے interaction).
یہ agentic deployments جیسی settings کے لیے خاص طور پر challenging ہے: ایک single agent trajectory hundreds of tool calls، ریپوزٹری state، network responses، یا transient failures پر depend کر سکتی ہے. اس سے real tool access کے ساتھ resampling challenging بھی ہو جاتی ہے اور potentially dangerous بھی. اس کے پیش نظر، live systems پر tool calls apply کرنے کے بجائے، ہم انہیں ایک اور LLM کے ساتھ simulate کرتے ہیں. ہم دکھاتے ہیں کہ اس LLM کو extra affordances دینا realism اور اس لیے estimation quality کے لیے essential ہے.
ہم tool-simulator ماڈل کو original final-turn rollout، conversation کے وقت کی ریپوزٹری، tool-call/response pairs کا database، اور read-only connectors دیتے ہیں. ایک test میں جہاں discriminator نے simulated اور real rollouts میں فرق بتانے کی کوشش کی، realism 11.6% win rate سے 49.5% تک بہتر ہوا، جو 50% chance level کے قریب ہے.
شکل 6: Tool calls کو increased affordances کے ساتھ simulate کرتے وقت tool-heavy settings میں بھی resampling realism کو real sampling سے تقریباً indistinguishable بنایا جا سکتا ہے.
Simulation fidelity کے additional evidence کے طور پر، GPT‑5.4 Codex thinking traffic کو GPT‑5.4 کے ساتھ simulate کرنے پر misalignment rates تقریباً error bars کے اندر ہیں. اس کے برعکس، ہماری pre-deployment testing میں GPT‑5.5 اکثر categories میں زیادہ misaligned تھا.
شکل 7: Tool simulation کے ساتھ، GPT‑5.4 سے resampled conversations اور actual GPT‑5.4 production traffic کے behavior rates کافی ملتے جلتے ہیں – جو high resampling environment fidelity کی نشاندہی کرتا ہے. Categories پر مزید context کے لیے GPT‑5.5 سسٹم کارڈ(نئی ونڈو میں کھلتا ہے) دیکھیں.
یہ results suggest کرتے ہیں کہ جب surrounding tool environment کو sufficient fidelity کے ساتھ simulate کیا جائے تو تعیناتی سمولیشن complex agent settings تک extend ہو سکتی ہے.
ایک natural question یہ ہے کہ کیا external auditors private production traffic تک access کے بغیر بھی کچھ same benefits حاصل کر سکتے ہیں. ہم نے اسے 100,000 WildChat conversations کو prefixes کے طور پر استعمال کر کے test کیا. WildChat recent OpenAI production data کے مقابلے میں کم accurate تھا، مگر پھر بھی informative تھا: recent production data کا average multiplicative error WildChat سے lower تھا (1.75× vs. 2.44×)، جبکہ WildChat اکثر production rates کے تقریباً 3× کے اندر رہا اور above-chance rates پر بہتر ماڈل identify کیا. ہم WildChat-style evaluations کو developer-run تعیناتی سمولیشن کا promising complement سمجھتے ہیں. اس point پر مزید results کے لیے یہ companion Alignment blogpost(نئی ونڈو میں کھلتا ہے) دیکھیں.
تعیناتی سمولیشن adversarial evaluations، red-teaming، اور targeted tail-risk analysis کا complement ہے، replacement نہیں. کچھ undesired ماڈل behaviors کی detection chain-of-thought monitorability پر rely کرتی ہے: اگر future ماڈلز کم legibly reason کریں، key steps omit کریں، یا intent obscure کرنا سیکھ لیں، تو ہم undesirable behavior کی ان forms کو detect نہیں کر پائیں گے. مزید برآں، کیونکہ production data private ہے، developers کے پاس فی الحال external auditors کے مقابلے میں representative contexts تک stronger access ہے. بہتر public datasets اس gap کو کم کر سکتے ہیں.
تعیناتی سمولیشن ان behaviors کے لیے سب سے مفید ہے جو sampled prefixes میں ظاہر ہونے کے لیے کافی often occur کرتے ہیں. دس million conversations میں ایک بار occurring failure کا million-sample run میں discover ہونا unlikely ہے، اس لیے adversarial evaluations، red-teaming، اور targeted tail-risk analysis necessary رہتے ہیں. ہم currently ایک single assistant response simulate کرنے پر focus کرتے ہیں، کیونکہ preliminary experiments میں multiple turns simulate کرنے سے اپنے estimates میں meaningful improvements نہیں ملیں. یہ future میں simulation fidelity بہتر بنانے کا ایک important area ہو سکتا ہے.
Method prefix distribution پر بھی depend کرتا ہے، یعنی conversations کا وہ mix جسے resample کیا جا رہا ہے. Historical traffic کسی major product change، new tool release، world event، یا seasonal shift کے بعد users کے زیادہ capable ماڈل سے interact کرنے کے انداز سے match نہیں کر سکتا. Full paper میں analysis suggest کرتا ہے کہ available most recent data استعمال کر کے اس issue کو mitigate کیا جا سکتا ہے.
تعیناتی سمولیشن pre-deployment risk assessment کا ایک new approach ہے جو frontier labs اور evaluators کو یہ predict کرنے میں مدد دیتا ہے کہ language models real world میں کیسے behave کر سکتے ہیں اور deployment سے پہلے وہ risks سمجھ سکتے ہیں جو وہ pose کرتے ہیں. یہ existing safety evaluations، red-teaming، اور targeted analysis کو ایک زیادہ production-like prediction layer شامل کر کے complement کرتا ہے جو deployment behavior کے estimates improve کر سکتی ہے، evaluation-awareness effects کم کر سکتی ہے، اور pre-deployment predictions کو release کے بعد checkable بنا سکتی ہے. Traditional evaluations کے ساتھ استعمال ہونے پر، تعیناتی سمولیشن ماڈل risk assessment کو زیادہ realistic، زیادہ quantitative، اور deployment decisions کے لیے زیادہ useful بنانے میں مدد کر سکتی ہے.


