Codex کے ساتھ خود بہتر ہونے والے ٹیکس ایجنٹس بنانا

Thrive Holdings اور OpenAI نے ماہرین کی مہارت کو Codex سے چلنے والے لوپ کے ساتھ ملا کر Crete اکاؤنٹنٹس کے لیے Tax AI کیسے مشترکہ طور پر تیار کیا

حقیقی دنیا کے سسٹمز پروڈکشن میں لیب کے مقابلے میں مختلف طرح سے برتاؤ کرتے ہیں، اور ایسے طریقوں سے ٹوٹتے ہیں جن کی تعیناتی سے پہلے پیش بینی کرنا مشکل ہوتا ہے. ٹیمیں اکثر ان ناکامیوں کو لانچ کے بعد دریافت کرتی ہیں، پھر edge cases کا جائزہ لینے، پرومپٹس کو ایڈجسٹ کرنے، اور پروڈکشن feedback کو پائیدار پروڈکٹ بہتریوں میں بدلنے پر ہفتے صرف کرتی ہیں. feedback loop دستی اور سست ہوتا ہے، اور صرف تب بہتر ہوتا ہے جب کوئی انجینئر اسے آگے بڑھائے. لیکن آج، سوچ سمجھ کر ڈیزائن کیے گئے eval infrastructure، ماہرین اور حقیقی دنیا کے ماحول تک براہِ راست رسائی، اور Codex کی frontier agentic صلاحیتوں کے ساتھ، آپ ایسے ایجنٹس بنا سکتے ہیں جو خود بہتر ہوں.

اس پوسٹ میں، ہم کھول کر بتائیں گے کہ ہم نے اس قسم کا ایجنٹ بنانے کے لیے Codex کیسے استعمال کیا. گزشتہ چھ ماہ میں، OpenAI کے forward deployed انجینئرز اور محققین نے Thrive Holdings کے انجینئرز کے ساتھ مل کر Crete⁠(نئی ونڈو میں کھلتا ہے) کے 30+ اکاؤنٹنگ فرموں کے نیٹ ورک کے ساتھ اور ان کے لیے Tax AI تیار کیا تاکہ بڑھتی ہوئی پیچیدگی والے ٹیکس ریٹرنز کی تیاری میں مدد مل سکے. ہر ناکامی کو ڈھونڈنے اور ٹھیک کرنے کے لیے انجینئرز پر انحصار کرنے کے بجائے، Tax AI Codex کا استعمال کر کے پروڈکشن استعمال کو structured signals میں بدلتا ہے جو خودکار بہتری کو ایندھن دیتے ہیں.

Crete کے ماہرین ہر سیزن میں دسیوں ہزار ٹیکس ریٹرنز تیار کرتے ہیں، جس کے لیے لاکھوں بنیادی دستاویزات پر کام کرنا پڑتا ہے. درمیانی سے بڑی پیچیدگی والی فائلنگز کے لیے، صرف data entry ہی فی ریٹرن آٹھ گھنٹے لے سکتی ہے، اور اس میں اکثر بے ترتیب data sources، پچھلے سال کی دستاویزات، اور دستی extraction اور calculation شامل ہوتے ہیں. انہوں نے ہمیں بتایا کہ ٹیکس سیزن کے مصروف ترین حصے میں ٹیکس تیاری ایک اہم bottleneck ہے.

اس مسئلے کو حل کرنے کے لیے، Tax AI نے اس ٹیکس سیزن میں پائلٹ میں شریک Crete فرموں میں 7,000 ٹیکس ریٹرنز پروسیس کیے. یہ سسٹم 1040 اور 1041 ٹیکس ریٹرنز کی تیاری کے وقت طلب عمل کا بڑا حصہ خودکار بناتا ہے، لیکن کارکردگی میں اضافے سے بھی زیادہ متاثر کن بات یہ ہے کہ سسٹم خود اس ورژن سے قابلِ پیمائش طور پر بہتر ہے جو تین ماہ پہلے پہلی بار تعینات کیا گیا تھا.

