امروز Jev 1.13 رو از طریق API رسمی OpenRouter آزمایش کردم، و نتیجه‌اش بیشتر از چیزی که انتظار داشتم جالب بود.

روی دیتاست MASSIVE با ۵٬۹۴۸ جمله‌ی فارسی و انگلیسی و ۶۰ نوع Intent، چهارده مدل رو روی یک داده‌ی یکسان مقایسه کردم. بر اساس دقت:

- اول، E5 Base با Logistic Regression: ۸۳٫۷۹٪+

- دوم، TF-IDF با Logistic Regression: ۸۲٫۴۸٪+

- سوم، Decider-2B: ۸۱٫۶۴٪

- بعد، E5 Small: ۸۰٫۹۰٪

- بعد، Jev 1.13: ۷۹٫۸۶٪

- بعد، Decider-0.8B: ۷۶٫۷۷٪

- آخر، Kev-0.8B: ۵۷٫۹۵٪

یعنی یک مدل امبدینگ ۲۷۸ میلیونی از مدل‌های تخصصی تصمیم‌گیری جلوتر افتاد، و TF-IDF هم هنوز از Jev و Decider دقیق‌تر بود.

حالا راز E5 چیه؟ از مدل چندزبانه‌ی E5 استفاده کردم تا متن رو به بردارهای ۷۶۸بعدی تبدیل کنه و فقط یک Logistic Regression ساده روی خروجی‌اش آموزش دادم. هیچ‌کدوم از پارامترهای E5 رو دوباره آموزش ندادم.

ولی یک نکته‌ای هست که نباید از قلم بیفته: من برای E5 و TF-IDF از بیش از ۲۳ هزار نمونه‌ی آموزشی برچسب‌دار استفاده کردم، درحالی‌که Jev و Decider بدون آموزش و به‌صورت Zero-shot ارزیابی شدن. پس این نتایج ثابت نمی‌کنه E5 یک موتور تصمیم‌گیری عمومی قوی‌تره.

از Jev یک نتیجه‌ی غیرمنتظره هم درآمد. اگر به‌جای Accuracy از Macro-F1 استفاده کنیم، مقایسه برعکس می‌شه: Jev به ۷۷٫۳۲٪ می‌رسه و Decider-2B به ۷۶٫۲۵٪. چون Macro-F1 به همه‌ی کلاس‌ها وزن یکسان می‌ده، یعنی Jev با وجود دقت کلی پایین‌تر، بین دسته‌های مختلف متعادل‌تر بوده.

کالیبراسیون هم داستان جداگانه‌ای داشت. خطای کالیبراسیون یا ECE برای Decider-2B حدود ۰٫۰۱۸۶، برای Jev حدود ۰٫۰۵۰۹ و برای E5 Base حدود ۰٫۲۵۷۳ دراومد. هرچه ECE کمتر باشه یعنی اطمینان پیش‌بینی‌شده به دقت واقعی نزدیک‌تره. البته ECE همه‌چیز رو نشون نمی‌ده؛ E5 با وجود خطای بالاتر، توی آزمایش من در رتبه‌بندی تصمیم‌ها بر اساس ریسک بهتر عمل کرد.

از نظر هزینه و سرعت هم، اجرای کامل Jev روی هر ۵٬۹۴۸ جمله حدود ۰٫۲۹۳ دلار شد و میانه‌ی زمان پاسخ هم حدود ۶۲۶ میلی‌ثانیه.
یک نکته‌ی دیگه هم این بود که در دو اجرای مستقل روی ۳۹۸ ورودی مشترک، حدود ۲٫۳ درصد پیش‌بینی‌های Jev تغییر کرد. یعنی نتیجه‌ی یک اجرای منفرد رو نباید خیلی قطعی گرفت.

