အဓိက အကြောင်းအရာသို့ ကျော်သွားရန်
OpenAI

Codex ဖြင့် ကိုယ်တိုင်တိုးတက်သော အခွန်အေးဂျင့်များ တည်ဆောက်ခြင်း

နည်းပညာဝန်ထမ်းများမှ - Aravind Srinivasan & Samay Shamdasani (Thrive Holdings), Arthur Fernandes Araujo & John de Wasseige (OpenAI)

ဖွင့်နေသည်…

Thrive Holdings နှင့် OpenAI သည် လက်တွေ့လုပ်ဆောင်သူ ကျွမ်းကျင်မှုကို Codex မောင်းနှင်သော လှည့်ပတ်မှုနှင့် ပေါင်းစပ်ကာ Crete စာရင်းကိုင်များအတွက် Tax AI ကို မည်သို့ ပူးတွဲတီထွင်ခဲ့ပုံ

လက်တွေ့ကမ္ဘာ စနစ်များသည် lab ထဲတွင် ပြုမူသည့်ပုံစံနှင့် production တွင် မတူဘဲ၊ deployment မတိုင်မီ ကြိုတင်ခန့်မှန်းရန် ခက်ခဲသော ပုံစံများဖြင့် ပျက်ကွက်တတ်သည်။ အဖွဲ့များသည် launch ပြီးနောက်မှ ထိုပျက်ကွက်မှုများကို မကြာခဏ တွေ့ရှိကြပြီး၊ edge case များကို စစ်ဆေးခြင်း၊ တုံ့ပြန်ညွှန်ကြားချက်များကို ချိန်ညှိခြင်းနှင့် production feedback ကို တည်တံ့သော ထုတ်ကုန်တိုးတက်မှုများအဖြစ် ပြောင်းလဲခြင်းတွင် ရက်သတ္တပတ်များစွာ ကုန်ဆုံးတတ်သည်။ feedback လှည့်ပတ်မှုသည် လက်ဖြင့်လုပ်ရပြီး နှေးကွေးကာ၊ အင်ဂျင်နီယာတစ်ဦးက တိုးတက်အောင် လုပ်ပေးမှသာ ပိုကောင်းလာသည်။ သို့သော် ယနေ့တွင် စဉ်းစားဆင်ခြင်ပြီး ဒီဇိုင်းဆွဲထားသော eval infrastructure၊ လက်တွေ့လုပ်ဆောင်သူများနှင့် လက်တွေ့ကမ္ဘာ ပတ်ဝန်းကျင်များသို့ တိုက်ရိုက်ဝင်ရောက်နိုင်မှု၊ နှင့် Codex ၏ စွမ်းဆောင်ရည်အမြင့်ဆုံး အေးဂျင့်စွမ်းရည်များဖြင့် ကိုယ်တိုင်တိုးတက်နိုင်သော အေးဂျင့်များကို တည်ဆောက်နိုင်သည်။

ဤပို့စ်တွင် ဤအမျိုးအစား အေးဂျင့်ကို တည်ဆောက်ရန် Codex ကို မည်သို့ အသုံးပြုခဲ့သည်ကို ရှင်းလင်းဖော်ပြမည်။ ပြီးခဲ့သည့် ခြောက်လအတွင်း OpenAI ၏ field တွင် တိုက်ရိုက်ပါဝင်သော အင်ဂျင်နီယာများနှင့် သုတေသီများသည် Thrive Holdings ၏ အင်ဂျင်နီယာများနှင့်အတူ Crete(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) ၏ စာရင်းကိုင်လုပ်ငန်း 30+ ခုပါဝင်သော ကွန်ရက်အတွက် Tax AI ကို ပူးပေါင်းတည်ဆောက်ခဲ့ပြီး ပိုမိုရှုပ်ထွေးလာသော အခွန် return များ ပြင်ဆင်ရာတွင် ကူညီပေးခဲ့သည်။ အင်ဂျင်နီယာများကို ပျက်ကွက်မှုတစ်ခုချင်းစီ ရှာဖွေပြင်ဆင်ရန်သာ မမှီခိုဘဲ၊ Tax AI သည် Codex ကို အသုံးပြုကာ production အသုံးပြုမှုကို ကိုယ်ပိုင်တိုးတက်မှုကို အားဖြည့်ပေးသော ဖွဲ့စည်းထားသည့် signal များအဖြစ် ပြောင်းလဲသည်။

Crete ၏ လက်တွေ့လုပ်ဆောင်သူများသည် ရာသီတစ်ခုစီတွင် အခွန် return သောင်းချီ ပြင်ဆင်ကြပြီး၊ ထိုအတွက် အခြေခံ စာရွက်စာတမ်း သန်းချီကို ကိုင်တွယ်ရသည်။ အလယ်အလတ်မှ အကြီးစား ရှုပ်ထွေးမှုရှိသော filing များအတွက် data entry တစ်ခုတည်းကပင် return တစ်ခုလျှင် ရှစ်နာရီ ကြာနိုင်ပြီး၊ မကြာခဏ ရှုပ်ထွေးသော data source များ၊ ယခင်နှစ် စာရွက်စာတမ်းများ၊ နှင့် လက်ဖြင့် ထုတ်ယူခြင်း၊ တွက်ချက်ခြင်းတို့ ပါဝင်သည်။ ၎င်းတို့က အခွန်ရာသီ၏ အလုပ်အများဆုံးကာလအတွင်း အခွန်ပြင်ဆင်မှုသည် အဓိက bottleneck တစ်ခုဖြစ်ကြောင်း ကျွန်ုပ်တို့ကို ညွှန်ပြခဲ့သည်။

ဤပြဿနာကို ဖြေရှင်းရန် Tax AI သည် ယခုအခွန်ရာသီ pilot တွင် ပါဝင်ခဲ့သော Crete လုပ်ငန်းများတစ်လျှောက် အခွန် return 7,000 ကို ကိုင်တွယ်ခဲ့သည်။ စနစ်သည် 1040 နှင့် 1041 အခွန် return များ ပြင်ဆင်ရာတွင် အချိန်ကုန်သော လုပ်ငန်းစဉ်အများစုကို အလိုအလျောက်လုပ်ဆောင်ပေးသော်လည်း၊ ထိရောက်မှုတိုးလာခြင်းထက် ပိုမိုဆွဲဆောင်မှုရှိသည်မှာ စနစ်ကိုယ်တိုင်သည် သုံးလမတိုင်မီ ပထမဆုံး deploy လုပ်ခဲ့သော version ထက် တိုင်းတာနိုင်လောက်အောင် ပိုကောင်းလာခြင်းဖြစ်သည်။