Tax AI میں، ماہرین سورس فائلیں کسی بھی کلائنٹ مخصوص نوٹس کے ساتھ اپ لوڈ کرتے ہیں. پھر Tax AI ایک tax engine submission بناتا ہے، جو جائزے کے لیے تیار ہوتی ہے. یہ ماہرین کا ٹیکس تیاری پر تقریباً ایک تہائی وقت بچاتا ہے، 97% تک درستگی کے ساتھ ریٹرنز کا مسودہ تیار کرتا ہے، اور تھروپٹ میں تقریباً 50% اضافہ کرتا ہے، جس سے انہیں کلائنٹس کے ساتھ وقت گزارنے کے لیے زیادہ گنجائش ملتی ہے. 

ہم اس بہتری کو اس بات سے ناپ سکتے ہیں کہ Tax AI بعد میں درستی کی ضرورت کے بغیر ایک ریٹرن کتنی درستگی سے مکمل کر سکتا ہے. ہم درستگی کو اس بات سے ناپتے ہیں کہ کتنے ریٹرنز 75%، 90%، یا 100% درست فیلڈ تکمیل تک پہنچتے ہیں. لانچ کے وقت، صرف ایک چوتھائی ریٹرنز 75% درست فیلڈ تکمیل پر تھے، لیکن چھ ہفتوں کے اندر 86% اس حد تک پہنچ گئے. 90% اور 100% درست فیلڈ تکمیل کی سطحوں پر سسٹم نے اس سے بھی تیز ترقی دکھائی. یہ حدیں ہمیں اس بات کا عملی اندازہ دیتی ہیں کہ مختلف ریٹرنز کو اب بھی ماہرین کی کتنی بعد کی توجہ درکار ہے. 

ابتدا میں، Tax AI نے آسان کام سنبھالے، جیسے W-2s اور 1099s. جیسے جیسے سیزن آگے بڑھا، یہ K-1s، schedules، اور زیادہ مشکل edge cases والے زیادہ پیچیدہ ریٹرنز تک پہنچ گیا. ہر نئی صلاحیت نے پچھلی کے مقابلے میں فی ریٹرن زیادہ وقت بچایا کیونکہ جو کام اس نے سنبھالے وہ زیادہ مشکل اور دستی طور پر کرنے میں زیادہ وقت لینے والے تھے. ہم آج بھی مسلسل پیش رفت دیکھ رہے ہیں.

اگلا، ہم بتائیں گے کہ ہماری ٹیموں نے Tax AI کو خود بہتر ہونے والا بنانے کے لیے تین اہم ستونوں پر انحصار کرتے ہوئے مشترکہ انجینئرنگ کیسے کی: 1) ماہرین کا expert feedback، 2) پروڈکشن traces (inputs سے آخری output تک کی structured history)، اور 3) tailored evals پر مبنی Codex سے چلنے والا iteration loop تاکہ مسلسل اور تیز تر پروڈکٹ development ممکن ہو. ہم امید کرتے ہیں کہ ہمارا تجربہ ان دوسرے builders کے لیے مفید ہوگا جہاں مجموعی سسٹم اور اس میں چلنے والے data کے معیار کو شکل دینے میں ماہرین کی مہارت کلیدی ہے.

جیسے جیسے ہم ٹیکس تیاری کے زیادہ مشکل حصوں (K-1s، کرایہ کی رہائشی schedules، اور ایسے ٹیکس forms جہاں قدروں کو متعدد سورس فائلوں میں ملا کر درست کرنا پڑتا تھا) میں آگے بڑھے، یہ واضح ہو گیا کہ اصل چیلنج یہ تھا کہ آیا پروڈکٹ پیچیدہ پروڈکشن ناکامیوں کو نمایاں، قابلِ فہم، اور قابلِ عمل بنا سکتی ہے.

