پرش به محتوای اصلی
OpenAI

۶ خرداد ۱۴۰۵

مهندسی

ساخت عامل‌های مالیاتی خودبهبوددهنده با Codex

به قلم اعضای کادر فنی: Aravind Srinivasan و Samay Shamdasani (Thrive Holdings)، Arthur Fernandes Araujo و John de Wasseige (OpenAI)

در حال بارگذاری…

چگونه Thrive Holdings و OpenAI با ترکیب تخصص کارشناسان و یک حلقه مبتنی بر Codex، Tax AI را برای حسابداران Crete به‌صورت مشترک توسعه دادند

سامانه‌های دنیای واقعی در محیط تولید متفاوت از آزمایشگاه رفتار می‌کنند و به شیوه‌هایی از کار می‌افتند که پیش‌بینی آن‌ها پیش از استقرار دشوار است. تیم‌ها اغلب این شکست‌ها را پس از راه‌اندازی کشف می‌کنند و سپس هفته‌ها صرف بررسی موارد مرزی، تنظیم اعلان‌ها و تبدیل بازخورد تولید به بهبودهای پایدار محصول می‌کنند. حلقه بازخورد دستی و کند است و فقط زمانی بهتر می‌شود که یک مهندس آن را پیش ببرد. اما امروز، با زیرساخت ارزیابی که با دقت طراحی شده، دسترسی مستقیم به کارشناسان و محیط‌های واقعی، و قابلیت‌های عامل‌محور پیشروِ Codex، می‌توانید عامل‌هایی بسازید که خود را بهبود دهند.

در این مطلب، توضیح می‌دهیم چگونه از Codex برای ساخت این نوع عامل استفاده کردیم. در شش ماه گذشته، مهندسان و پژوهشگران مستقرشده OpenAI همراه با مهندسان Thrive Holdings همکاری کردند تا Tax AI را در کنار و برای شبکه بیش از ۳۰ شرکت حسابداری Crete(در یک پنجره جدید باز می‌شود) بسازند تا به آماده‌سازی اظهارنامه‌های مالیاتی هرچه پیچیده‌تر کمک کنند. Tax AI به‌جای تکیه بر مهندسان برای یافتن و رفع تک‌تک شکست‌ها، از Codex استفاده می‌کند تا استفاده در تولید را به سیگنال‌های ساخت‌یافته‌ای تبدیل کند که بهبود خودکار را تغذیه می‌کنند.

کارشناسان Crete در هر فصل ده‌ها هزار اظهارنامه مالیاتی آماده می‌کنند که مستلزم کار روی میلیون‌ها سند پایه است. برای پرونده‌های با پیچیدگی متوسط تا زیاد، فقط ورود داده می‌تواند برای هر اظهارنامه هشت ساعت زمان ببرد و اغلب شامل منابع داده آشفته، اسناد سال قبل، و استخراج و محاسبه دستی است. آن‌ها آماده‌سازی مالیات را به‌عنوان یک گلوگاه مهم در شلوغ‌ترین بازه فصل مالیات به ما نشان دادند.

برای حل این مشکل، Tax AI در این فصل مالیات ۷٬۰۰۰ اظهارنامه مالیاتی را در شرکت‌های Crete که در پایلوت شرکت داشتند پردازش کرد. این سامانه بخش زیادی از فرایند زمان‌بر آماده‌سازی اظهارنامه‌های مالیاتی 1040 و 1041 را خودکار می‌کند، اما حتی قانع‌کننده‌تر از افزایش بهره‌وری این است که خود سامانه به‌طور قابل‌اندازه‌گیری از نسخه‌ای که سه ماه پیش نخستین‌بار مستقر شد بهتر شده است.

خودبهبوددهی قابل‌اندازه‌گیری

در Tax AI، کارشناسان فایل‌های منبع را همراه با هر یادداشت ویژه مشتری بارگذاری می‌کنند. سپس Tax AI یک ارسال برای سامانه مالیاتی ایجاد می‌کند که آماده بازبینی است. این سامانه حدود یک‌سوم از زمان آماده‌سازی مالیات کارشناسان را صرفه‌جویی می‌کند، اظهارنامه‌ها را با دقتی تا ۹۷٪ پیش‌نویس می‌کند، و توان عملیاتی را حدود ۵۰٪ افزایش می‌دهد تا فضای بیشتری برای گذراندن وقت با مشتریان ایجاد شود. 

