Agentic RAG چیست؟ نمایندگان ساختمان با Qdrant

Summarize this content to 400 words in Persian Lang
Retrieval Augmented Generation یک مسیر خطی و قابل پیش بینی را دنبال می کند: دریافت یک پرس و جو، بازیابی اسناد مربوطه، و ایجاد پاسخ. در بسیاری از موارد این ممکن است برای حل یک مشکل خاص کافی باشد. در بدترین حالت، LLM شما فقط تصمیم می گیرد که به سوال پاسخ ندهید، زیرا زمینه اطلاعات کافی را ارائه نمی دهد.

از طرفی ما کارگزار داریم. به این سیستم ها آزادی عمل بیشتری داده می شود و می توانند چندین گام غیر خطی را برای رسیدن به یک هدف خاص بردارند. تعریف واحدی از چیستی عامل وجود ندارد، اما به طور کلی، این برنامه کاربردی است که از LLM و معمولاً از برخی ابزارها برای برقراری ارتباط با دنیای خارج استفاده می کند.

LLM ها به عنوان تصمیم گیرندگانی استفاده می شوند که تصمیم می گیرند در آینده چه اقدامی انجام دهند. کنش‌ها می‌توانند هر چیزی باشند، اما معمولاً به خوبی تعریف شده و محدود به مجموعه‌ای از امکانات هستند. یکی از این اقدامات ممکن است پرس و جو از یک پایگاه داده برداری، مانند Qdrant، برای بازیابی اسناد مربوطه باشد، اگر زمینه برای تصمیم گیری کافی نباشد.

با این حال، RAG تنها یک ابزار در زرادخانه عامل است.

Agentic RAG: ترکیب RAG با Agents

از آنجایی که تعریف عامل مبهم است، مفهوم RAG نمایندگی همچنین به خوبی تعریف نشده است. به طور کلی به ترکیب RAG با عوامل اشاره دارد. این به عامل اجازه می دهد تا از منابع دانش خارجی برای تصمیم گیری استفاده کند و در درجه اول تصمیم بگیرد که چه زمانی به دانش خارجی نیاز است.

اگر سیستمی را خراب کند، می‌توانیم آن را به‌عنوان عامل RAG توصیف کنیم جریان خطی یک سیستم استاندارد RAG، و به عامل این توانایی را می دهد که چندین گام برای رسیدن به یک هدف بردارد.

یک روتر ساده که مسیری را برای دنبال کردن انتخاب می کند، اغلب به عنوان ساده ترین شکل یک عامل توصیف می شود. چنین سیستمی دارای چندین مسیر با شرایطی است که توضیح می دهد چه زمانی باید یک مسیر خاص را طی کرد. در زمینه Agentic RAG، عامل می تواند تصمیم بگیرد که یک پایگاه داده برداری را پرس و جو کند، اگر زمینه برای پاسخ کافی نیست، یا از پرس و جو بگذرد، اگر کافی است، یا زمانی که سوال به دانش رایج اشاره دارد.

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

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

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

حل مشکلات بازیابی اطلاعات با LLM

به طور کلی، ابزارهایی که در یک سیستم عامل RAG قرار دارند برای حل مشکلات بازیابی اطلاعات استفاده می شوند که برای جامعه جستجو جدید نیستند. LLM نحوه برخورد ما با این مشکلات را تغییر داده است، اما هسته اصلی مشکل باقی می ماند. از چه نوع ابزارهایی می توانید در یک RAG عامل استفاده کنید؟ در اینجا چند نمونه آورده شده است:

پرس و جو از پایگاه داده برداری – رایج ترین ابزار مورد استفاده در سیستم های عامل RAG. این به عامل اجازه می دهد تا اسناد مربوطه را بر اساس پرس و جو بازیابی کند.

گسترش پرس و جو – ابزاری که می تواند برای بهبود پرس و جو استفاده شود. می توان از آن برای افزودن مترادف ها، تصحیح اشتباهات تایپی یا حتی برای ایجاد پرس و جوهای جدید بر اساس درخواست اصلی استفاده کرد.

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

