مهندسیِ «هارنس»: مسیر تبدیل توسعه‌دهندگان نرم‌افزار به مهندس هوش مصنوعی

تصور کنید یک معمار نرم‌افزار است که باید سیستمی طراحی کند که قطعاتش هر بار پاسخی متفاوت می‌دهند؛ این دقیقاً همان نقطه‌ای است که نقش «مهندس هوش مصنوعی» تعریف می‌شود. یک مهندس ارشد در یک شرکت پرداخت‌های الکترونیکی استدلال می‌کند که برای مدیریت این پیش‌بینی‌ناپذیری، باید از نگاه دانشمندان داده فاصله گرفت و به سراغ ساخت چارچوب‌های کنترلی یا همان «هارنس» (Harness) رفت. او معتقد است تمرکز باید از علم داده سنتی به سمت مهندسی سیستم‌های پیرامونی تغییر کند.

به نقل از این راهنمای جامع، در توسعه ابزاری به نام PayIQ — دستیاری برای پذیرندگان فروشگاهی جهت مدیریت عملیات پیچیده مالی مانند محاسبه بازپرداخت‌ها و دفاع در برابر شارژبک‌ها — نقش مدل زبانی تنها تامین هوشمندی است، اما این مهندس است که «هارنس» یا همان برنامه را می‌سازد تا قابلیت اطمینان سیستم تضمین شود. فرض اصلی این است که مدل هوش می‌دهد، اما مهندس «قالب» یا اپلیکیشنی را می‌سازد که این هوش را به نتیجه‌ای قابل پیش‌بینی تبدیل کند.

این تحول در زمانی رخ می‌دهد که موجی از توسعه‌دهندگان نرم‌افزار می‌بینند همکارانشان یک‌شبه عناوین شغلی خود را در لینکدین به «مهندس هوش مصنوعی» تغییر می‌دهند و برخی حتی ادعای «مهندس ارشد هوش مصنوعی» را دارند. صنعت اکنون از پرامپت‌نویسی ساده به سمت ارکستراسیون (Orchestration) پیچیده حرکت می‌کند. این گذار از مهارت‌های پایه به تخصص‌های مهندسی، یادآور مسیر تبدیل کاربر به متخصص هوش مصنوعی با متد Claude 101 است که بر توسعه تدریجی تسلط بر این ابزارها تاکید دارد. برای یک کدنویس سنتی، این تغییر به معنای آن است که با یک مدل زبانی بزرگ (LLM) نه به عنوان یک تابع استاندارد، بلکه مانند یک API عجیب و پیش‌بینی‌ناپذیر برخورد کند. این تغییر، نیازمند مدل ذهنی جدیدی از هزینه‌های عملیاتی و حالت‌های شکست است. هدف نهایی این است که بفهمیم توسعه اپلیکیشن‌های هوش مصنوعی، در واقع همان مهندسی نرم‌افزار است که روی یک مؤلفه تک و واقعاً عجیب و غیرقطعی (یعنی LLM) اعمال شده است.

مدل ذهنی عملیاتی

طبق مستندات این راهنما، یک مهندس هوش مصنوعی نیازی به درک عمیق شبکه‌های عصبی یا جزئیات داخلی ترنسفورمرها ندارد؛ این موارد مربوط به دانشمندان داده است. در عوض، او باید بر یک مدل ذهنی عملیاتی متمرکز شود که بر اساس یک رابط ساده تعریف شده است:
f(list of input messages) -> output message

نکته حیاتی این است که مدل یک پرامپت واحد را نمی‌بیند؛ بلکه توالی پیاماتی را پردازش می‌کند که شامل موارد زیر است:

• یک پیام سیستمی (System Message) که برای «پیکربندی برنامه» استفاده می‌شود.
• کل تاریخچه گفتگو که در واقع نماینده «وضعایت فعلی» (Current State) است.
• آخرین پرامپت ارسالی توسط کاربر.