پروڈکٹ کے ابتدائی دنوں میں، زیادہ تر درستی دستی تھی. ماہرین سسٹم کی غلطیاں درست کر سکتے تھے، لیکن پروڈکٹ پورا context محفوظ نہیں کرتی تھی: فائلنگ سے پہلے بدلی گئی قدر واقعی extraction کی کمی، mapping کا مسئلہ، غائب پروڈکٹ معاونت، یا متوقع ورک فلو شور کو ظاہر کر سکتی تھی. ان معاملات کو الگ کرنا اب بھی انجینئرنگ ٹیم کی follow-up کا تقاضا کرتا تھا. انجینئرز coding agents استعمال کر سکتے تھے، لیکن سسٹم ابھی اس طرح ڈیزائن نہیں ہوا تھا کہ بہتری کے لوپ کے اندر AI کو بامعنی طور پر استعمال کر سکے. ہمارے پاس یہ شناخت کرنے کا سگنل نہیں تھا کہ چڑھنے کے لیے صحیح پہاڑی کون سی ہے.

اسی وجہ سے ہم نے سسٹم کو تین ستونوں کے گرد ڈیزائن کیا:

1. ماہرین کے قریب رہیں: جو لوگ کام کر رہے ہیں، انہیں یہ رہنمائی کرنی چاہیے کہ پروڈکٹ کیا سیکھے. ان کی بصیرت اور سمجھ یہ ظاہر کرتی ہے کہ کون سی غلطیاں اہم ہیں اور یہ بتانے میں مدد دیتی ہے کہ اگلا فوکس ورک فلو کے کن حصوں پر ہونا چاہیے.
2. پروڈکٹ کو اس طرح بنائیں کہ پروڈکشن شہادت پیدا کرے: پروڈکٹ کو صرف inputs اور outputs سے زیادہ محفوظ کرنا ہوگا؛ اسے سورس مواد سے extract شدہ فیلڈز اور provenance، پھر downstream submission اور expert correction تک پورا راستہ محفوظ کرنا ہوگا.
3. Codex سے چلنے والا بہتری کا لوپ بنائیں: جب پروڈکشن مسائل نمایاں اور structured ہو جائیں، تو وہ findings، tailored evals، اور محدود انجینئرنگ tasks بن سکتے ہیں. پھر Codex تحقیق میں مدد کر سکتا ہے، تبدیلیاں تجویز کر سکتا ہے، انہیں targeted اور regression evals کے خلاف validate کر سکتا ہے، اور پروڈکٹ کو خالصتاً دستی iteration cycle کے مقابلے میں زیادہ تیزی سے آگے بڑھا سکتا ہے. 

نیچے دی گئی کرایہ کی جائیداد کی مثال دکھاتی ہے کہ یہ لوپ عملی طور پر کیسے کام کرتا ہے، اور آپ کو یہ بتاتی ہے کہ ماہر کی درستی کیسے ایک structured finding بنتی ہے، پھر eval target، اور آخر میں Codex کے دائرے میں ایک انجینئرنگ task.

کرایہ کی جائیداد کی آمدنی انفرادی ٹیکس ریٹرن کے Schedule E میں رپورٹ کی جاتی ہے. انجینئرنگ کے نقطۂ نظر سے، اسے extract کرنے کا کام بیان کرنا آسان مگر اچھی طرح انجام دینا مشکل ہے. سسٹم کو بے ترتیب سورس مواد (ہاتھ سے لکھی نوٹس، emails، spreadsheets، اور دیگر کلائنٹ فائلیں) پڑھنا ہوتا ہے، کرایہ کی جائیداد کی وہ فیلڈز extract کرنی ہوتی ہیں جنہیں سسٹم اعتماد کے ساتھ tax engine میں میپ کر سکے، اور اتنی شہادت محفوظ رکھنی ہوتی ہے کہ ماہر نتیجے کی منظوری دے سکے یا اسے درست کر سکے. نیچے دی گئی سادہ مثال دکھاتی ہے کہ وہ سورس فائلیں اور extract شدہ outputs کیسے دکھائی دے سکتے ہیں.

