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


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


یک ایجنت صورت‌حساب‌های مالی شرکت را تحلیل می‌کند.


ایجنت دیگر خبرهای مرتبط با شرکت در یک ماه گذشته را مرور می‌کند.


ایجنت سوم شاخص‌های سهام آن شرکت در بورس را بررسی می‌کند.


در نهایت، هر یک از این ایجنت‌ها نتایج خود را برای ایجنت اصلی ارسال می‌کنند و ایجنت اصلی وظیفه‌ی ترکیب و ارائه‌ی خروجی نهایی را بر عهده دارد.


نکته‌ای که باید به آن توجه داشت این است که هرچند نام این الگو «موازی‌سازی» است، در عمل (به‌ویژه به دلیل استفاده از زبان پایتون در اکثر کتابخانه‌ها) این فراخوانی‌ها معمولاً به‌صورت async در یک event loop اجرا می‌شوند. این موضوع از لحاظ کارایی مشکلی ایجاد نمی‌کند، زیرا بیشتر این فراخوانی‌ها از نوع IO-bound هستند.


در کتابخانه‌هایی مانند Google ADK می‌توان این الگو را به شکل زیر پیاده‌سازی کرد.

 parallel_research_agent = ParallelAgent(
     name="ParallelWebResearchAgent",
     sub_agents=[researcher_agent_1, researcher_agent_2, researcher_agent_3],
     denoscription="Runs multiple research agents in parallel to gather information."
 )

#ADP_AG_CH_3

@metapageai

الگوی Reflection

در فصل چهارم کتاب Agentic Design Patterns با الگوی Reflection آشنا می‌شویم. ایده‌ی اصلی این الگو ارزیابی خروجی یک ایجنت توسط ایجنتی دیگر است. یعنی از یک ایجنت برای بررسی، نقد و بهبود خروجی ایجنت دیگر استفاده می‌کنیم. به همین دلیل در اینجا با یک حلقه روبه‌رو هستیم.


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


در Google ADK معمولاً این الگو به شکل زیر پیاده‌سازی می‌شود:

content_creation_workflow = LoopAgent(
    name="CCWorkflow",
    denoscription="Iterates between Content Creator and Critic agents until the results are approved.",
    sub_agents=[cc_agent, critic_agent, CheckApprovalStatus(name="ApprovalChecker")],
    max_iterations=3,
)

این یکی از الگوهایی است که شخصاً خیلی دوستش دارم. بارها در کار از آن استفاده کرده‌ام و تأثیرش را در خروجی به‌خوبی دیده‌ام.


#ADP_AG_CH_4

@metapageai

استفاده از Tools

در فصل پنجم کتاب Agentic Design Patterns با ابزارها یا همان Tools آشنا می‌شویم.


به بیان ساده، Tool همان چیزی است که به ایجنت‌ها قدرت می‌دهد و آن‌ها را به موجودیتی فراتر از یک LLM تبدیل می‌کند. ابزارها در واقع همان قابلیت‌ها هستند.

اما این قابلیت‌ها را چطور می‌توان به ایجنت‌ها اضافه کرد؟

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

برای مثال:

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

ابزاری طراحی کنید که قابلیت ORM برای پایگاه داده فراهم کند و آن را به ایجنت متصل نمایید؛ در این صورت ایجنت می‌تواند زبان طبیعی را به کوئری دیتابیس تبدیل و اجرا کند.

یا قابلیتی برای جست‌وجو در اسناد داخلی و منابع شرکت ایجاد کنید.

و البته هزاران نمونه دیگر از ابزارها را می‌توان تصور کرد.
#ADP_AG_CH_5

@metapageai

فصل ششم کتاب به مفهوم Planning می‌پردازد.

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


یکی از نمونه‌های کاربردی این الگو، در حوزه‌ی برنامه‌نویسی دیده می‌شود. اگر از ابزارهایی مانند Cursor یا Roo Code (که قابلیت ایجنت دارند) استفاده کرده باشید، مشاهده می‌کنید وقتی مسئله‌ای را به آن‌ها می‌سپارید، در گام نخست مسئله را به چند بخش کوچک‌تر تقسیم می‌کنند.