با توجه به این پیام‌های پیشین، مدل پیام بعدی در گفتگو را تولید می‌کند. اگر از ابزارهایی مثل Codex یا Claude Code استفاده کرده‌اید، می‌بینید که آن‌ها در وب جستجو می‌کنند، اسناد را می‌خوانند یا کدها را ویرایش می‌کنند. تمام این «جادو»، در واقع همان منطق برنامه‌ای است که دور مدل ساخته شده است. این رویکرد دقیقاً با این دیدگاه همسو است که در لایه‌ی عملیاتی هوش مصنوعی، منطق و طراحی سیستم باید بر کدنویسی صرف اولویت داشته باشد تا خروجی‌های قابل اتکا حاصل شود. مدل در ذات خود بدون وضعیت (Stateless) است؛ این مهندس هوش مصنوعی است که از طریق هارنس، توهم حافظه و قابلیت را ایجاد می‌کند.

توکن‌ها و ریسک «تخلیه کیف پول»

محاسبات در هوش مصنوعی بر اساس توکن (Token) اندازه‌گیری می‌شود، نه کاراکتر یا کلمه. مؤلفه‌ای به نام توکن‌ساز (Tokenizer) ابتدا متن را به توکن‌ها تقسیم کرده و به هر کدام یک شناسه عددی (Token ID) اختصاص می‌دهد. کلمات رایج اغلب یک توکن هستند، اما کلمات uncommon ممکن است به چندین توکن تقسیم شوند. مدل هرگز متن اصلی را نمی‌بیند و فقط این شناسه‌های عددی را پردازش می‌کند.

از آنجا که توکن‌ها واحد صورت‌حساب هستند، پیوندی مستقیم بین کارایی کد و هزینه مالی ایجاد می‌شود. شما به ازای هر توکن ورودی و خروجی هزینه می‌پردازید، درست مانند نحوه محاسبه ثانیه‌های پردازشی در صورت‌حساب‌های ابری. این موضوع باعث می‌شود ویژگی‌های هوش مصنوعی اولین نوع Endpoint در بک‌اند باشند که هزینه یک درخواست واحد در آن‌ها به قدری زیاد است که تبدیل به یک دغدغه اصلی می‌شود. برای مثال، عاملی (Agent) که به ازای هر درخواست کاربر، پنج بار مدل را فراخوانی کند، در حجم ترافیک تولیدی، هزینه‌های واقعی و سنگینی دارد.

این وضعیت یک ریسک امنیتی خاص به نام «حمله تخلیه کیف پول» (Denial of Wallet) ایجاد می‌کند. برخلاف حملات DDoS سنتی که منابع زیرساختی مانند CPU، حافظه و پهنای باند یا نمونه‌های مقیاس‌پذیر (Autoscaled) را هدف قرار می‌دهند، این حملات بودجه API شرکت را با اجبار مدل به مصرف توکن‌های گران‌قیمت در مقیاس بالا، تخلیه می‌کنند.

مدیریت پنجره زمینه

هر مدل یک پنجره زمینه (Context Window) ثابت دارد که مانند حافظه فعال مدل عمل می‌کند. این حداکثر تعداد توکن‌های ورودی اغلب می‌تواند صدها هزار توکن را در خود جای دهد. هر چیزی که مدل برای پاسخ به درخواست نیاز دارد باید در این پنجره جای بگیرد، از جمله:

• پرامپت سیستمی
• تاریخچه گفتگو
• اسناد بازیابی شده
• نتایج ابزارها (Tool results)
• هرگونه زمینه (Context) ارائه شده دیگر.

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

• پوسیدگی زمینه (Context Rot): با انباشت اطلاعات نامرتبط، مدل با حواس‌پرتی‌های بیشتری روبرو می‌شود و جزئیات مهم راحت‌تر گم می‌شوند.
• مقیاس هزینه: افزایش توکن‌های ورودی منجر به افزایش خطی در صورت‌حساب مالی می‌شود.