တိုင်းတာနိုင်သော ကိုယ်တိုင်တိုးတက်မှု

Tax AI တွင် လက်တွေ့လုပ်ဆောင်သူများသည် client အလိုက် မှတ်စုများနှင့်အတူ အရင်းအမြစ်ဖိုင်များကို upload လုပ်သည်။ ထို့နောက် Tax AI သည် review အတွက် အသင့်ဖြစ်သော tax engine submission တစ်ခုကို ဖန်တီးသည်။ ၎င်းသည် လက်တွေ့လုပ်ဆောင်သူများ၏ အခွန်ပြင်ဆင်ချိန်၏ သုံးပုံတစ်ပုံခန့်ကို သက်သာစေပြီး၊ return များကို တိကျမှု 97% အထိဖြင့် draft လုပ်ပေးကာ၊ ဆောင်ကြဉ်းပေးမှု ပမာဏကို 50% ခန့် တိုးစေသဖြင့် client များနှင့် အချိန်ပိုကုန်နိုင်ရန် နေရာပို ဖန်တီးပေးသည်။ 

နောက်ပိုင်းတွင် ပြင်ဆင်ရန် မလိုအပ်ဘဲ Tax AI က return တစ်ခုကို မည်မျှ တိကျစွာ ပြီးစီးစေနိုင်သည်ကို နားလည်ခြင်းဖြင့် ဤတိုးတက်မှုကို ကျွန်ုပ်တို့ တိုင်းတာနိုင်သည်။ return များအနက် မည်မျှက 75%၊ 90% သို့မဟုတ် 100% မှန်ကန်သော အကွက်ဖြည့်စွက်မှုသို့ ရောက်ရှိသည်ကို စစ်ဆေးခြင်းဖြင့် တိကျမှုကို တိုင်းတာသည်။ launch အချိန်တွင် return များ၏ လေးပုံတစ်ပုံသာ 75% မှန်ကန်သော အကွက်ဖြည့်စွက်မှုသို့ ရောက်ရှိခဲ့သော်လည်း၊ ခြောက်ပတ်အတွင်း 86% သည် ထိုအမှတ်သို့ ရောက်ရှိခဲ့သည်။ စနစ်သည် 90% နှင့် 100% မှန်ကန်သော အကွက်ဖြည့်စွက်မှု အဆင့်များတွင် ပိုမိုမြန်ဆန်သော တိုးတက်မှုကို ပြသခဲ့သည်။ ဤသတ်မှတ်ချက်များက မတူညီသော return များအတွက် လက်တွေ့လုပ်ဆောင်သူ၏ နောက်ဆက်တွဲ လုပ်ဆောင်မှု မည်မျှ လိုအပ်နေသေးသည်ကို လက်တွေ့ကျကျ မြင်နိုင်စေသည်။ 

အစပိုင်းတွင် Tax AI သည် W-2 နှင့် 1099 များကဲ့သို့ ပိုမိုရိုးရှင်းသော အလုပ်များကို ကိုင်တွယ်ခဲ့သည်။ ရာသီတိုးလာသည်နှင့်အမျှ ၎င်းသည် K-1 များ၊ schedule များနှင့် ပိုမိုခက်ခဲသော edge case များပါဝင်သည့် ပိုမိုရှုပ်ထွေးသော return များသို့ ရွှေ့ပြောင်းသွားခဲ့သည်။ စွမ်းရည်အသစ်တိုင်းသည် လက်ဖြင့်လုပ်ရန် ပိုခက်ခဲပြီး အချိန်ပိုကုန်သော လုပ်ငန်းများကို ကိုင်တွယ်လာသောကြောင့် ယခင်ထက် return တစ်ခုလျှင် အချိန်ပို သက်သာစေခဲ့သည်။ ယနေ့အထိ ဆက်လက်တိုးတက်နေမှုကို ကျွန်ုပ်တို့ မြင်တွေ့နေရဆဲဖြစ်သည်။

နောက်တွင် ကျွန်ုပ်တို့၏ အဖွဲ့များက Tax AI ကို ကိုယ်တိုင်တိုးတက်နိုင်အောင် မည်သို့ ပူးတွဲအင်ဂျင်နီယာလုပ်ခဲ့သည်ကို အရေးကြီးသော အခြေခံတိုင် သုံးခုအပေါ် မူတည်၍ ရှင်းပြမည် - 1) ကျွမ်းကျင် လက်တွေ့လုပ်ဆောင်သူ feedback၊ 2) production trace များ (input မှ နောက်ဆုံး output အထိ ဖွဲ့စည်းထားသော မှတ်တမ်း) နှင့် 3) ဆက်တိုက် ပိုမိုမြန်ဆန်သော ထုတ်ကုန်ဖွံ့ဖြိုးတိုးတက်မှုကို ဖြစ်စေရန် tailored eval များအပေါ် အခြေခံသော Codex မောင်းနှင်သည့် iteration loop ဖြစ်သည်။ ကျွန်ုပ်တို့၏ အတွေ့အကြုံသည် လက်တွေ့လုပ်ဆောင်သူ ကျွမ်းကျင်မှုက စနစ်တစ်ခုလုံး၏ အရည်အသွေးနှင့် ၎င်းအတွင်း စီးဆင်းနေသော data ကို ပုံဖော်ရာတွင် အဓိကကျသော နယ်ပယ်များရှိ အခြားတည်ဆောက်သူများအတွက် အသုံးဝင်မည်ဟု မျှော်လင့်ပါသည်။

