بناء وكلاء ضرائب يتحسنون ذاتيًا باستخدام Codex

كيف طورت Thrive Holdings وOpenAI نظام Tax AI لشركة Crete بشكل مشترك عبر دمج خبرة الممارسين مع حلقة يقودها Codex

تتصرف الأنظمة الواقعية بشكل مختلف في بيئة الإنتاج عما تفعله في المختبر، وتتعطل بطرق يصعب توقعها قبل النشر. غالبًا ما تكتشف الفرق هذه الإخفاقات بعد الإطلاق، ثم تقضي أسابيع في فحص الحالات الطرفية، وضبط المطالبات، وتحويل ملاحظات الإنتاج إلى تحسينات دائمة في المنتج. حلقة التغذية الراجعة يدوية وبطيئة، ولا تتحسن إلا عندما يدفعها مهندس إلى الأمام. لكن اليوم، ومع بنية تقييم مصممة بعناية، ووصول مباشر إلى الممارسين والبيئات الواقعية، وقدرات Codex الوكيلة المتقدمة، يمكنك بناء وكلاء يتحسنون ذاتيًا.

في هذا المقال، سنشرح كيف استخدمنا Codex لبناء هذا النوع من الوكلاء. على مدى الأشهر الستة الماضية، تعاون مهندسون وباحثون من OpenAI نُشروا ميدانيًا إلى جانب مهندسي Thrive Holdings لبناء Tax AI مع شبكة Crete⁠(يفتح في نافذة جديدة) التي تضم أكثر من 30 شركة محاسبة ولأجلها، للمساعدة في إعداد إقرارات ضريبية تزداد تعقيدًا. بدلًا من الاعتماد على المهندسين للعثور على كل إخفاق وإصلاحه، يستخدم Tax AI نظام Codex لتحويل الاستخدام في الإنتاج إلى إشارات منظَّمة تغذي التحسين الذاتي.

يُعد ممارسو Crete عشرات الآلاف من الإقرارات الضريبية كل موسم، ما يتطلب العمل على ملايين المستندات الأساسية. وبالنسبة إلى الإيداعات متوسطة إلى عالية التعقيد، قد يستغرق إدخال البيانات وحده ثماني ساعات لكل إقرار، وغالبًا ما يشمل مصادر بيانات فوضوية، ومستندات من سنوات سابقة، واستخراجًا وحسابًا يدويين. وقد أشاروا لنا إلى أن إعداد الضرائب يمثل عنق زجاجة كبيرًا خلال أكثر فترات موسم الضرائب ازدحامًا.

ولحل هذه المشكلة، عالج Tax AI هذا الموسم الضريبي 7,000 إقرار ضريبي عبر شركات Crete التي شاركت في البرنامج التجريبي. يؤتمت النظام جزءًا كبيرًا من العملية المستهلكة للوقت لإعداد الإقرارات الضريبية 1040 و1041، لكن الأكثر إقناعًا من مكاسب الكفاءة هو أن النظام نفسه أصبح أفضل بشكل قابل للقياس من النسخة التي نُشرت أول مرة قبل ثلاثة أشهر.

في Tax AI، يحمّل الممارسون الملفات المصدر مع أي ملاحظات خاصة بالعميل. ثم ينشئ Tax AI إرسالًا إلى محرك الضرائب جاهزًا للمراجعة. يوفر لهم نحو ثلث وقتهم في إعداد الضرائب، ويُعد مسودات إقرارات بدقة تصل إلى 97%، ويزيد الإنتاجية بنحو 50%، ما يخلق مساحة أكبر لقضاء الوقت مع العملاء. 

