FinanceBench: چرا RAG مبتنی بر ذخیرهساز برداری در اسناد مالی واقعی شکست میخورد
FinanceBench در زمانی ارائه میشود که هر فروشنده هوش مصنوعی سازمانی ادعا میکند سیستمش میتواند «به سوالات از اسناد مالی شما پاسخ دهد». این مقاله از Patronus AI این ادعاها را با استفاده از گزارشهای واقعی SEC و سوالات کتاب-باز (open-book) که با دقت انتخاب شدهاند، به چالش میکشد. نتایج برای هر کسی که در حال ساخت هوش مصنوعی مالی است، ناخوشایند خواهد بود.
درباره مقاله
اسلام و همکاران، FinanceBench: بنچمار ک جدیدی برای پاسخگویی به سوالات مالی (arXiv:2311.11944) را معرفی میکنند؛ مجموعهای شامل ۱۰،۲۳۱ سوال درباره شرکتهای سهامی عام که از گزارشهای واقعی SEC استخراج شده است — گزارشهای سالانه 10-K، گزارشهای فصلی 10-Q، گزارشهای جاری 8-K و متن جلسات سود (earnings transcripts). برخلاف مجموعهدادههای قبلی پرسش و پاسخ مالی (FinQA، TAT-QA) که جداول و بخشهای از پیش استخراج شده را ارائه میدهند، FinanceBench سیستم را ملزم میکند تا پیش از پاسخگویی، شواهد را از اسناد کامل بازیابی کند. این یک محیط واقعگرایانه است. سوالات به گونهای طراحی شدهاند که از نظر واقعیت بدون ابهام باشند و به گفته نویسندگان، «حداقل استاندارد عملکرد» محسوب شوند.
این تیم ۱۶ پیکربندی شامل GPT-4-Turbo، Llama2 و Claude2 را در چهار استراتژی بازیابی ارزیابی کرد: کتاب-بسته (بدون بازیابی)، ذخیرهساز برداری مشترک (shared vector store)، ذخیرهساز برداری برای هر سند، و پرومپتهای با بافت طولانی (long-context) که کل صفحه مربوطه را تغذیه میکنند. ارزیابان انسانی به صورت دستی تمام ۲،۴۰۰ پاسخ را در ۱۵۰ مورد متنباز بررسی کردند.
ایدههای کلیدی
- بازیابی گلوگاه نیست. GPT-4-Turbo با داشتن قطعه متن مرجع (oracle passage) — یعنی دقیقاً همان صفحهای که حاوی پاسخ است — باز هم تنها به دقت ۸۵٪ میرسد. پرومپتینگ با بافت طولانی (تغذیه خودکار صفحه درست) امتیاز ۷۹٪ را کسب کرد. بازیابی بینقص تنها شش امتیاز به شما اضافه میکند.
- RAG مبتنی بر ذخیرهساز برداری مشکل اصلی است. GPT-4-Turbo با ذخیرهساز برداری مجزا برای هر سند: ۵۰٪ صحیح، ۳۹٪ امتناع از پاسخ. با ذخیرهساز برداری مشترک بین شرکتها: ۱۹٪ صحیح، ۶۸٪ امتناع. تیتر «۸۱٪ نرخ شکست» مربوط به همین چیدمان ذخیرهساز مشترک است — پیکربندیای که اکثر دموهای هوش مصنوعی سازمانی در واقع از آن استفاده میکنند.
- مدلها به روشهای متفاوتی شکست میخورند. Llama2 به شدت دچار توهم میشود (۵۴-۷۰٪ پاسخ نادرست)؛ GPT-4-Turbo امتناع میکند (۳۹-۶۸٪ امتناع به جای پاسخ اشتباه). هر دو حالت شکست در محیط عملیاتی غیرقابل قبول هستند، اما خطرات یکسانی ندارند.
- ۶۶٪ از سوالات به استدلال عددی نیاز دارند. نرخ رشد، حاشیه سود، تغییرات سال به سال. اینجاست که مدلها بیشترین خطا را دارند — اشتباهات محاسباتی، سردرگمی در واحدها، خطاهای علامت (مثبت/منفی).
- بافت طولانی (Long context) تقریباً نجاتدهنده است. Claude2 در حالت بافت طولانی: ۷۶٪ صحیح. GPT-4-Turbo در حالت بافت طولانی: ۷۹٪. اینها بهترین اعداد عملی هستند که با دور زدن مرحله بازیابی و تغذیه مستقیم کل صفحه مربوطه به دست آمدهاند.
- حتی متن مرجع هم نشت دارد. با وجود شواهد بینقص، سقف دقت ۸۵٪ است و نه ۱۰۰٪. پانزده درصد از شکستها، شکستهای محض در استدلال هستند که هیچ ارتباطی به بخش بازیابی ندارند.
چه چیزی درست است — و چه چیزی نیست
طراحی این بنچمارک هوشمندانه است. پافشاری بر استفاده از اسناد واقعی به جای تکههای از پیش استخراج شده، انتخاب متدولوژیک درستی است — این کار چیزی را آزمایش میکند که واقعاً در استقرار سیستم اهمیت دارد. ارزیابی دستی ۲،۴۰۰ پاسخ هزینهبر و معتبر است.
چیزی که برای من کمتر قانعکننده است، نتیجهگیری رتبهبندی از تعداد نمونه n=۱۵۰ است. تفاوت بین Claude2 (۷۶٪) و GPT-4-Turbo (۷۹٪) در حالت بافت طولانی، با این اندازه نمونه از نظر آماری بیمعنی است، اما مقاله آن را به عنوان یک رتبهبندی ارائه میدهد. بنچمارک کامل ۱۰،۲۳۱ سوالی وجود دارد اما به صورت عمومی امتیازدهی نشده است که بازتولید مستقل آن را محدود میکند.
نتیجه متن مرجع (oracle) نیز مهمترین یافتهای است که کمتر تحلیل شده است. اگر مدلها با داشتن صفحه صحیح در اختیار، باز هم ۱۵٪ مواقع شکست میخورند، مشکل استدلال و محاسبات است، نه بازیابی. مقاله به ابزارهای ماشینحساب و زنجیره تفکر (chain-of-thought) به عنوان کارهای آینده اشاره میکند — این آزمایشها باید مرکز ثقل این مقاله میبودند، نه یک پینوشت.
همچنین بنچمارک اذعان میکند که «حداقل عملکرد» را هدف قرار داده است: سوالات تکسندی با پاسخهای بدون ابهام. استدلال بینسندی، روندهای چندساله و مقایسههای بینشرکتی حذف شدهاند. مقالاتی که عدد ۷۹٪ بافت طولانی را نقل میکنند، به ندرت به این محدودیت اشاره خواهند کرد.
چرا این موضوع برای هوش مصنوعی مالی اهمیت دارد
مورد استفاده «ثبت در Beancount» مستقیماً با حالتهای شکست FinanceBench مطابقت دارد. عاملی (agent) که یک ورودی تراکنش را بازیابی میکند و بررسی میکند که آیا مبلغ با صورتحساب بانکی همخوانی دارد یا خیر، همان وظیفه «بازیابی و سپس محاسبات» را انجام میدهد که این بنچمارک اندازهگیری میکند. سقف ۸۵ درصدی متن مرجع — حتی با بافت بینقص — محدودیت طراحی مربوطه است: حتی اگر عامل ورودی دفتر کل درست را پیدا کند، احتمال واقعی وجود دارد که مقایسه را اشتباه محاسبه کند، علامت را اشتباه بفهمد یا واحدها را اشتباه بخواند.
تفاوت شکست Llama2 و GPT-4 در معماری عاملها اهمیت دارد. امتناع از پاسخ قابل جبران است (ارجاع به بررسی انسانی)؛ اما یک تطابق متوهمانه که در دفتر کل ثبت شود، قابل جبران نیست. این موضوع استدلال میکند که رفتار محافظهکارانه (امتناع) بر توهم با اعتماد به نفس ترجیح داده شود، حتی به قیمت کاهش نرخ موفقیت ظاهری.
مزیت بافت طولانی (۷۹٪ در مقابل ۵۰٪) برای برنامههای دفتر کل از نظر عملی چالشبرانگیز است. فایلهای Beancount چندساله بزرگتر از آن هستند که به طور کامل تغذیه شوند. حل مشکل بازیابی روی اسناد عددی متراکم — و نه فقط بازیابی متنی — همچنان یک مسئله باز است.
مطالعه بیشتر
- FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122) — بنچمارک پیشنیازی که FinanceBench صراحتاً آن را بهبود میبخشد؛ مفید برای درک آنچه در این حوزه پیش از نیاز به بازیابی اسناد واقعی درست انجام شده بود.
- DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024) — توسعه FinanceBench با سوالات چندمرحلهای (multi-hop) دشوارتر که نیاز به استدلال در بخشهای مختلف یک سند واحد دارند.
- PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023) — محاسبات ریاضی را به یک مفسر پایتون واگذار میکند و مستقیماً به ۶۶٪ سوالات FinanceBench که در استدلال عددی شکست میخورند، میپردازد.
