رونمایی کوهیر از مدل‌های Embed 5؛ ایندکس هوشمند اسناد با جست‌وجوی ۲.۴ برابر سریع‌تر

مدل Embed 5 کوهیر: ترکیب ایندکس باکیفیت با جست‌وجوی فوق‌سریع

شرکت کوهیر (Cohere) از خانواده مدل‌های امبدینگ جدید خود به نام Embed 5 در دو نسخه با بردارهای کاملاً سازگار رونمایی کرد. نسخه Embed 5 Pro به طور ویژه برای ارتقای کیفیت بازیابی در زمان ایندکس آفلاین اسناد و متون طراحی شده است؛ در حالی که نسخه Embed 5 Fast با تمرکز روی کم‌ترین تاخیر و بالا‌ترین توان پردازشی، گزینه‌ای بی‌نقص برای جست‌وجوی تعاملی و حلقه‌های کاری ایجنت‌ها به شمار می‌رود. از آنجا که هر دو مدل از یک فضای برداری (Embedding Space) مشترک استفاده می‌کنند، توسعه‌دهندگان می‌توانند اسناد خود را با نسخه Pro ایندکس کنند و سپس پرسش‌های کاربران را با نسخه Fast پاسخ دهند، بدون اینکه نیازی به بازسازی مجدد ایندکس برداری باشد.

مدل‌های امبدینگ وظیفه دارند متن، تصویر و انواع محتوا را به بردارهای عددی تبدیل کنند؛ بردارهایی که فاصله و نزدیکی آن‌ها به یکدیگر نشان‌دهنده شباهت معنایی میان محتواهاست. سیستم‌های بازیابی اطلاعات (Retrieval) با مقایسه این بردارها، اسناد مرتبط را پیدا می‌کنند. به این ترتیب، ایده فضای مشترک در Embed 5 باعث می‌شود مدلی که برای بارگذاری و ذخیره اولیه اسناد استفاده می‌شود از مدلی که پاسخگوی درخواست‌های کاربران است کاملاً تفکیک شود. کوهیر جزئیات فنی این مدل‌ها را در یادداشت‌های انتشار رسمی خود تشریح کرده است.

یک فضای برداری مشترک، دو کاربرد متفاوت

هر دو نسخه از امبدینگ‌های ماتروشکا (Matryoshka Embeddings) پشتیبانی می‌کنند؛ قابلیتی که به برنامه‌ها اجازه می‌دهد در صورتی که صرفه‌جویی در فضای ذخیره‌سازی مهم‌تر از حداکثر کیفیت بازیابی باشد، بردارهای کوتاه‌شده را ذخیره کنند. البته برای بازیابی متقابل میان دو مدل (Cross-model retrieval)، باید مسیرهای ایندکس‌گذاری و جست‌وجو از ابعاد خروجی یکسان و فرمت پشتیبانی‌شده توسط پایگاه داده برداری استفاده کنند.

مدل‌های Embed 5 از طریق API کوهیر، پلتفرم Microsoft Foundry، سرویس Amazon SageMaker و Model Vault برای استقرار در محیط‌های اختصاصی (Single-tenant) در دسترس هستند. قیمت‌های اعلام‌شده بر حسب توکن مربوط به استفاده از API است و هزینه‌های میزبانی ابری اختصاصی بر اساس شرایط هر پلتفرم محاسبه می‌شود.

بنچمارک‌های ارائه‌شده: برتری چشمگیر نسخه Pro

طبق گزارش کوهیر، مدل Embed 5 Pro در بنچمارک ViDoRe V3 (که به طور ویژه برای ارزیابی اسناد سازمانی پیچیده با داده‌های بصری طراحی شده) میانگین امتیاز ۸۵.۸ را به دست آورده است. این شرکت امتیاز Embed 5 Fast را ۸۴.۷، مدل Voyage 4 Large را ۸۳.۷، مدل Gemini Embedding 2 را ۸۳.۲ و مدل text-embedding-3-large شرکت اوپن‌ای‌آی (OpenAI) را ۷۵.۵ اعلام کرده است.