بنابراین، مهندسی هوش مصنوعی مؤثر بر «مهندسی زمینه» (Context Engineering) متمرکز است تا کیفیت را بر کمیت ترجیح دهد؛ زیرا استراتژی «چسباندن همه چیز به پرامپت» در مقیاس صنعتی پاسخ نمی‌دهد.

پیاده‌سازی PayIQ

برای نمایش این مفاهیم، ابزار PayIQ به عنوان یک ابزار تخصصی برای عملیات پرداخت ساخته شد. PayIQ برای مدیریت نیازهای خاص پذیرندگان طراحی شده است:

• عملیات بازپرداخت: این ابزار می‌تواند بازپرداخت‌ها را صادر و هزینه‌های پردازش را محاسبه کند. PayIQ محاسبه می‌کند که یک بازپرداخت در واقع چقدر هزینه دارد و به این نکته مالی حیاتی اشاره می‌کند که هزینه واقعی یک بازپرداخت، بیشتر از خود مبلغ بازگشتی است.
• دفاع در برابر شارژبک: با استفاده از ریاضیات «ارزش مورد انتظار» (Expected-value math) و یک پایگاه دانش، تعیین می‌کند که آیا جنگیدن برای بازپس‌گیری یک تراکنش از نظر زمانی و مالی به‌صرفه است یا خیر.
• مدیریت خطا: این سیستم به‌گونه‌ای طراحی شده است که وقتی نمی‌تواند پاسخی مسئولانه بدهد، به‌جای حدس زدن یا دچار توهم (Hallucination) شدن، از کاربر درخواست اطلاعات تکمیلی کند.

ابزارها و زیرساخت فنی

این پیاده‌سازی از Python 3.11+، LangChain و مدل Claude-Sonnet-5 شرکت Anthropic استفاده می‌کند. با استفاده از سازنده‌های مستقل از تامین‌کننده (Provider-agnostic) مانند init_chat_model- مهندسان می‌توانند مدل‌ها را (مثلاً از کلود به GPT-5.5، Llama 3.3 یا مدل‌های محلی از طریق Ollama) بدون بازطراحی کل سیستم تعویض کنند. این رویکرد از اصل مهندسی نرم‌افزار مبنی بر «برنامه‌نویسی بر اساس انتزاع‌ها (Abstractions) به جای پیاده‌سازی‌های concrete» پیروی می‌کند تا انعطاف‌پذیری در هزینه، قابلیت یا انطباق (Compliance) حفظ شود.

راه‌اندازی محیط توسعه نیازمند یک محیط مجازی (Virtual Environment) و مجموعه‌ای از وابستگی‌های خاص است. برای کسانی که می‌خواهند این مسیر را دنبال کنند، مخزن کد در https://github.com/BjornvdLaan/ai-engineering-articles-code-samples در دسترس است. فرآیند نصب شامل ایجاد یک فایل .env برای ذخیره ANTHROPIC_API_KEY (که از platform.claude.com گرفته می‌شود) است، به طوری که هزینه اعتباری برای کل این مجموعه کمتر از پنج یورو باقی بماند.

جزئیات: نیازمندی‌های وابستگی (Dependencies)

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

• چارچوب‌های اصلی: langchain>=1.3,<2.0 ، langchain-core>=1.4,<2.0 ، langgraph>=1.2,<2.0 و langgraph-swarm>=0.1.
• متن و Embeddings: langchain-text-splitters>=1.1,<2.0 و sentence-transformers>=3.0.
• تامین‌کنندگان و پروتکل‌ها: langchain-anthropic>=0.4 ، langchain-huggingface>=0.2 ، langchain-mcp-adapters>=0.1 و mcp>=1.9.
• API و اعتبارسنجی: fastapi>=0.115 ، uvicorn>=0.32 ، pydantic>=2.9 و python-dotenv>=1.0.

نظارت بر مصرف منابع

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