قضاوت کیفیت – دانستن کیفیت نتایج برای پرس و جو داده شده می تواند برای تصمیم گیری در مورد اینکه آیا آنها به اندازه کافی برای پاسخ دادن خوب هستند یا اینکه آیا نماینده باید گام دیگری برای بهبود آنها بردارد استفاده شود. از طرف دیگر، می‌تواند عدم ارائه پاسخ خوب را نیز بپذیرد.

اینها تنها برخی از نمونه ها هستند، اما فهرست کامل نیست. به عنوان مثال، LLM شما احتمالاً می تواند با پارامترهای جستجوی Qdrant بازی کند یا روش های مختلفی را برای پرس و جو انتخاب کند. یک مثال؟ اگر کاربران شما با استفاده از کلمات کلیدی خاصی جستجو می کنند، ممکن است بردارهای پراکنده را به بردارهای متراکم ترجیح دهید، زیرا در چنین مواردی کارآمدتر هستند. در این صورت باید عامل خود را با ابزارهایی مسلح کنید تا تصمیم بگیرید چه زمانی از بردارهای پراکنده و چه زمانی از بردارهای متراکم استفاده کنید. Agentaware از ساختار مجموعه می تواند چنین تصمیماتی را به راحتی اتخاذ کند.

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

جزء بسیار مفید یک RAG عامل نیز یک انسان در حلقه است که می تواند برای تصحیح تصمیمات عامل یا هدایت آن در جهت درست استفاده شود.

در کجا از عوامل استفاده می شود؟

عامل ها مفهوم جالبی هستند، اما از آنجایی که به شدت به LLM ها متکی هستند، برای همه مشکلات قابل استفاده نیستند. استفاده از مدل‌های زبان بزرگ گران است و به کندی انجام می‌شود، که در بسیاری از موارد ارزش هزینه کردن را ندارد. RAG استاندارد فقط شامل یک تماس واحد به LLM است و پاسخ به روشی قابل پیش بینی تولید می شود. از سوی دیگر، Agent ها می توانند چندین مرحله را انجام دهند و تأخیر تجربه شده توسط کاربر افزایش می یابد.

در بسیاری از موارد قابل قبول نیست. Agentic RAG احتمالاً در جستجوی تجارت الکترونیک، جایی که کاربر انتظار پاسخ سریع را دارد، چندان قابل استفاده نیست، اما ممکن است برای پشتیبانی مشتری خوب باشد، جایی که کاربر مایل است برای پاسخ بهتر کمی صبر کند.

کدام چارچوب بهترین است؟

فریمورک های زیادی برای ساخت عوامل وجود دارد و انتخاب بهترین آنها کار آسانی نیست. این بستگی به پشته موجود شما یا ابزارهایی دارد که با آنها آشنا هستید. برخی از محبوب ترین کتابخانه های LLM در حال حاضر به سمت پارادایم عامل حرکت کرده اند و ابزارهایی برای ساخت آنها ارائه می دهند. با این حال، ابزارهایی وجود دارند که عمدتاً برای توسعه عامل ها ساخته شده اند، بنابراین بیایید روی آنها تمرکز کنیم.

لانگ گراف

LangGraph که توسط تیم LangChain توسعه یافته است، به نظر می‌رسد یک توسعه طبیعی برای کسانی است که قبلاً از LangChain برای ساخت سیستم‌های RAG خود استفاده می‌کنند و می‌خواهند با RAG عامل شروع کنند.

