تبدیل داده خام به ورودی مدل؛ مسیر مستقیم Feedforward Pass چطور کار می‌کند؟

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

چهار بعد پیچیدگی در دنیای کاربر:

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

سطح انتزاع (Abstraction): از یک غلط‌گیری املایی سرراست تا برنامه‌ریزی چندمرحله‌ای یک سفر با در نظر گرفتن سلیقه شخصی.

کانتکست مورد نیاز (Context): آیا متن کاربر کافی است، یا باید اسناد فنی، لاگ‌های سیستمی و API تقویم و بلیت هواپیما خوانده شود؟

حفظ وضعیت (Statefulness): آیا هر درخواست مستقل است، یا اپلیکیشن باید تاریخچه تعاملات، روش‌های شکست‌خورده قبلی و وضعیت برنامه را ذخیره و مدیریت کند؟

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

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

فصل چهارم، بخش دوم

کتاب Prompt Engineering for LLMs

بیش از ۶۰۰+ پرامپت برای طراحی وب‌سایت‌های شگفت‌انگیز

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

https://motionsites.ai/?prompt=vintage-care

تبدیل متن به اقدام واقعی؛ ابزارها و چرخه تصمیم‌گیری

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

- فرمت فراخوانی تابع (Tool/Function Calling):
مدل در قالب یک گرامر ساختاریافته مثل JSON یا تگ‌های اختصاصی درخواست اجرای یک ابزار مشخص همراه با ورودی‌های دقیق آن را در متن خود می‌نویسد.

- رهگیری توسط لایه اپلیکیشن: برنامه شما جلوی ارسال مستقیم متن به کاربر را می‌گیرد، سینتکس دستور را استخراج کرده و تابع مورد نظر (مثلاً کوئری دیتابیس یا اجرای کد پایتون) را در بک‌اند اجرا می‌کند.

- بستن حلقه فیدبک (Feedback Loop): خروجی اجرای ابزار مجدداً به عنوان یک پیام جدید به ساختار پرامپت چسبانده می‌شود تا مدل با اتکا به دیتای تازه، پاسخ نهایی یا تصمیم بعدی را بسازد.

- اهمیت الگوی استدلال و اقدام: در مسائل پیچیده، مدل ابتدا فرآیند تفکر و بررسی را به زبان می‌آورد، ابزار مناسب را فرامی‌خواند و نتیجه را می‌سنجد. با این چرخه، مدل از یک نویسنده منفعل متن به یک عامل فعال برای حل مسئله ارتقا می‌یابد.

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

فصل چهارم، بخش سوم

کتاب Prompt Engineering for LLMs

سایت TrustMRR در اصل یه مارکت‌پلیس خرید و فروش استارتاپ‌های نرم‌افزاریه. در واقع SaaS، اپلیکیشن، AI و محصولات دیجیتال رو لیست می‌کنه، درآمد و MRR رو از دیتای واقعی مثل Stripe و RevenueCat شناسایی می‌کنه و خریدار می‌تونه مستقیم با Founder مذاکره و معامله رو تا قرارداد و Escrow جلو ببره. یعنی چیزی شبیه بورس خرید و فروش استارتاپ، با درآمد قابل‌راستی‌آزمایی.
این سایت http://trustmrr.com توسط marclou درست شده، الانم به درآمد ۴۴ هزار دلار در ماه رسیده.

Saman Faegh

Made with claude opus 5.5

چگونه بفهمیم اپلیکیشن ما واقعاً کار می‌کند؟ ارزیابی آفلاین در برابر تله‌های آنلاین!

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

- ارزیابی آفلاین Offline Evaluation: قبل از اینکه کد را به پروداکشن بفرستید، پرامپت و پایپ‌لاین خود را روی یک مجموعه داده معیار Benchmark اجرا کنید. در این مرحله می‌توانید از سنجه‌های تطبیق قطعی، کدهای اعتبارسنجی ساختار مانند ولیدیت کردن JSON، یا روش LLM-as-a-Judge استفاده از یک مدل قوی‌تر برای نمره‌دهی به پاسخ‌ها استفاده کنید.

- ارزیابی آنلاین و تله‌متری Online Telemetry: وقتی محصول به دست کاربر رسید، باید رفتار واقعی را زیر نظر گرفت. اما سنجه‌های سطحی می‌توانند گمراه‌کننده باشند؛ مثلاً نرخ پذیرش پیشنهاد همیشه به معنای بی‌نقص بودن نیست و ممکن است کاربر صرفاً برای بازنویسی، متن را قبول کرده باشد. ثبت دقیق فیدبک‌های صریح Like/Dislike و میزان ویرایش کاربر روی خروجی مدل، تصویر واقعی‌تری به شما می‌دهد.

- سرمشق طلایی مهندسی نرم‌افزار: سیستم ارزیابی خود را پیش از پیچیده‌تر کردن پرامپت‌ها بنا کنید. هر تغییری در تزریق زمینه Context باید در بنچمارک آفلاین سنجیده شود تا مطمئن شوید برنامه گامی به جلو برداشته، نه به عقب.

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

فصل چهارم، بخش چهارم

کتاب Prompt Engineering for LLMs

.
دلیل گران بودن رم 🫪

ایلان ماسک به جوان‌های ۲۰ ساله:

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

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