ما می‌توانیم این بهبود را با درک این موضوع کمی‌سازی کنیم که Tax AI تا چه اندازه می‌تواند یک اظهارنامه را بدون نیاز به اصلاح بعدی تکمیل کند. ما دقت را با بررسی این می‌سنجیم که چه سهمی از اظهارنامه‌ها به ۷۵٪، ۹۰٪ یا ۱۰۰٪ تکمیل صحیح فیلدها می‌رسند. در زمان راه‌اندازی، فقط یک‌چهارم اظهارنامه‌ها به ۷۵٪ تکمیل صحیح فیلدها رسیده بودند، اما ظرف شش هفته، ۸۶٪ به این سطح رسیدند. سامانه در سطوح ۹۰٪ و ۱۰۰٪ تکمیل صحیح فیلدها حتی رشد سریع‌تری نشان داد. این آستانه‌ها دیدی عملی به ما می‌دهند از اینکه انواع مختلف اظهارنامه‌ها هنوز چه میزان پیگیری از سوی کارشناس نیاز دارند. 

در ابتدا، Tax AI کارهای ساده‌تر مانند W-2 و 1099 را انجام می‌داد. با پیش رفتن فصل، به اظهارنامه‌های پیچیده‌تر با K-1، برنامه‌ها و موارد مرزی دشوارتر وارد شد. هر قابلیت جدید نسبت به قبلی در هر اظهارنامه زمان بیشتری ذخیره می‌کرد، زیرا وظایفی که بر عهده می‌گرفت دشوارتر و انجام دستی آن‌ها زمان‌برتر بود. ما امروز هم همچنان شاهد پیشرفت مداوم هستیم.

در ادامه، توضیح می‌دهیم که تیم‌های ما چگونه Tax AI را به‌صورت مشترک طوری مهندسی کردند که با تکیه بر سه رکن حیاتی خودبهبوددهنده باشد: ۱) بازخورد کارشناسان خبره، ۲) ردپاهای تولید (تاریخچه‌ای ساخت‌یافته از ورودی‌ها تا خروجی نهایی)، و ۳) یک حلقه تکرار مبتنی بر Codex بر پایه ارزیابیهای سفارشی برای امکان‌دادن به توسعه پیوسته و سریع‌تر محصول. امیدواریم تجربه ما برای سازندگان دیگر در حوزه‌هایی مفید باشد که در آن‌ها تخصص کارشناسان برای شکل‌دادن به کیفیت سامانه کلان و داده‌های جاری در آن کلیدی است.

با گسترش Tax AI به اظهارنامه‌های پیچیده‌تر، سهم اظهارنامه‌های امتیازدهی‌شده‌ای که به ۷۵٪، ۹۰٪ و حالت تکمیل رسیدند، در طول فصل مالیاتی همچنان افزایش یافت.

مسئله

وقتی به بخش‌های دشوارتر آماده‌سازی مالیات وارد شدیم (K-1، برنامه‌های املاک اجاره‌ای، و فرم‌های مالیاتی‌ای که در آن‌ها مقادیر باید میان چند فایل منبع با هم تطبیق داده می‌شدند)، روشن شد که چالش واقعی این است که آیا محصول می‌تواند شکست‌های پیچیده تولید را قابل‌مشاهده، قابل‌فهم و قابل‌اقدام کند یا نه.

در روزهای نخست محصول، بیشتر اصلاحات دستی بود. کارشناسان می‌توانستند خطاهای سامانه را اصلاح کنند، اما محصول زمینه کامل را ثبت نمی‌کرد: یک مقدار تغییرکرده پیش از ثبت می‌توانست بازتاب‌دهنده خطای واقعی استخراج، مشکل نگاشت، نبود پشتیبانی محصول، یا نویز مورد انتظار جریان کاری باشد. مرتب‌سازی این موارد همچنان به پیگیری از سوی تیم مهندسی نیاز داشت. مهندسان می‌توانستند از عامل‌های کدنویسی استفاده کنند، اما سامانه هنوز برای استفاده معنادار از هوش مصنوعی درون یک حلقه بهبود طراحی نشده بود. ما سیگنال لازم برای شناسایی مسیر درست بهبود را نداشتیم.

رویکرد ما: یک حلقه سه‌بخشی

