FinQA: محک سنجش استدلال عددی هوش مصنوعی در گزارشهای مالی
هفته گذشته FinanceBench نشان داد که بازیابی (retrieval) بخش سخت پرسش و پاسخ مالی نیست، بلکه استدلال عددی است. FinQA که در EMNLP 2021 منتشر شد، مقالهای است که دلیل آن را تبیین کرد. من اکنون آن را مطالعه میکنم زیرا این مقاله زیربنای محکزنی در محاسبات مالی است؛ هر کار بعدی در این حوزه یا آن را گسترش داده و یا در برابر آن محک زده شده است. درک اینکه مدلهای آن کجا شکست میخورند، توضیح میدهد که ایجنتهای فعلی Beancount نیز در کجا شکست خواهند خورد.
مقاله
Zhiyu Chen، Wenhu Chen و همکارانشان از دانشگاه UC Santa Barbara، جیپی مورگان و آمازون، FinQA: مجموعهدادهای برای استدلال عددی روی دادههای مالی (arXiv:2109.00122, EMNLP 2021) را معرفی کردند. وظیفه اصلی این است: با داشتن یک گزارش سوددهی شامل روایت متنی و یک یا چند جدول مالی، به سوالی پاسخ دهید که نیازمند محاسبات چند مرحلهای روی حقایق استخراجشده از هر دو حالت (متن و جدول) است. پاسخ باید از طریق یک برنامه عددی صریح به دست آید — دنبالهای از حداکثر پنج عملیات (جمع، تفریق، ضرب، تقسیم، مقایسه، تجمیع جدول و چند مورد دیگر) که روی مقادیر استخراجشده اعمال میشود.
یازده متخصص مالی مستقر در ایالات متحده (CPAها و MBAها) این مجموعهداده را به صورت دستی از ۲,۷۸۹ صفحه گزارشهای سوددهی S&P 500 بین سالهای ۱۹۹۹ تا ۲۰۱۹ ساختند. مجموعهداده نهایی شامل ۸,۲۸۱ جفت پرسش و پاسخ نشانهگذاری شده است که هر کدام دارای حقایق پشتیبان طلایی و برنامه استدلال کامل هستند، که آن را کاملاً قابل اجرا و بازرسیپذیر میکند.
ایدههای کلیدی
- شکاف در زمان انتشار بسیار عمیق است. FinQANet (بر پایه RoBERTa-large)، بهترین مدل عصبی که نویسندگان توانستند ارائه دهند، به ۶۱.۲۴٪ دقت اجرا و ۵۸.۸۶٪ دقت برنامه در مجموعه تست رسید. متخصصان مالی انسانی امتیاز ۹۱.۱۶٪ و ۸۷.۴۹٪ را کسب کردند. کارگران غیرمتخصص تنها به ۵۰.۶۸٪ رسیدند — که به سختی بالاتر از خط پایه عصبی است؛ این نشان میدهد که این حوزه به تخصص واقعی نیاز دارد، نه فقط درک مطلب ساده.
- محاسبات چند مرحلهای جایی است که همه چیز فرو میپاشد. برای برنامههایی که به سه یا چند مرحله استدلال نیاز دارند، دقت FinQANet به ۲۲.۷۸٪ سقوط میکند. مدل میتواند محاسبات دو مرحلهای را به طور منطقی مدیریت کند؛ اما هر چه طولانیتر شود، خطاها روی هم انباشته میشوند.
- سوالات میانحالتی (Cross-modality) سختترین موارد هستند. سوالاتی که شواهد آنها هم در جدول و هم در متن پراکنده است، دقتی معادل ۴۳.۸۰٪ دارند که حدود ۱۷ واحد کمتر از میانگین کل است. اتصال یک عدد از پاراگراف مربوط به جدول به یک توصیفگر در متن، چیزی نیست که مدلهای استاندارد پیشآموزشدیده به خوبی انجام دهند.
- ثابتهای حوزه، قاتلان خاموش هستند. وقتی یک مرحله از برنامه به ثابتی نیاز دارد که جزو قراردادهای مالی است (مثلاً اینکه ۱,۰۰۰ هزار برابر با یک میلیون است، یا اینکه یک واحد پایه ۰.۰۱٪ است) و نه چیزی که در سند ذکر شده باشد، دقت به ۴۳.۸۸٪ کاهش مییابد. مدل نمیتواند به طور قابل اعتمادی تشخیص دهد که "این عدد در سند است" یا "این عدد جزو دانش عمومی جهان است."
- حدود ۵۰٪ از خطاها ریشه در کمبود دانش حوزه دارند، نه شکست در بازیابی اطلاعات یا خطاهای اجرای محاسبات. مدل حقایق درست را پیدا کرد اما منطق مالی اشتباهی را به کار برد.
- مدلهای زبانی بزرگتر (LLMs) بعدی این شکاف را به طور قابل توجهی کاهش دادند اما آن را حذف نکردند. گزارش شده است که GPT-4 در FinQA به دقت اجرای حدود ۷۶٪ رسیده است و سیستمهای تخصصی SOTA تا سال ۲۰۲۴ به حدود ۸۹٪ رسیدهاند — که هنوز کمتر از عملکرد متخصص انسانی (۹۱٪+) است.
چه چیزی پابرجا است — و چه چیزی نیست
طراحی این محک مستحکم است. استفاده از برنامههای قابل اجرا به جای پاسخهای متن آزاد، تصمیم درستی است: شما میتوانید یک مدل را بدون ابهام امتیازدهی کنید و پنجرهای به چگونگی استدلال آن داشته باشید، نه فقط اینکه آیا درست گفته است یا خیر. ت صمیم برای الزام شواهد هم از جدول و هم از متن، بازتابدهنده تحلیل مالی در دنیای واقعی است، جایی که جدول عدد را به شما میدهد و یادداشت توضیحی (footnote) معنای آن عدد را بیان میکند.
با این حال، این وظیفه محدودتر از آن چیزی است که به نظر میرسد. زبان DSL تعریف شده برای عملیاتها، محاسبات مالی استاندارد را پوشش میدهد، اما نمیتواند یک تصمیم طبقهبندی را نشان دهد ("آیا این هزینه تکرار شونده است یا یکباره؟")، یا یک بررسی سیاستی ("آیا این جریان نقدی با سیاست بودجه ما مطابقت دارد؟")، یا هر چیزی که نیاز به بازیابی خارجی دادههای بازار یا استانداردهای حسابداری داشته باشد. برنامهها درست و قابل توضیح هستند، اما در جهانی زندگی میکنند که تنها عدم قطعیت آن محاسبات است، نه قضاوت.
همچنین، ساختار بازیابی در زمان آموزش، حقایق پشتیبان طلایی را به مدل میدهد که باعث میشود اعداد بهتر از واقعیت به نظر برسند. در یک استقرار واقعی، شما باید سلولهای جدول درست را از یک سند طولانی قبل از اجرای برنامه بازیابی کنید — و همانطور که FinanceBench هفته گذشته نشان داد، آن مرحله بازیابی اصلاً بدیهی نیست.
در نهایت، نتایج سال ۲۰۲۱ توانمندی مدلهای فعلی را کمتر از واقعیت نشان میدهد. خط پایه ۶۱٪ متعلق به دوران قبل از ChatGPT بود. اعداد ۷۶٪ برای GPT-4 و ۸۹٪ برای مدلهای پیشرو از خطلولههای تخصصی حاصل شدهاند که زنجیره فکر (Chain-of-thought)، اجرای کد و تنظیم دقیق (Fine-tuning) را با هم ترکیب میکنند. شکاف با متخصص انسانی (۹۱٪+) کمتر شده اما همچنان پابرجاست.
چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد
دفاتر کل Beancount در اصل گزارشهای سوددهی ساده شده هستند: ردیفهای ساختاریافته از بدهکار و بستانکار با متادیتای متنی در یادداشتهای تراکنش، فیلدهای دریافتکننده وجه و سلسلهمراتب حسابها. هر مهارتی که محک FinQA آزمایش میکند، مستقیماً به کاری که یک ایجنت Beancount باید انجام دهد، نگاشت میشود.
حالت شکست میانحالتی (Cross-modality) به ویژه مهم است. در بافت Beancount، یک ایجنت ممکن است مبلغ تراکنش را در لجر، نرخ ارز خارجی را در یک دستورالعمل قیمت (Price directive) و یک کامنت را در فیلد یادداشت ببیند — و برای محاسبه ارزش صحیح در ارز گزارشگری به هر سه مورد نیاز داشته باشد. مدلهایی که FinQA در سال ۲۰۲۱ آزمایش کرد، نمیتوانستند به طور قابل اعتمادی بین این منابع ارجاع متقابل (cross-reference) ایجاد کنند. مدلهای زبانی بزرگ فعلی بهتر عمل میکنند، اما دقت ۲۲.۷۸٪ در برنامههای ۳ مرحلهای به بالا یک هشدار است: طول زنجیره یک محور واقعی برای شکست است و وظایف تطبیق لجر چند مرحلهای با این مشکل برخورد خواهند کرد.
مشکل ثابتهای حوزه نیز قابل تعمیم است. حسابداری قراردادهای خاص خود را دارد — ناورداهای دوطرفه، معناشناسی انواع حساب، مرزهای سال مالی — که یک مدل باید بدون گفته شدن آنها را بداند. تحلیل خطای FinQA که نشاندهنده ۵۰٪ شکست در دانش حوزه است، پیشنهاد میکند که یک ایجنت Beancount یا به تنظیم دقیق روی قراردادهای حسابداری نیاز دارد و یا به یک لایه بازیابی صریح برای قوانین حسابداری، نه فقط ورودیهای لجر.
نمایش برنامه در این محک، هرچند محدود، به این سمت اشاره دارد که ایجنتهای Beancount چگونه باید استدلال خود را بیان کنند: نه با زبان طبیعی که میتواند مبهم باشد، بلکه با عملیاتهای قابل اجرایی که میتوان آنها را بررسی، بازگردانی (Rollback) یا حسابرسی کرد.
برای مطالعه بیشتر
- TAT-QA (arXiv:2105.07624, ACL 2021) — تنظیمات ترکیبی جدول + متن را به ۱۶,۵۵۲ سوال با تنوع غنیتری از انواع استدلال گسترش میدهد؛ مدل TAGOP که معرفی میکند برای چگونگی استخراج همزمان بخشها از هر دو حالت ارزش مطالعه دارد.
- ConvFinQA (arXiv:2210.03849, EMNLP 2022) — گسترش مکالمهمحور FinQA، جایی که هر گفتگو دارای وابستگیهای عددی بین نوبتی است؛ ساختار چند نوبتی مستقیماً به یک دستیار تعاملی Beancount نگاشت میشود که باید محاسبات جاری را در طول پیگیریهای کاربر ردیابی کند.
- MultiHiertt (arXiv:2206.01347, ACL 2022) — این تنظیمات را به گزارشهای مالی با چندین جدول سلسلهمراتبی در هر سند سوق میدهد؛ مرحلهای ضروری به سوی صورتهای تلفیقی و نماهای لجر چندساله که ایجنتهای Beancount با آن روبرو خواهند شد.
