DSPy

این پروژه مهم است چون یک مسیر رسمی و نسبتاً روشن برای ساخت agentهای عملی می‌دهد. primitiveهای اصلی مثل agent، tool، handoff، session و guardrail در یک مدل واحد کنار هم دیده می‌شوند و این کار فهم جریان اجرا را برای تیم‌ها ساده‌تر می‌کند.

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

کاربردهای رایج

• توسعه اپلیکیشن‌های LLM
• ارزیابی و آزمایش ایجنت
• آزمایش و پژوهش
• اپلیکیشن‌های retrieval-augmented

مخاطب مناسب

• مهندسان هوش مصنوعی
• سازندگان اپلیکیشن‌های LLM
• مهندسان پژوهشی
• تیم‌های فنی پیشرفته

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

DSPy در مستندات رسمی خود یک declarative framework برای ساخت نرم‌افزارهای ماژولار مبتنی بر مدل‌های زبانی معرفی می‌شود. هسته اصلی آن روی signatureها، moduleها، metricها و optimizerها بنا شده است تا توسعه‌دهنده به‌جای دستکاری مستقیم prompt stringها، رفتار سیستم را در قالب کد ساخت‌یافته تعریف و سپس آن را compile و optimize کند. این پروژه می‌تواند classifier، RAG pipeline، reasoning chain یا حتی agent loop را مدل کند، اما هویت اصلی آن orchestration runtime، generic chatbot toolkit یا autonomous agent platform نیست.

معماری DSPy را می‌توان در چهار لایه خواند. لایه اول language model configuration است که مدل پایه را برای برنامه تعریف می‌کند. لایه دوم signatureها هستند که قرارداد ورودی/خروجی هر واحد رفتاری را به‌صورت typed و declarative مشخص می‌کنند. لایه سوم moduleها هستند؛ moduleهایی مانند Predict، ChainOfThought یا ReAct همان strategy invocation را روی signatureها سوار می‌کنند و در کنترل‌فلو معمول Python با هم compose می‌شوند. لایه چهارم optimizer و compile loop است که با trainset و metric، instructionها، few-shot demoها یا حتی weight updateها را برای بهبود عملکرد برنامه تنظیم می‌کند. در این مدل، promptها و reasoning traceها بیشتر artifactهای قابل‌بهینه‌سازی‌اند تا رابط اصلی طراحی.

DSPy می‌تواند agent loop را مدل کند، اما agent loop در آن یک shape اختیاری از برنامه است نه هویت اصلی framework. مستندات رسمی نمونه‌هایی از ReAct agent، finetuning agents و agent tutorialها دارند، ولی این‌ها روی همان primitiveهای signature و module سوار می‌شوند. بنابراین DSPy را بهتر است ابزاری برای تعریف و بهینه‌سازی reasoning programهایی دانست که بعضی از آن‌ها agentic هستند، نه frameworkی که از ابتدا حول runtime اجرای agentها یا coordination آن‌ها ساخته شده باشد.

DSPy از tool use و moduleهایی مانند ReAct پشتیبانی می‌کند و می‌تواند ابزارهایی مثل search یا Python execution را داخل برنامه قرار دهد. با این حال، نقش tool calling در DSPy تابع design برنامه است. ابزارها بخشی از signature و control flow کلی هستند و optimizerها هم می‌توانند behavior همین pipeline را تنظیم کنند. در نتیجه، tool calling در DSPy بیشتر جزئی از structured program design است تا مرکز هویت محصول.

DSPy در مستندات رسمی به‌طور صریح برای RAG، multi-hop retrieval و retrieval-as-program examples material دارد و حتی نشان می‌دهد که optimizerها می‌توانند کیفیت RAG pipeline را هم بهبود دهند. اما DSPy به‌تنهایی یک data platform، vector database یا retrieval runtime کامل نیست. retrieval در این پروژه بیشتر به‌عنوان بخشی از program architecture دیده می‌شود؛ یعنی توسعه‌دهنده باید index، retriever، dataset و metric مناسب را جداگانه طراحی کند و DSPy لایه programming و optimization آن را فراهم می‌کند.

DSPy می‌تواند الگوهای delegation یا agent exampleها را مدل کند، اما multi-agent coordination در آن primitive مرکزی و product identity اصلی نیست. بر خلاف frameworkهایی که vocabulary صریحی برای team، crew، group chat یا graph orchestration دارند، DSPy بیشتر به توسعه‌دهنده اجازه می‌دهد هر نوع pipeline reasoning یا composition را با moduleها بسازد. بنابراین اگر چندعاملی هم در DSPy پیاده‌سازی شود، باید آن را نتیجه program composition دانست نه نشانه اینکه DSPy ذاتا orchestration-first multi-agent runtime است.

مدل orchestration در DSPy بیشتر declarative composition درون Python و سپس compile/optimization بر پایه metric است. برنامه با signatureها و moduleها تعریف می‌شود، در کنترل‌فلو عادی Python compose می‌شود و بعد optimizerها instruction، demo یا weight behavior آن را تنظیم می‌کنند. این با graph-first runtimeها یا conversation-driven coordination frameworkها تفاوت دارد. DSPy را بهتر است نزدیک reasoning/program optimization layer و prompt/program abstraction system دید تا engine اصلی orchestration عملیاتی.

نقاط قوت

• signature و module باعث می‌شوند interface رفتاری برنامه از prompt stringهای شکننده جدا شود و طراحی سیستم ساخت‌یافته‌تر بماند.
• optimizerها می‌توانند prompt، few-shot demo و در بعضی مسیرها weight behavior را با اتکا به metric و trainset بهینه کنند.
• برای reasoning pipelineهای چندمرحله‌ای، RAG، classification و evaluation-driven iteration ماده آموزشی رسمی و شفاف دارد.
• model/provider abstraction آن باعث می‌شود برنامه‌ها نسبت به تغییر مدل، strategy یا optimizer قابل‌حمل‌تر بمانند.

محدودیت‌ها

• برای استفاده موثر معمولا به dataset، metric و discipline ارزیابی نیاز دارد؛ بدون آن بخش مهمی از ارزش DSPy بالفعل نمی‌شود.
• compile و optimization هزینه زمانی و هزینه مدل دارند و مستندات رسمی هم درباره این tradeoff صریح هستند.
• DSPy به‌تنهایی جایگزین orchestration runtime، data layer، observability stack یا production operations بیرونی نیست.
• فهم رفتار نهایی سیستم پس از optimization برای تیمی که هنوز با signature، trace و metric design آشنا نیست می‌تواند دشوارتر از prompt scripting ساده باشد.