<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های میلاد رئیسی</title>
        <link>https://virgool.io/feed/@Milad_Reisi</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-04-15 08:11:52</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/3527494/avatar/QD9vew.jpg?height=120&amp;width=120</url>
            <title>میلاد رئیسی</title>
            <link>https://virgool.io/@Milad_Reisi</link>
        </image>

                    <item>
                <title>اگر می‌خواهید AI یاد بگیرید، این تله را دور بزنید</title>
                <link>https://virgool.io/@Milad_Reisi/from-zero-to-ai-qw4qhcicq5xe</link>
                <description>برای یادگیری هوش مصنوعی از کجا باید شروع کرد؟این نوشته بیشتر خطاب به کسانیست که زمینه فنی یا تحصیلات کامپیوتری مرتبط ندارند اما با دیدن فناوری‌های جدید هوش مصنوعی (مانند ChatGPT) هیجان‌زده‌اند و می‌خواهند وارد دنیای AI شوند.اگر همین امروز در اینترنت «?How to learn AI» را جست‌وجو کنید، معمولا با مسیرهایی پر از ML، NN و DL (یادگیری ماشین، شبکه‌های عصبی و یادگیری عمیق) روبه‌رو می‌شوید.اما شرایط امروز متفاوت شده. قبلا دانشجویان و پژوهشگران خودشان ابزار می‌ساختند تا بعد بتوانند محصولی بسازند. امروز شرکت‌های بزرگ این ابزارها (مثل LLMها) را ساخته‌اند و به صورت API در اختیار ما قرار داده‌اند.یعنی لایه‌ی «ساخت ابزار» از «ساخت محصول» جدا شده است و شما می‌توانید مستقیم وارد لایه‌ی کاربرد شوید و با یاد گرفتن LangGraph، OpenAI API و ابزارهای مشابه، خیلی سریع یک اپلیکیشن واقعی بسازید.مثال ساده: قبلا اگر می‌خواستید سفر کنید، باید خودتان ماشین می‌ساختید. امروز اما ماشین آماده است؛ کافیست پشت فرمان بنشینید و حرکت کنید.البته که یادگیری مباحث پایه‌ای عمق درک را بالا می‌برد، اما برای شروع، ضرورتی ندارد. پس خودتان را در تله‌ی «ML/NN/DL برای ورود» گرفتار نکنید.🔹 حال اگر می‌پرسید «پس دقیقا چه یاد بگیرم؟» یک نقشه‌راه ساده به صورت زیر است:* آشنایی مقدماتی با Python* کار با APIها (مثل OpenAI API)* یادگیری یک ابزار ساخت اپلیکیشن LLM (مثل LangGraph) و آشنایی اولیه با Prompt Engineeringبعد با ۲–۳ پروژه کوچک کاربردی ادامه بدهید.✔️ شما چه فکر می‌کنید؟ اگر همین امروز بخواهید وارد AI شوید، از مباحث کلاسیک شروع می‌کنید یا سراغ ابزارهای مدرن می‌روید؟</description>
                <category>میلاد رئیسی</category>
                <author>میلاد رئیسی</author>
                <pubDate>Wed, 17 Sep 2025 20:30:01 +0330</pubDate>
            </item>
                    <item>
                <title>RAG در مقیاس واقعی: پنج اشتباه عملیاتی هزینه‌ساز در RAG</title>
                <link>https://virgool.io/@Milad_Reisi/rag-realworld-pitfalls-uuzukvvfgp6d</link>
                <description>به تجربه من، در بیشتر پروژه‌های سازمانی مشکل اصلی RAG از خود مدل نیست. تحقیقات تازه هم همین را می‌گویند. بیشتر خطاها از داده و Ops می‌آید؛ یعنی همان بخش‌هایی مثل chunking، evaluation، guardrails و observability. وقتی این بخش‌ها درست مدیریت نشوند، خروجی پر از hallucination می‌شود، ریسک بالا می‌رود و رضایت کاربری پایین می‌آید.▪️منبع ناقص یا نامنظم: اگر اسناد از اول کامل و تمیز نباشند، retrieval ضعیف می‌شود. (نمونه: AWS Prescriptive Guidance)▫️چانکینگ ضعیف: برش نادرست متن باعث می‌شود بخشی از اطلاعات گم شود یا خطا زیاد شود. انتخاب استراتژی درست می‌تواند تا ۴۵٪ دقت را بهتر کند (Chroma). بعضی تیم‌ها مثل Weaviate نیز از chunk-on-demand استفاده می‌کنند تا کیفیت حفظ شود و هزینه پایین بماند.▪️ارزیابی نامرتبط: معیارهای عمومی کافی نیستند. باید metricsهایی متناسب با نیاز سازمان تعریف شود. ابزارهایی مثل Arize یا Weights &amp; Biases کمک می‌کنند حتی با داده کم یک LLM-as-a-Judge بسازیم و کیفیت را پیوسته بسنجیم.▫️نبود guardrails: فقط کنترل ورودی و خروجی کافی نیست. حملات اخیر نشان داده‌اند خود روند استدلال (reasoning process) هم باید امن شود. (NVIDIA NeMo Guardrails)▪️فقدان observability: بدون رصد دقیق، خطاها پنهان می‌مانند. ابزارهایی مثل Langfuse یا OpenTelemetry امکان رهگیری هزینه، latency و مسیر استدلال را فراهم می‌کنند.✔️ جمع‌بندی: RAG فقط زمانی به تجربه کاربری خوب منجر می‌شود که این پنج بخش جدی گرفته شوند. اگر شما هم تجربه‌ای در این زمینه دارید یا مورد مهم دیگری به ذهنتان می‌رسد، خوشحال می‌شوم برایم بنویسید.</description>
                <category>میلاد رئیسی</category>
                <author>میلاد رئیسی</author>
                <pubDate>Fri, 05 Sep 2025 00:43:37 +0330</pubDate>
            </item>
                    <item>
                <title>نخبه کیست؟ آن‌که می‌داند یا آن‌که می‌سازد؟</title>
                <link>https://virgool.io/@Milad_Reisi/the-real-talent-yrmgouqcaptj</link>
                <description>در میان دانشجویان، معمولا دو مسیر مشخص دیده می‌شود:·        گروهی آینده‌ی خود را در بازار کار جست‌وجو می‌کنند و تمرکز اصلیشان بر یادگیری عملی و مهارت‌آموزی است.·        و گروهی دیگر مقصد را در اپلای و ادامه‌ی تحصیل می‌بینند و بیش از هر چیز به نمره و رزومه‌ی آکادمیک توجه دارند.این دو رویکرد پیامدهایی متفاوت دارند. دانشجویان فنی اغلب در عمل تواناترند، اما به دلیل معدل و کارنامه‌ی تحصیلی ضعیف‌تر، در نگاه نخست چندان جدی گرفته نمی‌شوند. در مقابل، دانشجویان آکادمیک با نمره‌های بالا و رزومه‌ای پررنگ‌تر در آغاز مسیر حرفه‌ای قوی به نظر می‌رسند، اما در محیط واقعی کار، به مرور ضعف تجربه‌ی عملی آنان آشکار می‌شود.البته استثنا همیشه وجود دارد و برخی می‌کوشند هر دو مسیر را هم‌زمان پیش ببرند؛ هرچند در عمل یک بُعد پررنگ‌تر از دیگری باقی می‌ماند. از منظر رفتاری نیز تفاوت‌ها قابل توجه است: آکادمیک‌ها معمولا با اعتمادبه‌نفس بیشتری وارد می‌شوند و گاه انتظار دارند زودتر به جایگاه‌های مدیریتی برسند، در حالی که فنی‌ها در سال‌های نخست ناچارند بیش از دیگران برای اثبات خود تلاش کنند.با این حال، شاید یکی از بزرگ‌ترین سوءتفاهم‌ها این باشد که «نخبه» را مساوی بدانیم با کسی که معدل بالا دارد، مقاله منتشر کرده و به دانشگاه‌های خارجی راه یافته است. این نگاه محدودکننده، جمع بزرگی از افرادی را نادیده می‌گیرد که مسیر فنی را برگزیده‌اند و در سکوت، به متخصصانی توانمند تبدیل شده‌اند. اینان سرمایه‌ی واقعی برای آینده‌ی کشورند. شاید به جای نگرانی مداوم برای بازگشت تحصیل‌کردگان خارج، بهتر باشد بر کسانی سرمایه‌گذاری کنیم که اینجا مانده‌اند و در میدان عمل رشد کرده‌اند.بی‌تردید آنانی که مسیر آکادمیک را در دانشگاه‌های معتبر جهانی ادامه می‌دهند نیز ارزشمندند، اما بار اصلی سازندگی و پیشبرد امور فنی بر دوش کسانی است که تجربه‌ی عملی اندوخته‌اند. حتی در بهترین حالت، بازگشتگان آکادمیک بیش از هر چیز می‌توانند در سطح راهبردی و کلی راهنما باشند. حال آن‌که پرداختن به جزئیات و ریزکاری‌های فنی نیازمند سال‌ها تجربه‌ی میدانی است.در این میان، نباید فراموش کنیم که استعداد و توان بالقوه اگرچه اهمیت دارد، اما «زمان و استمرار» وزنی حتی سنگین‌تر دارد. گاهی چنین می‌پنداریم که هرچه بر توانمندی‌های آکادمیک بیفزاییم، همچون زه کمانی که هرچه بیشتر کشیده شود، نیروی پرتاب آغازینمان بیشتر خواهد شد. درست است؛ اما اگر زمان را نادیده بگیریم، نتیجه معکوس خواهد بود.فردی که زودتر وارد مسیر فنی شده، شاید با شتابی کمتر آغاز کند، اما سال‌ها حرکت آرام و پیوسته‌ی او فاصله‌ای می‌سازد که دیگر با پرتابی هرچند تند، پرشدنی نیست. استمرار در یک مسیر، در نهایت ارزشمندتر از استعداد ذاتی و حتی از شتاب اولیه خواهد بود.</description>
                <category>میلاد رئیسی</category>
                <author>میلاد رئیسی</author>
                <pubDate>Fri, 29 Aug 2025 17:53:53 +0330</pubDate>
            </item>
                    <item>
                <title>فارسی، زبان برنامه‌نویسی جدید؟ مفاهیم، سکوی پرتاب برنامه‌نویسان!</title>
                <link>https://virgool.io/@Milad_Reisi/future-of-coding-ai-ugfssnnraztf</link>
                <description>در دی ماه ۱۴۰۱ (ژانویه ۲۰۲۳)، آندری کارپاتی، از چهره‌های برجسته‌ی هوش مصنوعی، با توییتی پربازدید، آینده‌ی برنامه‌نویسی را به چالش کشید: «زبان انگلیسی، زبان برنامه‌نویسی جدید است!». او پیش‌بینی کرد که با پیشرفت مدل‌های زبانی بزرگ (LLM)، زبان طبیعی جایگزین کدنویسی سنتی می‌شود. اما آیا این فقط یک پیش‌بینی بود؟شاید دو سال پیش، این ایده بیشتر شبیه یک رویای دور بود. اما امروز، با ظهور مدل‌هایی مانند Claude Sonnet 3.7 و ابزار تخصصی کدنویسی Claude Code، این رویا به واقعیت تبدیل شده است. مدل‌های زبانی بزرگ (LLMs) دیگر فقط دستیاران کمکی برنامه‌نویسان نیستند؛ آن‌ها به مترجمان قدرتمند زبان تبدیل شده‌اند. تصور کنید، شما به فارسی یا انگلیسی صحبت می‌کنید و نیازی نیست نگران جزئیات کد تولید شده باشید. LLMها، مانند یک کامپایلر یا مفسر (interpreter) حرفه‌ای، آن را مستقیما به کد قابل اجرا تبدیل می‌کنند. این تحول، برنامه‌نویسی را از قید زبان‌های خاص رها می‌کند. دیگر نیازی نیست نگران قواعد زبان (syntax) پایتون یا جاوا اسکریپت باشید. فقط منطق برنامه‌تان را به زبان خودتان، چه فارسی، چه انگلیسی، توضیح دهید. مدل‌های زبانی بزرگ (LLM) آن را به کد تبدیل می‌کنند.اما آیا این یعنی برنامه‌نویسان بیکار می‌شوند؟ قطعا نه! برنامه‌نویسی هنوز یک مهارت ارزشمند است. اما تمرکز از حفظ قواعد زبان (syntax) به درک مفاهیم تغییر می‌کند. برنامه‌نویسان آینده، کسانی هستند که بر مفاهیم بنیادین مانند الگوریتم‌ها و تفکر محاسباتی تسلط دارند و می‌توانند با مدل‌های زبانی بزرگ (LLMs) همکاری کنند.پس، زبان برنامه‌نویسی آینده چیست؟ شاید فارسی، شاید انگلیسی، شاید هر زبان دیگری. مهم نیست! مفاهیم، زبان مشترک برنامه‌نویسان آینده است.</description>
                <category>میلاد رئیسی</category>
                <author>میلاد رئیسی</author>
                <pubDate>Wed, 26 Feb 2025 14:41:17 +0330</pubDate>
            </item>
                    <item>
                <title>Command Line: نمایشی برای حرفه‌ای‌ها یا نیاز واقعی برای کنترل بیشتر؟</title>
                <link>https://virgool.io/@Milad_Reisi/command-line-%D9%86%D9%85%D8%A7%DB%8C%D8%B4%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AD%D8%B1%D9%81%D9%87-%D8%A7%DB%8C-%D9%87%D8%A7-%DB%8C%D8%A7-%D9%86%DB%8C%D8%A7%D8%B2-%D9%88%D8%A7%D9%82%D8%B9%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-t2ba2gosxwyv</link>
                <description>رابط خط فرمان (CLI) در مقابل رابط کاربری گرافیکی (GUI)هر قدر هم که Command Line (یا CLI) توانمند و کارا باشد، نمی‌توان منکر این بود که تا همین اواخر در میان برنامه‌نویس‌ها، یکی از معیارهای رایج حرفه‌ای و ماهر بودن افراد، تسلط بر Command Line بود. (با آن ظاهر گنگ و مبهم و رازآلودش)هر برنامه‌نویس در حضور دیگران با نوشتن سریع و پی‌در‌پی دستورات در تلاش بود تسلط خود در درک و مدیریت این نوشته‌های به ظاهر پیچیده، نامفهموم و درهم و برهم را به نمایش بگذارد و در همین حین، از گوشه‌ی چشم خود نگاه تسخیر شده‌ی ناظران را بپاید و در دل احساس غرور کند.البته، نمی‌توان این واقعیت را انکار کرد که CLI (Command Line Interface) همچنان یک ابزار فوق‌العاده برای حرفه‌ای‌هاست؛ اما در این میان باید به این نکته هم اشاره کرد که صرفا حرفه‌ای به نظر رسیدن، تنها دلیل استفاده از آن نیست. CLI ابزاری است که به دلایل فنی و کاربردی همچنان جایگاه مهمی در دنیای برنامه‌نویسی دارد. بیایید برای روشن‌تر شدن این موضوع مثالی را مرور کنیم. فرض کنید وارد یک فست‌فود شده‌اید. در منوی رستوران چندین غذا با ترکیبات و مواد اولیه از پیش تعیین شده وجود دارد. شما تنها می‌توانید از میان این گزینه‌ها انتخاب کنید و هیچ امکانی برای تغییر دادن ترکیبات یا مقدار مواد اولیه در اختیار ندارید. این شبیه کار با یک سیستم‌عامل گرافیکی مانند ویندوز است؛ شما ابزارهایی از پیش ساخته و بهینه شده دارید و فقط از میان آن‌ها انتخاب می‌کنید.  اما حالا تصور کنید که وارد یک آشپزخانه حرفه‌ای شده‌اید. در این آشپزخانه، به جای انتخاب غذاهای از پیش آماده، می‌توانید دقیقا مواد اولیه و روش پخت را مشخص کنید. حتی می‌توانید نسبت مواد اولیه را هم مطابق با سلیقه خودتان تغییر دهید؛ مثلا مقدار بیشتری پنیر به پیتزای خود اضافه کنید یا نان برگر را بدون سس سفارش دهید. این تجربه دقیقا همان چیزی است که CLI به شما می‌دهد؛ آزادی کامل در کنترل تمامی جزئیات و ترکیب‌ها!متاسفانه و همچنان در محیط‌های گرافیکی، شما محدود به امکاناتی هستید که سازندگان نرم‌افزار برایتان آماده کرده‌اند، اما در CLI این شما هستید که مرزها را تعریف می‌کنید. از نوشتن اسکریپت‌های سفارشی برای انجام خودکار وظایف تکراری تا دسترسی مستقیم به منابع سیستمی، CLI ابزارهای بی‌شماری در اختیارتان قرار می‌دهد که در هیچ محیط گرافیکی به آن دسترسی ندارید.بنابراین، فراتر از ظاهر وهم‌آلود، خفن و حرفه‌ای که CLI به برنامه‌نویس‌ها می‌دهد، همچنان دلیل اصلی محبوبیت این ابزار در میان آن‌ها، توانایی کنترل کامل و انعطاف بی‌نظیر آن در انجام کارهاست. CLI ابزار قدرت است و هر کسی که بتواند از آن به درستی استفاده کند، به راحتی می‌تواند سیستم را به شکلی مدیریت کند که در محیط‌های گرافیکی ممکن نیست.</description>
                <category>میلاد رئیسی</category>
                <author>میلاد رئیسی</author>
                <pubDate>Sat, 21 Sep 2024 13:31:01 +0330</pubDate>
            </item>
            </channel>
</rss>