← 返回列表

سوالات مصاحبه سری AI 11: چگونه RAG را بهینه کنیم؟

بهینه‌سازی RAG یک تنظیم تک‌بخشی نیست، بلکه یک فرآیند بهینه‌سازی تمام زنجیره است. در زیر از چهار بعد سمت نمایه‌سازی داده، سمت جستجو، سمت تولید و سمت ارزیابی، استراتژی‌های بهینه‌سازی سیستماتیک ارائه می‌دهیم و تجربیات عملی را که می‌توانید در مصاحبه ذکر کنید، ضمیمه می‌کنیم.


۱. بهینه‌سازی سمت نمایه‌سازی داده (بهبود کیفیت "پایگاه دانش")

این بخش اغلب نادیده گرفته می‌شود اما سریع‌ترین تأثیر را دارد.

نکته بهینه‌سازی مشکل مشاهده شده روش خاص شاخص اثر
تجزیه اسناد جداول و نمودارهای جریانی در PDF نادیده گرفته می‌شوند، یا کاراکترها بهم ریخته و ترتیب نامرتب است. استفاده از کتابخانه‌های تجزیه بهتر (مانند unstructured، حالت حفظ چیدمان pypdf)؛ استخراج جداول با pandas و تبدیل به Markdown. نرخ بازیابی +5~15%
اندازه تکه‌های متن تکه‌های کوچک باعث از دست رفتن متن (مانند ضمیر "او" در "درآمد او امسال رشد کرد")؛ تکه‌های بزرگ نویز جستجو را افزایش می‌دهند. آزمایش اندازه‌های مختلف تکه (۲۵۶/۵۱۲/۷۶۸ توکن)، هم‌پوشانی ۱۰~۲۰%؛ برای اسناد بلند، بر اساس مرزهای معنایی (پاراگراف/عنوان) تقسیم کنید. نرخ ضربه / وفاداری
اضافه کردن فراداده پاراگراف مرتبط پیدا می‌شود اما منبع یا زمان قابل ردیابی نیست، یا نیاز به فیلتر بر اساس حوزه دارد. برای هر تکه فراداده اضافه کنید: source (نام فایل/URL)، timestamp، page_num، doc_type. در زمان جستجو از فیلتر استفاده کنید (مثلاً doc_type == 'legal'). دقت فیلتر
انتخاب مدل جاسازی embedding عمومی در حوزه‌های تخصصی (پزشکی، کد، حقوق) عملکرد ضعیفی دارد. استفاده از مدل‌های ریزدانه‌شده برای حوزه (BGE‑large‑zh، GTE‑Qwen2‑7B‑instruct)؛ یا ریزدانه‌سازی مدل embedding خود (با triplet loss). MRR@10 جستجو +10~20%

۲. بهینه‌سازی سمت جستجو (دقیق‌تر کردن "مرور کتاب")

جستجو کیفیت "منابع مرجع" تغذیه شده به LLM را تعیین می‌کند.

نکته بهینه‌سازی مشکل مشاهده شده روش خاص اثر
جستجوی ترکیبی جستجوی برداری نمی‌تواند اصطلاحات دقیق (مانند مدل محصول ABC-123) را مطابقت دهد، جستجوی کلیدواژه‌ای نمی‌تواند مترادف‌ها را بفهمد. هم‌زمان از جستجوی برداری (معنایی) و BM25 (کلیدواژه) استفاده کنید، با وزن‌دهی (مانند ۰.۷برداری + ۰.۳BM25) یا ادغام با rerank. نرخ بازیابی +10~25%
بازبینی (Rerank) چند نتیجه اول جستجوی برداری لزوماً مرتبط‌ترین نیستند، دهمین نتیجه بهترین است. استفاده از مدل cross‑encoder (مانند BGE‑reranker-v2، Cohere Rerank) برای امتیازدهی مجدد به مجموعه نامزدها (مثلاً ۲۰ مورد اول) و انتخاب top‑K. نرخ ضربه به طور قابل توجهی بهبود می‌یابد (به‌ویژه top‑1)
بازنویسی پرسش سوال کاربر مبهم یا ارجاع‌های نامشخص در مکالمات چندنوبته ("قیمتش چقدر است؟"). استفاده از LLM برای بازنویسی سوال اصلی به شکلی مناسب‌تر برای جستجو (مانند "قیمت iPhone 15 چقدر است؟")؛ یا تکمیل با تاریخچه مکالمه. نرخ بازیابی +5~15%
HyDE سوال کاربر بسیار کوتاه یا انتزاعی است (مانند "فتوسنتز را توضیح دهید")، جستجوی مستقیم ضعیف است. ابتدا LLM یک پاسخ فرضی تولید کند، سپس از این پاسخ برای جستجوی اسناد استفاده کنید. مناسب برای حوزه‌های باز، اما برای پرسش‌های دقیق واقعی مناسب نیست
تنظیم تعداد جستجو Top‑K K کوچک ممکن است اطلاعات کلیدی را از دست بدهد؛ K بزرگ مصرف توکن و نویز را افزایش می‌دهد. آزمایش K=۳/۵/۱۰ و مشاهده تعادل بین نرخ بازیابی و دقت پاسخ. معاوضه کارایی و اثربخشی

