DocFinQA: استدلال مالی با متن طولانی بر روی گزارش‌های کامل SEC

DocFinQA یک مقاله ACL 2024 است که مجموعه داده FinQA موجود را گرفته و هر پرسش را در کنار گزارش کامل SEC که از آن استخراج شده، دوباره ارائه می‌دهد - و میانگین متن ورودی را از کمتر از ۷۰۰ کلمه به ۱۲۳,۰۰۰ کلمه افزایش می‌دهد. من این مقاله را می‌خوانم زیرا دقیقاً سناریویی را آزمایش می‌کند که هر عامل Beancount در محیط عملیاتی با آن روبرو است: نه یک قطعه استخراج‌شده تمیز، بلکه کل سند به‌هم‌ریخته. نتایج برای هر کسی که قصد دارد مدل‌های با متن طولانی را روی دفاتر کل چندساله پیاده‌سازی کند، تامل‌برانگیز است.

خود مقاله

DocFinQA: A Long-Context Financial Reasoning Dataset — ورشینی ردی، ریک کانسل-کدزیورسکی، ویت داک لای، مایکل کرومدیک، چارلز لاورینگ و کریس تانر (ACL 2024، مقالات کوتاه) — ۸,۲۸۱ جفت پرسش و پاسخ از FinQA را گرفته و ۷,۶۲۱ مورد از آن‌ها را با گزارش سالانه کامل SEC که هر سوال در ابتدا از آن استخراج شده بود، تقویت می‌کند. نتیجه ۱,۲۳۶ گزارش منحصر به فرد است که در ۵,۷۹۸ مثال آموزشی، ۷۹۱ مثال توسعه و ۱,۰۳۲ مثال تست تقسیم شده‌اند، که میانگین متن ورودی با افزایش ۱۷۵ برابری از حدود ۷۰۰ کلمه به ۱۲۳,۴۵۳ کلمه رسیده است.

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

ایده‌های کلیدی

• بهترین دقت خط لوله بازیابی در مجموعه تست: GPT-3.5 با ۴۲.۶۴٪. مدل‌های متن‌باز به شدت عقب هستند: Mistral/7B با ۲۴.۹۷٪، CodeLlama/13B با ۲۱.۰۱٪، MPT/30B با ۱۸.۰۷٪.
• بهترین رمزگذار بازیابی — یک ColBERT تنظیم‌شده — به HR@1 = ۰.۳۵ و HR@3 = ۰.۵۵ دست می‌یابد، به این معنی که قطعه صحیح در نزدیک به نیمی از مواقع در متن مدل وجود ندارد، حتی زمانی که سه قطعه بازیابی می‌شود.
• مدل GPT-4 با متن طولانی (ارزیابی شده بر روی یک زیرمجموعه ۴۰۰ سوالی): ۴۶.۵٪ در اسناد کوتاه‌تر (≤۱۰۰ هزار توکن) در مقابل ۲۳.۰٪ با استراتژی «خلاصه‌سازی و سپس پاسخ‌دهی» در طولانی‌ترین اسناد (>۱۰۰ هزار توکن). GPT-4 در اسناد طولانی تقریباً دو برابر بیشتر از اسناد کوتاه مرتکب خطا می‌شود.
• تجزیه PDF مخصوص امور مالی (Kensho Extract) به طور قابل توجهی از تجزیه HTML عمومی (BeautifulSoup) بهتر عمل کرد، به ویژه برای حفظ جداول — یافته‌ای کاربردی برای هر خط لوله‌ای که بر اساس گزارش‌های SEC ساخته شده است.
• بخش قابل توجهی از قطعه‌های مرتبط فراتر از موقعیت ۲۵۰ سند قرار دارند، به این معنی که استراتژی‌های مبتنی بر برش (truncation) پیش از اینکه مدل حتی شواهد را ببیند، به طور خاموش شواهد درست را دور می‌اندازند.

چه چیزی پابرجا می‌ماند و چه چیزی نه

سهم تجربی اصلی محکم است: مجموعه داده گسترش وفادارانه‌ای از FinQA با متدولوژی خوش‌تعریف است (امتیازدهی شباهت چهار-گرمی برای شناسایی قطعات طلایی، قطعات ۲,۷۵۰ کاراکتری با ۲۰٪ همپوشانی)، و این یافته که عملکرد با افزایش طول سند به شدت کاهش می‌یابد، در هر دو رویکرد بازیابی و متن طولانی سازگار است. افزایش تقریباً دو برابری خطاهای GPT-4 در اسناد طولانی نسبت به کوتاه، چشمگیر است و به سختی می‌توان آن را نادیده گرفت.