۵ میلیون توکن رایگان بدون نیاز به کردیت کارت!

این سایت بدون هیچ دردسری ۵ میلیون توکن رایگان میده برای استفاده از مدل‌هایی مثل Claude، Qwen و GLM. نه نیازی به کارت اعتباری داره و نه پیچیدگی خاصی.

https://cleanapis.com/?ref=CCNKY978

پرامپت ایستا در برابر پویا و ۳ قانون طلایی دستورنویسی پرامپت مهندسی‌شده دقیقاً از چه بخش‌هایی تشکیل شده است؟

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

- محتوای ایستا Static Content: کدهای ثابت متنی، شفاف‌سازی مسئله، قوانین سیستم و نمونه‌ها. این بخش برای تمام کاربران یکسان است و تغییر نمی‌کند.

- محتوای پویا Dynamic Content: اطلاعات متغیر هر کاربر؛ مثل تاریخچه چت، خریدهای قبلی، لوکیشن فعلی یا متن خطای ارسالی.

چرا شفاف‌سازی دقیق Clarification حیاتی است؟ در گفتگوی انسان‌ها، ابهامات خیلی زود با یک سوال متقابل حل می‌شوند. اما در ارتباط نرم‌افزار با LLM، ابهام یعنی شکست کامل فرایند. شفاف‌سازی، ثبات و یکدستی Consistency ایجاد می‌کند.
۳ قانون تجربی در نوشتن دستورات صریح Rules of Thumb:

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

در قسمت بعدی سراغ Few-Shot Prompting می‌رویم و می‌بینیم که چرا مثال زدن گاهی می‌تواند کل مدل را به بیراهه ببرد!

فصل پنجم، بخش اول

کتاب Prompt Engineering for LLMs

دسترسی رایگان به جدیدترین مدل‌های هوش مصنوعی!

بدون نیاز به کردیت‌کارت و پرداخت ارزی، می‌تونی به مدل‌هایی مثل Claude Opus 5، Claude Sonnet 5، ChatGPT Astra، ChatGPT 5.6 Sol، Kimi K3، GLM 5.3، Gemini 2.5 Pro و Grok 4.3 رایگان دسترسی داشته باشی.

https://app.ashna.ai/signup?referral_code=RL32RI

​ اشتراک ماهانه جمنای پرو فمیلی

​▪️ دسترسی کامل به ابزارهای هوش مصنوعی گوگل
▪️ پشتیبانی و ضمانت تا روز آخر
▪️ ظرفیت باقی‌مانده: ۴ نفر
​💵 فقط ۱۵۰ هزار تومان
​📩 ثبت سفارش: @HamedHeydarian

ترب MCP هم آماده شد
این دفعه اوپن سورس با لایسنس MIT

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

https://github.com/mmdju/torob-mcp

Mmdj

قدرت مثال‌ها و ۳ تله خطرناک در Few-Shot Prompting

مدل‌های زبانی در کشف الگوها استادند؛ به همین دلیل، آوردن چند مثال از ورودی و خروجی مدنظرتان Few-Shot، اغلب بسیار موثرتر از نوشتن ده‌ها خط دستورالعمل خشک و صریح است. مثال‌ها به مدل یاد می‌دهند لحن، قالب و ساختار خروجی دقیقاً چه شکلی باشد.
اما چندشات‌نویسی همیشه بی‌خطر نیست و اگر حواستان نباشد، می‌تواند خروجی سیستم را کاملاً خراب کند:

۱. افت شدید مقیاس‌پذیری در کانتکست‌های بزرگ Scaling Poorly:
اگر هر نمونه چندشات دارای جزئیات طولانی از کاربر باشد، تکرار چندباره آن بخش زیادی از پنجره توکن را می‌سوزاند. بدتر از آن، واحدهای پردازشی مدل در مکانیزم توجه Attention میان داده‌های متناقض افراد مختلف سردرگم می‌شوند.

۲. سوگیری و اثر لنگر انداختن Anchoring Bias:
مدل‌ها از توزیع داده‌های مثال‌ها الگوبرداری می‌کنند. اگر برای نمره‌دهی به نظرات کاربران، از هر نمره ۱ تا ۵ فقط یک نمونه بیاورید، مدل تصور می‌کند احتمال دریافت نمره ۱ دقیقاً با نمره ۵ برابر است؛ در حالی که در دنیای واقعی اکثر نظرات مثبت هستند. مدل بر اساس مثال‌های محدود شما دچار قضاوت زودهنگام و سوگیرانه می‌شود.

۳. استخراج الگوهای کاذب و ناخواسته Spurious Patterns:
مدل ممکن است به ترتیبی که مثال‌ها را چیده‌اید حساس شود. اگر عادت داشته باشید ابتدا نمونه‌های موفق Happy Path و سپس موارد خطا Edge Cases را بنویسید، مدل الگوی خطاها همیشه آخر می‌آیند را یاد می‌گیرد و روی درخواست اصلی کاربر به اشتباه اعلام شکست یا خطا می‌کند!

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

در قسمت بعدی بررسی می‌کنیم که چگونه داده‌های متغیر کاربر را بدون افتادن در تله تفنگ چخوف جمع‌آوری و فیلتر کنیم!

فصل پنجم، بخش دوم

کتاب Prompt Engineering for LLMs