Postدو موضوع مهم در طراحی Agentهای هوشمند

دو موضوع مهم در طراحی Agentهای هوشمند در پست‌های قبلی تا حدودی درباره تفاوت جستجوی کلمات مشابه و جستجوی مبتنی بر مفهوم (Semantic Search) صحبت کردیم. در سیستم‌های واقعی، برای رسیدن به نتایج بهتر معمولاً از Hybrid Search استفاده می‌کنیم تا بتوانیم از قدرت و انعطاف هر دو رویکرد بهره ببریم. اما دو موضوع مهم دیگر در طراحی Agentها وجود دارد که نقش بسیار مهمی در کیفیت و امنیت سیستم دارند: --- 1️⃣ Reranking؛ پیدا کردن مرتبط‌ترین نتایج فرض کنید ۶ داکیومنت در اختیار داریم. با جستجوی کلمه‌ای (Keyword Search)، داکیومنت‌های ۱ و ۳ پیدا می‌شوند. با جستجوی مفهومی (Semantic Search)، داکیومنت‌های ۲ و ۴ به دست می‌آیند. حالا سؤال این است: در نهایت کدام داکیومنت‌ها واقعاً بهترین پاسخ را برای سؤال کاربر دارند؟ اینجاست که Reranking وارد می‌شود. در Reranking، نتایج اولیه بر اساس میزان ارتباط و کیفیت، مجدداً امتیازدهی و مرتب می‌شوند. به طور کلی دو رویکرد برای ساخت سیستم Reranking داریم: 🔹 رویکرد اول: ساخت مدل امتیازدهی داخلی می‌توان از متخصصان و افراد سازمان خواست نتایج مختلف را ارزیابی و امتیازدهی کنند. سپس با جمع‌آوری این داده‌ها می‌توان یک مدل یا سیستم امتیازدهی متناسب با نیازهای همان سازمان ایجاد کرد. 🔹 رویکرد دوم: استفاده از مدل‌های آماده می‌توان از مدل‌های آماده و Open Source موجود در اکوسیستم Hugging Face استفاده کرد، مانند: * Sentence Transformers * BGE Reranker از BAAI * و مدل‌های مشابه در نهایت Reranker مانند یک فیلتر هوشمند عمل می‌کند و از میان نتایج اولیه، مرتبط‌ترین موارد را انتخاب می‌کند. این موضوع اهمیت زیادی دارد؛ چون قرار نیست تمام اطلاعات بازیابی‌شده را به مدل اصلی منتقل کنیم. برای مثال: User Query ↓ Hybrid Search ↓ 20 Documents ↓ Reranker ↓ Top 5 Documents ↓ LLM / Agent در نتیجه، هم کیفیت Context افزایش پیدا می‌کند و هم حجم اطلاعاتی که به مدل اصلی منتقل می‌شود کاهش می‌یابد؛ موضوعی که می‌تواند روی هزینه، سرعت و کیفیت پاسخ تأثیر مستقیم داشته باشد. --- 2️⃣ Guardrail؛ کنترل رفتار و خروجی Agent موضوع مهم دوم Guardrail است. مدل‌های هوش مصنوعی عاری از خطا نیستند؛ حتی مدل‌های قدرتمند نیز ممکن است دچار Hallucination شوند یا در شرایط خاص، خروجی نامناسب، تبعیض‌آمیز یا قابل سوءاستفاده تولید کنند. بنابراین در معماری Agent باید لایه‌هایی برای کنترل ورودی و خروجی در نظر بگیریم. یک رویکرد این است که از خود یک LLM به عنوان ناظر استفاده کنیم. برای مثال، یک Prompt به مدل می‌دهیم که: > پاسخ را بررسی کن، فقط بر اساس داده‌های دریافت‌شده قضاوت کن و اگر پاسخ نامناسب بود، آن را رد کن. در این حالت یک مدل بزرگ مانند GPT می‌تواند نقش Evaluator / Guardrail را داشته باشد. اما راهکار دیگر استفاده از مدل‌های تخصصی Safety Classifier است. یکی از نمونه‌های معروف: 🛡️ ShieldGemma ShieldGemma محصول Google و خانواده Gemma است که برای Safety Classification طراحی شده است. می‌توان از آن برای بررسی ورودی کاربر و همچنین بررسی خروجی Agent یا LLM استفاده کرد. برای مثال: User Input ↓ ShieldGemma ↓ Safe? ├── No → Block │ └── Yes ↓ Agent ↓ LLM ↓ ShieldGemma ↓ Safe Output? ├── No → Block └── Yes → User در نتیجه می‌توان Guardrail را هم قبل از اجرای Agent و هم بعد از تولید پاسخ قرار داد. ShieldGemma در نسخه‌های متنی خود روی دسته‌هایی مانند Harassment، Hate، Dangerous Content و Sexually Explicit Content تمرکز دارد. --- 🛡️ Llama Guard گزینه شناخته‌شده دیگر Llama Guard از Meta است. Llama Guard نیز برای Safety Classification طراحی شده و می‌تواند در سناریوهای مختلف برای کنترل محتوای ورودی و خروجی مورد استفاده قرار گیرد. یکی از مزیت‌های مهم این خانواده، امکان استفاده و شخصی‌سازی متناسب با نیازهای سیستم است. --- جمع‌بندی در یک Agent یا RAG System حرفه‌ای، فقط پیدا کردن اطلاعات کافی نیست. ما باید دو سؤال مهم را پاسخ دهیم: 1. آیا اطلاعاتی که پیدا کرده‌ایم واقعاً مرتبط و باکیفیت هستند؟ ⬅️ Reranking 2. آیا ورودی و خروجی سیستم امن، مناسب و مطابق Policy ما هستند؟ ⬅️ Guardrails بنابراین یک معماری ساده می‌تواند چیزی شبیه این باشد: @code_crafters