این ما را به طراحی سامانه حول سه رکن رساند:

  1. نزدیک به کارشناسان بمانید: افرادی که کار را انجام می‌دهند باید هدایت کنند که محصول چه چیزی را یاد بگیرد. شهود و درک آن‌ها نشان می‌دهد کدام خطاها مهم‌اند و کمک می‌کند مشخص شود روی کدام بخش‌های جریان کاری باید بعداً تمرکز کرد.
  2. محصول را طوری بسازید که تولید شواهد ایجاد کند: محصول باید بیش از ورودی‌ها و خروجی‌ها را ثبت کند؛ باید کل مسیر از مواد منبع، تا فیلدهای استخراج‌شده و منشأ آن‌ها، تا ارسال پایین‌دستی و اصلاح کارشناس را ثبت کند.
  3. یک حلقه بهبود مبتنی بر Codex بسازید: وقتی مسائل تولید قابل‌مشاهده و ساخت‌یافته شوند، می‌توانند به یافته‌ها، ارزیابیهای سفارشی و وظایف مهندسی محدودشده تبدیل شوند. سپس Codex می‌تواند به بررسی، پیشنهاد تغییرات، اعتبارسنجی آن‌ها در برابر ارزیابیهای هدفمند و رگرسیونی، و پیشبرد سریع‌تر محصول نسبت به یک چرخه تکرار کاملاً دستی کمک کند. 

نمونه املاک اجاره‌ای در ادامه نشان می‌دهد این حلقه در عمل چگونه کار می‌کند و شما را مرحله‌به‌مرحله از تبدیل یک اصلاح کارشناس به یک یافته ساخت‌یافته، سپس یک هدف ارزیابی، و در نهایت یک وظیفه مهندسی محدودشده برای Codex عبور می‌دهد.

نمونه ملک اجاره‌ای

درآمد ملک اجاره‌ای در Schedule E یک اظهارنامه مالیاتی فردی گزارش می‌شود. از دید مهندسی، توصیف وظیفه استخراج آن ساده است اما انجام خوب آن دشوار. سامانه باید مواد منبع آشفته (یادداشت‌های دست‌نویس، ایمیل‌ها، صفحات گسترده و دیگر فایل‌های مشتری) را بخواند، فیلدهای ملک اجاره‌ای را که سامانه می‌تواند با اطمینان به موتور مالیاتی نگاشت کند استخراج کند، و شواهد کافی حفظ کند تا یک کارشناس بتواند نتیجه را تأیید یا اصلاح کند. نمونه ساده‌شده زیر نشان می‌دهد این فایل‌های منبع و خروجی‌های استخراج‌شده ممکن است چگونه به نظر برسند.

«»

بسته داده‌‌های ملک اجاره‌ای پیش از نگاشت به مفاهیم سامانه مالیاتی پس از پردازش، به فیلدهای دارای استناد نرمال‌سازی می‌شود.

۱. اصلاحی از سوی یک کارشناس، باعث آشکار شدن شکست می‌شود

تفاوت میان مقدار پیش‌بینی‌شده توسط عامل و مقدار واقعی در اظهارنامه مالیاتی ثبت‌شده ممکن است نشان‌دهنده یک خطای واقعی در استخراج باشد، اما همچنین می‌تواند ناشی از ترجیح کارشناس، مقداری منتقل‌شده از اظهارنامه سال قبل در سامانه مالیاتی، یا مقداری باشد که در جای دیگری از جریان ثبت وارد یا تغییر داده شده است. کارشناسان به ما کمک کردند این موارد را از هم تشخیص دهیم تا بتوانیم مشخص کنیم کدام اقدامات به اصلاح کارشناس نیاز داشتند یا مانع ارسال می‌شدند.

چون می‌توانستیم این اصلاحات را با جزئیات ببینیم، فرایند بازبینی را از یک مرحله نهایی پس از شکست به یک چرخه یادگیری پیوسته تبدیل کردیم. ما این جریان کاری را طوری طراحی کردیم که اقدامات متخصصان را به‌صورت داده‌های ساخت‌یافته ثبت کند. اکنون هر مداخله با ثبت دقیق آنچه Tax AI پیشنهاد داده بود، آنچه کارشناس تغییر داد، و آنچه در نهایت در اظهارنامه ثبت‌شده وارد شد، به حلقه بهبود محصول کمک می‌کند.