برای مثال، یک برنامه‌ریز ممکن است چنین طرحی تدوین کند (این مثال واقعی است!):

Set up Google Cloud Vision API for PDF processing  
Implement file location functionality  
Implement text matching logic for PDF documents  
Return PDF-specific location including the page number

اما چه زمانی نباید از این الگو استفاده کرد؟

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

#ADP_AG_CH_6

@metapageai

در فصل هفتم کتاب با الگوی همکاری چندایجنتی (Multi-Agent Collaboration) آشنا می‌شویم.

الگویی که به نوعی ترکیب و جمع‌بندی مفاهیم فصل‌های قبل است.

در فصل‌های پیشین یاد گرفتیم چطور ایجنت‌ها می‌توانند مثلاً به‌صورت زنجیره‌ای (Chaining)، موازی (Parallelization)، یا بازتابی (Reflection) کار کنند.

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

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

فرض کنید سیستمی داریم با هفت ایجنت، که هرکدام وظیفه‌ی خاصی بر عهده دارند. سه ایجنت ممکن است به‌صورت زنجیره‌ای با هم کار کنند، بعضی در قالب reflection به ارزیابی نتایج یکدیگر بپردازند، و گروهی دیگر به شکل موازی فعالیت کنند. معمولاً یکی از ایجنت‌ها نقش هماهنگ‌کننده (Coordinator) را دارد و نقطه‌ی آغاز گراف محسوب می‌شود.

برای مثال، در یک پروژه‌ی برنامه‌نویسی پیچیده، ایجنت هماهنگ‌کننده ابتدا وظیفه‌ی برنامه‌ریزی را به ایجنت Planner می‌سپارد تا مسیر حل مسئله مشخص شود. سپس کار به ایجنت Architect واگذار می‌شود تا ساختار سیستم طراحی گردد، و پس از آن ایجنت Coder وظیفه‌ی نوشتن کد را برعهده می‌گیرد. در این میان، ایجنت Debugger ممکن است از طریق الگوی Reflection خروجی را بررسی و اصلاح کند، و در پایان، ایجنت Tester تست‌های لازم را اجرا می‌کند. در نهایت، نتیجه‌ی نهایی به ایجنت هماهنگ‌کننده بازگردانده می‌شود تا به کاربر ارائه شود.

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

#ADP_AG_CH_7

@metapageai

در فصل هشتم کتاب، با مفهوم حافظه (Memory) و اهمیت آن آشنا می‌شویم.

به‌طور کلی، می‌توان دو نوع حافظه را در نظر گرفت: حافظه کوتاه‌مدت و حافظه بلندمدت.

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

برای مثال، گفتیم معمولاً تنها یک ایجنت (Agent) نداریم، بلکه گرافی از ایجنت‌ها وجود دارد که با همکاری یکدیگر وظیفه تحقق درخواست کاربر را بر عهده دارند. حال اگر خروجی یکی از ایجنت‌ها باید توسط ایجنت دیگری بررسی شود (الگوی Reflection)، این سؤال پیش می‌آید که ایجنت دوم چگونه به خروجی ایجنت اول دسترسی داشته باشد؟

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

در کتابخانه‌ی Google ADK این مفهوم با واژه‌ی State بیان می‌شود. اگر به پشت‌صحنه‌ی State نگاهی بیندازید، خواهید دید چیزی جز یک دیکشنری (Dictionary) نیست.

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

کاربرد دیگر حافظه کوتاه‌مدت، در موقعیتی است که کاربر در حال چت با ایجنت است. در این حالت، لازم است محتوای گفتگوهای اخیر (مثلاً چند دقیقه پیش) در همان صفحه حفظ شود تا جریان مکالمه حفظ گردد. این اطلاعات معمولاً در قالب Events در کتابخانه‌ی Google ADK ذخیره می‌شوند. مستندات این کتابخانه به این شکل آن را تعریف می‌کند:

An Event in ADK is an immutable record representing a specific point in the agent's execution. It captures user messages, agent replies, requests to use tools (function calls), tool results, state changes, control signals, and errors.

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

