تصور کنید مدیرعاملی به دنبال قرارداد «سقف مسئولیت» می‌گردد، اما چون سند با عبارت «محدودیت مسئولیت» ثبت شده، هرگز آن را نمی‌یابد. او احتمالاً نمی‌داند که سند امضا شده در حال حاضر در یک درایو مشترک ذخیره شده است. این جست‌وجوی سه روزه، در یک روز سه‌شنبه از ماه مارس، منجر به ضرر ۴۰ هزار دلاری یک شرکت شد.
به گزارش وب‌سایت dev.to در تاریخ ۳۱ ژوئیه ۲۰۲۶، دلیل این شکست این است که نوار جست‌وجوی سنتی به جای معنا، فقط دنبال تطابق حروف و کلمات است. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی ساختارهای بازیابی داده اشاره کردیم، اکثر دانش سازمانی در میلیون‌ها فایل و صدها فرمت مختلف پخش شده است. این فایل‌ها اغلب توسط هر کسی سازماندهی شده‌اند که در آن روز اتفاقاً نزدیک‌تر به فایل‌های اداری بوده است. سازمان‌ها در مجموع بیشتر از هر فرد به‌تنهایی در درون آن‌ها می‌دانند، اما بخش دشوار ماجرا، دسترسی به این دانش است.
شکست کلمات کلیدی
وقتی کاربر عبارت «سقف مسئولیت» را تایپ می‌کند، موتور جست‌وجوی کلاویدی (Keyword) فقط اسنادی را برمی‌گرداند که دقیقاً همین رشته‌های متنی را داشته باشند. اگر در قراردادی از عبارت «محدودیت مسئولیت» استفاده شده باشد، سیستم هیچ نتیجه‌ای نمی‌دهد. این دو عبارت معنای یکی دارند اما هیچ کلمه مشترکی ندارند؛ در نتیجه کاربر به اشتباه نتیجه می‌گیرد که سند اصلاً وجود ندارد. نوار جست‌وجو نمی‌تواند تفاوت بین «ما چنین قراردادی نداریم» و «ما قرارداد را داریم، اما با کلمات متفاوتی بایگانی شده است» را تشخیص دهد.
علاوه بر این، جست‌وجوی سنتی در مدیریت «قصد» (Intent) کاربر شکست می‌خورد. انسان‌ها سؤال می‌پرسند، نه کلمه کلیدی. هیچ‌کس مانند یک پایگاه داده فکر نمی‌کند؛ بلکه در ذهن خود می‌پرسد: «آیا تا به حال سقف مسئولیتی زیر یک میلیون پذیرفته‌ایم؟». یک موتور کلاویدی هیچ راهی ندارد که بفهمد این یک سؤال است یا کدام کلمات در این پرس‌وجو در واقع اهمیت بیشتری دارند. برای مثال، اگر عبارت «فسخ» (Termination) را جست‌وجو کنید، ممکن است ترکیبی از اخراج کارکنان، انقضای قراردادها یا پایان لایسنس‌های نرم‌افزاری را دریافت کنید که تنها بر اساس تکرار کلمات رتبه‌بندی شده‌اند، نه بر اساس نیاز واقعی شما.
برای پر کردن این شکاف، توسعه‌دهندگان به سراغ بردار معنایی (Embedding) می‌روند. این مدل‌ها متن را به لیستی از چندین صد عدد تبدیل می‌کنند و آن‌ها را در یک فضای ریاضی قرار می‌دهند که در آن، فاصله بین نقاط نشان‌دهنده شباهت معنایی است. برای مثال، مدل all-MiniLM-L6-v2 می‌تواند مورد استفاده قرار گیرد تا اسناد را به مختصاتی با ۳۸۴ بُعد منتقل کند.
سازوکار فنی
بر اساس مستندات فنی، این سیستم از سه رکن اصلی تشکیل شده است:
- نگاشت معنایی: مدل بردار معنایی یک قطعه متن را می‌خواند و یک لیست مختصات برمی‌گرداند. متون مربوط به «مرخصی سالانه» در یک خوشه قرار می‌گیرند، در حالی که «سقف مسئولیت» بر اساس نحوه استفاده از زبان و نه بر اساس حروف مشترک، در ناحیه‌ای کاملاً مجزا از نقشه می‌نشیند.
- بازیابی مبتنی بر معنا: پرسشی درباره «تعداد روزهای تعطیلی کارکنان در سال اول» در فضای ریاضی نزدیک به متنی درباره «مرخصی سالانه» می‌افتد، حتی اگر کلمه «تعطیلی» هرگز در متن اصلی نباشد.
- اجرای محلی: مدل‌هایی با حجم بسیار کم (مانند ۸۰ مگابایت) می‌توانند بدون نیاز به GPU یا کلید API به‌صورت محلی روی یک لپ‌تاپ اجرا شوند. این موضوع برای سازمان‌ها حیاتی است، زیرا اولین سؤال جدی در هوش مصنوعی سازمانی این نیست که «کدام مدل بهتر است»، بلکه این است که «داده‌های من اجازه دارند به کجا بروند». مدل‌های محلی تضمین می‌کنند داده‌ها به هیچ جای خارج از سازمان نروند.
آرشیوی که مقاومت می‌کند
با این حال، انتقال به این روش بازیابی مبتنی بر هوش مصنوعی به ندرت بدون مشکل است. مانع اصلی، خودِ مدل نیست، بلکه «آرشیو مقاوم» است. داده‌ها وجود دارند، اما استخراج آن‌ها از فرمت‌های قدیمی یک نبرد واقعی است:
- محدودیت‌های PDF: یک فایل PDF در واقع یک سند نیست؛ بلکه مجموعه‌ای از دستورات ترسیمی است که شکل حروف را تولید می‌کند. درخواست متن از یک PDF در واقع درخواستی است که فایل ممکن است از پاسخ دادن به آن امتناع کند.
- مشکلات اکسل: یک صفحه گسترده در واقع پایگاه داده‌ای است که لباس اکسل پوشیده است. تبدیل (Flatting) آن به یک رشته متنی ساده، اغلب منجر به ایجاد ردیفی از اعداد می‌شود که هیچ زمینه‌ای (Context) ندارند که نشان دهد این اعداد به چه چیزی اشاره می‌کنند.
- اسکن‌های قدیمی: قراردادهای اسکن شده از سال ۱۹۹۴ لایه‌ی متنی ندارند و فقط عکس‌هایی از کاغذ هستند. خط لوله‌های (Pipelines) ساده، این‌ها را بی‌صدا به عنوان یک رشته خالی برمی‌گردانند و مهم‌ترین اسناد آرشیو را برای سیستم نامرئی می‌کنند.
استخراج داده‌ها همچنان مرحله‌ای با اصطکاک بالا است. فراتر از استخراج، متن باید «تکه‌بندی» (Chunking) شود. تکه‌بندی ساده (مثلاً بریدن هر ۵۰۰ کاراکتر) اغلب جملات را از وسط کلمه می‌برد و تکه‌هایی می‌سازد که با عباراتی ناقص مثل «در طی این...» شروع می‌شوند و هیچ پاسخی نمی‌دهند. برای اینکه سیستم درست کار کند، باید دقیقاً از مفاصل طبیعی سند برش بزند و عنوانی را که قطعه متن زیر آن قرار داشت، حفظ کند.
برای یک مدیر کسب‌وکار، این یعنی بخش «هوش مصنوعی» در یک سامانه بازیابی، فقط به اندازه کیفیت «پاک‌سازی داده‌ها» مؤثر است. تحول واقعی، تغییر از سیستم بایگانی کتابخانه‌ای (که بر اساس مکان قرارگیری پوشه است) به یک سیستم ریاضی است که بر اساس «آنچه یک جمله در واقع подразуме می‌کند» کار می‌کند.
این گذار، مزیت رقابتی را از کسانی که «داده‌های بیشتر» دارند، به کسانی منتقل می‌کند که می‌توانند داده‌ها را در فضای برداری دقیق‌تر نمایش دهند. سازمان‌هایی که بخش‌های «خسته‌کننده» خط لوله مثل OCR و تکه‌بندی هوشمند را نادیده بگیرند، خواهند دید که ابزارهای گران‌قیمت هوش مصنوعی آن‌ها همچنان نسبت به مهم‌ترین اسنادشان کور هستند.
گام بعدی شما
- بررسی کیفیت OCR در اسناد قدیمی سازمان برای شناسایی نقاط کور بازیابی.
- تست مدل‌های کوچک محلی (مانند خانواده MiniLM) برای استخراج مفاهیم بدون خروج داده از شبکه داخلی.
- بازنگری در استراتژی تکه‌بندی (Chunking) متون برای حفظ معنای جملات در لبه‌های برش.
اگر می‌خواهید این سیستم را از صفر بسازید، می‌توانید چارچوب گام‌به‌گام ما را بر اساس یک تولیدکننده خیالی ۲۴۰ نفری بررسی کنید تا ببینید چگونه تک‌فایل PDF در یک پوشه به یک سامانه بازیابی عملیاتی تبدیل می‌شود؛ فصل اول این راهنما به‌صورت رایگان در leanpub.com/learn2rag در دسترس است.
گفتگو