اگر توسعه‌دهنده هستید و با تأخیر زیاد یا پاسخ‌های ناقص در سیستم‌های بازیابی داده دست‌وپنجه نرم می‌کنید، باید بدانید که منطق سخت‌افزاریِ قدیمی در حال مرگ است. اکنون مدل‌ها می‌توانند به‌جای پیروی از یک دستورالعمل خطی، مانند یک مدیر پروژه تصمیم بگیرند که چه ابزاری در چه زمانی لازم است.
طبق یک راهنمای توسعه‌دهندگان که در ۲۷ ژوئن ۲۰۲۶ منتشر شد، مدل Gemini 2.5 Flash اکنون قادر است استفاده از ابزارها را به‌طور خودکار مدیریت کند. در حالی که خط‌لوله‌های سنتی RAG بر یک جریان ثابت «پرسش $\rightarrow$ جست‌وجو $\rightarrow$ پاسخ» تکیه داشتند، این مدل اکنون از توالی‌های سخت‌کد شده فراتر رفته و استراتژی بهینه جست‌وجو را در لحظه و بر اساس پرس‌وجوی کاربر تصمیم‌گیری می‌کند.
سیستم‌های قدیمی تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — اغلب از منطقی صلب و انعطاف‌ناپذیر رنج می‌برند. همان‌طور که در تحلیل قبلی ما درباره‌ی کاهش هزینه‌های استنتاج در DeepInfra اشاره کردیم، گلوگاه فعلی توسعه‌دهندگان دیگر فقط هزینه نیست، بلکه هوشمندیِ فرآیند بازیابی است. اکثر سیستم‌ها بدون توجه به اینکه آیا مدل پاسخ را می‌داند یا خیر، جست‌وجو را فعال می‌کنند که منجر به اتلاف توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — و افزایش تأخیر می‌شود.
گذار به استفاده خودکار از ابزار
بر اساس مستندات آموزشی dev.to، تغییر بنیادین در این است که به‌جای توالی‌های کدنویسی شده، امضاهای توابع (Function Signatures) و توصیفات آن‌ها به مدل داده می‌شود. مدل بر اساس فیلد description در اعلان تابع تصمیم می‌گیرد که آیا به یک ابزار نیاز دارد یا خیر. این رویکرد در واقع بخشی از تغییر پارادایم مدیریت ابزارهایی است که مدل را از یک مخزن دانش ساده به یک کنترل‌کننده فعال تبدیل می‌کند. برای مثال، اگر پرس‌وجوی کاربر ساده باشد، مانند «۲ به‌علاوه ۲ چند می‌شود؟»، مدل به‌طور کامل از مرحله جست‌وجو عبور کرده و پاسخ را مستقیماً تولید می‌کند.
با قابلیت استفاده از ابزار (Tool Use)، جریان کار از یک خط‌لوله سخت به یک فرآیند تصمیم‌گیری پویا تبدیل می‌شود: پرسش $\rightarrow$ تصمیم مدل $\rightarrow$ اجرای search() در صورت نیاز $\rightarrow$ تصمیم مجدد مدل $\rightarrow$ پاسخ نهایی. این انعطاف‌پذیری زمانی حیاتی است که پرس‌وجوی مناسب برای جست‌وجو با سؤال اصلی کاربر متفاوت باشد، یا زمانی که برای بهبود پاسخ نهایی، نیاز به چندین جست‌وجوی مجزا با عبارات مختلف باشد.
وقتی نیاز به جست‌وجو تشخیص داده شود، سیستم از کتابخانه psycopg2 برای برقراری اتصال به پایگاه‌داده و از مدل gemini-embedding-001 برای تولید یک بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که می‌گوید این کلمه «همسایه‌ی» چه کلمات دیگری است — با ۷۶۸ بُعد استفاده می‌کند. مدل سپس آرگومان‌های دقیق تابع search_documents را، شامل رشته‌ی پرس‌وجو (query) و تعداد اسناد بازیابی (top_k)، تعیین می‌کند.
سازوکارهای فنی اجرای ابزار
تعامل بین کاربر، مدل و محیط اجرا طبق یک الگوی تبادل مشخص پیش می‌رود:
- درخواست اولیه: کاربر، ابزارهای در دسترس و سؤال خود را به مدل ارسال می‌کند.
- فراخوانی تابع: مدل با یک شیء
function_callپاسخ می‌دهد (به عنوان مثال:name: "search_documents", args: { query: "F1 score" }). - اجرا: کد پایتون شما تابع را اجرا کرده و نتایج را از پایگاه‌داده برداری (Vector Database) بازیابی می‌کند.
- نتیجه تابع: کد، مقدار
function_resultرا به مدل بازمی‌گرداند. - سنتز نهایی: مدل بررسی می‌کند که آیا اکنون اطلاعات کافی برای ارائه پاسخ متنی را در اختیار دارد یا خیر.
در پیاده‌سازی پایه (در فایل 06_tool_basic.py)، تابع search_documents از یک پرس‌وجوی SQL برای محاسبه شباهت با استفاده از عملگر برداری <=> استفاده می‌کند: SELECT title, body, category, 1 - (embedding <=> %s::vector) AS similarity. این سازوکار تضمین می‌کند که مرتبط‌ترین اسناد بر اساس فاصله برداری استخراج شوند.
مسیریابی از طریق توصیفات دقیق
این پیاده‌سازی با ارائه چندین ابزار به مدل، مسیریابی (Routing) پیشرفته‌ای را معرفی می‌کند. برای مثال، توسعه‌دهنده در فایل 07_tool_multi.py دو ابزار جست‌وجوی مجزا تعریف کرده است:
search_documents: ابزاری توصیف شده برای «جست‌وجو در تمام دسته‌ها، زمانی که دسته نامعلوم است یا سؤال چندین حوزه را پوشش می‌دهد.»search_by_category: ابزاری مخصوص برای جست‌وجو در دسته‌های «ML، Python یا Cloud» در صورتی که سؤال به‌طور واضح یک دسته خاص را هدف قرار داده باشد.
در این ساختار، توصیفات ابزارها به منطق اصلی مسیریابی تبدیل می‌شوند. مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — در نوشتن این توصیفات، تضمین می‌کند که مدل بهینه‌ترین ابزار را برای هر وظیفه انتخاب کند. یک توصیف مبهم اغلب منجر به انتخاب تصادفی ابزار می‌شود، در حالی که توصیفات دقیق، نرخ موفقیت مسیریابی را تقریباً در هر بار اجرا به حداکثر می‌رسانند.
حلقه عامل‌محور و حافظه
پیشرفت اصلی در «حلقه‌ی عامل‌محور» (Agentic Loop) است که در فایل 08_tool_agent.py پیاده شده است. در این ساختار، تاریخچه گفتگو به عنوان حافظه عامل (Agent Memory) عمل می‌کند. هر فراخوانی ابزار و نتیجه‌ی متعاقب آن به لیستی به نام contents اضافه شده و در هر گام دوباره به مدل تزریق می‌شود.
این قابلیت به مدل اجازه می‌دهد استدلال‌های چندمرحله‌ای (Multi-step Reasoning) انجام دهد. با این حال، پیاده‌سازی این حلقه‌ها همیشه بدون نقص نیست؛ چنان‌که برخی تحلیل‌ها نشان می‌دهند شکست عامل‌های هوش مصنوعی لزوماً به دلیل حجم متن نیست، بلکه ریشه در نحوه بازخوانی اطلاعات دارد. برای مثال، وقتی کاربر درباره معیارهای ارزیابی ML و پیاده‌سازی آن‌ها در پایتون می‌پرسد، عامل با یک جست‌وجوی اولیه متوقف نمی‌شود. بلکه ممکن است ابتدا جست‌وجویی برای شناسایی معیارها انجام دهد و سپس یک جست‌وجوی هدفمند دوم برای یافتن قطعه‌کدهای scikit-learn اجرا کند و در نهایت پاسخ را سنتز نماید. در مثال ارائه شده، عامل این کار را در ۳ گام به پایان رساند:
۱. search_by_category({'query': 'ML evaluation metrics', 'category': 'ML'})
۲. search_by_category({'query': 'scikit-learn model evaluation', 'category': 'ML'})
۳. ترکیب نهایی اطلاعات و ارائه پاسخ.
پل پیاده‌سازی
تابع dispatch() به عنوان پل ارتباطی حیاتی بین درخواست‌های رشته‌ای مدل و اجرای واقعی کد پایتون عمل می‌کند. این تابع نام‌هایی مانند search_by_category را به منطق پایتون متناظر نگاشت می‌کند تا اطمینان حاصل شود که قصد مدل به یک عملیات دیتابیسی تبدیل می‌شود. همچنین تابع run_agent این فرآیند را با یک محدودیت max_steps (که پیش‌فرض آن ۸ است) مدیریت می‌کند تا از ایجاد حلقه‌های بی‌نهایت جلوگیری شود و در عین حال فرصت کافی برای جمع‌آوری اطلاعات مکمل به مدل داده شود.
این رویکرد، خط‌لوله RAG را به یک عامل (Agent) پویا تبدیل می‌کند. مدل به‌صورت تکرارشونده اطلاعات را جمع‌آوری کرده و پیشرفت خود را با هدف کاربر می‌سنجد تا زمانی که تصمیم بگیرد پاسخ قطعی را تولید کند.
برای توسعه‌دهندگان، این یعنی انتقال بار منطقی از نوشتن زنجیره‌های پیچیده if-else در پایتون به اصلاح توصیفات متنی ابزارها. تاریخچه گفتگو باعث می‌شود مدل بداند چه چیزی را بازیابی کرده و چه چیزی هنوز ناقص است.
با حرکت به سمت عامل‌های کاملاً خودگردان، توانایی مدل در برنامه‌ریزی بازیابی داده‌ها، اولین گام برای حل مسائل پیچیده است. هرچند این پیشرفت‌ها در محیط‌های نرم‌افزاری چشمگیر است، اما چالش‌های متفاوتی در تعامل با دنیای فیزیکی وجود دارد که حتی مدل‌های پیشرفته‌تر Gemini نیز در آن‌ها با نرخ شکست بالایی مواجه شده‌اند. مرز بعدی، افزودن حافظه دائمی و برنامه‌ریزی بلندمدت به این حلقه‌ها برای مدیریت کارهایی است که ساعت‌ها یا روزها به طول می‌کشند.
گام بعدی شما
- بررسی ساختار
function_callدر مستندات Gemini برای جایگزینی منطق‌های شرطی سخت در اپلیکیشن‌های خود. - تمرکز بر نوشتن توصیفات (description) دقیق برای ابزارها به‌جای پیچه کردن کد پایتون.
- تست کردن محدودیت
max_stepsبرای یافتن تعادل میان دقت پاسخ و هزینه استنتاج.
اما تأثیر این رویکرد بر مدیریت حافظه در مقیاس بالا هنوز ناشناخته است — در تحلیل ما درباره پروتکل زمینه مدل (MCP) به این موضوع بپردازید.
گفتگو