۲. آثار محصول، اصلاحات را به ارزیابی تبدیل می‌کنند

برای یک جریان کاری پیچیده مانند املاک اجاره‌ای، سیستم باید آنچه را میان فایل‌های منبع و اظهارنامه ثبت‌شده رخ می‌دهد حفظ کند. در این مسیر، اسناد سازمان‌دهی، تفکیک و دسته‌بندی می‌شوند؛ فیلدهای مربوط به ملک اجاره‌ای با استناد به داده‌ها استخراج می‌شوند؛ این مقادیر به سامانه مالیاتی نگاشت می‌شوند؛ و کارشناسان ممکن است پیش از ثبت همچنان آن‌ها را اصلاح کنند. این ردپاهای سطح محصول امکان بررسی محل وقوع شکست را فراهم می‌کنند. برای تبدیل اصلاحات کارشناسان به اهداف ارزیابی مفید، سیستم آن‌ها را در سه گام پردازش می‌کند:

  • ثبت تفاوت: خروجی Tax AI با اظهارنامه ثبت‌شده مقایسه می‌شود تا ردیف‌هایی مخصوص بازبینی در سطح فیلد تولید شوند که مقدار مورد انتظار، مقدار پیش‌بینی‌شده و امکان قابل‌اقدام بودن تفاوت را ثبت می‌کنند.
  • گروه‌بندی شکست‌های مرتبط: ردیف‌های بازبینی مشابه گروه‌بندی می‌شوند تا خرابی‌های تکرارشونده محصول از نویز مورد انتظار جریان کار جدا شوند. برای مثال، اصلاحات تکراری کارشناسان ممکن است نشان دهد که Tax AI اغلب فیلدهای «روزهای اجاره منصفانه» را ندارد، «سایر هزینه‌ها» را به شکلی نادرست مدیریت می‌کند، یا چند ملک اجاره‌ای را در یک بسته داده‌های خام با هم اشتباه می‌گیرد.
  • تبدیل الگوهای تکراری به اهداف ارزیابی: پس از بازبینی و اندازه‌گیری، یافته‌های تکراری به اهداف مشخص ارزیابی برای انجام بهبود توسط Codex تبدیل می‌شوند.
«»

ردیف‌های بازبینی ملک اجاره‌ای، خرابی‌های تکرارشونده محصول را از نویزی که مورد انتظار است، جدا می‌کنند و سپس موارد قابل‌اقدام را به اهداف ارزیابی تبدیل کرده تا Codex مسیری برای بهبود داشته باشد.

۳. مورد یافته‌شده به مسیری برای بهبود Codex تبدیل می‌شود

سومین رکن، ایجاد حلقه‌ای مهندسی است که بتواند بر اساس این ارزیابی‌های جدید عمل کند. اینجاست که Codex به عنصر مرکزی تبدیل می‌شود.

فرض کنید خط لوله ارزیابی ما نشان دهد که Tax AI مداوماً فیلد "روزهای اجاره منصفانه" را ندارد، در حالی که کارشناسان با اطمینان آن را تکمیل می‌کنند. از آنجا که این یافته از پیش در قالب یک مجموعه ارزیابی هدفمند، همراه با بسته‌های داده‌های خام نماینده و خروجی‌های مورد انتظار بسته‌بندی شده است، Codex می‌تواند علت ریشه‌ای را مستقیماً درون چارچوب محصول بررسی کند.

Codex فقط با یک خروجی نهایی ضعیف کار نمی‌کند. بلکه اثر، ارزیابی، محل نگهداری و مهارت‌ها را با هم بررسی می‌کند:

  • بررسی خط لوله: بسته‌های منبع، الگوهای استخراج، رفتار نگاشت‌گر و مسیرهای کد را بررسی کنید تا مشخص شود مسئله ناشی از فیلدی پشتیبانی‌نشده، الگوی استخراجِ انجام‌نشده، مشکل انتخاب منبع، شکاف در نگاشت‌گر یا مشکل ارزیاب است.
  • پیاده‌سازی اصلاحات هدفمند: الگوی استخراج را گسترش دهید، انتخاب منبع برای اسناد ملک اجاره‌ای را بهبود دهید، نگاشت‌گر موتور مالیاتی را به‌روزرسانی کنید، یا اگر نویز مورد انتظار جریان کاری به‌عنوان شکست شمرده می‌شود، ارزیاب را دقیق‌تر کنید.
  • اعتبارسنجی و پیشنهاد: ارزیابی هدفمند را دوباره اجرا کنید، مجموعه‌های گسترده‌تر رگرسیون را اجرا کنید، و یک pull request پیشنهادی را برای بازبینی مهندسی آماده‌سازی و ارائه دهید.
  • بستن حلقه: یک اصلاح تکرارشونده کارشناس را به یک وظیفه مهندسی قابل‌اندازه‌گیری تبدیل کنید. اگر شواهد مبهم باشند یا خودکارسازی آن‌ها ایمن نباشد، مورد به‌جای عبور اجباری از حلقه، دوباره به تیم محصول ارجاع داده می‌شود.