ایجنٹ کی پیش گوئی کردہ قدر اور جمع شدہ ٹیکس ریٹرن کی اصل قدر کے درمیان فرق واقعی extraction کی کمی کو ظاہر کر سکتا ہے، لیکن یہ ماہر کی ترجیح، ٹیکس انجن میں پچھلے سال کے ریٹرن سے آگے لائی گئی قدر، یا فائلنگ ورک فلو میں کہیں اور شامل یا تبدیل کی گئی قدر بھی ہو سکتی ہے. ماہرین نے ہمیں ان معاملات میں فرق سمجھنے میں مدد دی تاکہ ہم شناخت کر سکیں کہ کن اقدامات کے لیے ماہر کی درستی درکار تھی یا کنہوں نے submission کو روکا.

چونکہ ہم ان درستیوں کو تفصیل سے دیکھ سکتے تھے، ہم نے جائزہ عمل کو ناکامی کے بعد کے آخری مرحلے سے بدل کر مسلسل سیکھنے کے چکر میں تبدیل کر دیا. ہم نے ورک فلو کو اس طرح ڈیزائن کیا کہ ماہر اقدامات کو structured data کے طور پر محفوظ کیا جا سکے. اب ہر مداخلت پروڈکٹ کے بہتری والے لوپ کو یہ ریکارڈ کر کے فیڈ کرتی ہے کہ Tax AI نے کیا تجویز کیا، ماہر نے کیا بدلا، اور آخرکار جمع شدہ ریٹرن میں کیا گَیا.

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

• فرق محفوظ کریں: Tax AI کے آؤٹ پٹ کا جمع شدہ ریٹرن سے موازنہ کیا جاتا ہے تاکہ فیلڈ سطح کی review rows بنیں جو متوقع قدر، پیش گوئی کردہ قدر، اور یہ کہ فرق قابلِ عمل لگتا ہے یا نہیں، محفوظ کریں.
• متعلقہ ناکامیوں کو گروپ کریں: ملتی جلتی review rows کو گروپ کیا جاتا ہے تاکہ بار بار ہونے والی پروڈکٹ ناکامیوں کو متوقع ورک فلو شور سے الگ کیا جا سکے. مثال کے طور پر، ماہرین کی بار بار درستی یہ دکھا سکتی ہے کہ Tax AI اکثر “fair rental days” فیلڈز چھوڑ دیتا ہے، “other expenses” کو غلط سنبھالتا ہے، یا ایک ہی سورس پیکیج میں متعدد کرایہ کی جائیدادوں کو گڈمڈ کر دیتا ہے.
• بار بار آنے والے پیٹرنز کو eval اہداف میں بدلیں: جائزہ اور پیمائش کے بعد، بار بار ملنے والی چیزیں Codex کی بہتری کے لیے واضح eval اہداف بن جاتی ہیں.

تیسرا ستون ایسا انجینئرنگ لوپ بنانا ہے جو ان نئے evals پر عمل کر سکے. یہی وہ جگہ ہے جہاں Codex مرکزی بن جاتا ہے.

فرض کریں ہمارا eval pipeline یہ نشان زد کرتا ہے کہ Tax AI مسلسل "fair rental days" فیلڈ چھوڑ دیتا ہے، جبکہ ماہرین اسے باقاعدگی سے بھر دیتے ہیں. چونکہ یہ دریافت پہلے ہی نمائندہ سورس پیکیجز اور متوقع آؤٹ پٹس کے ساتھ ایک ہدفی eval set میں پیک کی جا چکی ہے، Codex پروڈکٹ scaffold کے اندر براہِ راست بنیادی وجہ کی تحقیق کر سکتا ہے.

Codex صرف کمزور آخری آؤٹ پٹ کے ساتھ کام نہیں کر رہا ہوتا. یہ ٹریس، eval، repo اور skills کو ایک ساتھ دیکھتا ہے:

• pipeline کی تحقیق کریں: سورس پیکیجز، extraction schemas، mapper کے رویے، اور code paths کا جائزہ لیں تاکہ طے ہو سکے کہ مسئلہ غیر معاونت یافتہ فیلڈ، چھوٹا ہوا extraction pattern، سورس انتخاب کا مسئلہ، mapper کی کمی، یا grader کا مسئلہ ہے.
• ہدفی اصلاحات نافذ کریں: extraction schema کو بڑھائیں، کرایہ کی جائیداد کی دستاویزات کے لیے سورس انتخاب بہتر کریں، tax-engine mapper کو اپ ڈیٹ کریں، یا اگر متوقع ورک فلو شور کو ناکامی گنا جا رہا ہو تو grader کو بہتر بنائیں.
• توثیق کریں اور تجویز دیں: ہدفی eval دوبارہ چلائیں، وسیع regression suites چلائیں، اور انجینئرنگ جائزے کے لیے ایک ممکنہ pull request سامنے لائیں.
• لوپ بند کریں: ماہر کی بار بار ہونے والی درستی کو ایک قابلِ پیمائش انجینئرنگ کام میں بدل دیں. اگر شہادت مبہم ہو یا محفوظ طور پر خودکار نہ بنائی جا سکے، تو معاملہ زبردستی لوپ سے گزارنے کے بجائے دوبارہ پروڈکٹ ٹیم کے پاس بھیج دیا جاتا ہے.

کرایہ کی جائیداد کی مثال ایک وسیع اور دوبارہ استعمال ہونے والے پیٹرن کی نمائندہ ہے: پروڈکشن آرٹیفیکٹس اور ٹریسز کو استعمال کر کے ایک ایجنٹ کی صلاحیتیں بہتر بنانا۔ پروڈکشن ڈیٹا سے جائزہ شدہ فائنڈنگز، سورس ٹریسز، متوقع ٹیکس-انجن آؤٹ پٹ، متعلقہ کوڈ مثالیں، اور ایوال کمانڈز کو ان پٹس کے ایک مجموعے کے طور پر دینے پر، Codex ہفتوں اور مہینوں میں کارکردگی اور درستگی میں نمایاں بہتری لا سکتا ہے۔ یہ ہمارےہارنِس انجینئرنگ اور سمفنیپر کیے گئے کام میں بیان کردہ اصولوں پر مبنی ہے، جو یہ بتاتے ہیں کہ کاموں کو Codex کے لیے کیسے واضح بنایا جائے، محدود کانٹیکسٹ اور ٹولز کیسے دیے جائیں، اور ویلیڈیشن اور انسانی جائزے کو ماحول کا حصہ کیسے رکھا جائے۔

یہ شہادت خود بخود Codex کا کام نہیں بن جاتی. ماہر کی درستی extraction کی کمی، mapping کا مسئلہ، غیر معاونت یافتہ پروڈکٹ رویہ، ٹیکس فیصلہ، یا متوقع ورک فلو شور کو ظاہر کر سکتی ہے. صرف اس وقت جب بار بار آنے والے فرقوں کا جائزہ لے کر انہیں ایک قابلِ عمل دریافت میں گروپ کر دیا جائے، سسٹم انہیں واضح کامیابی شرط والے محدود کام میں بدلتا ہے.

ہم یہ automation پروڈکٹ کی ایک محدود تہہ پر لاگو کرتے ہیں. یہ تہہ extraction انجام دیتی ہے اور سورس دستاویزات کو ٹیکس ورک فلوز میں میپ کرتی ہے. انجینئرز بدستور architecture، پروڈکٹ فیصلوں اور shipping کے ذمہ دار رہتے ہیں. ماہرین اپنے پہلے سے کیے جانے والے کام کے ذریعے بہتری کے لوپ کی رہنمائی کرتے ہیں: extract کی گئی قدروں کو درست کرنا، ریٹرنز کا جائزہ لینا، اور آخری فائلنگز کی منظوری دینا.