با کمال تعجب، LangGraph به تنهایی هیچ ارتباطی با مدل های زبان بزرگ ندارد. این چارچوبی برای ساخت برنامه های کاربردی مبتنی بر گراف است که در آن هر کدام گره مرحله ای از گردش کار است. هر گره یک برنامه کاربردی می گیرد دولت به عنوان ورودی، و یک حالت اصلاح شده به عنوان خروجی ایجاد می کند. سپس حالت به گره بعدی منتقل می شود و به همین ترتیب. لبه ها بین گره ها ممکن است مشروط باشد که انشعاب را ممکن می کند. برخلاف برخی از ابزارهای مبتنی بر DAG (یعنی Apache Airflow)، LangGraph اجازه می‌دهد تا حلقه‌هایی در نمودار ایجاد شود، که اجرای گردش‌های کاری چرخه‌ای را ممکن می‌سازد، بنابراین یک عامل می‌تواند به خود بازتابی و تصحیح خود دست یابد. از نظر تئوری، LangGraph را می توان برای ساخت هر نوع برنامه ای به شیوه ای مبتنی بر نمودار، نه تنها عامل های LLM، استفاده کرد.

برخی از نقاط قوت LangGraph عبارتند از:

ماندگاری – وضعیت نمودار گردش کار به عنوان یک نقطه بازرسی ذخیره می شود. این اتفاق در هر به اصطلاح فوق مرحله (که یک گره متوالی منفرد از یک گراف است) اتفاق می افتد. پاسخ دادن به مراحل خاصی از گردش کار، تحمل خطا، و از جمله تعاملات انسان در حلقه را امکان پذیر می کند. این مکانیسم همچنین به عنوان یک عمل می کند حافظه کوتاه مدت، در زمینه اجرای یک گردش کار خاص قابل دسترسی است.

حافظه بلند مدت – LangGraph همچنین دارای مفهومی از خاطرات است که بین اجراهای مختلف گردش کار به اشتراک گذاشته می شود. با این حال، این مکانیسم باید به صراحت توسط گره های ما مدیریت شود. Qdrant با قابلیت جستجوی معنایی خود اغلب به عنوان یک لایه حافظه بلند مدت استفاده می شود.

پشتیبانی چند عاملی – در حالی که هیچ مفهوم جداگانه ای از سیستم های چند عاملی در LangGraph وجود ندارد، می توان با ساختن یک نمودار که شامل چندین عامل و نوعی سرپرست است که تصمیم می گیرد از کدام عامل در یک موقعیت خاص استفاده کند، چنین معماری ایجاد کرد. اگر یک گره ممکن است هر چیزی باشد، ممکن است عامل دیگری نیز باشد.

برخی دیگر از ویژگی های جالب LangGraph عبارتند از توانایی تجسم نمودار، خودکار کردن تکرار مراحل شکست خورده، و شامل تعاملات انسان در حلقه.

یک نمونه حداقلی از یک RAG عامل می تواند پرس و جو کاربر را بهبود بخشد، به عنوان مثال با رفع اشتباهات تایپی، گسترش آن با مترادف ها، یا حتی ایجاد یک پرس و جو جدید بر اساس درخواست اصلی. سپس عامل می تواند اسناد را از یک پایگاه داده برداری بر اساس پرس و جو بهبود یافته بازیابی کند و یک پاسخ ایجاد کند. برنامه LangGraph که این رویکرد را پیاده‌سازی می‌کند می‌تواند به شکل زیر باشد:

from typing import Sequence
from typing_extensions import TypedDict, Annotated
from langchain_core.messages import BaseMessage
from langgraph.constants import START, END
from langgraph.graph import add_messages, StateGraph

class AgentState(TypedDict):
# The state of the agent includes at least the messages exchanged between the agent(s)
# and the user. It is, however, possible to include other information in the state, as
# it depends on the specific agent.
messages: Annotated[Sequence[BaseMessage], add_messages]

def improve_query(state: AgentState):
…

def retrieve_documents(state: AgentState):
…

def generate_response(state: AgentState):
…

# Building a graph requires defining nodes and building the flow between them with edges.
builder = StateGraph(AgentState)

builder.add_node(“improve_query”, improve_query)
builder.add_node(“retrieve_documents”, retrieve_documents)
builder.add_node(“generate_response”, generate_response)

builder.add_edge(START, “improve_query”)
builder.add_edge(“improve_query”, “retrieve_documents”)
builder.add_edge(“retrieve_documents”, “generate_response”)
builder.add_edge(“generate_response”, END)