دارم هنوز تست میکنم این مدل هارو، مرحله بعدی هدفم دیگه فقط تشخیص Intent نیست؛ می‌خوام ببینم Encoderهای کوچک و چندزبانه می‌تونن توی ۵۰ کاربرد مختلف، از انتخاب ابزار و کنترل Agent تا ارزیابی RAG و تصمیم‌گیری چندمرحله‌ای، با مدل‌های تصمیم گیری تخصصی مث Jev رقابت کنن یا نه.

درسی که خودم از این آزمایش گرفتم اینه: برای حل یک مسئله‌ی مشخص، همیشه مدل بزرگ‌تر لازم نیست. یک Encoder ازپیش‌آموزش‌دیده کنار یک الگوریتم کلاسیک می‌تونه نتیجه‌ی چشمگیری بده. ولی تشخیص یک دسته‌ی ازپیش‌تعریف‌شده با تصمیم‌گیری درباره‌ی مسئله‌ای کاملاً جدید، دو تا مسئله‌ی متفاوتن.

🛠 Join @LLMEngineers Community

جمنای ۴ معرفی شد !

چند روز اخیر پر از خبر AI بود، ولی وقتی تکراری‌ها، لیک‌ها و تغییرات کم‌اهمیت رو کنار بذاریم، یه روند خیلی واضح دیده می‌شه: رقابت دیگه فقط سر «باهوش‌ترین مدل» نیست؛ رقابت اصلی داره می‌ره سمت ساخت Agentهایی که بتونن کارهای طولانی و چندمرحله‌ای رو با دخالت کمتر انسان انجام بدن.

اول از همه، OpenAI با GPT-6.1 Sol، Dots، Codex Cloud، Space و Ultrafast عملاً داره ChatGPT رو از یه چت‌بات به پلتفرمی برای اجرای Agentها تبدیل می‌کنه. Dots قراره Agentهای شخصی و دائمی باشن که کامپیوتر ابری خودشون رو دارن و می‌تونن روی کارهای طولانی ادامه بدن. Codex هم بیشتر از قبل از «دستیار کدنویسی» فاصله گرفته و به سمت انجام کامل کارهای مهندسی می‌ره.

از طرف دیگه، Google با Gemini 4 Argon تمرکزش رو گذاشته روی کارهای پیچیده و طولانی مثل مهندسی نرم‌افزار، کارهای سازمانی، حقوقی، مالی و امنیت سایبری. نکته مهم این نسل از مدل‌ها دیگه فقط جواب بهتر به یه سؤال نیست؛ مهم اینه که مدل تا چه حد می‌تونه وسط یه فرایند طولانی، وضعیت کار رو حفظ کنه، ابزار استفاده کنه و چند مرحله جلو بره.

در Anthropic هم Claude Sonnet 5.5 اومده که طبق اعلام خود شرکت بیش از ۳۰٪ سریع‌تر شده و هزینه انجام بعضی کارها رو هم تا ۳۰٪ پایین آورده، در حالی که عملکردش به مدل‌های Opus نزدیک شده. این اتفاق مهمه چون برای سیستم واقعی همیشه قوی‌ترین مدل انتخاب منطقی نیست؛ نسبت هزینه، سرعت و کیفیت خیلی وقت‌ها مهم‌تر از چند امتیاز بیشتر در Benchmarkه.

برای اکوسیستم لوپن سورس هم چند اتفاق جدی افتاده. Mistral Large 4 با معماری MoE و یک تریلیون پارامتر، Reflection Beam و Aleph Alpha Kolibri نشون می‌دن مدل‌های با وزن باز (Open Weight) دوباره دارن به مرز مدل‌های قدرتمند بسته نزدیک می‌شن. این یعنی برای تیم‌هایی که کنترل زیرساخت، استقرار داخلی، حریم خصوصی یا Fine-tuning مهمه، گزینه‌ها خیلی جدی‌تر از یک سال قبل شدن.

ولی به نظرم یکی از مهم‌ترین روندها برای AI Engineerها رشد سریع Decision Model یا System One Modelهاست.

