اگر در حال حاضر برای پیادهسازی سیستمهای بازیابی دادهها روی شباهتهای ریاضی تکیه میکنید، احتمالاً با نتایجی مواجه شدهاید که هیچ منطق تجاری ندارند. حقیقت این است که ریاضیات، قوانین کسبوکار شما را نمیفهمد و این دقیقاً همان نقطهای است که بسیاری از سیستمهای تولید بازیابیافزا در دنیای واقعی سقوط میکنند.
طبق یک راهنمای فنی در ۱۱ ژوئیه ۲۰۲۶، سیستمهای تولید بازیابیافزا (RAG) — که شبیه دانشآموزی است که قبل از جواب دادن، اول کتاب درسی را باز میکند و از آن نقل میآورد — برای رسیدن به سطح عملیاتی، به جای تکیه بر شباهت کسینوسی (Cosine Similarity) ساده، به فیلترهای متادیتای قطعی نیاز دارند که توسط مدلهای زبانی هدایت شوند. این چالش در واقع ریشه در نحوه درک ماشین از محتوا دارد؛ چنانکه پیشتر بررسی کردیم برخی محتواهای انسانی در FAQها بهدلیل ساختار غیربهینه، برای موتورهای پاسخ نامرئی میمانند.
تصور کنید میخواهید «کاربران فعال با امتیاز بالای ۴.۵» را پیدا کنید. تلاش برای تبدیل مقادیر عددی مثل قیمت یا شناسه مشتری به یک فضای برداری چندبعدی، تلاشی بیهوده است که منجر به بازیابیهای نادرست میشود. همانطور که در تحلیلهای قبلی ما دربارهی امنیت و دقت مدلهای بازمتن اشاره کردیم، تکیه محض بر احتمال در لایههای دادهای، ریسک توهمهای سیستمی را بالا میبرد.
به نقل از مستندات Spring AI، این چارچوب از الگوی Self-Querying Retriever استفاده میکند. در این سازوکار، یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — مانند GPT-4o، پرسوجوهای زبان طبیعی را به یک نمایش ساختاریافته JSON از محدودیتهای متاداتا تبدیل میکند. سپس این محدودیتها توسط FilterExpressionBuilder به یک درخت نحو انتزاعی (AST) در قالب Filter.Expression تبدیل میشوند.
این رویکرد ترکیبی به توسعهدهندگان اجازه میدهد تا پیش از محاسبه شباهت برداری، فیلترینگ سختگیرانه متاداتا را در سطح پایگاهداده اجرا کنند. این قابلیت در ذخیرهسازهایی نظیر PgVector، Milvus و Qdrant پشتیبانی میشود تا ابتدا فضای جستوجو با قوانین concrete محدود شده و سپس آستانههای شباهت (مثلاً ۰.۸) اعمال شوند.
برای توسعهدهندگان جاوا، این تغییر به معنای تبدیل نقش LLM از یک «تولیدکننده متن» به یک «تجزیهکننده ساختاریافته» است. با بهرهگیری از AST، کدها در برابر تغییر پایگاهداده برداری مقاوم میشوند و بهدلیل کوچک کردن فضای جستوجو پیش از محاسبات سنگین، مصرف توکن (Token) — یا همان تکههای کوچک متن که مدل میخورد — بهشدت کاهش مییابد. این بهینهسازی در مصرف منابع، یادآور استراتژیهای مدیریت مدلهای پرچمدار است که هدفشان کاهش هزینههای سنگین عملیاتی از طریق مسیریابی هوشمند است.
گام بعدی شما
- بررسی پیادهسازی FilterExpressionBuilder در پروژههای فعلی برای جایگزینی جستوجوهای ساده برداری.
- آزمایش ترکیب مدلهای کوچکتر (SLM) برای تبدیل پرسوجو به JSON جهت کاهش هزینه استنتاج.
- مطالعه الگوهای ردیابی AST در javalld.com برای بهینهسازی کوئریهای پیچیده.
اما تأثیر این رویکرد بر کاهش تأخیر (Latency) در مقیاس میلیونی حتی جذابتر است؛ در گزارش بعدی به بررسی بهینهسازیهای لایه حافظه در vLLM خواهیم پرداخت.
گفتگو