برای مثال، اگر چند ماه پیش سلیقه‌ی کاربر را شناسایی کرده‌ایم و می‌خواهیم آن را در خروجی ایجنت‌ها لحاظ کنیم، این داده باید در حافظه بلندمدت ذخیره شود. چنین اطلاعاتی معمولاً در پایگاه داده (Database) نگهداری می‌شوند.

در واقع، حافظه بلندمدت زیربنای اصلی ساخت سرویس‌های مبتنی بر RAG است که در فصل مخصوص خود بررسی می‌کنیم.

#ADP_AG_CH_8

@metapageai

Model Context Protocol

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

این پست به فصل دهم کتاب اختصاص دارد. جایی که قرار است درباره‌ی استاندارد MCP (Model Context Protocol) صحبت کنیم. این استاندارد امکان تعامل ایجنت‌ها را با سیستم‌هایی خارج از محیط اجرای آن‌ها فراهم می‌کند.


بگذارید مثالی بزنیم: فرض کنید یک برنامه‌ی مدیریت پروژه با استفاده از ایجنت‌ها نوشته‌ایم و می‌خواهیم ایجنت ما بتواند برای کاربرانش در جیرا تسک ایجاد کند. در این حالت، سیستم جیرا خارج از کنترل ایجنت است و به‌عنوان یک سیستم خارجی (external system) شناخته می‌شود. حالا سؤال اینجاست:


چطور می‌توان این کار را انجام داد؟
چطور ایجنت‌ها می‌توانند با سیستم‌های خارجی ارتباط برقرار کنند؟
و چطور می‌توان منابع (resources) یا ابزارهایی (tools) را در اختیار ایجنت‌ها گذاشت که به‌صورت محلی تعریف نشده‌اند، بلکه توسط یک سرور دیگر فراهم شده‌اند؟



اینجاست که استاندارد MCP وارد عمل می‌شود. MCP یک استاندارد مبتنی بر معماری کلاینت-سرور است (مطابق تصویری که در پست قبلی پیوست کردم). در این ساختار، سرورها مانند جیرا، نوشن، یا زیرساخت‌های ابری می‌توانند مجموعه‌ای از ابزارها یا منابع مطابق این استاندارد ارائه دهند. برنامه‌ای که ما می‌نویسیم، به‌عنوان کلاینت می‌تواند با این سرورها ارتباط برقرار کند و آن‌ها را فراخوانی کند.


برای مثال، فرض کنید نوشن ابزاری (مطابق این استاندارد) برای ایجاد سند تعریف کرده است. ما می‌توانیم این ابزار را به‌عنوان یک MCP Tool در ایجنت خود تعریف کنیم.

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

@metapageai

در این پست به فصل ۱۸ کتاب و موضوع مهم امنیت در سیستم‌های مبتنی بر ایجنت‌ها، یعنی Guardrails، می‌پردازیم.


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


۱. ممکن است اطلاعات شخصی کاربر (مثل شماره کارت بانکی) ناخواسته وارد مدل شود.
۲. کاربر مخرب بتواند با دستکاری ورودی، پرامپت را تغییر دهد و کنترل مدل را به‌دست بگیرد (Jailbreak Attack).
۳. اطلاعات محرمانه کاربران دیگر در خروجی مدل نشت کند.


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


این لایه وظایف زیر را بر عهده دارد⁠:


۱. پاک‌سازی ورودی‌ها و حذف اطلاعات حساس کاربر
۲. شناسایی حملات و جلوگیری از ارسال ورودی مخرب به مدل
۳. کنترل خروجی مدل و جلوگیری از نشت داده‌های محرمانه


این فرایند پیچیده به‌نظر می‌رسد اما پیاده‌سازی آن معمولاً ساده است. برای مثال، در فریم‌ورک Google ADK می‌توان از callbackها استفاده کرد تا قبل و بعد از ارسال پیام به مدل، منطق امنیتی خود را اجرا کنیم. همچنین ابزارها و کتابخانه‌هایی مخصوص این کار وجود دارند، مانند Guardrails AI.

#ADP_AG_CH_18

@metapageai