این مدل‌ها قرار نیست مثل ChatGPT متن تولید کنن. وضعیت سیستم + یه سؤال مشخص بهشون می‌دی و به‌جای جواب آزاد، احتمال گزینه‌ها رو برمی‌گردونن. مثلاً:
«این درخواست به کدوم مسیر بره؟»
«ایجنت باید ادامه بده یا متوقف بشه؟»
«این محتوا متعلق به کدوم دسته است؟»

اول Jev این ایده رو جدی مطرح کرد، ولی حالا GLiDE، مدل‌های Clef و Clef-flash از Cloudflare، خانواده Decision 2.0 از vLLM و d1 از Liquid AI هم وارد رقابت شدن.

اینجا هرکدوم یه مزیت متفاوت دارن: Jev فعلاً مرجع شناخته‌شده‌تر این حوزه‌ست، Clef-flash روی سرعت و ورودی تصویری جذابه، Decision 2.0 برای اجرای محلی و مدل‌های با اندازه‌های مختلف مناسبه، d1 روی هزینه پایین تمرکز داره و GLiDE ادعا می‌کنه در تصمیم‌های سخت‌تر و استدلالی بهتر عمل می‌کنه. البته بخش زیادی از این امتیازات هنوز توسط خود سازنده‌ها منتشر شده، پس قبل از انتخاب باید روی داده و سناریوی واقعی خودتون ارزیابی‌شون کنید.

در لایه زیرساخت Agent هم همین تغییر دیده می‌شه. Manus 2.0، Meta Muse و Claude Code Mods دارن نشون می‌دن Agent دیگه فقط یه حلقه ساده‌ی «Prompt → Tool → Prompt» نیست. کم‌کم داریم به سمت محیط‌های اجرایی کامل می‌ریم که حافظه، ابزار، کامپیوتر، هویت، زمان‌بندی کارها، افزونه و دسترسی به سرویس‌های مختلف دارن.

هم‌زمان، بحث ایمنی Agentها هم خیلی جدی‌تر شده. OpenAI گفته فعالیت‌های ناسازگار Agentها رو در بیش از ۱۰۰ سازمان شناسایی کرده و طبق گزارش‌ها انتشار GPT-6.1 Astra هم به‌دلیل نگرانی‌های ایمنی متوقف شده. وقتی یه Agent بتونه چند ساعت مستقل کار کنه، فایل بخونه، API صدا بزنه و روی سیستم تغییر ایجاد کنه، کنترل دسترسی، Sandbox، ثبت فعالیت‌ها، پایش و ارزیابی دیگه قابلیت جانبی نیستن؛ بخشی از معماری اصلی محصولن.

خلاصه برای AI Engineerها اینه: خیلی جدی‌تر برید سمت معماری Agentها، استفاده از Tool، کار با کامپیوتر، سیستم‌های ارزیابی، Decision Modelها، Sandbox، حافظه، کنترل دسترسی و هماهنگ‌کردن کارهای طولانی.

مدل پایه هنوز خیلی مهمه، ولی مزیت اصلی کم‌کم داره از «کدوم مدل رو استفاده کردی؟» منتقل می‌شه به «چه سیستمی دور مدل ساختی؟»

🛠 Join @LLMEngineers Community

جدا از موج Decision Modelها، چند خبر فنی این هفته هست که برای AI Engineerها واقعاً ارزش دنبال‌کردن داره.

اولیش EmbeddingGemma 2 از Google DeepMindـه؛ یه مدل باز 740M پارامتری که متن، کد، تصویر، صدا و ویدیو رو داخل یه فضای Embedding مشترک می‌بره. مدل Apache 2.0ـه، برای اجرای روی لپ‌تاپ و موبایل طراحی شده و حتی می‌شه فقط بخش‌های موردنیازش رو بارگذاری کرد؛ مثلاً نسخه متن و کد سبک‌تر از مدل کامل چندرسانه‌ایه. برای جست‌وجوی محلی، RAG، جست‌وجوی کد و بازیابی بین چند نوع محتوا، این خیلی کاربردی‌تر از فرستادن همه‌چیز به یه API بزرگه.
https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2