Codex کے لیے نتیجہ کوئی مبہم alert نہیں بلکہ شہادت، قابلِ تدوین پروڈکٹ سطحوں، اور واضح validation gates کے ساتھ ایک محدود انجینئرنگ کام ہوتا ہے. نمائندہ کرایہ کی جائیداد کے کام کا context یوں خلاصہ کیا جا سکتا ہے:

یہی لوپ کرایہ کی جائیدادوں سے آگے بھی لاگو ہوتا ہے. کرایہ کی جائیدادوں کو 90% precision اور recall تک پہنچانے میں تقریباً چھ ہفتے اور خاطر خواہ انجینئرنگ نگرانی لگی، لیکن اس کام نے دوبارہ استعمال ہونے والی abstractions، review artifacts، eval conventions، اور implementation patterns پیدا کیے جنہوں نے Schedule C اور Schedule A جیسے اسی طرح پیچیدہ schedules کی معاونت آسان بنا دی.

Tax AI خود بہتر ہونے والے ایجنٹس بنانے کا ایک راستہ ثابت کرتا ہے. ماہرین سروس فراہم کرتے ہوئے اعلیٰ قدر کے feedback signals پیدا کرتے ہیں. پروڈکٹ ورک فلوز ان سگنلز کو structured evidence کے طور پر محفوظ رکھتے ہیں. Eval سے تقویت یافتہ انجینئرنگ سسٹمز بہتریوں کو پروڈکشن تک پہنچنے سے پہلے validate کرتے ہیں، اور ایجنٹ سے چلنے والا لوپ سسٹم کو مسلسل خود بہتری کے بہاؤ میں رکھتا ہے. 

Thrive Holdings کا ڈھانچہ ہمیں مخصوص صنعتوں میں اس ماحول کو دہرانے کی اجازت دیتا ہے. Holdings مالک بھی ہے اور Operator بھی، اس لیے ہماری مشترکہ انجینئرنگ ٹیمیں Crete جیسے کاروباروں کے اندر سے براہِ راست ماہرین اور پروڈکشن data کے ساتھ کام کر سکتی ہیں، vendor کے طور پر نہیں بلکہ شراکت داروں کے طور پر. اس کا مطلب ہے کہ ٹیکنالوجی، پروڈکٹ اور سروس سب ایک ہی چھت تلے ہیں تاکہ ہم تیزی سے آگے بڑھ سکیں اور غیر معمولی پروڈکٹس بنا سکیں.

ایک سینئر اکاؤنٹنٹ جس نے پچھلے سال ٹیکس تیاری پر 180 گھنٹے صرف کیے تھے، اس سال صرف 15 گھنٹے صرف کیے. اس نے اس وقت کا ایک حصہ اپنے ہر کلائنٹ کو فون کرنے اور ان کے ریٹرنز سمجھانے میں لگایا، جو قریبی خدمت کی ایسی سطح تھی جو ایک سال پہلے ممکن نہیں تھی. باقی وقت اس نے نئے کلائنٹس لینے اور نئی سروس پیشکشوں تک توسیع کے لیے استعمال کیا.

اب ہماری ٹیمیں مل کر Tax AI کے اسی تین حصوں والے ڈیزائن کو Thrive Holdings⁠(نئی ونڈو میں کھلتا ہے) میں دوسرے شعبوں کے ورک فلوز بنانے کے لیے blueprint کے طور پر استعمال کر رہی ہیں؛ اکاؤنٹنگ ورک فلوز جیسے bookkeeping اور audit، اور عملیاتی ورک فلوز جیسے IT help desk automation. شعبوں اور صنعتوں میں، خود بہتر ہونے والے ایجنٹس کا وسیع تر وعدہ برقرار ہے. بہترین ایجنٹس کو لوگ اس طرح رہنمائی دیتے ہیں کہ وہ وقت کے ساتھ زیادہ قابل، زیادہ قابلِ اعتماد، اور زیادہ قیمتی بنتے جائیں.

اس پروجیکٹ پر کام کرنے والی OpenAI ٹیم کے بارے میں مزید جاننے کے لیے، رابطہ کریں.