یکی از مسائلی که اگر با مدل‌های زبانی بزرگ (LLMها) یا ایجنت‌ها کار کرده باشید حتماً با آن روبه‌رو شده‌اید و احتمالاً گاهی هم آزارتان داده این است که وقتی از مدل خروجی را در قالب JSON می‌خواهید، همیشه دقیقاً همان‌طور تحویلتان نمی‌دهد.

گاهی ابتدای خروجی یا انتهای آن ``` یا ```json می‌گذارد، گاهی هم ساختار JSON را درست رعایت نمی‌کند و چیزی کم یا زیاد دارد که رفع کردن آن آزاردهنده است.


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

این کتابخانه خروجی مدل را می‌گیرد و اگر مشکل داشته باشد، آن را به‌صورت خودکار اصلاح می‌کند.

ممکن است بپرسید خودمان نمی‌توانیم چنین کدی بنویسیم؟


چرا، می‌شود. اما نکته‌ی جالب در مورد این کتابخانه این است که از دید نظری به مسئله نگاه کرده است. اگر درس نظریه‌ی زبان‌ها و ماشین‌ها را گذرانده باشید، می‌دانید که هر زبانی از جمله ساختار JSON را می‌توان با یک گرامر (Grammar) توصیف کرد.


این کتابخانه هم دقیقاً از همین ایده استفاده کرده: سعی می‌کند خروجی مدل را طوری اصلاح کند که با گرامر JSON سازگار شود.


در پست قبلی درباره‌ی Guardrails و به‌ویژه قابلیت Callback‌ها صحبت کردیم. یکی از بهترین جاها برای فراخوانی این کتابخانه، همین Callbackها هستند.


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

ادامه پست‌های این کانال بررسی کتاب‌های دیگر خواهد بود.


#ADP_AG_CH_18

@metapageai

در ادامه‌ی پست‌های کانال، قصد داریم کتاب

Build A Robo-Advisor with Python: Automate Your Financial and Investment Decisions

را همراه با هم بخوانیم و بررسی کنیم. این کتاب توسط انتشارات Manning منتشر شده و تمرکز آن بر شیوه‌های مدیریت سرمایه‌گذاری مالی است. نگاه کتاب به سرمایه‌گذاری بلندمدت است و وارد مباحث مربوط به ترید نمی‌شود.

نویسندگان تلاش کرده‌اند به پرسش‌های زیر پاسخ دهند:

۱. چطور یک سبد سرمایه‌گذاری مناسب تشکیل دهیم؟ چه مقدار از دارایی در بورس باشد؟ چه مقدار در رمزارزها؟ و هر سهم بورسی چه وزنی در کل سبد داشته باشد؟

۲. سطح ریسک‌پذیری ما چقدر است؟ و برای هر میزان ریسک، بهترین استراتژی کدام است؟

۳. چگونه میزان مالیات را به حداقل برسانیم؟ و چطور برای دوران بازنشستگی یک برنامه‌ریزی بلندمدت انجام دهیم؟

۴. چطوری مدیریت سرمایه‌گذاری را به صورت خودکار برنامه‌نویسی کنیم؟

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

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

#BRP_RR

@metapageai

اول از همه، بیایید مفهوم مشاور مالی خودکار (robo-advisor) را بررسی کنیم. مشاور مالی خودکار در واقع جایگزین مشاور مالی (انسان) است. به جای اینکه یک فرد کارهایی مثل تعیین اهداف مالی، چیدمان پورتفولیو، برنامه‌ریزی مالی و مدیریت دارایی را انجام دهد، یک نرم‌افزار این وظایف را بر عهده می‌گیرد و معمولاً در ازای کارمزدی (مثلاً حدود ۱ درصد) این خدمات را ارائه می‌دهد.

بنابراین از چنین نرم‌افزاری انتظار داریم مجموعه‌ای از قابلیت‌ها را (حداقل در سطح پایه) به مشتری ارائه دهد:

۱. تخصیص دارایی‌ها (asset allocation). نرم‌افزار باید بتواند بر اساس میزان ریسکی که کاربر حاضر است بپذیرد، ترکیب دارایی او را مشخص کند. این دارایی‌ها معمولاً ترکیبی از سهام، رمزارز، اوراق قرضه، طلا و سایر ابزارهای مالی هستند. این کار اساساً تعیین می‌کند هر دارایی چه سهمی از پورتلفیو را داشته باشد.

