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

مدل فقط نقطه شروع است

به‌راحتی می‌توان فهمید چرا مبتدیان روی مدل‌ها وسواس دارند. یادداشت‌های انتشار (release notes) وعده استدلال بهتر، پنجره‌های بافت (context windows) بزرگ‌تر و خروجی‌های تمیزتر را می‌دهند. این بهبودها واقعی هستند، اما همگی عمومی (general-purpose) می‌باشند. یک مدل پیشرفته (state-of-the-art) به‌طور خودکار سیاست بازگشت وجه شرکت شما را نخواهد دانست. مگر اینکه به آن بگویید چگونه، وگرنه پاسخ‌ها را برای اپلیکیشن موبایل شما با دقت قالب‌بندی نمی‌کند. نمی‌تواند داده‌های موجودی کالا را از هیچ، به صورت زنده استخراج کند.

من این را از راه سخت یاد گرفتم. اولین نمونه اولیه من از یک مدل توانمند استفاده می‌کرد و پاراگراف‌های زیبا و مطمئنی تولید می‌کرد که گاهی اوقات کاملاً اشتباه بودند. متن حرفه‌ای به نظر می‌رسید چون مدل بر لحن مسلط شده بود، اما به اطلاعات به‌روز دسترسی نداشت. من روزها را صرف مقایسه بنچمارک‌های مدل کرده بودم، در حالی که باید به خط لوله داده‌ها (data pipelines) و تزریق بافت (context injection) فکر می‌کردم. مدل خراب نبود؛ سیستمِ اطراف آن ناقص بود. وقتی از مرحله دمو به سمت نرم‌افزاری می‌روید که مردم واقعاً به آن تکیه می‌کنند، این تمایز همه چیز است.

پرامپت‌ها کد هستند، نه پیشنهاد

پرامپت‌های باکیفیت در قلب هر اپلیکیشن هوش مصنوعی قابل‌اطمینانی قرار دارند. در ابتدا، با پرامپت‌ها مثل پرس‌وجوهای جستجو برخورد می‌کردم؛ کوتاه، غیررسمی و خوش‌بینانه. از مدل می‌خواستم «این را خلاصه کن» یا «مفید باش» و به بهترین نتیجه امیدوار بودم. نتایج به‌شدت بین مفید و بی‌ربط نوسان می‌کرد و من نمی‌دانستم چرا.

حالا با پرامپت‌ها مثل برنامه‌های سبک برخورد می‌کنم. یک پرامپت خوب، نقش را تعریف می‌کند، قالب خروجی را مشخص می‌کند، در صورت نیاز مثال‌هایی می‌آورد و مرزها را تعیین می‌کند. اگر JSON می‌خواهم، درخواست JSON می‌کنم و schema را نشان می‌دهم. اگر به پاسخ کوتاهی نیاز دارم، صراحتاً طول آن را محدود کرده و از آوردن مقدمه‌چینی (preamble) منع می‌کنم. تکرار و اصلاح (iteration) مهم است. من یک گزارش مستمر از پرامپت‌ها و خروجی‌هایشان نگه می‌دارم و در هر بار فقط یک متغیر را تغییر می‌دهم. یک صفت مبهم در یک پرامپت می‌تواند رفتار کل یک گردش کار (workflow) را تغییر دهد. این حساسیت نیازمند دقت و سخت‌گیری است، نه حدس و گمان.

ورودی بی‌کیفیت، خروجی بی‌کیفیت

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