در آزمون‌های متمرکز بر حوزه مالی، پیشتازی نسخه Pro حتی محسوس‌تر است. این مدل در بنچمارک FinanceBench امتیاز ۸۰.۱، در FinQA امتیاز ۹۰.۰ و در ViDoRe V3 Finance امتیاز ۸۵.۰ را ثبت کرده و نسخه Fast در هر سه آزمون در جایگاه دوم ایستاده است. جالب اینکه امتیاز نسخه Pro در بنچمارک FinanceBench حدود ۲۱.۴ امتیاز از رقیب سرشناس خود یعنی مدل اوپن‌ای‌آی بالا‌تر است. علاوه بر این، کوهیر گزارش داده که در مقایسه با نسل قبلی (Embed 4)، بیش‌ترین جهش عملکرد چندزبانه این مدل در زبان فارسی با ۱۳ امتیاز رشد، زبان تلوگو با ۱۲ امتیاز و زبان هندی با ۱۲ امتیاز رشد حاصل شده است.

البته این آمار‌ها حاصل ارزیابی‌های درون‌سازمانی کوهیر هستند و باید آن‌ها را در کنار تست‌های متناسب با حجم کاری واقعی سنجید؛ چرا که کیفیت نهایی بازیابی به فاکتورهایی مثل نحوه قطعه‌بندی متون (Chunking)، ساختار اسناد، ترکیب زبان‌ها، شیوه پرسش‌وجو، مرحله بازرتبه‌بندی (Reranking) و تنظیمات شباهت پایگاه داده برداری بستگی دارد.

استراتژی بازیابی میان‌مدلی؛ برگ برنده کوهیر

کوهیر عملکرد ترکیب مدل‌های مختلف را برای ثبت سند و جست‌وجوی پرسش در ۴۰ دیتاست توسعه بررسی کرده است. طبق اعلام این شرکت، عملکرد حالت ترکیبی (ایندکس با یک مدل و جست‌وجو با مدلی دیگر) تنها بین ۱.۶ تا ۲.۷ درصد کم‌تر از حالتی است که هر دو مرحله با همان مدل اصلی انجام شود.

این نتیجه زمینه را برای یک معماری دو مرحله‌ای فوق‌العاده جذاب فراهم می‌کند: تمام اسناد و پایگاه داده خود را فقط یک بار با نسخه Pro با نهایت کیفیت ایندکس کنید، و سپس پرسش‌های لحظه‌ای کاربران را با نسخه Fast انکود و جست‌وجو نمایید. با این ترفند، مرحله ذخیره‌سازی داده‌ها از دقت بالای Pro بهره‌مند می‌شود و پاسخ‌دهی مکرر به درخواست‌ها با سرعت بالا‌تر و هزینه بسیار کم‌تر Fast صورت می‌گیرد. آزمایش‌های کوهیر نشان می‌دهد که در طول‌های معمول متن، توان پردازشی Fast به طور میانگین ۲.۴ برابر Pro است (حدود ۳۷۷ سند در ثانیه در برابر ۱۶۰ سند در ثانیه).

البته تاخیر واقعی به عواملی چون طول ورودی، دسته‌بندی داده‌ها (Batching)، موقعیت جغرافیایی، سربار شبکه و سخت‌افزار سرور‌ها بستگی دارد؛ بنابراین تیم‌های فنی بهتر است به جای اتکا به اعداد خام، زمان کلی پاسخ‌دهی را در سیستم‌های خود اندازه بگیرند.

حل چالش برچسب‌های ناقص با روش ارزیابی جدید RCP-nDCG

کوهیر برای بهینه‌سازی Embed 5 از روش ارزیابی ویژه‌ای به نام RCP-nDCG@10 استفاده کرده که هدف آن حل مشکل برچسب‌های ناقص در دیتاست‌ها است. معیار سنتی nDCG نتایج رتبه‌بندی‌شده را با یک کلید پاسخ ثابت مقایسه می‌کند؛ بنابراین اگر سندی مرتبط باشد اما در کلید پاسخ ثبت نشده باشد، سیستم بازیابی بابت پیدا کردن آن هیچ امتیازی دریافت نمی‌کند.

در بررسی کوهیر با مشارکت ۴۶ ارزیاب انسانی، برچسب‌های بنچمارک‌های موجود در پیش‌بینی قضاوت انسان‌ها به دقت (AUC) برابر با ۰.۶۵ رسیدند؛ در حالی که یک مدل زبانی بزرگ کالیبره‌شده به عنوان داور توانست به دقت ۰.۹۱ دست پیدا کند. جالب اینجاست که ارزیاب‌های انسانی ۲۸ درصد از اسنادی را که بنچمارک‌ها «نامرتبط» دانسته بودند، در واقع مفید تشخیص دادند!