خبر دوم شاید از نظر مهندسی حتی مهم‌تر باشه. Hugging Face یه راهنمای کامل برای Multi-Harness RL منتشر کرده و یه نتیجه خیلی معنی‌دار داره: همون مدل LFM2.5-2.6B با دقیقاً همون وزن‌ها در Mini-SWE-Agent حدود ۶۲٪ و در Claude Code فقط ۳۳٪ از کارها رو حل کرده. یعنی عملکرد Agent فقط «قدرت مدل» نیست؛ برنامه‌ای که دور مدل ساخته شده، Toolها، Context، حلقه اجرا و نحوه پایان‌دادن کار می‌تونن نتیجه رو تقریباً دو برابر تغییر بدن.
https://adithyask-multi-harness-rl.hf.space

جالب‌تر اینکه وقتی همون مدل با RL روی چند Harness مختلف آموزش داده شد، عملکرد کلیش از ۴۲٪ به ۵۴٪ رسید. این یه نکته مهم برای Benchmarkها هم داره: وقتی می‌گیم «فلان مدل روی Coding Agent بهتره»، بدون گفتن Harness عملاً نصف اطلاعات رو حذف کردیم.

یه موضوع کوچیک‌تر ولی کاربردی هم از پست Andrej Karpathy راه افتاده: استفاده از ASD-STE100 برای توضیح‌های LLM. این همون انگلیسی کنترل‌شده‌ایه که برای مستندات فنی صنایع هوایی ساخته شده؛ جمله کوتاه، فعل مستقیم، واژه ساده و ابهام کمتر. الان چند Skill برای Claude Code و Agentهای دیگه ساخته شده که خروجی توضیحی رو با همین قواعد بازنویسی می‌کنن تا از متن‌های شلخته و پر از حاشیه کم بشه.
https://github.com/JordanBelfort1/explaining-in-asd-ste100

و یه نمونه جالب دیگه از قدرت مدل‌های تخصصی BioCLIP 2ـه. این مدل برای تصاویر موجودات زنده روی TreeOfLife-200M آموزش دیده و روی تشخیص گونه‌ها و چند کار تصویری زیستی از مدل‌های عمومی جلو زده. نکته مهمش برای من خود زیست‌شناسی نیست؛ دوباره همون الگوییه که داریم همه‌جا می‌بینیم: یه مدل نسبتاً تخصصی، وقتی دقیقاً برای یک فضای مسئله ساخته شده، لازم نیست اندازه یه Frontier LLM باشه تا روی همون کار خیلی قوی عمل کنه.
https://huggingface.co/imageomics/bioclip-2

خلاصه اینکه جهت کلی معماری AI داره جالب می‌شه: به‌جای اینکه همه‌چیز رو بندازیم گردن یه LLM غول‌پیکر، داریم قطعات تخصصی می‌سازیم؛ Embedding Model برای بازیابی، Decision Model برای تصمیم، مدل تخصصی برای دامنه مشخص، و یه Agent Harness خوب برای وصل‌کردن همه این‌ها به هم.

شاید سؤال مهم دیگه «بهترین مدل چیه؟» نباشه؛ «بهترین ترکیب مدل‌ها برای این مسئله چیه؟» سؤال بهتریه.

🛠 Join @LLMEngineers Community

کمتر از یک ماه از معرفی Jev گذشته و چیزی که اول شبیه یه مدل خاص برای «تصمیم‌گیری بدون تولید متن» بود، الان تبدیل شده به یه دسته مستقل از مدل‌ها؛ Jev، Clef، d1، GLiDE، Decision 2.0، Julia، OpenJev و چند پروژه دیگه هم‌زمان دارن روی همین ایده کار می‌کنن.