۲. توازن بخشی (rebalancing). در ابتدای کار، کاربر معمولاً درصد هدفی برای پورتفولیو خود تعیین می‌کند. مثلاً ۱۰ درصد طلا، ۲۰ درصد سهام شرکت الف، ۳۰ درصد سهام شرکت ب، ۴۰ درصد اوراق قرضه. اما عملکرد دارایی‌ها در طول زمان متفاوت است. ممکن است پس از شش ماه سهام شرکت الف رشد زیادی کند و از ۲۰ درصد به ۲۵ درصد برسد، در حالی‌که سهام شرکت ب ضرر کند و سهمش در پورتفولیو از ۳۰ درصد به ۲۵ درصد کاهش یابد. توازن بخشی یعنی بازگرداندن پورتفولیو به ترکیب هدف. این عملیات به دو گروه کلی دسته‌بندی می‌شود.

توازن بخشی بر اساس میزان تغییر از هدف (drift-based): هر زمان که ترکیب واقعی پورتفولیو بیش از یک حد مشخص از ترکیب هدف فاصله گرفت، توازن انجام می‌شود. مثلاً بخشی از سهام شرکت الف فروخته می‌شود تا تا دوباره درصد‌ها درست شود.

توازن بخشی دوره‌ای (time-based): در فواصل زمانی مشخص، مثلاً هر سه ماه یا هر شش ماه، پورتفولیو به وضعیت هدف برگردانده می‌شود، حتی اگر انحراف خیلی زیاد نباشد.

آیا توزان‌بخشی کار ساده‌ای است؟ در ظاهر بله، اما در عمل خیر. فروش برخی دارایی‌ها ممکن است مشمول مالیات شود. بنابراین نرم‌افزار باید کاری کند که توازن‌بخشی باعث افزایش هزینه مالیاتی نشود. از طرف دیگر، برخی دارایی‌ها سود نقدی (dividend) پرداخت می‌کنند. اینکه این سودها در توزان بخشی چگونه استفاده شوند، مثلاً آیا دوباره سرمایه‌گذاری شوند یا برای اصلاح ترکیب پورتفولیو استفاده شوند، خودش یک تصمیم مهم است.

۳. پیش‌بینی آینده مالی (financial projection). نرم‌افزار باید بتواند بر اساس نرخ تورم، سود مورد انتظار دارایی‌ها، میزان پس‌انداز دوره‌ای کاربر و سایر پارامترها، به او نشان دهد که طی ۳، ۵ یا ۱۰ سال آینده احتمالا چه میزان دارایی خواهد داشت. این قابلیت برای هدف‌گذاری‌های مالی مثل پس‌انداز بازنشستگی یا خرید خانه اهمیت دارد.

۴. استفاده از زیان برای کاهش مالیات (tax-loss harvesting). فرض کنید سهام شرکت الف داریم که خیلی رشد کرده و اگر آن را بفروشیم، باید مالیات سود بپردازیم. در مقابل سهام شرکت ب را داریم که ضررده بوده است.ایده این است که بخشی از سهام ضررده را در همان زمانی بفروشیم که سهام سودده را می‌فروشیم. در این صورت زیان شرکت ب، سود شرکت الف را خنثی می‌کند و در نتیجه مالیات کمتری پرداخت می‌کنیم. مثلاً اگر قرار بوده یک ماه دیگر سهام شرکت ب را بفروشیم، می‌توانیم همین حالا بخشی از آن را بفروشیم تا زیانش به‌عنوان جبران سود شرکت الف استفاده شود. به این ترتیب مقدار مالیاتی که باید بپردازیم کاهش می‌یابد.

۵. مسیر کاهش ریسک (glide path). گاهی کاربر مستقیماً می‌گوید که چه میزان ریسکی برایش قابل‌قبول است. اما گاهی نرم‌افزار خودش می‌تواند سطح ریسک مناسب را پیشنهاد دهد، مخصوصاً بر اساس سن فرد. معمولاً فردی که به سن بازنشستگی نزدیک است تحمل ریسک پایین‌تری دارد، در حالی‌که فردی جوان‌تر (مثلاً در دهه سوم زندگی) می‌تواند ریسک بیشتری بپذیرد. یعنی مسیری که به‌تدریج پورتفولیو از پرریسک به کم‌ریسک تغییر وضعیت می‌دهد.