۳. بهینه‌سازی سمت تولید (به LLM آموزش دهیم از منابع مرجع به خوبی استفاده کند)

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

نکته بهینه‌سازی مشکل مشاهده شده روش خاص اثر
مهندسی پرامپت LLM محتوای جستجو را نادیده می‌گیرد یا اطلاعات نادرست تولید می‌کند. دستور واضح: "فقط بر اساس منابع مرجع ارائه شده به سوال پاسخ دهید. اگر اطلاعات کافی یا مرتبط نیست، بگویید 'اطلاعات کافی نیست'." اضافه کردن few‑shot examples که نحوه استناد به منابع را نشان می‌دهد. وفاداری +20~40%
فشرده‌سازی متن محتوای جستجو شده بیش از حد طولانی است (بیش از پنجره متن مدل) یا بیشتر آن نویز است. استفاده از LLMLingua یا فشرده‌سازی متن انتخابی برای حفظ مرتبط‌ترین جملات و سپس ارسال به LLM. کاهش خطر از دست دادن اطلاعات
ارتقاء مدل LLM مدل کوچک (۷B) نمی‌تواند استدلال پیچیده انجام دهد یا متن بلند را به خاطر بسپارد. استفاده از مدل قوی‌تر (GPT‑4o، Claude 3.5 Sonnet، Qwen2.5‑72B). افزایش قابل توجه دقت استدلال
جریان و استناد کاربر نمی‌تواند اعتبار پاسخ را تأیید کند. در زمان تولید، LLM [citation:1] را خروجی دهد که به شماره سند جستجو شده اشاره دارد. در باطن، لینک متن اصلی را ضمیمه کنید. اعتماد کاربر + قابلیت اشکال‌زدایی
کالیبراسیون پاسخ امتناع مدل بدون دلیل پاسخ نادرست می‌دهد یا وقتی باید پاسخ دهد، می‌گوید نمی‌داند. یک آستانه تشابه تنظیم کنید: اگر شباهت کسینوسی top‑1 تکه جستجو شده با سوال کمتر از ۰.۷ بود، به LLM اعلام کنید "مطالب مرتبط نیست". کاهش نرخ توهم

۴. سمت ارزیابی و تکرار (بدانیم به کجا باید تنظیم کنیم)

بدون اندازه‌گیری، بهینه‌سازی غیرممکن است.

نکته بهینه‌سازی روش شاخص
ایجاد مجموعه ارزیابی ۱۰۰~۳۰۰ سوال واقعی کاربر + پاسخ استاندارد + شناسه سند جستجوی صحیح آماده کنید. پوشش سطوح مختلف دشواری و اهداف مختلف.
ارزیابی خودکار استفاده از RAGAS (Faithfulness, Answer Relevance, Context Recall) یا TruLens. سه شاخص اصلی: وفاداری، مرتبط بودن پاسخ، نرخ بازیابی متن.
ارزیابی انسانی هفتگی ۲۰ مورد بد (bad case) را نمونه‌گیری کنید و نوع خطا را تحلیل کنید (شکست جستجو / خطای تولید / کمبود پایگاه دانش). اولویت‌بندی بهبودها.
آزمایش A/B در محیط تولید، استراتژی‌های مختلف جستجو (مثلاً BM25 در مقابل جستجوی ترکیبی) را به صورت سطل‌بندی آزمایش کنید. شاخص‌های آنلاین: رضایت کاربر، نرخ بدون پاسخ.

۵. "تجربیات عملی" که می‌توانید در مصاحبه ذکر کنید (امتیاز اضافی)

"در پروژه RAG که مسئول آن بودم، نرخ ضربه پایه فقط ۶۷٪ بود. من سه کار انجام دادم:
1. تقسیم از ۱۰۲۴ ثابت به تقسیم معنایی پویا (بر اساس عنوان + پاراگراف)، نرخ ضربه به ۷۴٪ رسید؛
2. اضافه کردن جستجوی ترکیبی (برداری + BM25) و یک مدل rerank کوچک، نرخ ضربه به ۸۳٪ افزایش یافت؛
3. بهینه‌سازی پرامپت و الزام به [اطلاعات مرتبط یافت نشد]، نرخ توهم از ۲۲٪ به زیر ۵٪ کاهش یافت.

علاوه بر این، ما یک خط لوله ارزیابی مداوم ایجاد کردیم، قبل از هر تغییر، نمره RAGAS را روی ۲۰۰ سوال اجرا می‌کردیم تا اطمینان حاصل شود که تخریب رخ نداده است."


خلاصه نهایی: یک نقشه راه کامل برای بهینه‌سازی RAG

لایه داده ─→ پاکسازی اسناد، بهینه‌سازی تقسیم، افزایش فراداده، embedding حوزه‌ای
لایه جستجو ─→ جستجوی ترکیبی، rerank، بازنویسی پرسش، HyDE، تنظیم Top-K
لایه تولید ─→ تقویت پرامپت، الزامات دستور، فشرده‌سازی، استناد، آستانه امتناع
لایه ارزیابی ─→ مجموعه ارزیابی، RAGAS، تحلیل انسانی، آزمایش A/B

评论

暂无已展示的评论。

发表评论(匿名)