# Compiling the graph performs some checks and prepares the graph for execution.
compiled_graph = builder.compile()

# Compiled graph might be invoked with the initial state to start.
compiled_graph.invoke({
“messages”: [
(“user”, “Why Qdrant is the best vector database out there?”),
] })

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

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

CrewAI

CrewAI یکی دیگر از گزینه های محبوب برای عوامل ساختمانی از جمله RAG است. این یک چارچوب سطح بالا است که فرض می کند برخی از عوامل مبتنی بر LLM برای دستیابی به یک هدف مشترک با هم کار می کنند. اینجاست که “خدمه” در CrewAI از آنجا می آید. CrewAI با در نظر گرفتن سیستم های چند عاملی طراحی شده است. بر خلاف LangGraph، توسعه دهنده نموداری از ایجاد نمی کند پردازش، اما عوامل و نقش آنها را در خدمه تعریف می کند.

برخی از مفاهیم کلیدی CrewAI عبارتند از:

عامل – واحدی که نقش و هدف خاصی دارد و توسط یک LLM کنترل می شود. می تواند به صورت اختیاری از برخی ابزارهای خارجی برای برقراری ارتباط با دنیای خارج استفاده کند، اما عموماً با درخواستی که ما به LLM ارائه می دهیم هدایت می شود.

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

نقش ها و اهداف – هر عامل نقش معینی در خدمه دارد و هدفی که باید برای رسیدن به آن هدف داشته باشد. اینها زمانی تنظیم می شوند که ما یک عامل را تعریف می کنیم و برای تصمیم گیری در مورد اینکه کدام عامل را در یک موقعیت خاص استفاده کنیم استفاده می شود.

حافظه – یک سیستم حافظه گسترده شامل حافظه کوتاه مدت، حافظه بلند مدت، حافظه موجود و حافظه متنی است که سه مورد دیگر را ترکیب می کند. همچنین حافظه کاربر برای تنظیمات برگزیده و شخصی سازی وجود دارد. این جایی است که Qdrant وارد بازی می شود، زیرا ممکن است به عنوان یک لایه حافظه بلند مدت استفاده شود.

CrewAI مجموعه ای غنی از ابزارهای ادغام شده در چارچوب را فراهم می کند. این ممکن است یک مزیت بزرگ برای کسانی باشد که می خواهند RAG را با اجرای کد یا تولید تصویر ترکیب کنند. اکوسیستم غنی است، با این حال استفاده از ابزارهای شخصی شما کار مهمی نیست، زیرا CrewAI به گونه ای طراحی شده است که قابل توسعه باشد.

یک برنامه ساده عامل RAG که در CrewAI پیاده سازی شده است می تواند به شکل زیر باشد:

from crewai import Crew, Agent, Task
from crewai.memory.entity.entity_memory import EntityMemory
from crewai.memory.short_term.short_term_memory import ShortTermMemory
from crewai.memory.storage.rag_storage import RAGStorage

class QdrantStorage(RAGStorage):
…

response_generator_agent = Agent(
role=”Generate response based on the conversation”,
goal=”Provide the best response, or admit when the response is not available.”,
backstory=(
“I am a response generator agent. I generate ”
“responses based on the conversation.”
),
verbose=True,
)

query_reformulation_agent = Agent(
role=”Reformulate the query”,
goal=”Rewrite the query to get better results. Fix typos, grammar, word choice, etc.”,
backstory=(
“I am a query reformulation agent. I reformulate the ”
“query to get better results.”
),
verbose=True,
)

task = Task(
description=”Let me know why Qdrant is the best vector database out there.”,
expected_output=”3 bullet points”,
agent=response_generator_agent,
)

crew = Crew(
agents=[response_generator_agent, query_reformulation_agent],
tasks=[task],
memory=True,
entity_memory=EntityMemory(storage=QdrantStorage(“entity”)),
short_term_memory=ShortTermMemory(storage=QdrantStorage(“short-term”)),
)
crew.kickoff()

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