يمكننا قياس هذا التحسن من خلال فهم مدى دقة Tax AI في إكمال الإقرار دون الحاجة إلى تصحيح لاحق. نقيس الدقة عبر التحقق من نسبة الإقرارات التي تصل إلى اكتمال صحيح للحقول بنسبة 75% أو 90% أو 100%. عند الإطلاق، لم يكن سوى ربع الإقرارات عند مستوى 75% من اكتمال الحقول الصحيح، لكن خلال ستة أسابيع وصلت 86% إلى هذا المستوى. وأظهر النظام نموًا أسرع حتى عند مستويي اكتمال الحقول الصحيحين 90% و100%. تمنحنا هذه العتبات رؤية عملية لمقدار المتابعة التي لا تزال الإقرارات المختلفة تتطلبها من الممارسين. 

في البداية، تعامل Tax AI مع الأعمال الأبسط، مثل W-2 و1099. ومع تقدم الموسم، انتقل إلى إقرارات أكثر تعقيدًا تتضمن K-1 وجداول وحالات طرفية أصعب. وقد وفرت كل قدرة جديدة وقتًا أكبر لكل إقرار من سابقتها لأن المهام التي تولتها كانت أصعب وأكثر استهلاكًا للوقت عند تنفيذها يدويًا. ونواصل رؤية تقدم مستمر حتى اليوم.

بعد ذلك، سنستعرض كيف شاركت فرقنا في هندسة Tax AI ليصبح متحسنًا ذاتيًا بالاعتماد على ثلاث ركائز أساسية: 1) ملاحظات الممارسين الخبراء، 2) آثار الإنتاج (سجل منظَّم من المدخلات حتى المخرج النهائي)، و3) حلقة تكرار يقودها Codex تستند إلى عمليات تقييم مخصصة لتمكين تطوير منتج أسرع ومستمر. ونأمل أن تكون تجربتنا مفيدة لبناة آخرين في مجالات تكون فيها خبرة الممارسين أساسية في تشكيل جودة النظام الأشمل والبيانات التي تمر عبره.

عندما دفعنا نحو الأجزاء الأصعب من إعداد الضرائب (K-1، وجداول العقارات المؤجرة، والنماذج الضريبية التي كان يجب فيها تسوية القيم عبر ملفات مصدر متعددة)، أصبح واضحًا أن التحدي الحقيقي هو ما إذا كان المنتج يستطيع جعل إخفاقات الإنتاج المعقدة مرئية ومفهومة وقابلة للتنفيذ.

في الأيام الأولى للمنتج، كان معظم التصحيح يدويًا. كان بإمكان الممارسين تصحيح أخطاء النظام، لكن المنتج لم يلتقط السياق الكامل: فقد تعكس قيمة متغيرة قبل التقديم إخفاقًا حقيقيًا في الاستخراج، أو مشكلة في الربط، أو نقصًا في دعم المنتج، أو ضوضاء متوقعة في سير العمل. وكان فرز هذه الحالات لا يزال يتطلب متابعة من الفريق الهندسي. كان بإمكان المهندسين استخدام وكلاء البرمجة، لكن النظام لم يكن قد صُمم بعد لاستخدام الذكاء الاصطناعي بصورة ذات معنى داخل حلقة تحسين. لم تكن لدينا الإشارة التي تحدد الهدف الصحيح للتحسن.

قادنا ذلك إلى تصميم النظام حول ثلاث ركائز:

1. البقاء قريبين من الممارسين: يجب أن يوجّه الأشخاص الذين يقومون بالعمل ما يتعلمه المنتج. يكشف حدسهم وفهمهم عن الأخطاء المهمة ويساعدان في تحديد أي أجزاء من سير العمل تستحق التركيز عليها بعد ذلك.
2. بناء المنتج بحيث يخلق الإنتاج أدلة: يجب على المنتج أن يلتقط أكثر من مجرد المدخلات والمخرجات؛ بل يحتاج إلى التقاط المسار الكامل من المادة المصدر، إلى الحقول المستخرجة وإثبات المصدر، إلى الإرسال اللاحق والتصحيح الخبير.
3. إنشاء حلقة تحسين يقودها Codex: بمجرد أن تصبح مشكلات الإنتاج مرئية ومنظَّمة، يمكن أن تتحول إلى نتائج، وعمليات تقييم مخصصة، ومهام هندسية محددة النطاق. يمكن لـ Codex بعد ذلك المساعدة في التحقيق، واقتراح التغييرات، والتحقق منها مقابل عمليات التقييم المستهدفة والانحدارية، ودفع المنتج إلى الأمام أسرع من دورة تكرار يدوية بحتة. 