معیار RCP-nDCG@10 با بهره‌گیری از یک داور هوش مصنوعی تنظیم‌شده، یک فرمول ارزیابی یکپارچه را روی تمام اسناد بازیابی‌شده اعمال می‌کند. در مقایسه‌های زوجی بین سیستم‌ها، این معیار در ۷۷ درصد موارد سیستمی را برگزید که داوران انسانی نیز آن را ترجیح داده بودند (در مقایسه با ۵۲ درصد برای nDCG سنتی). همین لحاظ کردن اسناد مرتبط جاافتاده در کلید پاسخ، باعث ارتقای ۱۹ امتیازی شد.

کوهیر کدها و داده‌های این روش را در گیت‌هاب منتشر کرده است. با این حال، نتایج همچنان به مدل داور و داده‌های کالیبراسیون وابسته هستند و ممکن است مدل‌های بهینه‌شده با این معیار، در لیدربوردهای سنتی nDCG رتبه‌های متفاوتی کسب کنند.

کاهش حجم بردارها تا ۳۲ بایت؛ صرفه‌جویی چشمگیر در هزینه‌ها

در پروژه‌های بزرگ با حجم دیتای سنگین، هزینه ذخیره‌سازی بردارها حتی می‌تواند از هزینه اینفرنس مدل امبدینگ هم فراتر برود! مدل Embed 5 با ترکیب ابعاد قابل انتخاب و فرمت‌های خروجی با دقت پایین‌تر، گزینه‌های ذخیره‌سازی متنوعی را در اختیار تیم‌ها می‌گذارد:

• بردار ۲۰۴۸ بعدی float32: معادل ۸ کیلوبایت برای هر بردار
• بردار ۱۰۲۴ بعدی int8: معادل ۱ کیلوبایت برای هر بردار
• بردار ۲۵۶ بعدی باینری (Binary): تنها ۳۲ بایت برای هر بردار

برای یک مجموعه شامل ۱۰۰ میلیون چانک (قطعه متنی)، این فرمت‌ها به ترتیب به حدود ۸۱۹ گیگابایت، ۱۰۲ گیگابایت و تنها ۳.۲ گیگابایت فضای ذخیره‌سازی خام نیاز دارند. فشرده‌ترین حالت یعنی ۲۵۶ بعدی باینری، دقیقاً ۲۵۶ برابر کوچک‌تر از حالت ۲۰۴۸ بعدی float32 فضا اشغال می‌کند! البته متادیتاهای ایندکس، ساختارهای گراف، نسخه‌های پشتیبان و سربار دیتابیس نیز به این حجم خام افزوده می‌شوند.

کوهیر فرمت ۱۰۲۴ بعدی int8 را به عنوان تعادلی عالی میان حجم ذخیره‌سازی و کیفیت بازیابی پیشنهاد می‌کند و می‌گوید عملکرد آن در هر دو مدل تقریباً با حالت اعشاری (Float) برابری می‌کند. البته پشتیبانی دیتابیس‌ها از این فرمت‌ها متفاوت است و سیستم شما باید توان ذخیره و مقایسه فرمت انتخابی را داشته باشد.

ایندکس با Pro، جست‌وجو با Fast؛ نمونه کد پیاده‌سازی

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

import os

import cohere

co = cohere.ClientV2(api_key=os.environ["CO_API_KEY"])

documents = co.embed(
    model="embed-v5.0-pro",
    input_type="search_document",
    texts=["Net interest margin narrowed 12 bps to 2.61%."],
    output_dimension=1024,
    embedding_types=["float"],
)

query = co.embed(
    model="embed-v5.0-fast",
    input_type="search_query",
    texts=["How did net interest margin change?"],
    output_dimension=1024,
    embedding_types=["float"],
)

document_vector = documents.embeddings.float_[0]
query_vector = query.embeddings.float_[0]

در این فرآیند، بردار سند وارد ایندکس پایگاه داده می‌شود و بردار پرسش در لحظه ارسال درخواست کاربر، با بردارهای ذخیره‌شده مقایسه می‌گردد. البته خطوط لوله (پایپ‌لاین‌های) موجود بازیابی باید ابعاد یکسان، فرمت خروجی و پیکربندی شباهت مشابه را در هر دو مسیر حفظ نمایند.

سیستم‌های RAG که با فایل‌های PDF، گزارش‌های مالی، تصاویر یا متون چندزبانه کار می‌کنند، می‌توانند از مدل Pro برای ایندکس‌گذاری‌های زمان‌بر و از مدل Fast برای جست‌وجوهای مکرر کاربران بهره ببرند. وجود این فضای برداری مشترک، دردسر امبدینگ مجدد را به کل از بین برده و بدون نیاز به ذخیره نسخه دوم از ایندکس، سرعت جابه‌جایی میان مدل‌ها را به حداکثر می‌رساند.