آنچه مقاله به طور کامل به آن نمی‌پردازد، مرزهای مدل‌های با متن طولانی سال ۲۰۲۴ است. ارزیابی متن طولانی تنها ۴۰۰ نمونه را شامل می‌شود که به دلیل هزینه محدود شده است و Gemini 1.5 Pro (پنجره ۱ میلیون توکنی) یا Claude 3 (۲۰۰ هزار توکن) را آزمایش نمی‌کند. هایپرپارامترهای قطعه‌بندی معقول هستند اما به صورت سیستماتیک بررسی نشده‌اند، و استراتژی چند-فراخوانی «خلاصه‌سازی و سپس پاسخ‌دهی» احتمالاً بهترین گزینه موجود نیست — بازیابی درهم‌تنیده IRCoT و سنتز ساختاریافته StructRAG هر دو نشان می‌دهند که رویکردهای بهتری برای تجمیع شواهد چند-مرحله‌ای در اسناد طولانی وجود دارد.

رسیدن ColBERT تنظیم‌شده به HR@3 = ۰.۵۵ مشکل عمیق‌تری را آشکار می‌کند: بازیابی در اسناد مالی طولانی خود یک مسئله حل‌نشده است. حتی با یک مدل مولد بی‌نقص، نزدیک به نیمی از پرس‌وجوها پاسخی دریافت می‌کنند که بر اساس قطعات اشتباه ساخته شده است. مقاله این را به عنوان محدودیت اصلی مطرح می‌کند اما از کمی‌سازی این موضوع که با بازیابی ایده‌آل (oracle) چقدر دقت بازیابی می‌شود، باز می‌ماند.

چرا این برای هوش مصنوعی مالی مهم است

دفاتر کل Beancount چندساله به طور پیش‌فرض به طور میانگین ۱۲۳ هزار کلمه نیستند، اما یک دهه تراکنش با یادداشت‌های دقیق به راحتی به آن می‌رسد، و یک عامل مالی که روی گزارش‌های سالانه کامل کار می‌کند با دقیقاً چنین وضعیتی روبرو است. فشرده‌سازی از «ما ۷۰۰ کلمه درست را گلچین کردیم» (FinQA) به «این کل گزارش 10-Q است» (DocFinQA) نشان‌دهنده فاصله بین یک بنچمارک بازی و واقعیت عملیاتی است. DocFinQA این شکاف را قابل اندازه‌گیری می‌کند.

کاهش نزدیک به ۵۰ درصدی در دقت GPT-4 از اسناد کوتاه به بلند، بر علیه پاسخ ساده «فقط از یک پنجره متنی بزرگتر استفاده کن» استدلال می‌کند. بازیابی همچنان ضروری است اما تنها در ۵۵٪ مواقع در HR@3 قابل اعتماد است. برای یک عامل ثبت Beancount که نیاز به یافتن جدول استهلاک مدفون در یک یادداشت پیوست صورت‌های مالی یک‌ساله دارد، هیچ‌کدام از معماری‌ها قابلیت اطمینانی را که قبل از نهایی کردن یک ورودی دفتر روزنامه می‌خواهید، به شما نمی‌دهند. خوانش منصفانه این مقاله: بازیابی بهتر، تجمیع شواهد بهتر و ارزیابی صریح شکست‌های خاموش — و نه صرفاً پنجره متنی بزرگتر — چیزی است که این حوزه در واقع به آن نیاز دارد.

مطالب پیشنهادی برای مطالعه بعدی

• "Lost in the Middle: How Language Models Use Long Contexts" — لیو و همکاران، ۲۰۲۳، arXiv:2307.03172. توضیح مکانیکی برای فروپاشی دقت موقعیتی که DocFinQA اندازه‌گیری می‌کند را با منحنی عملکرد U-شکل اکنون کلاسیک ارائه می‌دهد.
• FinDER: Financial Dataset for Question Answering and Evaluating Retrieval-Augmented Generation — arXiv:2504.15800، کارگاه ICLR 2025. یک بنچمارک جانشین در سال ۲۰۲۵ با ۵,۷۰۳ سه‌گانه پرس‌وجو-شاهد-پاسخ که حول پرس‌وجوهای واقعی جستجوی مالی حرفه‌ای طراحی شده است، از جمله اختصارات و نام‌های اختصاری که بازیاب‌های استاندارد از دست می‌دهند.
• Fin-RATE: A Real-world Financial Analytics and Tracking Evaluation Benchmark for LLMs on SEC Filings — arXiv:2602.07294. یک بنچمارک جدیدتر از گزارش‌های SEC که وظایف ردیابی زمانی را فراتر از پرسش و پاسخ تک‌سندی اضافه می‌کند، که به آنچه یک عامل حسابرسی Beancount واقعاً نیاز دارد نزدیک‌تر است.