Tax AI သည် ပိုမိုရှုပ်ထွေးသော တင်သွင်းမှုများသို့ တိုးချဲ့လာသည့်အခါ၊ အမှတ်ပေးထားသော return များအနက် 75%၊ 90% နှင့် အပြည့်အဝ ပြီးစီးမှုသို့ ရောက်ရှိသည့် အချိုးသည် အခွန်ရာသီတစ်လျှောက် ဆက်လက် မြင့်တက်ခဲ့သည်။

ပြဿနာ

အခွန်ပြင်ဆင်မှု၏ ပိုမိုခက်ခဲသော အစိတ်အပိုင်းများ (K-1 များ၊ အငှားအိမ်ခြံမြေ schedule များနှင့် အရင်းအမြစ်ဖိုင် အများအပြားအကြား တန်ဖိုးများကို ညှိနှိုင်းရသော အခွန်ပုံစံများ) သို့ တိုးချဲ့လာသည်နှင့်အမျှ၊ အမှန်တကယ် စိန်ခေါ်မှုမှာ ထုတ်ကုန်က ရှုပ်ထွေးသော production ပျက်ကွက်မှုများကို မြင်သာ၊ နားလည်နိုင်ပြီး လုပ်ဆောင်နိုင်အောင် ပြုလုပ်ပေးနိုင်မလားဆိုတာ ဖြစ်ကြောင်း ထင်ရှားလာခဲ့သည်။

ထုတ်ကုန်၏ အစောပိုင်းနေ့ရက်များတွင် ပြင်ဆင်မှုအများစုသည် လက်ဖြင့်လုပ်ရသည်။ လက်တွေ့လုပ်ဆောင်သူများသည် စနစ်အမှားများကို ပြင်ဆင်နိုင်သော်လည်း၊ ထုတ်ကုန်သည် context အပြည့်အစုံကို မဖမ်းယူနိုင်ခဲ့ပါ - filing မတိုင်မီ ပြောင်းလဲထားသော တန်ဖိုးတစ်ခုသည် အမှန်တကယ် ထုတ်ယူမှုလွဲချော်မှု၊ mapping ပြဿနာ၊ ထုတ်ကုန်ပံ့ပိုးမှု မရှိခြင်း၊ သို့မဟုတ် မျှော်မှန်းထားသော workflow noise ကို ထင်ဟပ်နိုင်သည်။ ထိုကိစ္စများကို ခွဲခြားဖြေရှင်းရန် အင်ဂျင်နီယာအဖွဲ့၏ နောက်ဆက်တွဲ လုပ်ဆောင်မှု လိုအပ်နေဆဲဖြစ်သည်။ အင်ဂျင်နီယာများသည် coding အေးဂျင့်များကို အသုံးပြုနိုင်သော်လည်း၊ စနစ်ကို တိုးတက်ရေး လှည့်ပတ်မှုအတွင်း AI ကို အဓိပ္ပာယ်ရှိစွာ အသုံးပြုရန် ဒီဇိုင်းမဆွဲရသေးပါ။ ကျော်ဖြတ်ရမည့်စိန်ခေါ်မှုကို သတ်မှတ်ရန် လိုအပ်သော signal ကို ကျွန်ုပ်တို့ မရရှိသေးခဲ့ပါ။

ကျွန်ုပ်တို့၏ နည်းလမ်း - အပိုင်းသုံးပိုင်း လှည့်ပတ်မှု

ထို့ကြောင့် စနစ်ကို မဏ္ဍိုင်ကြီးသုံးခုအပေါ် အခြေခံ၍ ဒီဇိုင်းဆွဲခဲ့သည် -

  1. လက်တွေ့လုပ်ဆောင်သူများနှင့် နီးကပ်နေပါ - အလုပ်ကို လုပ်နေသူများက ထုတ်ကုန် သင်ယူသည့်အရာကို ဦးတည်ပေးရမည်။ ၎င်းတို့၏ အတွေးအမြင်နှင့် နားလည်မှုက မည်သည့်အမှားများ အရေးကြီးသည်ကို ဖော်ပြပေးပြီး workflow ၏ မည်သည့်အစိတ်အပိုင်းများကို နောက်တစ်ဆင့် အာရုံစိုက်သင့်သည်ကို သိရှိစေသည်။
  2. production က အထောက်အထား ဖန်တီးနိုင်အောင် ထုတ်ကုန်ကို တည်ဆောက်ပါ - ထုတ်ကုန်သည် input နှင့် output များထက် ပိုမိုသော အရာများကို ဖမ်းယူရမည်။ အရင်းအမြစ်ပစ္စည်းမှ ထုတ်ယူထားသော အကွက်များနှင့် provenance၊ ထို့နောက် downstream submission နှင့် ကျွမ်းကျင်သူ ပြင်ဆင်မှုအထိ လမ်းကြောင်းအပြည့်အစုံကို ဖမ်းယူရမည်။
  3. Codex မောင်းနှင်သော တိုးတက်ရေး လှည့်ပတ်မှုကို ဖန်တီးပါ - production ပြဿနာများကို မြင်သာပြီး ဖွဲ့စည်းထားသောအခါ၊ ၎င်းတို့သည် တွေ့ရှိချက်များ၊ tailored eval များနှင့် ကန့်သတ်ထားသော အင်ဂျင်နီယာ လုပ်ငန်းတာဝန်များအဖြစ် ပြောင်းလဲနိုင်သည်။ ထို့နောက် Codex သည် စုံစမ်းရန်၊ ပြောင်းလဲမှုများ အဆိုပြုရန်၊ ၎င်းတို့ကို ပစ်မှတ်ထား eval များနှင့် regression eval များအပေါ် အတည်ပြုရန် ကူညီနိုင်ပြီး၊ လက်ဖြင့်သာ လုပ်သော iteration cycle ထက် ထုတ်ကုန်ကို ပိုမိုမြန်ဆန်စွာ ရှေ့တိုးစေနိုင်သည်။ 