سلب مسئولیت: QdrantStorage بخشی از چارچوب CrewAI نیست، اما از اسناد Qdrant در مورد نحوه ادغام Qdrant با CrewAI گرفته شده است.

اگرچه این یک مزیت فنی نیست، اما CrewAI مستندات عالی دارد. این فریم ورک برای پایتون در دسترس است و شروع کار با آن آسان است. CrewAI همچنین دارای یک پیشنهاد تجاری به نام CrewAI Enterprise است که بستری برای ساخت و استقرار عوامل در مقیاس فراهم می کند.

AutoGen

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

مفاهیم جالب زیادی در چارچوب وجود دارد که برخی از آنها حتی کاملاً منحصر به فرد هستند:

ابزار / توابع – اجزای خارجی که می توانند توسط عوامل برای برقراری ارتباط با دنیای خارج استفاده شوند. آنها به عنوان قابل فراخوانی پایتون تعریف می شوند و می توانند برای هر تعامل خارجی که می خواهیم به عامل اجازه انجام آن را بدهیم، استفاده شوند. حاشیه نویسی نوع برای تعریف ورودی و خروجی ابزارها استفاده می شود و مدل های Pydantic برای طرح های نوع پیچیده تر پشتیبانی می شوند. AutoGen در حال حاضر فقط API تماس ابزار سازگار با OpenAI را پشتیبانی می کند.

مجریان کد – مجریان کد داخلی شامل دستور محلی، دستور Docker و Jupyter هستند. یک عامل می‌تواند کد بنویسد و راه‌اندازی کند، بنابراین از نظر تئوری، عامل‌ها می‌توانند هر کاری را که در پایتون انجام شود انجام دهند. هیچ یک از فریم ورک های دیگر تولید و اجرای کد را آنقدر برجسته نکردند. اجرای کد به عنوان شهروند درجه یک در AutoGen مفهوم جالبی است.

هر عامل AutoGen حداقل از یکی از مؤلفه ها استفاده می کند: انسان در حلقه، مجری کد، مجری ابزار یا LLM. یک RAG عامل ساده، بر اساس مکالمه دو عامل که می تواند اسناد را از یک پایگاه داده برداری بازیابی کند یا پرس و جو را بهبود بخشد، می تواند به شکل زیر باشد:

from os import environ

from autogen import ConversableAgent
from autogen.agentchat.contrib.retrieve_user_proxy_agent import RetrieveUserProxyAgent
from qdrant_client import QdrantClient

client = QdrantClient(…)

response_generator_agent = ConversableAgent(
name=”response_generator_agent”,
system_message=(
“You answer user questions based solely on the provided context. You ask to retrieve relevant documents for ”
“your query, or reformulate the query, if it is incorrect in some way.”
),
description=”A response generator agent that can answer your queries.”,
llm_config={“config_list”: [{“model”: “gpt-4”, “api_key”: environ.get(“OPENAI_API_KEY”)}]},
human_input_mode=”NEVER”,
)

user_proxy = RetrieveUserProxyAgent(
name=”retrieval_user”,
llm_config={“config_list”: [{“model”: “gpt-4”, “api_key”: environ.get(“OPENAI_API_KEY”)}]},
human_input_mode=”NEVER”,
retrieve_config={
“task”: “qa”,
“chunk_token_size”: 2000,
“vector_db”: “qdrant”,
“db_config”: {“client”: client},
“get_or_create”: True,
“overwrite”: True,
},
)

result = user_proxy.initiate_chat(
response_generator_agent,
message=user_proxy.message_generator,
problem=”Why Qdrant is the best vector database out there?”,
max_turns=10,
)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای کسانی که در توسعه عامل تازه کار هستند، AutoGen AutoGen Studio را ارائه می دهد، یک رابط با کد پایین برای نمونه سازی عوامل. اگرچه برای استفاده در تولید در نظر گرفته نشده است، اما به طور قابل توجهی مانع ورود برای آزمایش با معماری عامل را کاهش می دهد.