به عنوان مثال، اجرای اسکریپت 01_first_call.py برای مدیریت یک اختلاف کارت ۴۸۰ یورویی، نوسان مصرف توکن را نشان می‌دهد. اولین فراخوانی ممکن است منجر به نتایج زیر شود:

• توکن ورودی: ۴۵
• توکن خروجی: ۱۱۹
• مجموع توکن‌ها: ۱۶۴

اما فراخوانی دوم برای دقیقاً همان درخواست ممکن است پاسخی مفصل‌تر تولید کند و معیارها را به این شکل تغییر دهد:

• توکن ورودی: ۵۷
• توکن خروجی: ۲۰۹
• مجموع توکن‌ها: ۲۶۶

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

واقعیت غیرقطعی بودن و توهمات

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

۱. غیرقطعی بودن (Non-determinism): مدل صرفاً محتمل‌ترین توکن را انتخاب نمی‌کند، بلکه از یک توزیع احتمال نمونه‌برداری می‌کند. مهندسان می‌توانند از طریق تنظیم «دما» (Temperature) بر این رفتار تاثیر بگذارند. این یک تفاوت کلیدی با مهندسی نرم‌افزار سنتی و قطعی است.
۲. توهمات (Hallucinations): چون مدل برای پیش‌بینی «محتمل‌ترین توکن بعدی» طراحی شده است و نه برای «تمایز بین حقیقت و خطا»، می‌تواند پاسخ‌هایی متقاعدکننده اما کاملاً اشتباه تولید کند. مدل در حال تولید متن محتمل است، نه بازیابی حقایق. اگرچه «پس‌آموزش» (Post-training) به مدل‌ها یاد می‌دهد که دستورات را دنبال کنند، فرمت‌های خاص را رعایت کنند و عدم قطعیت را بپذیرند، اما یک بررسی‌کننده حقیقت داخلی (Internal Fact-checker) در اختیار آن‌ها قرار نمی‌دهد.

از پرامپت‌نویسی به مهندسی

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

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

جزئیات: لایه‌های پیشرفته اپلیکیشن

• خروجی‌های ساختاریافته (Structured Outputs): تضمین اینکه پاسخ‌ها از ساختاری پیروی می‌کنند که قابل تجزیه (Parse) به اشیاء (مانند JSON) باشد تا کدهای بعدی بتوانند واقعاً به آن داده‌ها تکیه کنند.
• کمربند ابزار (Tool Belts): ادغام ماشین‌حساب‌های مالی که مدل می‌تواند برای عملیات دقیق فراخوانی کند.
• سیستم‌های بازیابی (Retrieval Systems): پیاده‌سازی بازیابی از روی یک پایگاه دانش برای اطمینان از اینکه مدل در زمان‌های حساس، اطلاعات درست را در اختیار دارد.
• حلقه‌های عامل (Agent Loops): ایجاد یک حلقه عامل با حافظه پایدار برای حفظ وضعیت (State).
• گراف‌های ارکستراسیون (Orchestration Graphs): ساخت گرافی با گام‌های تعریف شده که مدل نمی‌تواند از آن‌ها بگذرد و بدین ترتیب قابلیت اطمینان تضمین می‌شود.
• لایه وب: پیاده‌سازی استریم توکن‌ها (Token Streaming) در پشت یک سرویس FastAPI برای تعامل بلادرنگ با کاربر.
• تضمین کیفیت (QA): توسعه یک مجموعه ارزیابی رگرسیونی (Regression Eval Suite) و دفاع لایه‌ای در برابر تزریق (Injection Defense) برای ایمن کردن هارنس.

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

گام بعدی شما

• بررسی مفهوم خروجی‌های ساختاریافته (Structured Outputs) برای حذف خطاهای پارسینگ در بک‌اند.
• مطالعه نحوه پیاده‌سازی تولید بازیابی‌افزا (RAG) برای کاهش نرخ توهمات در داده‌های تخصصی.
• آزمایش مدل‌های مختلف در یک ساختار مستقل (Agnostic) برای بهینه‌سازی هزینه استنتاج.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.