يوضح مثال العقارات المؤجرة أدناه كيف تعمل هذه الحلقة عمليًا، إذ يشرح لك كيف يتحول تصحيح الممارس إلى نتيجة منظَّمة، ثم إلى هدف تقييم، وأخيرًا إلى مهمة هندسية محددة النطاق لـ Codex.

يُبلَّغ عن دخل العقار المؤجر في Schedule E من الإقرار الضريبي الفردي. ومن منظور هندسي، فإن مهمة استخراجه سهلة الوصف لكن يصعب تنفيذها جيدًا. يجب على النظام قراءة مادة مصدر فوضوية (ملاحظات مكتوبة بخط اليد، ورسائل بريد إلكتروني، وجداول بيانات، وملفات عميل أخرى)، واستخراج حقول العقار المؤجر التي يستطيع النظام ربطها بثقة بمحرك الضرائب، والحفاظ على قدر كافٍ من الأدلة بحيث يتمكن الممارس من اعتماد النتيجة أو تصحيحها. يوضح المثال المبسط أدناه كيف قد تبدو تلك الملفات المصدر والمخرجات المستخرجة.

قد يعكس الاختلاف بين القيمة التي توقّعها الوكيل والقيمة الفعلية من الإقرار الضريبي المُقدَّم إخفاقًا حقيقيًا في الاستخراج، لكنه قد يكون أيضًا تفضيلًا من الممارس، أو قيمة مُرحّلة من إقرار السنة السابقة في محرك الضرائب، أو قيمة أُدخلت أو عُدّلت في موضع آخر من سير عمل الإقرار. ساعدنا الممارسون على تمييز هذه الحالات حتى نتمكن من تحديد الإجراءات التي تطلبت تصحيحًا من الممارس أو منعت التقديم.

ولأننا استطعنا رؤية هذه التصحيحات بالتفصيل، حوّلنا عملية المراجعة من خطوة نهائية بعد الفشل إلى دورة تعلم مستمرة. صممنا سير العمل لالتقاط إجراءات الخبراء كبيانات منظَّمة. والآن، تُغذي كل مداخلة حلقة تحسين المنتج من خلال تسجيل ما اقترحه Tax AI بالضبط، وما عدّله الممارس، وما أُدرج في النهاية في الإقرار المُقدَّم.

في سير عمل معقد مثل العقارات المؤجرة، يجب على النظام الحفاظ على ما يحدث بين الملفات المصدر والإقرار المُقدَّم. وعلى هذا المسار، تُنظَّم المستندات وتُقسَّم وتُصنَّف؛ وتُستخرج حقول العقارات المؤجرة مع إسنادات إلى المادة المصدر؛ وتُربط هذه القيم بمحرك الضرائب؛ وقد يظل الممارسون يصححونها قبل التقديم. تجعل هذه الآثار على مستوى المنتج من الممكن التحقيق في موضع حدوث الإخفاق. ولتحويل تصحيحات الممارسين إلى أهداف تقييم مفيدة، يعالجها النظام في ثلاث خطوات:

• التقاط الفرق: تُقارَن مخرجات Tax AI بالإقرار المُقدَّم لإنتاج صفوف مراجعة على مستوى الحقول تلتقط القيمة المتوقعة والقيمة المتنبأ بها وما إذا كان الفرق يبدو قابلًا للتنفيذ.
• تجميع الإخفاقات المرتبطة: تُجمَّع صفوف المراجعة المتشابهة للفصل بين الإخفاقات المتكررة في المنتج وضوضاء سير العمل المتوقعة. فعلى سبيل المثال، قد تُظهر تصحيحات الممارسين المتكررة أن Tax AI كثيرًا ما يفوّت حقول «أيام الإيجار العادل»، أو يسيء التعامل مع «المصروفات الأخرى»، أو يخلط بين عدة عقارات مؤجرة ضمن حزمة المصدر نفسها.
• تحويل الأنماط المتكررة إلى أهداف تقييم: بعد مراجعة النتائج المتكررة وقياسها، تصبح أهداف تقييم واضحة يمكن لـ Codex تحسينها.

الركيزة الثالثة هي إنشاء حلقة هندسية قادرة على العمل بناءً على عمليات التقييم الجديدة هذه. وهنا يصبح Codex عنصرًا محوريًا.

لنفترض أن مسار عمليات التقييم لدينا يشير إلى أن Tax AI يفوّت باستمرار حقل "fair rental days"، بينما يملؤه الممارسون بشكل موثوق. ولأن هذه النتيجة جرى بالفعل تجميعها في مجموعة تقييم مستهدفة، مع حزم مصدر ممثلة ومخرجات متوقعة، يمكن لـ Codex التحقيق مباشرة في السبب الجذري داخل هيكل المنتج.

لا يعمل Codex اعتمادًا فقط على مخرج نهائي دون المستوى. بل يفحص الأثر والتقييم والمستودع والمهارات معًا:

• التحقيق في المسار: فحص حزم المصدر ومخططات الاستخراج وسلوك أداة الربط ومسارات الشيفرة لتحديد ما إذا كانت المشكلة حقلًا غير مدعوم، أو نمط استخراج فائتًا، أو مشكلة في اختيار المصدر، أو فجوة في أداة الربط، أو مشكلة في أداة التقييم.
• تنفيذ إصلاحات مستهدفة: توسيع مخطط الاستخراج، وتحسين اختيار المصدر لمستندات العقارات المؤجرة، وتحديث أداة ربط محرك الضرائب، أو تحسين أداة التقييم إذا كانت ضوضاء سير العمل المتوقعة تُحتسب كإخفاق.
• التحقق والاقتراح: إعادة تشغيل التقييم المستهدف، وتشغيل مجموعات الانحدار الأوسع، وإظهار طلب سحب مرشح للمراجعة الهندسية.
• إغلاق الحلقة: تحويل تصحيح متكرر من الممارس إلى مهمة هندسية قابلة للقياس. إذا كانت الأدلة ملتبسة أو غير قابلة للأتمتة بأمان، تُعاد الحالة إلى فريق المنتج بدلًا من فرضها عبر الحلقة.

يمثل مثال العقار المؤجر نمطًا أوسع قابلًا لإعادة الاستخدام: استخدام مخرجات وآثار الإنتاج لتحسين قدرات وكيل. عند تزويد Codex بنتائج مُراجَعة من بيانات الإنتاج، وآثار المصدر، ومخرجات محرك الضرائب المتوقعة، وأمثلة الشيفرة ذات الصلة، وأوامر التقييم كمجموعة مدخلات، يمكنه تحسين الأداء والدقة بصورة ملموسة عبر أسابيع وأشهر. يبني هذا على المبادئ الموصوفة في عملنا حول هندسة الحزام وSymphony، اللذين يشرحان كيفية جعل المهام واضحة لـ Codex، وتوفير سياق وأدوات محددة النطاق، والإبقاء على التحقق والمراجعة البشرية جزءًا من البيئة. 

ولا تتحول هذه الأدلة تلقائيًا إلى مهمة لـ Codex. قد يعكس تصحيح الممارس إخفاقًا في الاستخراج، أو مشكلة في الربط، أو سلوكًا غير مدعوم في المنتج، أو حكمًا ضريبيًا، أو ضوضاء متوقعة في سير العمل. فقط بعد مراجعة الفروق المتكررة وتجميعها في نتيجة قابلة للتنفيذ، يحولها النظام إلى مهمة محددة بوضوح مع شرط نجاح واضح.

