𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗔𝗿𝗲 𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗛𝘂𝗴𝗲

People use the word agent for everything.

A function that calls a tool is an agent. A chatbot with memory is an agent. A script with a loop is an agent.

This mistake leads to bad engineering. Teams over-engineer simple tasks and under-engineer complex ones. I see teams spend weeks on agent orchestration for workflows that only need one good prompt.

Here is my definition of a real agent.

An agent has an objective. It does not just follow instructions. It decides what to do next. It handles failure. It knows when to stop.

Use these benchmarks:

  • If a human must guide every step, it is a chat interface.
  • If the system recovers from a failed tool call, it is moving toward an agent.
  • If the system breaks a goal into tasks and delegates them, it is a real agent.

Most successful agents are narrow. They do one job well. They handle customer support triage or document extraction. They are not general reasoning engines.

Successful teams focus on these three things:

  • Tool design: How clean is the interface?
  • Failure handling: What happens when a tool returns nothing?
  • Observability: Can you trace why the agent made a decision?

Unsuccessful teams just swap one model for a newer one and expect better results. They ignore the system design.

Frameworks like LangChain or CrewAI change every month. The framework matters less than the pattern.

Use these patterns:

  • Plan then execute: Separate the reasoning step from the execution step.
  • Separate retrieval from reasoning: Fetching context is a different job than using it.
  • Explicit handoffs: Use structured logs when one agent passes work to another.

The framework is just scaffolding. The architecture is the building.

RAG is standard, but chunking is often broken. If you split documents poorly, the model loses context. This leads to hallucinations.

If your RAG results are useless, check your chunking and metadata. The model is rarely the problem.

Models will get better. Context windows will grow. Token costs will drop.

None of that solves the real engineering challenge. You must build systems that behave correctly when you are not watching.

Focus on governance, observability, and reliable tool use. The best engineers will not be model researchers. They will be systems designers who build reliable AI.

پنجره‌های بافت در حال بزرگ شدن هستند؛ و این یعنی همه چیز تغییر می‌کند

تا همین چند وقت پیش، محدودیت اصلی در کار با مدل‌های زبانی بزرگ (LLM)، اندازه «پنجره بافت» (Context Window) آن‌ها بود. اگر می‌خواستید یک کتاب یا یک پایگاه داده بزرگ را به مدل بدهید، با دیوار بزرگی روبرو می‌شدید. اما اکنون، اوضاع در حال تغییر است.

انفجار اندازه پنجره بافت

ما از مدل‌هایی با ۸ هزار توکن شروع کردیم. سپس به ۳۲ هزار، ۱۲۸ هزار و حالا به مدل‌هایی مثل Gemini 1.5 Pro رسیدیم که تا میلیون‌ها توکن را پشتیبانی می‌کنند. این جهش فقط یک عدد بزرگتر نیست؛ این یک تغییر پارادایم در نحوه تعامل ما با هوش مصنوعی است.

دوران RAG: چرا به آن نیاز داشتیم؟

قبل از اینکه پنجره‌های بافت بزرگ شوند، راه اصلی برای دادن اطلاعات اضافی به مدل، استفاده از RAG (تولید تقویت‌شده با بازیابی) بود. در سیستم‌های RAG، ما:

  1. اسناد را تکه‌تکه (Chunking) می‌کنیم.
  2. آن‌ها را به بردارهای ریاضی (Embeddings) تبدیل می‌کنیم.
  3. وقتی سوالی پرسیده می‌شود، مرتبط‌ترین تکه‌ها را پیدا کرده و به مدل می‌فرستیم.

این روش بسیار کارآمد بود، اما مشکلاتی داشت: اطلاعات پراکنده می‌شد، ارتباط بین بخش‌های مختلف اسناد از دست می‌رفت و دقت در درک ساختار کلی متن پایین می‌آمد.

عصر بافت طولانی (Long Context)

با بزرگ شدن پنجره‌های بافت، یک سوال اساسی مطرح می‌شود: آیا دیگر نیازی به RAG هست؟

وقتی می‌توانید کل یک مخزن کد (Codebase) یا ده کتاب را مستقیماً در پرامپت قرار دهید، مدل می‌تواند تمام ارتباطات پیچیده را درک کند. این یعنی:

  • درک بهتر ساختار: مدل می‌بیند که چگونه بخش‌های مختلف به هم متصل هستند.
  • سادگی در توسعه: دیگر نیازی به مدیریت پیچیده پایگاه داده‌های برداری (Vector Databases) نیست.

اما همه چیز هم عالی نیست: چالش‌ها

با وجود این مزایا، بافت طولانی با چالش‌های جدی روبروست:

۱. هزینه (Cost)

پردازش میلیون‌ها توکن بسیار گران‌تر از ارسال چند تکه کوچک است. مدل‌های فعلی بر اساس تعداد توکن‌ها هزینه می‌گیرند، و بافت‌های بزرگ یعنی هزینه‌های سنگین.

۲. تأخیر (Latency)

هرچه بافت بزرگتر باشد، زمان پاسخگویی مدل بیشتر می‌شود. برای کاربرانی که پاسخ آنی می‌خواهند، این یک مشکل بزرگ است.

۳. دقت و پدیده «گم شدن در میانه‌ها» (Lost in the Middle)

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

آینده: رویکرد ترکیبی

به نظر نمی‌رسد RAG کاملاً از بین برود. آینده احتمالاً در یک رویکرد ترکیبی نهفته است:

  • استفاده از RAG برای فیلتر کردن حجم عظیم داده‌ها و کاهش هزینه‌ها.
  • استفاده از بافت طولانی برای تحلیل عمیق و دقیق‌ترِ داده‌های منتخب.

این تغییر، نحوه ساخت اپلیکیشن‌های هوش مصنوعی را از پایه بازنویسی خواهد کرد.