شایان ذکر است که AutoGen در حال حاضر تحت به روز رسانی های قابل توجهی است، با نسخه 0.4.x در حال توسعه که تغییرات قابل توجهی در API در مقایسه با نسخه پایدار 0.2.x ایجاد می کند. در حالی که این فریم ورک در حال حاضر دارای قابلیت‌های ماندگاری داخلی و مدیریت حالت محدود است، این ویژگی‌ها ممکن است در نسخه‌های آینده تکامل یابند.

OpenAI Swarm

برخلاف سایر چارچوب‌های شرح داده شده در این مقاله، OpenAI Swarm یک پروژه آموزشی است و برای استفاده در تولید آماده نیست. البته شایان ذکر است، زیرا بسیار سبک وزن است و شروع کار با آن آسان است. OpenAI Swarm یک چارچوب آزمایشی برای سازماندهی جریان های کاری چند عاملی است که بر هماهنگی عامل از طریق انتقال مستقیم به جای الگوهای پیچیده ارکستراسیون تمرکز دارد.

با آن تنظیمات، عوامل فقط تبادل پیام در یک چت، فراخوانی اختیاری برخی از توابع پایتون برای برقراری ارتباط با سرویس‌های خارجی، یا واگذاری مکالمه به یک عامل دیگر، در صورتی که دیگری برای پاسخ به سؤال مناسب‌تر به نظر می‌رسد. هر عاملی نقش خاصی دارد که با دستورالعمل هایی که باید تعریف کنیم تعریف می شود.

ما باید تصمیم بگیریم که یک عامل خاص از کدام LLM استفاده کند و مجموعه ای از توابع را که می تواند فراخوانی کند. به عنوان مثال، یک عامل بازیابی می تواند از یک پایگاه داده برداری برای بازیابی اسناد استفاده کندو نتایج را به نماینده بعدی برگردانید. این بدان معناست که باید تابعی وجود داشته باشد که جستجوی معنایی را از طرف خود انجام دهد، اما مدل تصمیم خواهد گرفت که پرس و جو چگونه باید باشد.

در اینجا یک برنامه RAG عامل مشابه، که در OpenAI Swarm پیاده سازی شده است، می تواند به نظر برسد:

from swarm import Swarm, Agent

client = Swarm()

def retrieve_documents(query: str) -> list[str]:
“””
Retrieve documents based on the query.
“””
…

def transfer_to_query_improve_agent():
return query_improve_agent

query_improve_agent = Agent(
name=”Query Improve Agent”,
instructions=(
“You are a search expert that takes user queries and improves them to get better results. You fix typos and ”
“extend queries with synonyms, if needed. You never ask the user for more information.”
),
)

response_generation_agent = Agent(
name=”Response Generation Agent”,
instructions=(
“You take the whole conversation and generate a final response based on the chat history. ”
“If you don’t have enough information, you can retrieve the documents from the knowledge base or ”
“reformulate the query by transferring to other agent. You never ask the user for more information. ”
“You have to always be the last participant of each conversation.”
),
functions=[retrieve_documents, transfer_to_query_improve_agent],
)

response = client.run(
agent=response_generation_agent,
messages=[
{
“role”: “user”,
“content”: “Why Qdrant is the best vector database out there?”
}
],
)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

OpenAI Swarm روی ادغام با ابزارهای خارجی تمرکز نمی کند و اگر می خواهید جستجوی معنایی را با Qdrant ادغام کنید، باید خودتان آن را به طور کامل پیاده سازی کنید. بدیهی است که این کتابخانه به شدت با مدل‌های OpenAI مرتبط است، و در حالی که استفاده از برخی مدل‌های دیگر امکان‌پذیر است، نیاز به کارهای اضافی مانند راه‌اندازی پروکسی دارد که رابط را به OpenAI API تنظیم کنید.

برنده؟

