# تحقیقی منصوبے

Canonical HTML: https://aogavrilov.com/ur/projects/

Document language: ur

قابلِ مشاہدہ ناکامی سے شروع کریں، پھر موافق طریقے، شواہد اور دائرۂ کار کی حد اپنائیں۔

## مشاہدہ شدہ ناکامی کی بنیاد پر انتخاب کریں

ایک ہی علامت representation، generation، control یا verification سے آ سکتی ہے۔

| مشاہدہ شدہ مسئلہ | پہلی تشخیص | لازمی قرار دیے جانے والے شواہد | طریقۂ کار |
| --- | --- | --- | --- |
| رمزکشائی شدہ مخرج کم معیار ہے، مگر ناکام مرحلہ نامعلوم ہے | ماخذ، اس کی جوڑی دار بازتعمیر، اور مولّدہ نتیجے کو ایک ہی بیرونی جائزہ کار سے اسکور کریں۔ | ہر مرحلے پر قابلِ تقابل تقسیمات اور دُمی طرزِ عمل۔ | [مرحلہ وار bottleneck تشخیص](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#workflow) |
| فضائے نہاں کا پیمانہ بہتر ہوتا ہے، مگر حتمی معیار نہیں | آزمائیں کہ قائم مقام کی بہتری decoding کے بعد بھی منتقل ہوتی ہے یا نہیں۔ | جوڑی دار رمز کشائی شدہ ماحصل کے پیمانے، نہ کہ صرف نہاں تشخیص۔ | [نیابتی انتقال کی جانچ](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#decision-table) |
| ایک code editor مطلوبہ حصے سے زیادہ متن دوبارہ لکھ دیتا ہے | واضح حدِ تحفظ بیان کریں اور بیرونی خطے کا diff ناپیں۔ | مقامیت اور کام یابی کی مشترکہ پیمائش۔ | [مقامی ترمیم کا جائزہ](https://aogavrilov.com/ur/projects/discrete-latent-generation/#measurement) |
| refactoring کو محض نحو نہیں بلکہ رویہ بھی محفوظ رکھنا چاہیے | تجویز کو تنفیذ اور توثیق سے الگ رکھیں۔ | تالیف، آزمائشیں، جامد پڑتالیں، اور بازتشکیل کی شناخت۔ | [سطحِ کنٹرول کا فیصلہ جاتی نقشہ](https://aogavrilov.com/ur/projects/discrete-latent-generation/#control-surface) |

فعال تحقیقی سمت

## منفصل خفی تولید

منتخب کوڈ کی دوبارہ تولید کے لیے منفصل نمائندگیاں، نیز مقید تولید، مصنوعی ذہانت کی معاونت سے ری فیکٹرنگ، اور قابلِ پیش گوئی کوڈ تدوین کے درمیان شواہد سے رہنمائی یافتہ انتخاب۔

جانچ کی رہنما دستاویز

## کوڈیک تنگنائے کی تشخیص

یہ طے کرنے کا مرحلہ وار طریقہ کہ رمزکشائی شدہ معیار کو بازتعمیر، نہاں تولید، یا ایسا قائم مقام پیمانہ محدود کرتا ہے جو حتمی متن تک منتقل نہیں ہوتا۔

## مرکوز جوابات

ان وسیع تلاشوں کے مستقل شواہدی نوٹس جو مقالے کے عنوان سے شروع نہیں ہوتیں؛ ہر نوٹ متعلقہ اشاعت اور مکمل متن تک لے جاتا ہے۔

1. [فضائے کوڈ اور فضائے ٹوکن میں ماسک شدہ diffusion: تقابل کیسے کیا جائے](https://aogavrilov.com/ur/research-notes/code-space-vs-token-space-masked-diffusion/) جب منفصل کوڈیک ضیاعی ہو تو code-space اور token-space کے ماسک شدہ diffusion language models کے لیے مراحل میں ہم آہنگ تقابلی ضابطہ۔
2. [تولیدی ماڈلز سے کوڈ کی مقامی ترمیم](https://aogavrilov.com/ur/research-notes/localized-code-modification-generative-models/) پورے فنکشن کی غیر ضروری بازنویسی روکتے ہوئے، تولیدی ماڈل کو مطلوبہ تبدیلی کے لیے کافی آزادی کیسے دی جائے۔
3. [سافٹ ویئر انجینئرنگ کے لیے مقید کوڈ تولید](https://aogavrilov.com/ur/research-notes/constrained-code-generation-software-engineering/) تولید شدہ کوڈ کے لیے قواعدی قیود، نوعی قیود، حدودِ تحفظ، اور رویے کی سطح پر قبولیتی جانچوں کے درمیان عملی امتیاز۔
4. [مصنوعی ذہانت کی مدد سے بازساخت کاری: طریقے اور شواہد](https://aogavrilov.com/ur/research-notes/ai-assisted-refactoring-evidence/) مصنوعی ذہانت کی مدد سے بازساخت کاری کے حالیہ طریقوں کا جائزہ اس طرح کیسے لیا جائے کہ بظاہر معقول تولید شدہ patch کو رویے کے تصدیق شدہ تحفظ کے مترادف نہ سمجھا جائے۔
5. [قابلِ پیش گوئی کوڈ تولید کے لیے معاہدۂ تحفظ ضروری ہے](https://aogavrilov.com/ur/research-notes/predictable-code-generation-preservation-contract/) deterministic sampling کیوں کافی نہیں، اور قابلِ مشاہدہ محفوظ خصوصیات اور قبولیتی جانچیں کوڈ تولید کے رویے کو قابلِ آزمائش کیسے بناتی ہیں۔

## وہ تحقیقی سوالات جن کے جواب یہ ویب گاہ دے سکتی ہے

مختصر جواب کے لیے کوئی عملی سوال کھولیں، پھر طریقوں، پیمائشوں اور حدود کے لیے شواہد کے ربط پر جائیں۔ یہ تحقیق تک رسائی کے راستے ہیں، آفاقی ضمانتیں نہیں۔

1. ایک تولیدی ماڈل پورا فنکشن دوبارہ لکھے بغیر کوڈ میں ترمیم کیسے کر سکتا ہے؟ تولید سے پہلے قابلِ تدوین حد متعین کریں، اس سے باہر ماخذ کو محفوظ رکھیں یا دوبارہ استعمال کریں، صرف امکانی تبدیلیاں پیدا کریں، اور کام میں ناکام یا محفوظ خطوں کو بدلنے والے مخرجات رد کریں۔ درجہ بند متغیراتِ نہاں کا قفل ایک تجرباتی سطحِ کنٹرول ہے، مگر یہ یکساں ماخذی پھیلاؤ کی ضمانت نہیں دیتا۔ [مقامی تدوینی سطوحِ کنٹرول کا تقابل کریں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#control-surface) .
2. کون سی شہادت ظاہر کرتی ہے کہ code کی ترمیم محض نحوی طور پر درست نہیں بلکہ مقامی بھی ہے؟ مطلوبہ خطے سے باہر diff کو عملی کامیابی، قابلِ ترمیم خطے کی تبدیلی، ساختی مستقلات، آزمائشوں یا جامد جانچ، اور مکرر اجرا کے تغیر کے ساتھ ناپیں۔ صرف تجزیۂ نحوی کی شرح محض نحوی درست ساخت ثابت کرتی ہے۔ [مقامیت کے شواہد کی پڑتال فہرست کا جائزہ لیں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#measurement) .
3. کوڈ ترمیم کی مقامیت اور تولیدی تنوع کے مابین توازن کیسے قائم کیا جانا چاہیے؟ محفوظ حصے کا استحکام، قابلِ ترمیم حصے کی آزادی، اور امیدواروں کی انفرادیت ساتھ ساتھ رپورٹ کریں۔ input کی نقل استحکام کو زیادہ سے زیادہ کر سکتی ہے مگر کام میں کوئی پیش رفت نہیں کرتی؛ غیر مقید بازنوشت تبدیلی کو زیادہ سے زیادہ کرتے ہوئے مقامیت تباہ کر سکتی ہے۔ [محدود استحکام–آزادی کے شواہد دیکھیں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#evidence) .
4. مقامی کوڈ ترمیم، مقید تولید، اور پروگرام کی مرمت ایک دوسرے سے کیسے مختلف ہیں؟ مقامی ترمیم اس امر کو نمایاں کرتی ہے کہ کیا بلا تبدیلی رہنا چاہیے؛ مقید تولید، قواعدی رکنیت جیسی رسمی آؤٹ پٹ خصوصیت نافذ کرتی ہے؛ اور پروگرام کی مرمت تقاضا کرتی ہے کہ تبدیلی کسی نقص یا کام کی تخصیص پوری کرے۔ محض نحو، معنوی مساوات، فعلی درستی، کام یابی، یا مقامیت ثابت نہیں کرتی۔ [تینوں مقاصد کا تقابل کریں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#comparison) .
5. Python فنکشن کے منتخب حصوں کو اس طرح دوبارہ کیسے پیدا کیا جا سکتا ہے کہ باقی حصہ مستحکم رہے؟ تولید سے پہلے محفوظ اور قابلِ تدوین خطے متعین کریں، صرف قابلِ تدوین نمائندگی میں تبدیلی کریں، رمزکشائی کریں، اور ان امیدواروں کو رد کریں جو محفوظ کوڈ بدلیں یا نحو، آزمائشوں، جامد پڑتالوں، یا کام سے مخصوص غیر متغیرات میں ناکام ہوں۔ بیان کردہ درجہ بند نہاں تجربہ 64 ٹوکن کے تفاعلات پر احتمالی استحکام ناپتا ہے؛ یہ غیر تبدیل شدہ پھیلاؤ یا طرزِ عمل کی ضمانت نہیں دیتا۔ [انتخابی بازتولید کے عملی بہاؤ کا معائنہ کریں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#workflow) .
6. AI-assisted رویہ محفوظ رکھنے والی refactoring کے لیے کون سی حکمتِ ضبط موزوں ہے؟ model سے تحویل کی شناخت یا تجویز لیں، پھر جہاں ممکن ہو اسے قابلِ اعتماد refactoring engine سے نافذ کریں اور compilation، tests، static checks اور مطلوبہ refactoring کی توثیق کریں۔ بظاہر معقول تولید شدہ patch کافی شہادت نہیں۔ [بازساخت کاری کے فیصلے کی سطر کھولیں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#control-surface) .
7. کون سی چیز code generation کو محض قابلِ ضبط کے بجائے قابلِ پیش گوئی بناتی ہے؟ generator چننے سے پہلے قابلِ مشاہدہ معاہدۂ تحفظ اور قبولیت کی جانچیں بیان کریں۔ پیش بینی اس پر ہے کہ decoding و توثیق کے بعد کیا ثابت رہتا ہے، محض prompt، mask، grammar یا latent code ثابت ہونے پر نہیں۔ [معاہدۂ تحفظ متعین کریں](https://aogavrilov.com/ur/projects/discrete-latent-generation/#core-idea) .
8. بیان کردہ متنی تجربے میں کوڈ-فضا اور ٹوکن-فضا کے ماسک شدہ پھیلاؤ کا تقابل کیسا رہا؟ اسی بیرونی ممیز کے تحت code-space MDLM کا median perplexity 26.55 تھا، جبکہ token-space baseline کا 38.42، یعنی 30.9% کمی۔ کوڈیک باز تعمیر کا median پہلے ہی 27.36 تھا، اس لیے نتیجے کی تعبیر باز تعمیر کی رکاوٹ کے ساتھ کرنا ضروری ہے۔ [بیان کردہ مرحلہ وار اعداد کا معائنہ کریں](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
9. جب کوڈیک معلومات ضائع کرتا ہو تو کوڈ-فضا اور ٹوکن-فضا کے ماسک شدہ پھیلاؤ کا تقابل کیسے کیا جانا چاہیے؟ اصل نمونوں، کوڈیک باز تعمیرات، token-space حاصلات اور code-space حاصلات کے لیے وہی held-out samples اور غیر رمزشُدہ متن کا ممیز استعمال کریں۔ باز تعمیر کا فرق الگ بیان کریں، کیونکہ زیادہ قوی نہاں مولد بھی کوڈیک کی پہلے سے حذف کردہ معلومات واپس نہیں لا سکتا۔ [مراحل کا ایک ہی اسکور کار کے تحت تقابل کریں](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#code-space-vs-token-space) .
10. دو مرحلہ متن مولّد میں معیار کے زوال کی تشخیص کیسے کی جا سکتی ہے؟ ایک ہی غیر تبدیل شدہ، رمز کشائی شدہ متن کے جانچ کار کے تحت پہلے اصل سے بازتعمیر تک کا فرق، پھر بازتعمیر سے تولید تک کا فرق ناپیں۔ اس طرح کوڈیک کی عائد کردہ معیاری بالائی حد کو نہاں تولید سے پیدا ہونے والی اضافی تنزلی سے الگ کیا جا سکتا ہے۔ [چار پڑاؤ والی تشخیص پر عمل کریں](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#workflow) .
11. فضائے نہاں کے بہتر پیمانے غیر رمزشُدہ حاصل کو بہتر بنانے میں کب ناکام ہو سکتے ہیں؟ کوئی نہاں قائم مقام پیمانہ زیرِ نظر بعد کی خاصیت کی پیروی کیے بغیر بہتر ہو سکتا ہے۔ مماثل outputs کی رمزکشائی کر کے اور انہی حتمی metrics سے جانچ کر انتقال کی آزمائش کریں؛ بصورتِ دیگر codebook geometry یا utilization محض تشخیصی شہادت رہے گی، متنی معیار میں بہتری نہیں۔ [قائم مقام اشاریے کی منتقلی کی تشخیص استعمال کریں](https://aogavrilov.com/ur/projects/codec-bottleneck-diagnosis/#decision-table) .

## محدود شہادت کی دو جھلکیاں

یہ اعداد بتاتے ہیں کہ کیا ناپا گیا؛ یہ model کی آفاقی ضمانتیں نہیں۔

### ضغاطت کی تشخیص

TinyStories کی ایک 64-to-16 ترتیب میں، وسطانی perplexity یہاں سے بڑھی **15.17** ماخذ متن کے لیے تا **27.36** بازتعمیر کے بعد۔ Code-space MDLM یہاں تک پہنچا **26.55** بمقابلہ **38.42** اسی بیرونی اسکورر کے تحت فضائے ٹوکن کی اساسی کارکردگی کے لیے۔

### قابلِ معائنہ ترمیمی کنٹرول

64 ٹوکن والے Python فنکشن کی ایک ترتیب میں، چار بالائی سطحی کوڈ مقفل کرنے سے نحوی تجزیے کی شرح یہاں سے بڑھی **0.453** تا **0.591** ، جبکہ غیر مقفل جگہوں میں تبدیلی کی شرح تھی **0.936** اور مشروط نمونے بدستور رہے **0.998** منفرد۔

## یہ نقشہ کیا دعویٰ نہیں کرتا

تجربات exact AST preservation، semantic equivalence، functional correctness، repository-scale repair یا codec و generator bottlenecks کی آفاقی ترتیب قائم نہیں کرتے۔ رہنما محدود شواہد کو قابلِ بازاستعمال تشخیص بناتے ہیں؛ ہر نئے نظام کو اپنی decoded-output اور behavior-level validation چاہیے۔