«»

حلقه بهبود خودکار سرتاسری: آثار تولید، اصلاحات تکراری در سطح فیلدی را آشکار می‌کنند که نشان دهنده‌ی سیگنال‌های شکست می‌شوند تا Codex بتواند آن‌ها را در کنار این آثار، ارزیابی‌ها، محل نگهداری و مهارت‌ها را بررسی کند. الگوهای قابل‌اقدام به ارزیابی‌های محدود و تغییرات پیشنهادی محصول تبدیل شده؛ موارد مبهم برای بازبینی دوباره به مهندسان ارجاع داده می‌شوند. هر بهبود منتشرشده، شواهد تولیدی تازه‌ای برای چرخه بعدی ایجاد می‌کند.

چگونه از Codex برای ساخت این حلقه استفاده کنیم

نمونه ملک اجاره‌ای نمایانگر یک الگوی گسترده‌تر و قابل‌استفاده‌مجدد است: استفاده از ساخته‌ها و آثار تولید برای بهبود قابلیت‌های یک عامل. با در اختیار داشتن یافته‌های بازبینی‌شده از داده‌های تولید، ردپاهای منبع، خروجی مورد انتظار موتور مالیاتی، نمونه‌کدهای مرتبط و فرمان‌های ارزیابی به‌عنوان مجموعه‌ای از ورودی‌ها، Codex می‌تواند طی هفته‌ها و ماه‌ها عملکرد و دقت را به‌طور ملموس بهبود دهد. این رویکرد بر اصولی بنا شده که در کار ما درباره مهندسی harness و Symphony شرح داده شده‌اند؛ آثاری که توضیح می‌دهند چگونه وظایف را برای Codex خوانا کنیم، زمینه و ابزارهای محدودشده فراهم کنیم، و اعتبارسنجی و بازبینی انسانی را به عنوان بخشی از محیط نگه داریم. 

این شواهد به‌طور خودکار به یک وظیفه برای Codex تبدیل نمی‌شوند. یک اصلاح از سوی کارشناس ممکن است بازتاب‌دهنده خطای استخراج، مشکل نگاشت، رفتار محصولِ پشتیبانی‌نشده، قضاوت مالیاتی یا نویز مورد انتظار جریان کاری باشد. فقط پس از آنکه تفاوت‌های تکراری بازبینی و در قالب یک یافته قابل‌اقدام گروه‌بندی شوند، سیستم آن‌ها را به یک وظیفه محدود با شرط موفقیت واضح تبدیل می‌کند.

ما این خودکارسازی را بر یک لایه محدود از محصول اعمال می‌کنیم. این لایه استخراج را انجام می‌دهد و اسناد منبع را به جریان‌های کاری مالیاتی نگاشت می‌کند. مهندسان همچنان مسئول معماری، تصمیم‌های محصول و انتشار هستند. کارشناسان از طریق همان کاری که از پیش انجام می‌دهند، حلقه بهبود را هدایت می‌کنند: اصلاح مقادیر استخراج‌شده، بازبینی اظهارنامه‌ها و تأیید ثبت نهایی.

برای Codex، نتیجه یک هشدار مبهم نیست، بلکه یک وظیفه مهندسیِ محدودشده با شواهد، سطوح قابل‌ویرایش محصول و دروازه‌های اعتبارسنجی صریح است. زمینه یک وظیفه نماینده در حوزه ملک اجاره‌ای را می‌توان به‌صورت زیر خلاصه کرد:

متن ساده

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، درخت‌کارِ قابل‌نوشتن [1] را از زمینه تولیدِ فقط‌خواندنی [5] جدا می‌کند. درخت‌کار شامل سطح محدودشده محصول است که Codex می‌تواند آن را بررسی یا اصلاح کند [2]، ارزیابیهای هدفمند و رگرسیونی که موفقیت را تعریف می‌کنند [3]، و مهارت‌ها/مستندات قابل‌استفاده‌مجددی که نحوه اجرای وظیفه و احترام به تصمیم‌های پیشین را کدگذاری می‌کنند [4]. زمینه فقط‌خواندنی، ردپای تولید، اسناد منبع، پیش‌بینی Tax AI، اظهارنامه نهایی‌شده و مستندات فیلدهای موتور مالیاتی را فراهم می‌کند تا Codex بتواند بدون تغییر دادن شواهد پایه، شکست را بررسی کند.

گسترش به حوزه‌های جدید

همین حلقه فراتر از املاک اجاره‌ای نیز کاربرد دارد. املاک اجاره‌ای حدود شش هفته و نظارت مهندسی قابل‌توجهی نیاز داشت تا به دقت و بازخوانی ۹۰٪ برسد، اما این کار انتزاع‌های قابل‌استفاده‌مجدد، مصنوعات بازبینی، قراردادهای ارزیابی و الگوهای پیاده‌سازی‌ای تولید کرد که پشتیبانی از برنامه‌های پیچیده مشابه مانند Schedule C و Schedule A را آسان‌تر کرد.

Tax AI مسیری برای ساخت عامل‌های خودبهبوددهنده نشان می‌دهد. کارشناسان با ارائه خدمات، سیگنال‌های بازخوردیِ باارزش تولید می‌کنند. جریان‌های کاری محصول این سیگنال‌ها را به‌صورت شواهد ساخت‌یافته حفظ می‌کنند. سامانه‌های مهندسیِ پشتیبانی‌شده با ارزیابی، بهبودها را پیش از رسیدن به تولید اعتبارسنجی می‌کنند، و یک حلقه مبتنی بر عامل، سیستم را در جریان پیوسته‌ای از خودبهبود نگه می‌دارد. 

ساختار Thrive Holdings به ما امکان می‌دهد این محیط را در صنایع مشخص تکرار کنیم. Holdings هم مالک است و هم اپراتور، بنابراین تیم‌های مهندسی مشترک ما می‌توانند مستقیماً با کارشناسان و داده‌های تولید درون کسب‌وکارهایی مانند Crete کار کنند؛ نه به‌عنوان فروشنده، بلکه به‌عنوان شریک. این یعنی فناوری، محصول و خدمت همگی زیر یک سقف قرار دارند تا به ما کمک کنند سریع‌تر حرکت کنیم و محصولات استثنایی بسازیم.

یک حسابدار ارشد که سال گذشته ۱۸۰ ساعت صرف آماده‌سازی مالیات کرده بود، امسال فقط ۱۵ ساعت برای آن وقت گذاشت. او بخشی از این زمان را صرف تماس با تک‌تک مشتریانش و مرور اظهارنامه‌هایشان با آن‌ها کرد؛ سطحی از خدمت نزدیک و شخصی که یک سال پیش ممکن نبود. باقی این زمان را نیز صرف پذیرش مشتریان جدید و گسترش خدمات تازه کرد.

اکنون تیم‌های ما با هم از همین طراحی سه‌بخشی Tax AI به‌عنوان نقشه‌ای برای ساخت جریان‌های کاری در حوزه‌های دیگر در Thrive Holdings(در یک پنجره جدید باز می‌شود) استفاده می‌کنند؛ از جریان‌های کاری حسابداری مانند دفترداری و حسابرسی گرفته تا جریان‌های عملیاتی مانند خودکارسازی میز کمک فناوری اطلاعات. در سراسر حوزه‌ها و صنایع، وعده گسترده‌تر عامل‌های خودبهبوددهنده پابرجاست. بهترین عامل‌ها آنهایی هستند که با هدایت انسان‌ها یاد می‌گیرند که با گذر زمان توانمندتر، قابل‌اعتمادتر و ارزشمندتر شوند.

برای آشنایی بیشتر با تیم OpenAI که روی این پروژه کار کرده است، تماس بگیرید.

نویسنده

Aravind Srinivasan،‏ Samay Shamdasani،‏ Arthur Fernandes Araujo،‏ John de Wasseige