انتخاب بهترین فریم ورک برای سیستم عامل RAG بستگی به پشته موجود، تخصص تیم و الزامات خاص پروژه شما دارد. همه ابزارهای توصیف شده رقبای قوی هستند و با سرعتی سریع توسعه می یابند. ارزش این را دارد که همه آنها را زیر نظر داشته باشید، زیرا احتمالاً در طول زمان تکامل یافته و بهبود می یابند. در نهایت، شما باید بتوانید فرآیندهای مشابهی را با هر یک از آنها بسازید، اما برخی از آنها ممکن است در اکوسیستم خاصی از ابزارهایی که می خواهید عامل شما با آنها تعامل داشته باشد، مناسب تر باشند.

با این حال، هنگام انتخاب یک چارچوب برای سیستم RAG عامل خود، عوامل مهمی وجود دارد که باید در نظر بگیرید:

انسان در حلقه – حتی اگر هدف ما ساختن عوامل مستقل است، اغلب مهم است که بازخورد انسان را در بر بگیرد، بنابراین عوامل ما نمی توانند اقدامات مخرب انجام دهند.

قابلیت مشاهده – اشکال زدایی سیستم چقدر آسان است و درک آنچه در داخل اتفاق می افتد چقدر آسان است. به خصوص مهم است، زیرا ما با بسیاری از اعلان های LLM سر و کار داریم.

با این حال، انتخاب جعبه ابزار مناسب به وضعیت پروژه شما و نیازهای خاص شما بستگی دارد. اگر می خواهید نماینده خود را با تعدادی ابزار خارجی ادغام کنید، CrewAI ممکن است بهترین انتخاب باشد، زیرا مجموعه ادغام های خارج از جعبه بزرگترین هستند. با این حال، LangGraph به خوبی با LangChain ادغام می شود، بنابراین اگر با آن اکوسیستم آشنا هستید، ممکن است برای شما مناسب تر باشد.

همه فریم‌ورک‌ها رویکردهای متفاوتی برای ساخت عوامل دارند، بنابراین ارزش آن را دارد که همه آن‌ها را آزمایش کنید تا ببینید کدام یک به بهترین وجه با نیازهای شما مطابقت دارد. LangGraph و CrewAI بالغ‌تر هستند و ویژگی‌های بیشتری دارند، در حالی که AutoGen و OpenAI Swarm سبک‌تر و آزمایشی‌تر هستند. با این حال، هیچ یک از چارچوب های موجود تمام مشکلات بازیابی اطلاعات ذکر شده را حل نمی کند، بنابراین هنوز باید ابزارهای خود را برای پر کردن شکاف ها بسازید.

Building Agent RAG با Qdrant

مهم نیست که کدام فریم ورک را انتخاب می کنید، Qdrant ابزاری عالی برای ساخت سیستم های عامل RAG است. لطفاً ادغام‌های ما را بررسی کنید تا بهترین مورد را با توجه به موارد استفاده و ترجیحات خود انتخاب کنید. ساده ترین راه برای شروع استفاده از Qdrant استفاده از سرویس مدیریت شده ما، Qdrant Cloud است. یک کلاستر 1 گیگابایتی رایگان است به صورت رایگان در دسترس است، بنابراین می توانید در عرض چند دقیقه شروع به ساخت سیستم عامل RAG خود کنید.

ادامه مطلب

نحوه ادغام Qdrant با:

from typing import Sequence
from typing_extensions import TypedDict, Annotated
from langchain_core.messages import BaseMessage
from langgraph.constants import START, END
from langgraph.graph import add_messages, StateGraph


class AgentState(TypedDict):
    # The state of the agent includes at least the messages exchanged between the agent(s) 
    # and the user. It is, however, possible to include other information in the state, as 
    # it depends on the specific agent.
    messages: Annotated[Sequence[BaseMessage], add_messages]


def improve_query(state: AgentState):
    ...

def retrieve_documents(state: AgentState):
    ...

def generate_response(state: AgentState):
    ...

# Building a graph requires defining nodes and building the flow between them with edges.
builder = StateGraph(AgentState)

builder.add_node("improve_query", improve_query)
builder.add_node("retrieve_documents", retrieve_documents)
builder.add_node("generate_response", generate_response)

builder.add_edge(START, "improve_query")
builder.add_edge("improve_query", "retrieve_documents")
builder.add_edge("retrieve_documents", "generate_response")
builder.add_edge("generate_response", END)