من زمان زیادی را صرف عیب‌یابی یک پایگاه دانش ساده کردم که مدام نتایج بی‌ربط برمی‌گرداند. مدل مشکلی نداشت؛ لایه بازیابی (retrieval layer) در حال شکست خوردن بود. تکه‌های داده (chunks) من خیلی کوچک بودند و بافت (context) خود را از دست داده بودند. embeddings من بدون پاکسازی هدرهای تکراری تولید شده بودند. جستجوی شباهت، متنی را پیدا می‌کرد که از نظر فنی نزدیک بود اما به سوال اشتباهی پاسخ می‌داد. اصلاح آن مستلزم بازنگری در استراتژی تکه‌بندی (chunking)، افزودن فیلترهای metadata و معرفی مرحله بازرتبه‌بندی (re-ranking) بود. به محض اینکه بازیابی پایدار شد، پاسخ‌های مدل بلافاصله بهبود یافت. درس روشن بود: شما نمی‌توانید بازیابی بدِ داده‌ها را با یک مدل بهتر وصله پینه کنید. باید خط لوله را درست بسازید.

چیزی را که اندازه نگیرید، نمی‌توانید بهبود دهید

ارزیابی مداوم، عادتی است که آزمایش‌ها را از محصولات متمایز می‌کند. وقتی شروع کردم، بر اساس «حس و حال» (vibe) ارزیابی می‌کردم. پنج خروجی را می‌خواندم، با تایید سر تکان می‌دادم و می‌گذشتم. این روش تا زمانی جواب می‌دهد که کاربر سوال ششم را بپرسد و با چیزی عجیب روبرو شود.

حالا برای هر ویژگی، مجموعه‌های ارزیابی کوچکی می‌سازم. پرس‌وجوهای واقعی کاربران را جمع‌آوری می‌کنم، رفتار مورد انتظار را برچسب‌گذاری می‌کنم و بررسی‌های خودکار را روی آن‌ها اجرا می‌کنم. من مراقب «انحراف» (drift) هستم: پرامپتی که ماه گذشته خوب کار می‌کرد، ممکن است پس از به‌روزرسانی مدل یا تغییر داده‌های زیربنایی، کیفیت خود را از دست بدهد. من ارزیابی سبک را از دقت واقع‌گرایانه جدا می‌کنم. حرفه‌ای به نظر رسیدن خوب است، اما درست بودن الزامی است. بدون این چرخه، شما بر اساس امید محصول را عرضه می‌کنید، و امید یک استراتژی تست نیست.

محدودیت‌های ماشین را بشناسید

Understanding model limits has saved me from overpromising and underdelivering. These systems have genuine constraints. Context windows are larger than they used to be, but they still have ceilings, and stuffing them full degrades performance at the edges. Models hallucinate, especially on niche topics where training data is thin. They struggle with precise arithmetic and certain types of multi-step logic. They are sensitive to phrasing.

Cost and speed are limits too. A model that generates perfect prose in ten seconds might be unusable in a real-time chat interface. I now map features to latency budgets early. If a task needs sub-second response, I may precompute answers, cache aggressively, or use a smaller model for the first draft and a larger one only for refinement. Working within constraints is standard engineering. AI is no different.

Building for Real People

I am currently studying LLM applications and software engineering with a simple goal: build tools people use every day. That sounds obvious, but the gap between a cool prototype and a daily-use tool is massive. A demo can tolerate a forty-second pause and a verbose answer. A person trying to finish a task before a meeting cannot.

Daily-use tools need error handling, fallbacks, and clear UI when the model is uncertain. They need to integrate with existing workflows rather than forcing new ones. I think about edge cases now: what happens when the model refuses to answer, when the context overflows, or when the API times out? Shipping AI software means answering those questions with code, not just optimism.

Let's Share What We Learn

I want to connect with other developers who are navigating the same path. The field moves quickly, and the best practices are still being written. No one has all the answers. Whether you are wrestling with prompt design, fighting retrieval pipelines, or figuring out how to evaluate outputs at scale, the problems are better solved together.

Let us share what we learn. Not polished conference talks, but the messy middle. The broken pipelines, the prompt tweaks that finally worked, the evaluation tests that caught a bug before launch. That granular, honest exchange is what turns individual experiments into a shared body of knowledge.

The Real Takeaway

If you are starting out with AI development, spend less time searching for the