အောက်ပါ အငှားအိမ်ခြံမြေ ဥပမာသည် ထိုလှည့်ပတ်မှု မည်သို့ လက်တွေ့အလုပ်လုပ်သည်ကို ပြသပြီး၊ လက်တွေ့လုပ်ဆောင်သူ ပြင်ဆင်မှုတစ်ခုက ဖွဲ့စည်းထားသော တွေ့ရှိချက်တစ်ခု၊ ထို့နောက် eval ပစ်မှတ်တစ်ခု၊ နောက်ဆုံးတွင် Codex ကန့်သတ်ထားသော အင်ဂျင်နီယာ လုပ်ငန်းတာဝန်တစ်ခုအဖြစ် မည်သို့ ပြောင်းလဲသွားသည်ကို ရှင်းပြပေးသည်။

အငှားအိမ်ခြံမြေ ဥပမာ

အငှားအိမ်ခြံမြေ ဝင်ငွေကို တစ်ဦးချင်း အခွန် return ၏ Schedule E တွင် တင်ပြသည်။ အင်ဂျင်နီယာ ရှုထောင့်မှကြည့်လျှင် ၎င်းကို ထုတ်ယူရသော လုပ်ငန်းတာဝန်သည် ဖော်ပြရန် ရိုးရှင်းသော်လည်း ကောင်းစွာ လုပ်ဆောင်ရန် ခက်ခဲသည်။ စနစ်သည် ရှုပ်ထွေးသော အရင်းအမြစ်ပစ္စည်းများ (လက်ရေးမှတ်စုများ၊ email များ၊ spreadsheet များနှင့် အခြား client ဖိုင်များ) ကို ဖတ်ရှုရပြီး၊ စနစ်က အခွန်အင်ဂျင်သို့ ယုံကြည်စိတ်ချစွာ ချိတ်ဆက်နိုင်သော အငှားအိမ်ခြံမြေ အကွက်များကို ထုတ်ယူကာ၊ လက်တွေ့လုပ်ဆောင်သူက ရလဒ်ကို အတည်ပြု သို့မဟုတ် ပြင်ဆင်နိုင်ရန် လုံလောက်သော အထောက်အထားကို ထိန်းသိမ်းထားရသည်။ အောက်ပါ ရိုးရှင်းထားသော ဥပမာသည် ထိုအရင်းအမြစ်ဖိုင်များနှင့် ထုတ်ယူထားသော output များ မည်သို့ ဖြစ်နိုင်သည်ကို ပြသသည်။

""

အငှားအိမ်ခြံမြေ အရင်းအမြစ်ပက်ကေ့ချ်ကို နောက်ပိုင်း အခွန်အင်ဂျင် အယူအဆများနှင့် ချိတ်ဆက်မီ ကိုးကားထားသော အကွက်များအဖြစ် စံညှိထားသည်။

1. လက်တွေ့လုပ်ဆောင်သူ၏ ပြင်ဆင်မှုက ပျက်ကွက်မှုတစ်ခုကို ဖော်ပြသည်

အေးဂျင့်က ခန့်မှန်းထားသော တန်ဖိုးနှင့် တင်သွင်းပြီးသော အခွန် return မှ အမှန်တကယ် တန်ဖိုးကြား ကွာခြားမှုသည် အမှန်တကယ် ထုတ်ယူမှုလွဲချော်မှု ဖြစ်နိုင်သလို၊ လက်တွေ့လုပ်ဆောင်သူ၏ နှစ်သက်မှု၊ အခွန်အင်ဂျင်အတွင်း ယခင်နှစ် return မှ ဆက်လက်ယူဆောင်လာသော တန်ဖိုး၊ သို့မဟုတ် filing workflow ၏ အခြားနေရာတွင် ထည့်သွင်းထားသော သို့မဟုတ် ပြောင်းလဲထားသော တန်ဖိုးလည်း ဖြစ်နိုင်သည်။ မည်သည့် လုပ်ဆောင်ချက်များက လက်တွေ့လုပ်ဆောင်သူ၏ ပြင်ဆင်မှုလိုအပ်သည် သို့မဟုတ် တင်သွင်းမှုကို တားဆီးသည်ကို ခွဲခြားသိရှိနိုင်ရန် လက်တွေ့လုပ်ဆောင်သူများက ဤကိစ္စများကို နားလည်ခွဲခြားရာတွင် ကူညီပေးခဲ့သည်။

ဤပြင်ဆင်မှုများကို အသေးစိတ် မြင်နိုင်ခဲ့သောကြောင့်၊ ပြန်လည်သုံးသပ်မှု လုပ်ငန်းစဉ်ကို နောက်ဆုံးအဆင့် ပျက်ကွက်ပြီးနောက် လုပ်ရသော အဆင့်မှ ဆက်တိုက် သင်ယူမှု လှည့်ပတ်မှုတစ်ခုအဖြစ် ပြောင်းလဲနိုင်ခဲ့သည်။ ကျွမ်းကျင်သူများ၏ လုပ်ဆောင်ချက်များကို ဖွဲ့စည်းထားသော ဒေတာအဖြစ် ဖမ်းယူနိုင်ရန် workflow ကို ဒီဇိုင်းဆွဲခဲ့သည်။ ယခုအခါ intervention တိုင်းသည် Tax AI က အတိအကျ ဘာကို အဆိုပြုခဲ့သည်၊ လက်တွေ့လုပ်ဆောင်သူက ဘာကို ပြင်ဆင်ခဲ့သည်၊ နောက်ဆုံးတွင် တင်သွင်းသော return ထဲသို့ ဘာဝင်သွားသည်ကို မှတ်တမ်းတင်ခြင်းဖြင့် ထုတ်ကုန်၏ တိုးတက်ရေး လှည့်ပတ်မှုကို အားဖြည့်ပေးသည်။

2. ထုတ်ကုန် trace များက ပြင်ဆင်မှုများကို eval များအဖြစ် ပြောင်းလဲသည်