ایده اصلی خیلی ساده‌ست: برای خیلی از کارهای نرم‌افزار اصلاً لازم نیست LLM شروع کنه به تولید متن. مثلاً وقتی فقط می‌خوای بدونی «این تیکت برای کدوم تیمه؟»، «کدوم Tool اجرا بشه؟»، «این نتیجه RAG مرتبطه؟» یا «Agent اجازه داره این کار رو انجام بده؟»، مدل می‌تونه مستقیماً احتمال گزینه‌ها رو برگردونه و کد بر اساس همون تصمیم بگیره. Cloudflare همین الگو رو برای دسته‌بندی درخواست پشتیبانی و حتی تشخیص نوع سایت‌ها توضیح داده و Knowviq هم Decision Modelها رو برای سنجش ارتباط نتایج، پشتیبانی جمله‌ها با شواهد و تشخیص قابل‌پاسخ‌بودن سؤال استفاده کرده.
https://blog.cloudflare.com/clef-decision-models

چیزی که این چند روز جالب‌تر شده، رقابت شدید روی مدل‌های بازه. کلودفلر Clef و Clef-flash رو با Apache 2.0 منتشر کرده؛ خانواده Decision 2.0 از vLLM هم از 0.6B تا 27B می‌ره و می‌تونه تا ۶۴ سؤال درباره یک ورودی رو در یک Forward Pass جواب بده. حتی Julia-1 فقط 144M پارامتر داره، یعنی برای خیلی از دسته‌بندی‌ها و مسیردهی‌های ساده شاید اصلاً مدل چندمیلیاردپارامتری لازم نباشه.

از اون طرف llama.cpp در نسخه 0.6.0 یه endpoint جدید به اسم /v1/systemone اضافه کرده و چند مدل مثل OpenJev، Julia، Kev، Lev و Laya رو محلی اجرا می‌کنه؛ Clef هم با متن و تصویر پشتیبانی شده. یعنی این مدل‌ها دیگه فقط API ابری نیستن و می‌شه بخشی از تصمیم‌های حساس رو کاملاً روی سیستم خودمون نگه داشت.

یه مسیر متفاوت هم داره شکل می‌گیره: «فکر بیشتر» بدون تولید Token بیشتر. GLiDE وقتی بین گزینه‌ها مطمئن نباشه محاسبه بیشتری اختصاص می‌ده، و RSI-Jev v6.0-VL حتی عمق شبکه رو برای هر تصمیم تغییر می‌ده؛ نسخه 4B اون می‌تونه بسته به سختی سؤال در لایه 16، 20 یا 32 متوقف بشه و امتیاز گزارش‌شده‌اش در Decision Index از 38.38 به 46.24 رسیده.

خود Decision Index هم الان داره تبدیل به یکی از محل‌های اصلی مقایسه این مدل‌ها می‌شه، ولی رتبه‌بندی هنوز خیلی سیاله. مثلاً Fastino برای GLiDE امتیاز 64.81 گزارش کرده و Cloudflare هم در زمان انتشار Clef اون رو صدرنشین معرفی کرده؛ این اعداد از روش‌های ارزیابی متفاوت و بعضاً گزارش خود سازنده‌ها میان، پس نباید ازشون یه جدول قطعی «بهترین مدل» ساخت.

https://huggingface.co/spaces/multimodalart/jev-decision-index

🛠 Join @LLMEngineers Community

از نظر کاربرد Decision Modelها , قضیه دیگه فقط چند Demo نیست و چند الگوی مشخص واقعاً وارد محصول و فرایندهای کاری شدن.