#BRP_RR_CH_1

@metapageai

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

نویسندگان کتاب تمام سورس‌کد را به صورت عمومی در گیتهاب منتشر کردند.

می‌توانید از طریق این لینک به آن دسترسی پیدا کرده و آن را دانلود کنید.


#BRP_RR_CH_1

@metapageai

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

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

برای سادگی، فرض کنید سه سهم برای ما جذاب هستند: تسلا (TSLA)، انویدیا (NVDA) و مایکروسافت (MSFT).

هری مارکویتز، برنده‌ی جایزه‌ی نوبل اقتصاد، مدلی به نام مدل مارکویتز (Markowitz) ارائه می‌کند و توضیح می‌دهد که سرمایه‌گذاران دو هدف متعارض را دنبال می‌کنند:

از یک طرف به دنبال بازدهی بالا (high returns) هستند و از طرف دیگر می‌خواهند ریسک پایین (low risk) داشته باشند. مدل مارکویتز تلاش می‌کند بین این دو هدف متعارض توازن ایجاد کند.

اما در این پست قصد نداریم به مدل مارکویتز بپردازیم، چون قبل از آن لازم است چند اصطلاح و پیش‌نیاز را بشناسیم.

برگردیم به مثال سه سهمی که داشتیم. فرض کنید بازده مورد انتظار (expected return) هر سهم را می‌دانیم (در عمل از قبل نمی‌دانیم!). مثلاً انتظار داریم بازده سالانه‌ی تسلا ۵ درصد، انویدیا ۳۱ درصد و مایکروسافت ۸ درصد باشد. این مقادیر را می‌توانیم در قالب یک بردار به نام mu نمایش دهیم.


همچنین فرض کنید نوسان یا انحراف معیار سالانه (volatility) هر سهم را هم می‌دانیم (که باز هم در عمل از قبل مشخص نیست!). مثلاً نوسان سالانه‌ی تسلا ۲۵ درصد، انویدیا ۳۵ درصد و مایکروسافت ۱۰ درصد باشد. این مقادیر را هم می‌توان با یک بردار دیگر به نام sigma نمایش داد.

با داشتن این دو بردار می‌توانیم نموداری ترسیم کنیم که در محور عمودی بازده و در محور افقی ریسک قرار دارد. به این risk–reward plot می‌گویند. کد زیر این نمودار را برای ما رسم می‌کند.

فعلاً این نمودار را داشته باشید تا در پست‌های بعدی بیشتر درباره‌اش صحبت کنیم.

import matplotlib.pyplot as plt

stocks = ["TSLA", "NVDA", "MSFT"]
sigma = [0.25, 0.35, 0.10]
mu = [0.05, 0.31, 0.08]


def plot_points(sigma, mu, stocks):
    plt.figure(figsize=(8, 6))
    plt.scatter(sigma, mu, c="black")
    plt.xlim(0, 1)
    plt.ylim(0, 1)
    plt.ylabel("Expected Returns")
    plt.xlabel("Volatility")
    for i, stock in enumerate(stocks):
        plt.annotate(stock, (sigma[i], mu[i]), ha="center", va="bottom", weight="bold")


plot_points(sigma, mu, stocks)
plt.savefig("img/risk-reward.png")

#BRP_RR_CH_2

@metapageai

Risk-Reward Plot

در ادامه پست‌ قبل، حالا می‌خواهیم بازده مورد انتظار (سود) و ریسک سبد دارایی را محاسبه کنیم. از آن جایی که متن این پست نیاز به محاسبات ریاضی داشت، توضیحات را در قالب فایل پی‌دی‌اف تهیه و پیوست کردم.

برای فهمیدن فایل پیوست شده، لطفاً چندبار به دقت آن را به همراه متن پست‌های قبلی بخوانید.

#BRP_RR_CH_2

@metapageai