အငှားအိမ်ခြံမြေကဲ့သို့ ရှုပ်ထွေးသော workflow တစ်ခုအတွက်၊ စနစ်သည် အရင်းအမြစ်ဖိုင်များနှင့် တင်သွင်းပြီးသော return ကြားတွင် ဖြစ်ပျက်သမျှကို ထိန်းသိမ်းထားရသည်။ ထိုလမ်းကြောင်းတစ်လျှောက်တွင် စာရွက်စာတမ်းများကို စုစည်း၊ ခွဲခြား၊ အမျိုးအစားသတ်မှတ်ပြီး၊ အငှားအိမ်ခြံမြေ အကွက်များကို အရင်းအမြစ်ပစ္စည်းသို့ ပြန်လည်ကိုးကားချက်များနှင့်အတူ ထုတ်ယူကာ၊ ထိုတန်ဖိုးများကို အခွန်အင်ဂျင်ထဲသို့ ချိတ်ဆက်ထည့်သွင်းပြီး၊ တင်သွင်းမီ လက်တွေ့လုပ်ဆောင်သူများက ၎င်းတို့ကို ထပ်မံပြင်ဆင်နိုင်သေးသည်။ ထိုထုတ်ကုန်အဆင့် trace များကြောင့် ပျက်ကွက်မှု ဘယ်နေရာတွင် ဖြစ်ပွားခဲ့သည်ကို စုံစမ်းနိုင်လာသည်။ လက်တွေ့လုပ်ဆောင်သူ၏ ပြင်ဆင်မှုများကို အသုံးဝင်သော evaluation ပစ်မှတ်များအဖြစ် ပြောင်းလဲရန်၊ စနစ်သည် ၎င်းတို့ကို အဆင့်သုံးဆင့်ဖြင့် ကိုင်တွယ်သည် -

  • ကွာခြားချက်ကို ဖမ်းယူပါ - Tax AI ၏ output ကို တင်သွင်းပြီးသော return နှင့် နှိုင်းယှဉ်ကာ မျှော်မှန်းတန်ဖိုး၊ ခန့်မှန်းတန်ဖိုးနှင့် ထိုကွာခြားချက်သည် လုပ်ဆောင်နိုင်ပုံရှိမရှိကို ဖမ်းယူထားသော အကွက်အဆင့် review row များ ထုတ်ပေးသည်။
  • ဆက်စပ်သော ပျက်ကွက်မှုများကို အုပ်စုဖွဲ့ပါ - ဆင်တူသော review row များကို ထပ်တလဲလဲ ဖြစ်သော ထုတ်ကုန်ပျက်ကွက်မှုများနှင့် မျှော်မှန်းထားသော workflow noise ကို ခွဲထုတ်ရန် အုပ်စုဖွဲ့သည်။ ဥပမာအားဖြင့်၊ ထပ်တလဲလဲ ဖြစ်သော လက်တွေ့လုပ်ဆောင်သူ ပြင်ဆင်မှုများက Tax AI သည် “fair rental days” အကွက်များကို မကြာခဏ လွဲချော်နေသည်၊ “other expenses” ကို မှားယွင်းကိုင်တွယ်နေသည်၊ သို့မဟုတ် တူညီသော အရင်းအမြစ်ပက်ကေ့ချ်အတွင်း အငှားအိမ်ခြံမြေ အများအပြားကို ရောထွေးနေသည်ကို ပြသနိုင်သည်။
  • ထပ်တလဲလဲ ပုံစံများကို eval ပစ်မှတ်များအဖြစ် ပြောင်းပါ - ပြန်လည်သုံးသပ်ပြီး တိုင်းတာပြီးနောက်၊ ထပ်တလဲလဲ တွေ့ရှိချက်များသည် Codex တိုးတက်စေရန် ရှင်းလင်းသော eval ပစ်မှတ်များ ဖြစ်လာသည်။
""

အငှားအိမ်ခြံမြေ ပြန်လည်သုံးသပ်မှု row များသည် ထပ်တလဲလဲ ဖြစ်သော ထုတ်ကုန်ချို့ယွင်းမှုများကို မျှော်မှန်းထားသော noise မှ ခွဲထုတ်ပြီး၊ လုပ်ဆောင်နိုင်သော ကိစ္စများကို Codex အတွက် တက်လှမ်းရမည့် evaluation ပစ်မှတ်များအဖြစ် ပြောင်းလဲပေးသည်။

3. တွေ့ရှိချက်သည် Codex အတွက် ကျော်ဖြတ်ရမည့် စိန်ခေါ်မှုတစ်ခု ဖြစ်လာသည်

တတိယမဏ္ဍိုင်ကြီးမှာ ဤ eval အသစ်များအပေါ် လုပ်ဆောင်နိုင်သော အင်ဂျင်နီယာ လှည့်ပတ်မှုတစ်ခု ဖန်တီးခြင်းဖြစ်သည်။ ဤနေရာတွင် Codex သည် အဓိကကျလာသည်။

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့၏ eval pipeline က Tax AI သည် “fair rental days” အကွက်ကို အမြဲတမ်းလိုလို လွဲချော်နေပြီး၊ လက်တွေ့လုပ်ဆောင်သူများကတော့ ယုံကြည်စိတ်ချစွာ ဖြည့်သွင်းပေးနေသည်ဟု အချက်ပြသည်ဟု ယူဆကြည့်ပါ။ ဤတွေ့ရှိချက်ကို ကိုယ်စားပြု အရင်းအမြစ်ပက်ကေ့ချ်များနှင့် မျှော်မှန်း output များပါဝင်သော ပစ်မှတ်ထား eval set တစ်ခုအဖြစ် ထုပ်ပိုးထားပြီးဖြစ်သောကြောင့်၊ Codex သည် ထုတ်ကုန် scaffold အတွင်း တိုက်ရိုက် အရင်းခံအကြောင်းရင်းကို စုံစမ်းနိုင်သည်။