نطبق هذه الأتمتة على طبقة محددة من المنتج. تؤدي هذه الطبقة الاستخراج وتربط المستندات المصدر بسير العمل الضريبي. ويظل المهندسون مسؤولين عن البنية المعمارية وقرارات المنتج والإطلاق. يوجه الممارسون حلقة التحسين من خلال العمل الذي يقومون به أصلًا: تصحيح القيم المستخرجة، ومراجعة الإقرارات، واعتماد الإيداعات النهائية.

وبالنسبة إلى Codex، فالنتيجة ليست تنبيهًا غامضًا بل مهمة هندسية محددة النطاق مع أدلة، وأس surfaces منتج قابلة للتحرير، وبوابات تحقق صريحة. يمكن تلخيص سياق مهمة ممثلة للعقار المؤجر على النحو التالي:

تنطبق الحلقة نفسها خارج نطاق العقارات المؤجرة. استغرقت العقارات المؤجرة نحو ستة أسابيع وإشرافًا هندسيًا كبيرًا للوصول إلى دقة واسترجاع بنسبة 90%، لكن هذا العمل أنتج تجريدات قابلة لإعادة الاستخدام، ومخرجات مراجعة، وأعراف تقييم، وأنماط تنفيذ جعلت دعم الجداول المعقدة بالمثل مثل Schedule C وSchedule A أسهل.

يثبت Tax AI وجود مسار لبناء وكلاء يتحسنون ذاتيًا. يولّد الممارسون إشارات تغذية راجعة عالية القيمة من خلال تقديم الخدمة. وتحافظ سير عمل المنتج على هذه الإشارات كأدلة منظَّمة. تتحقق الأنظمة الهندسية المدعومة بعمليات التقييم من التحسينات قبل وصولها إلى الإنتاج، وتحافظ حلقة مدعومة بالوكلاء على النظام في تدفق مستمر من التحسين الذاتي. 

يتيح لنا هيكل Thrive Holdings تكرار هذه البيئة في صناعات محددة. تؤدي Holdings دور المالك وOperator معًا، لذا تستطيع فرقنا الهندسية المشتركة العمل مباشرة مع الممارسين وبيانات الإنتاج من داخل شركات مثل Crete، لا كمورّد بل كشركاء. وهذا يعني أن التقنية والمنتج والخدمة كلها تجتمع تحت سقف واحد لمساعدتنا على التحرك بسرعة أكبر وبناء منتجات استثنائية.

أمضت محاسِبة أولى قضت 180 ساعة في إعداد الضرائب العام الماضي 15 ساعة فقط هذا العام. وخصصت جزءًا من هذا الوقت للاتصال بكل واحد من عملائها وشرح إقراراتهم لهم، وهو مستوى من الخدمة عالية اللمس لم يكن ممكنًا قبل عام. واستخدمت بقية ذلك الوقت لاستقبال عملاء جدد والتوسع إلى عروض خدمات جديدة.

تستخدم فرقنا معًا الآن التصميم الثلاثي نفسه من Tax AI كمخطط لبناء سير عمل في مجالات أخرى عبر Thrive Holdings⁠(يفتح في نافذة جديدة)؛ مثل سير العمل المحاسبي كإمساك الدفاتر والتدقيق، وسير العمل التشغيلي مثل أتمتة مكتب المساعدة لتقنية المعلومات. وعبر المجالات والصناعات، يظل الوعد الأوسع للوكلاء المتحسنين ذاتيًا قائمًا. أفضل الوكلاء يوجّههم الناس ليتعلموا كيف يصبحون أكثر قدرة وأكثر موثوقية وأكثر قيمة بمرور الوقت.

لمعرفة المزيد عن فريق OpenAI الذي عمل على هذا المشروع، تواصل معنا.