• توی Search و RAG**، استارتاپ Knowviq الان از Jev داخل محصولش استفاده می‌کنه: نتیجه‌های جست‌وجو رو از نظر ارتباط امتیاز می‌ده، تک‌تک جمله‌های جواب رو با شواهد چک می‌کنه و در نهایت تصمیم می‌گیره اصلاً سؤال با اطلاعات پیدا‌شده قابل پاسخ هست یا نه. برای مقایسه Jev با Clef، d1 و مدل Perplexity هم ۹۳۸ بررسی واقعی از ترافیک خودش رو بازسازی کرده که حدود ۹۳۰۰ تصمیم مستقل می‌شده.
https://knowviq.com/blog/decision-models

• توی **امنیت**، خود Cloudflare داره Clef رو داخل تیم Threat Intelligence آزمایش می‌کنه تا سایت‌ها رو مثلاً به فروشگاهی، فیشینگ، مد و بقیه دسته‌ها تقسیم کنه. در آزمایش منتشرشده‌شون، کل فرایند دریافت، Render و دسته‌بندی یه سایت با Clef حدود ۲.۲ ثانیه طول کشیده، در حالی که همون مسیر با `gpt-oss-120b` حدود ۴.۷ ثانیه بوده. یعنی Decision Model اینجا فقط جای یه classifier ساده نیست؛ بخشی از یه فرایند امنیتی واقعی شده.
https://blog.cloudflare.com/clef-decision-models

• توی **انتشار محتوا هم یه نمونه خیلی ملموس داریم. Thorsten Meyer گزارش کرده سه Decision Model workflow رو در عملیات نشر خودش اجرا می‌کنه و تا الان حدود ۹۰ هزار تصمیم گرفته شده: تشخیص اینکه یه خبر به کدوم سایت مرتبطه، تشخیص زبان مقاله و یه classifier جایگزین برای موضوع مقاله. فقط در یکی از این کارها ۷۸٬۸۸۹ مقاله با هزینه گزارش‌شده ۲.۰۱ دلار بررسی شدن؛ حدود ۱۰ هزار تطبیق «خبر ↔️ سایت» هم طی سه روز انجام شده.
https://thorstenmeyerai.com/reality-check/24-ways-to-use-jev-a-decision-model-playbook/

• توی مسیردهی (routing) بین مدل‌ها و Agentها هم این ایده عملاً تبدیل به محصول شده. OpenRouter الان Jev Router داره که برای هر درخواست مدل و میزان استدلال مناسب رو انتخاب می‌کنه. در پروژه‌های Open Source مربوط به Claude Code هم Jev برای کارهایی مثل بررسی ایمنی قبل از اجرای Tool، انتخاب اندازه مناسب Sub-agent و تشخیص اینکه Agent واقعاً کارش رو تمام کرده یا نه استفاده شده.

• توی پشتیبانی مشتری، Lead qualification و Moderation هم الگو تقریباً یکیه: به‌جای اینکه برای هر تیکت یا پیام یه LLM کامل اجرا بشه، Decision Model چند سؤال محدود مثل «برای کدوم تیمه؟»، «چقدر فوریه؟»، «نیاز به بررسی انسان داره؟» یا «با این Policy تضاد داره؟» رو هم‌زمان جواب می‌ده. Cloudflare این‌ها رو جزو کاربردهای اصلی Clef معرفی کرده و ابزارهایی مثل Vercel AI Gateway هم Jev رو مشخصاً برای routing، بررسی ریسک و guardrail داخل Agent loop ارائه کردن.

نکته مشترک تقریباً همه این استفاده‌های واقعی هم اینه که Decision Model آخرین صاحب اختیار نیست. وقتی confidence بالاست، کد خودش مسیر رو ادامه می‌ده؛ وقتی مدل مطمئن نیست، پرونده می‌ره برای LLM قوی‌تر یا انسان. یعنی کاربرد اصلی این مدل‌ها حذف کامل LLM نیست، بلکه حذف هزاران LLM call ساده و گرون از وسط سیستم و نگه‌داشتن مدل‌های بزرگ برای جاهاییه که واقعاً استدلال یا تولید لازم داریم.