Codex သည် အရည်အသွေးမပြည့်မီသော နောက်ဆုံး output တစ်ခုတည်းနှင့်သာ အလုပ်လုပ်နေခြင်း မဟုတ်ပါ။ ၎င်းသည် trace၊ eval၊ repo နှင့် skills တို့ကို အတူတကွ စစ်ဆေးသည် -

  • pipeline ကို စုံစမ်းပါ - ပြဿနာသည် မပံ့ပိုးထားသော အကွက်တစ်ခုလား၊ လွဲချော်သော ထုတ်ယူမှုပုံစံလား၊ အရင်းအမြစ်ရွေးချယ်မှုပြဿနာလား၊ mapper ကွာဟချက်လား၊ သို့မဟုတ် grader ပြဿနာလားကို သတ်မှတ်ရန် အရင်းအမြစ်ပက်ကေ့ချ်များ၊ extraction စီမံချက်များ၊ mapper အပြုအမူနှင့် code path များကို စစ်ဆေးပါ။
  • ပစ်မှတ်ထား ပြင်ဆင်မှုများကို အကောင်အထည်ဖော်ပါ - extraction စီမံချက်ကို တိုးချဲ့ပါ၊ အငှားအိမ်ခြံမြေ စာရွက်စာတမ်းများအတွက် အရင်းအမြစ်ရွေးချယ်မှုကို ကောင်းမွန်အောင်လုပ်ပါ၊ tax-engine mapper ကို အပ်ဒိတ်လုပ်ပါ၊ သို့မဟုတ် မျှော်မှန်းထားသော workflow noise ကို ပျက်ကွက်မှုအဖြစ် ရေတွက်နေပါက grader ကို ပိုမိုတိကျအောင် ပြင်ဆင်ပါ။
  • အတည်ပြုပြီး အဆိုပြုပါ - ပစ်မှတ်ထား eval ကို ပြန်လည်လုပ်ဆောင်ပါ၊ ပိုမိုကျယ်ပြန့်သော regression suite များကို လုပ်ဆောင်ပါ၊ ထို့နောက် အင်ဂျင်နီယာ ပြန်လည်သုံးသပ်မှုအတွက် candidate pull request တစ်ခုကို တင်ပြပါ။
  • လှည့်ပတ်မှုကို ပိတ်ပါ - ထပ်တလဲလဲ ဖြစ်သော လက်တွေ့လုပ်ဆောင်သူ ပြင်ဆင်မှုကို တိုင်းတာနိုင်သော အင်ဂျင်နီယာ လုပ်ငန်းတာဝန်တစ်ခုအဖြစ် ပြောင်းပါ။ အထောက်အထား မရှင်းလင်းပါက သို့မဟုတ် လုံခြုံစွာ အလိုအလျောက်မလုပ်ဆောင်နိုင်ပါက၊ ထိုကိစ္စကို လှည့်ပတ်မှုအတွင်း အတင်းထည့်မလုပ်ဘဲ ထုတ်ကုန်အဖွဲ့ထံ ပြန်ပို့သည်။
""

အစမှအဆုံး ကိုယ်တိုင်တိုးတက်ရေး လှည့်ပတ်မှု - production trace များက ထပ်တလဲလဲ ဖြစ်သော အကွက်အဆင့် ပြင်ဆင်မှုများကို ဖော်ထုတ်ပေးပြီး၊ ၎င်းတို့သည် Codex က trace၊ evals၊ repo နှင့် skills တို့နှင့်အတူ စစ်ဆေးနိုင်သော ပျက်ကွက်မှု အချက်ပြများ ဖြစ်လာသည်။ လုပ်ဆောင်နိုင်သော ပုံစံများသည် ကန့်သတ်ထားသော evals များနှင့် ထုတ်ကုန်ပြောင်းလဲမှု ကိုယ်စားလှယ်များအဖြစ် ပြောင်းလဲသွားပြီး၊ မရှင်းလင်းသော ကိစ္စများကို ပြန်လည်သုံးသပ်ရန် အင်ဂျင်နီယာများထံ ပြန်ပို့သည်။ တင်ပို့ပြီးသော တိုးတက်မှုတိုင်းသည် နောက်တစ်ကြိမ် လှည့်ပတ်မှုအတွက် production အထောက်အထားအသစ်များ ဖန်တီးပေးသည်။

ဤလှည့်ပတ်မှုကို တည်ဆောက်ရန် Codex ကို မည်သို့ အသုံးပြုမည်နည်း

အငှားအိမ်ခြံမြေ ဥပမာသည် ပိုမိုကျယ်ပြန့်ပြီး ပြန်လည်အသုံးပြုနိုင်သော ပုံစံတစ်ခုကို ကိုယ်စားပြုသည် - production artifact များနှင့် trace များကို အသုံးပြု၍ အေးဂျင့်၏ စွမ်းရည်များကို တိုးတက်စေခြင်း။ production data မှ ပြန်လည်သုံးသပ်ပြီးသော တွေ့ရှိချက်များ၊ source trace များ၊ မျှော်မှန်းထားသော tax-engine output၊ သက်ဆိုင်ရာ code ဥပမာများနှင့် eval command များကို input အစုတစ်ခုအဖြစ် ပေးထားလျှင်၊ Codex သည် ရက်သတ္တပတ်များနှင့် လများအတွင်း စွမ်းဆောင်ရည်နှင့် တိကျမှုကို အဓိကကျကျ တိုးတက်စေနိုင်သည်။ ဤသည်မှာ harness engineering နှင့် Symphony ဆိုင်ရာ ကျွန်ုပ်တို့၏ အလုပ်တွင် ဖော်ပြထားသော အခြေခံသဘောတရားများအပေါ် တည်ဆောက်ထားခြင်းဖြစ်ပြီး၊ ထိုအရာများက Codex အတွက် လုပ်ငန်းတာဝန်များကို နားလည်လွယ်အောင် မည်သို့လုပ်ရမည်၊ ကန့်သတ်ထားသော context နှင့် tools များကို မည်သို့ပေးရမည်၊ အတည်ပြုခြင်းနှင့် လူသားပြန်လည်သုံးသပ်မှုကို ပတ်ဝန်းကျင်၏ အစိတ်အပိုင်းအဖြစ် မည်သို့ ထိန်းသိမ်းရမည်ကို ရှင်းပြထားသည်။ 