# Compiling the graph performs some checks and prepares the graph for execution.
compiled_graph = builder.compile()

# Compiled graph might be invoked with the initial state to start.
compiled_graph.invoke({
    "messages": [
        ("user", "Why Qdrant is the best vector database out there?"),
    ]
})

from crewai import Crew, Agent, Task
from crewai.memory.entity.entity_memory import EntityMemory
from crewai.memory.short_term.short_term_memory import ShortTermMemory
from crewai.memory.storage.rag_storage import RAGStorage

class QdrantStorage(RAGStorage):
    ...

response_generator_agent = Agent(
    role="Generate response based on the conversation",
    goal="Provide the best response, or admit when the response is not available.",
    backstory=(
        "I am a response generator agent. I generate "
        "responses based on the conversation."
    ),
    verbose=True,
)

query_reformulation_agent = Agent(
    role="Reformulate the query",
    goal="Rewrite the query to get better results. Fix typos, grammar, word choice, etc.",
    backstory=(
        "I am a query reformulation agent. I reformulate the " 
        "query to get better results."
    ),
    verbose=True,
)

task = Task(
    description="Let me know why Qdrant is the best vector database out there.",
    expected_output="3 bullet points",
    agent=response_generator_agent,
)

crew = Crew(
    agents=[response_generator_agent, query_reformulation_agent],
    tasks=[task],
    memory=True,
    entity_memory=EntityMemory(storage=QdrantStorage("entity")),
    short_term_memory=ShortTermMemory(storage=QdrantStorage("short-term")),
)
crew.kickoff()

from os import environ

from autogen import ConversableAgent
from autogen.agentchat.contrib.retrieve_user_proxy_agent import RetrieveUserProxyAgent
from qdrant_client import QdrantClient

client = QdrantClient(...)

response_generator_agent = ConversableAgent(
    name="response_generator_agent",
    system_message=(
        "You answer user questions based solely on the provided context. You ask to retrieve relevant documents for "
        "your query, or reformulate the query, if it is incorrect in some way."
    ),
    description="A response generator agent that can answer your queries.",
    llm_config={"config_list": [{"model": "gpt-4", "api_key": environ.get("OPENAI_API_KEY")}]},
    human_input_mode="NEVER",
)

user_proxy = RetrieveUserProxyAgent(
    name="retrieval_user",
    llm_config={"config_list": [{"model": "gpt-4", "api_key": environ.get("OPENAI_API_KEY")}]},
    human_input_mode="NEVER",
    retrieve_config={
        "task": "qa",
        "chunk_token_size": 2000,
        "vector_db": "qdrant",
        "db_config": {"client": client},
        "get_or_create": True,
        "overwrite": True,
    },
)

result = user_proxy.initiate_chat(
    response_generator_agent,
    message=user_proxy.message_generator,
    problem="Why Qdrant is the best vector database out there?",
    max_turns=10,
)

from swarm import Swarm, Agent

client = Swarm()

def retrieve_documents(query: str) -> list[str]:
    """
    Retrieve documents based on the query.
    """
    ...

def transfer_to_query_improve_agent():
    return query_improve_agent

query_improve_agent = Agent(
    name="Query Improve Agent",
    instructions=(
        "You are a search expert that takes user queries and improves them to get better results. You fix typos and "
        "extend queries with synonyms, if needed. You never ask the user for more information."
    ),
)

response_generation_agent = Agent(
    name="Response Generation Agent",
    instructions=(
        "You take the whole conversation and generate a final response based on the chat history. "
        "If you don't have enough information, you can retrieve the documents from the knowledge base or "
        "reformulate the query by transferring to other agent. You never ask the user for more information. "
        "You have to always be the last participant of each conversation."
    ),
    functions=[retrieve_documents, transfer_to_query_improve_agent],
)

response = client.run(
    agent=response_generation_agent,
    messages=[
        {
            "role": "user",
            "content": "Why Qdrant is the best vector database out there?"
        }
    ],
)