به نظرم مهم‌ترین نکته اینه که Decision Model قرار نیست جای LLM رو بگیره. داره اون بخش‌هایی از سیستم رو می‌گیره که جواب باز نمی‌خوان؛ فقط یه تصمیم سریع، ارزان و قابل‌استفاده توسط کد می‌خوان.

احتمالاً معماری خیلی از Agentها به این سمت می‌ره: LLM برای برنامه‌ریزی و تولید، Decision Model برای صدها تصمیم کوچک وسط مسیر.
🛠 Join @LLMEngineers Community

توی یکی از پروژه‌هام با یه مشکل نسبتاً جدی روبه‌رو شدم: استخراج دقیق متن از PDFهای فارسی برای استفاده توی RAG. چیزی که در ظاهر ساده‌ست، ولی وقتی پای اسناد واقعی، جدول‌ها، متن‌های راست‌به‌چپ و اعداد وسط باشه، داستان خیلی پیچیده‌تر می‌شه.

مشکل اینه که حتی اگه متن PDF قابل انتخاب باشه، لزوماً درست استخراج نمی‌شه. ممکنه ترتیب کلمات برعکس بشه، ستون‌های جدول قاطی بشن یا عددی به سطر اشتباه نسبت داده بشه. برای RAG این خطاها خطرناکن، چون مدل ممکنه با اعتمادبه‌نفس کامل روی اطلاعات اشتباه جواب بده!

برای حل این مسئله سراغ یه معماری *Adaptive PDF Extraction** رفتم. ایده اینه که به‌جای استفاده از یه OCR یا مدل برای همه اسناد، براساس وضعیت هر صفحه تصمیم بگیریم چه روشی مناسب‌تره.

معماری کلی به این شکله:

۱. استخراج اولیه با PyMuPDF

اول با PyMuPDF متن و ساختار اولیه هر صفحه رو استخراج می‌کنیم. بعد بررسی می‌کنیم آیا Text Layer واقعاً معتبره یا نه. صرفاً وجود متن کافی نیست؛ ترتیب RTL، کاراکترهای خراب و اعداد هم مهمن.

اگه متن سالم باشه، دلیلی نداره دوباره هزینه OCR یا LLM بدیم. ضمن اینکه Bounding Box کلمات و شماره صفحات رو هم حفظ می‌کنیم تا بعداً توی RAG بتونیم به منبع اصلی ارجاع بدیم.

۲. بازسازی ساختار با Docling

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

البته Docling هم برای فارسی بی‌نقص نیست. مخصوصاً Reading Order و RTL ممکنه مشکل داشته باشن و خروجی باید اعتبارسنجی بشه.

۳. استفاده از Gemini به‌عنوان Fallback

وقتی Text Layer خراب باشه یا صفحه اسکن‌شده باشه، می‌تونیم از قابلیت Native PDF Understanding در Gemini استفاده کنیم.

تفاوتش با OCR سنتی اینه که Gemini علاوه بر متن، چیدمان بصری صفحه رو هم درک می‌کنه. برای متن‌های فارسی پیچیده و جدول‌ها قابلیت مفیدیه، اما یه ریسک جدید اضافه می‌کنه: مدل ممکنه به‌جای رونویسی دقیق، متن رو اصلاح کنه یا حتی چیزی از خودش اضافه کنه.

برای همین Prompt باید صریحاً از مدل بخواد متن رو بدون ترجمه، خلاصه‌سازی یا اصلاح بازنویسی کنه و بخش‌های ناخوانا رو مشخص کنه.

۴. اعتبارسنجی و Normalization

این قسمت به‌اندازه خود استخراج مهمه. دو نسخه از متن نگه می‌داریم:

- Raw Text:
متن اصلی برای بررسی و ارجاع.
- Normalized Text:
نسخه استانداردشده برای Search و Embedding، مثلاً یکسان‌سازی ي/ی و ك/ک و مدیریت نیم‌فاصله.

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