ထိုအထောက်အထားသည် Codex လုပ်ငန်းတာဝန်တစ်ခုအဖြစ် အလိုအလျောက် မပြောင်းလဲသွားပါ။ လက်တွေ့လုပ်ဆောင်သူ၏ ပြင်ဆင်မှုသည် ထုတ်ယူမှုလွဲချော်မှု၊ mapping ပြဿနာ၊ မပံ့ပိုးထားသော ထုတ်ကုန်အပြုအမူ၊ အခွန်ဆိုင်ရာ ဆုံးဖြတ်ချက်၊ သို့မဟုတ် မျှော်မှန်းထားသော workflow noise ကို ထင်ဟပ်စေနိုင်သည်။ ထပ်တလဲလဲ ဖြစ်သော ကွာခြားချက်များကို ပြန်လည်သုံးသပ်ပြီး လုပ်ဆောင်နိုင်သော တွေ့ရှိချက်တစ်ခုအဖြစ် အုပ်စုဖွဲ့ပြီးမှသာ စနစ်သည် ၎င်းတို့ကို ရှင်းလင်းသော အောင်မြင်မှုအခြေအနေရှိသည့် ကန့်သတ်ထားသော လုပ်ငန်းတာဝန်တစ်ခုအဖြစ် ပြောင်းလဲသည်။

ကျွန်ုပ်တို့သည် ဤအလိုအလျောက်လုပ်ဆောင်မှုကို ထုတ်ကုန်၏ ကန့်သတ်ထားသော အလွှာတစ်ခုတွင် အသုံးချသည်။ ဤအလွှာသည် ထုတ်ယူမှုကို လုပ်ဆောင်ပြီး အရင်းအမြစ် စာရွက်စာတမ်းများကို အခွန် workflow များထဲသို့ ချိတ်ဆက်ပေးသည်။ အင်ဂျင်နီယာများသည် architecture၊ ထုတ်ကုန်ဆုံးဖြတ်ချက်များနှင့် တင်ပို့ခြင်းအတွက် တာဝန်ရှိနေဆဲဖြစ်သည်။ လက်တွေ့လုပ်ဆောင်သူများသည် ၎င်းတို့ လုပ်နေပြီးသား အလုပ်များမှတစ်ဆင့် တိုးတက်ရေး လှည့်ပတ်မှုကို ဦးတည်ပေးသည် - ထုတ်ယူထားသော တန်ဖိုးများကို ပြင်ဆင်ခြင်း၊ return များကို ပြန်လည်သုံးသပ်ခြင်းနှင့် နောက်ဆုံး filing များကို အတည်ပြုခြင်း။

Codex အတွက် ရလဒ်မှာ မရေရာသော သတိပေးချက်တစ်ခု မဟုတ်ဘဲ အထောက်အထား၊ ပြင်ဆင်နိုင်သော ထုတ်ကုန်မျက်နှာပြင်များနှင့် ရှင်းလင်းသော အတည်ပြု gate များပါဝင်သည့် ကန့်သတ်ထားသော အင်ဂျင်နီယာ လုပ်ငန်းတာဝန်တစ်ခု ဖြစ်သည်။ ကိုယ်စားပြု အငှားအိမ်ခြံမြေ လုပ်ငန်းတာဝန်တစ်ခုအတွက် context ကို အောက်ပါအတိုင်း အကျဉ်းချုပ်နိုင်သည် -

ရိုးရိုးစာသား

1
/candidates/FIND-RENTAL-0042/
2
3
├── repo/ [1]
4
│ └── branch: codex/fix-rental-0042
5
│ │
6
│ ├── AGENTS.md
7
│ │
8
│ ├── tasks/FIND-RENTAL-0042/
9
│ │ ├── task.yaml
10
│ │ ├── EXEC_PLAN.md
11
│ │ └── RESULTS.md
12
│ │
13
│ ├── app/tax-ai/rental-income/ [2]
14
│ │ ├── agent.ts
15
│ │ ├── schema.ts
16
│ │ ├── provenance.ts
17
│ │ └── mapper.ts
18
│ │
19
│ ├── evals/ [3]
20
│ │ ├── datasets/fair-rental-days.yaml
21
│ │ ├── suites/fair-rental-days.yaml
22
│ │ ├── suites/rental-income-regression.yaml
23
│ │ └── graders/rental-income.yaml
24
│ │
25
│ ├── skills/ [4]
26
│ │ ├── eval-runner/
27
│ │ └── tax-field-docs/
28
│ │
29
│ └── docs/ [4]
30
│ ├── architecture/
31
│ └── task-environments/
32
33
└── scoped-tools/ [5]
34
├── production-trace
35
├── source-artifacts
36
└── tax-engine-docs

ကန့်သတ်ထားသော Codex လုပ်ငန်းတာဝန် ပတ်ဝန်းကျင်တစ်ခုသည် ရေးသားပြင်ဆင်နိုင်သော worktree [1] ကို ဖတ်ရှုရန်သာရသော production context [5] မှ ခွဲထားသည်။ worktree တွင် Codex က စစ်ဆေးနိုင် သို့မဟုတ် ပြင်ဆင်နိုင်သော ကန့်သတ်ထားသည့် ထုတ်ကုန်မျက်နှာပြင် [2]၊ အောင်မြင်မှုကို သတ်မှတ်ပေးသော ပစ်မှတ်ထား eval များနှင့် regression eval များ [3]၊ နှင့် လုပ်ငန်းတာဝန်ကို မည်သို့ လုပ်ဆောင်ရမည်နှင့် ယခင်ဆုံးဖြတ်ချက်များကို မည်သို့ လေးစားလိုက်နာရမည်ကို encode လုပ်ထားသော ပြန်လည်အသုံးပြုနိုင်သည့် skills/docs များ [4] ပါဝင်သည်။ ဖတ်ရှုရန်သာရသော context သည် production trace၊ အရင်းအမြစ် စာရွက်စာတမ်းများ၊ Tax AI ခန့်မှန်းချက်၊ အပြီးသတ် return နှင့် tax-engine field documentation တို့ကို ပံ့ပိုးပေးသဖြင့် Codex သည် အခြေခံအထောက်အထားကို မပြောင်းလဲဘဲ ပျက်ကွက်မှုကို စုံစမ်းနိုင်သည်။

နယ်ပယ်အသစ်များသို့ တိုးချဲ့ခြင်း

