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

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

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

چرا برنامه‌ی هوش مصنوعی چرخه‌ی عمر می‌خواهد؟

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

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

از MLOps به LLMOps

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

تفاوت در عمل

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

به همین دلیل کار اصلی در LLMOps یکپارچه‌سازی است؛ یعنی وصل‌کردن مدل به داده، ابزار و رابط کاربری. مهارت‌های تازه‌ای هم لازم شده است: طراحی پرامپت، RAG، ارزیابی پاسخ و هوش مصنوعی مسئولانه. جدول زیر تفاوت‌ها را کنار هم می‌گذارد.

پنج معیار LLMOps

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

• کیفیت: پاسخ چقدر خوب و مفید است؟
• آسیب: آیا پاسخ اصول هوش مصنوعی مسئولانه را رعایت می‌کند؟
• صداقت: آیا پاسخ منطقی و درست است و به منبع متکی است؟
• هزینه: آیا راه‌حل در بودجه‌ی تعیین‌شده می‌ماند؟
• تأخیر: میانگین زمان تولید پاسخ چقدر است؟

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

سه مرحله‌ی چرخه‌ی عمر

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

ایده‌پردازی و کاوش

در این مرحله بر اساس نیاز کسب‌وکار کاوش می‌کنید. با مهندسی پرامپت، چند مدل را آزمایش می‌کنید تا ببینید فرضیه‌تان درست است یا نه. ابزارهایی مثل PromptFlow کمک می‌کنند یک نمونه‌ی اولیه‌ی سریع بسازید و آزمایشش کنید.

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

ساخت و تقویت

وقتی فرضیه تأیید شد، ارزیابی را روی داده‌ی بیشتری انجام می‌دهید. در این مرحله تکنیک‌هایی مثل RAG و فاین‌تیون را امتحان می‌کنید تا ببینید راه‌حل چقدر مقاوم است. اگر نتیجه کافی نبود، جریان را بازطراحی می‌کنید، مرحله‌های تازه اضافه می‌کنید یا داده‌ها را بازسازی می‌کنید.

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

عملیاتی‌سازی

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

برای نمونه‌ی عملی یک برنامه‌ی کامل، مخزن Contoso Chat مایکروسافت یک چت‌بات فروشگاهی را با همین چرخه نشان می‌دهد؛ از ایده تا استقرار.

ابزارهای چرخه‌ی عمر

مایکروسافت برای این چرخه دو ابزار اصلی پیشنهاد می‌کند. Microsoft Foundry، که پیش‌تر Azure AI Studio بود، پورتالی وب برای کاوش مدل‌ها، آزمایش نمونه‌ها، ارزیابی و استقرار است. منابعی مثل جستجوی برداری و پایگاه داده را هم در یک‌جا مدیریت می‌کند.

PromptFlow ابزار ساخت جریان‌های مبتنی بر مدل زبانی است؛ از اثبات مفهوم تا برنامه‌ی مقیاس بزرگ. می‌توانید در VS Code جریان را با ابزارهای تصویری طراحی کنید، آن را آزمایش و تنظیم کنید و در فضای ابری منتشرش کنید. ابزارهای مشابه از ارائه‌دهندگان دیگر هم وجود دارد؛ مهم این است که چرخه را با ابزاری مدیریت کنید، نه با حافظه‌ی تیم.

بهداشت فنی در هر نسخه

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

رازها بیرون از کد

کلید API هرگز نباید داخل کد باشد. آن را در متغیر محیطی یا فایل .env نگه دارید و این فایل را به .gitignore اضافه کنید. در کد هم با کتابخانه‌ای مثل python-dotenv آن را بخوانید:

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

در محیط‌های ابری از مدیر رازها استفاده کنید؛ مثل Secrets در GitHub Codespaces یا Key Vault در Azure. این کار هم امنیت را بالا می‌برد و هم تعویض کلید را بدون تغییر کد ممکن می‌کند.

توکن، تنظیمات و مدل‌های استدلالی

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

یک تغییر مهم را هم در نظر داشته باشید. مدل‌های استدلالی جدید مثل خانواده‌ی GPT-5 پارامترهای temperature و top_p را پشتیبانی نمی‌کنند. اگر مدل را به چنین نسخه‌ای ارتقا دهید و کدتان این پارامتر را بفرستد، خطا می‌گیرید. این دقیقاً از همان تغییرهایی است که بدون آزمون پیش از انتشار، به کاربر می‌رسد.

نسخه‌ی قابل بازگشت؛ سناریوی به‌روزرسانی سرفصل

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

ورودی و اقدام

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

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

برگه‌ی انتشار

هر نسخه باید یک برگه‌ی انتشار داشته باشد که دقیقاً بگوید چه چیزی عوض شده است. جدول زیر یک قالب ساده است.

نمونه‌ی شکست؛ چند تغییر همزمان

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

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

تمرین عملی؛ برگه‌ی انتشار دستیار

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

1. همه‌ی چیزهایی را که رفتار دستیار را تغییر می‌دهند فهرست کنید: مدل، پرامپت، اسناد و تنظیمات.
2. برای هر کدام یک شماره‌ی نسخه تعیین و در گیت ثبت کنید.
3. یک مجموعه‌ی آزمون ده‌پرسشی بسازید و قبل از هر انتشار اجرایش کنید.

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

سخن پایانی

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

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

این آموزش بر پایه‌ی درس The Generative AI Application Lifecycle از مجموعه‌ی آزاد Generative AI for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.