از نظر من، برای Production بهتره اول روش‌های ساده‌تر رو تست کنیم و فقط وقتی واقعاً نیاز شد سراغ Pipeline پیچیده‌تر بریم.

برای ارزیابی هم فقط CER و WER کافی نیستن. باید دقت اعداد، ترتیب RTL، ساختار جدول‌ها، ارجاع به صفحات، هزینه و Latency رو جداگانه اندازه بگیریم.

درس اصلی این تجربه برای من این بود: PDF Extraction فقط OCR نیست؛ یه مسئله Document Understanding و Data Quality هم هست.

توی سیستم‌های RAG، کیفیت خروجی هیچ‌وقت نمی‌تونه مستقل از کیفیت اطلاعات ورودی باشه. گاهی اصلاح Pipeline استخراج سند، از عوض‌کردن Embedding Model یا LLM تأثیر مهم‌تری روی قابل‌اعتمادبودن پاسخ‌ها داره.

🛠 Join @LLMEngineers Community

انتشار Tasmim-Bench؛ مقایسه ۲۹ مدل Decision روی زبان فارسی

ما برای اینکه ببینیم مدل‌های تخصصی تصمیم‌گیری واقعاً چقدر فارسی رو می‌فهمن، یه بنچمارک به اسم Tasmim-Bench ساختیم و نتایجش رو به‌صورت عمومی روی Hugging Face منتشر کردیم.

مدل‌های Decision با LLMهای چت‌محور فرق دارن. قرار نیست متن طولانی تولید کنن؛ یه وضعیت رو می‌گیرن و برای سؤال‌های مشخص، تصمیم ساختاریافته همراه با احتمال هر گزینه برمی‌گردونن.

ما سه نوع تصمیم رو بررسی کردیم:

- Choice:
انتخاب بین گزینه‌های پویا؛ مثلاً یه درخواست مشتری به کدوم بخش ارجاع داده بشه یا Agent کدوم ابزار رو اجرا کنه؟
- Noul:
تصمیم دودویی؛ مثلاً آیا شواهد پیدا‌شده برای پاسخ به سؤال کافی هستن؟ آیا درخواست نیاز به بررسی انسانی داره؟
- Score:
امتیازدهی ترتیبی؛ مثلاً فوریت یه تیکت چقدره یا ریسک یه عملیات در چه سطحیه؟

برای این کار ۱۲۰ سناریوی فارسی در ۸ حوزه طراحی کردیم؛ از پشتیبانی مشتری، RAG و انتخاب ابزار Agent گرفته تا Moderation، فروشگاه اینترنتی، پردازش اسناد، فاکتورها و امنیت.

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

در مجموع ۲۹ مدل رو ثبت کردیم: ۱۹ مدل Local زیر ۵۰۰ میلیون پارامتر و ۱۰ مدل Decision از طریق OpenRouter. از این تعداد، ۲۰ مدل حداقل در بخشی از ارزیابی نتیجه قابل‌اندازه‌گیری داشتن.

نتایج توی تصویر جالبه:

مدل GPT-6 Luna Decisions با امتیاز ترکیبی 92.1 در صدر قرار گرفت؛ البته این عدد Accuracy نیست، بلکه ترکیبی از معیارهای Choice، Noul و Score هست.

در بخش Choice، مدل رایگان Mercury Decide با دقت 96.4٪ اول شد. مدل Jev 1.13 هم به 94.3٪ رسید.

بین مدل‌های Local، بهترین نتیجه کامل متعلق به Decima-base با حدود ۳۲۲ میلیون پارامتر بود؛ ولی دقت Choice اون فقط 47.9٪ شد.

هدف نهایی پروژه ساخت یه Decision Model سبک و تخصصی برای فارسی هست که بشه به‌صورت Local اجرا و Fine-tune کرد.

https://huggingface.co/datasets/mshojaei77/tasmim-bench

🛠 Join @LLMEngineers Community