တူညီသော လှည့်ပတ်မှုသည် အငှားအိမ်ခြံမြေများကို ကျော်လွန်၍လည်း အသုံးချနိုင်သည်။ အငှားအိမ်ခြံမြေများသည် 90% precision နှင့် recall သို့ ရောက်ရန် ခန့်မှန်းခြေ ခြောက်ပတ်နှင့် အင်ဂျင်နီယာ ကြီးကြပ်မှု များစွာ လိုအပ်ခဲ့သော်လည်း၊ ထိုအလုပ်က ပြန်လည်အသုံးပြုနိုင်သော abstraction များ၊ review artifact များ၊ eval စံနှုန်းများနှင့် implementation pattern များကို ထုတ်ပေးခဲ့ပြီး Schedule C နှင့် Schedule A ကဲ့သို့ ဆင်တူရှုပ်ထွေးသော schedule များကို ပံ့ပိုးရန် ပိုမိုလွယ်ကူစေခဲ့သည်။

Tax AI သည် ကိုယ်တိုင်တိုးတက်နိုင်သော အေးဂျင့်များကို တည်ဆောက်ရန် လမ်းကြောင်းတစ်ခုကို သက်သေပြသည်။ လက်တွေ့လုပ်ဆောင်သူများသည် ဝန်ဆောင်မှုကို ပေးအပ်ခြင်းဖြင့် တန်ဖိုးမြင့် feedback signal များကို ဖန်တီးပေးသည်။ ထုတ်ကုန် workflow များသည် ထို signal များကို ဖွဲ့စည်းထားသော အထောက်အထားအဖြစ် ထိန်းသိမ်းထားသည်။ eval အထောက်အပံ့ရှိသော အင်ဂျင်နီယာ စနစ်များသည် တိုးတက်မှုများကို production သို့ မရောက်မီ အတည်ပြုပေးပြီး၊ အေးဂျင့်စွမ်းအားဖြင့် လည်ပတ်သော လှည့်ပတ်မှုတစ်ခုက စနစ်ကို ဆက်တိုက် ကိုယ်တိုင်တိုးတက်နေသော စီးဆင်းမှုအတွင်း ထိန်းသိမ်းပေးသည်။ 

Thrive Holdings ၏ ဖွဲ့စည်းပုံက ဤပတ်ဝန်းကျင်ကို သီးသန့်စက်မှုလုပ်ငန်းများအတွင်း ပြန်လည်တည်ဆောက်နိုင်စေသည်။ Holdings သည် ပိုင်ရှင်လည်းဖြစ်၊ အော်ပရေတာလည်းဖြစ်သောကြောင့် ကျွန်ုပ်တို့၏ ပေါင်းစည်းထားသော အင်ဂျင်နီယာအဖွဲ့များသည် vendor အဖြစ်မဟုတ်ဘဲ မိတ်ဖက်များအဖြစ် Crete ကဲ့သို့သော လုပ်ငန်းများအတွင်းမှ လက်တွေ့လုပ်ဆောင်သူများနှင့် production data တို့နှင့် တိုက်ရိုက် အလုပ်လုပ်နိုင်သည်။ ဤအရာက နည်းပညာ၊ ထုတ်ကုန်နှင့် ဝန်ဆောင်မှုတို့ကို တစ်နေရာတည်းအောက်တွင် စုစည်းထားစေပြီး ကျွန်ုပ်တို့ကို ပိုမိုမြန်ဆန်စွာ ရွေ့လျားကာ ထူးချွန်သော ထုတ်ကုန်များ တည်ဆောက်နိုင်ရန် ကူညီပေးသည်။

ပြီးခဲ့သည့်နှစ်က အခွန်ပြင်ဆင်မှုအတွက် နာရီ 180 သုံးခဲ့သော အကြီးတန်း စာရင်းကိုင်တစ်ဦးသည် ယခုနှစ်တွင် 15 နာရီသာ သုံးခဲ့သည်။ သူမသည် ထိုအချိန်၏ တစ်စိတ်တစ်ပိုင်းကို မိမိ၏ client တစ်ဦးချင်းစီထံ ဖုန်းခေါ်ပြီး ၎င်းတို့၏ return များကို အတူတကွ ရှင်းပြပေးရာတွင် အသုံးပြုခဲ့ပြီး၊ ယင်းကဲ့သို့ အနီးကပ်ဝန်ဆောင်မှုအဆင့်သည် တစ်နှစ်မတိုင်မီက မဖြစ်နိုင်ခဲ့ပါ။ ကျန်ရှိသော အချိန်ကိုတော့ client အသစ်များ လက်ခံရန်နှင့် ဝန်ဆောင်မှုအသစ်များသို့ တိုးချဲ့ရန် အသုံးပြုခဲ့သည်။

ယခုအခါ ကျွန်ုပ်တို့၏ အဖွဲ့များသည် Thrive Holdings(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တစ်လျှောက် အခြားနယ်ပယ်များတွင် workflow များ တည်ဆောက်ရန် Tax AI မှ တူညီသော အပိုင်းသုံးပိုင်း ဒီဇိုင်းကို blueprint အဖြစ် အသုံးပြုနေကြသည်။ စာရင်းကိုင် workflow များဖြစ်သော bookkeeping နှင့် audit၊ နှင့် လုပ်ငန်းလည်ပတ်မှု workflow များဖြစ်သော IT help desk automation တို့ပါဝင်သည်။ နယ်ပယ်များနှင့် စက်မှုလုပ်ငန်းများတစ်လျှောက် ကိုယ်တိုင်တိုးတက်နိုင်သော အေးဂျင့်များ၏ ပိုမိုကျယ်ပြန့်သော ကတိကဝတ်သည် တည်ရှိနေဆဲဖြစ်သည်။ အကောင်းဆုံး အေးဂျင့်များကို လူများက ဦးတည်ပေးပြီး အချိန်ကြာလာသည်နှင့်အမျှ ပိုမိုစွမ်းဆောင်နိုင်၊ ပိုမိုယုံကြည်ရပြီး ပိုမိုတန်ဖိုးရှိလာစေရန် သင်ယူစေသည်။

ဤပရောဂျက်တွင် လုပ်ဆောင်ခဲ့သော OpenAI အဖွဲ့အကြောင်း ပိုမိုလေ့လာလိုပါက ဆက်သွယ်ပါ

စာရေးသူ

Aravind Srinivasan - Samay Shamdasani - Arthur Fernandes Araujoနှင့် John de Wasseige