AI-Native چیست؟ راهنمای ساخت محصول هوش مصنوعی‌محور

AI-Native یا «هوش مصنوعی‌محور» به محصول، نرم‌افزار یا کسب‌وکاری گفته می‌شود که هوش مصنوعی از ابتدا در هسته تجربه کاربر، معماری فنی و مدل ارائه ارزش آن قرار گرفته است.

در یک محصول AI-Native، هوش مصنوعی صرفاً یک چت‌بات اضافه‌شده به گوشه نرم‌افزار نیست. محصول بدون مدل هوش مصنوعی یا قابل‌استفاده نیست یا بخش مهمی از ارزش خود را از دست می‌دهد.

برای مثال، اضافه‌کردن یک دکمه «بازنویسی با هوش مصنوعی» به نرم‌افزار مدیریت پروژه، آن را الزاماً AI-Native نمی‌کند. اما محصولی که هدف کاربر را دریافت می‌کند، پروژه را به وظایف قابل‌اجرا تقسیم می‌کند، اطلاعات لازم را می‌خواهد، پیشرفت را تحلیل می‌کند و اقدام بعدی را پیشنهاد می‌دهد، می‌تواند هوش مصنوعی‌محور محسوب شود.

در این مقاله بررسی می‌کنیم:

• AI-Native دقیقاً چیست؟
• چه تفاوتی با AI-Enabled و AI-First دارد؟
• یک محصول هوش مصنوعی‌محور چه اجزایی دارد؟
• چگونه یک نرم‌افزار معمولی را به محصول AI-Native تبدیل کنیم؟
• API درواره در این معماری چه نقشی دارد؟
• چگونه نسخه اولیه یک محصول AI-Native را بسازیم؟

AI-Native به زبان ساده چیست؟

در نرم‌افزارهای سنتی، توسعه‌دهنده تمام مسیرها را از قبل تعریف می‌کند:

اگر کاربر گزینه A را انتخاب کرد، عملیات B را اجرا کن.

اما در یک محصول هوش مصنوعی‌محور، کاربر می‌تواند هدف خود را با زبان طبیعی بیان کند:

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

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

بنابراین، یک محصول AI-Native معمولاً حول این چرخه شکل می‌گیرد:

1. دریافت هدف کاربر
2. درک زمینه و وضعیت
3. انتخاب روش انجام کار
4. استفاده از مدل یا ابزار مناسب
5. تولید یا اجرای نتیجه
6. دریافت بازخورد
7. اصلاح خروجی یا ادامه فرایند

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

آیا AI-Native تعریف رسمی و ثابتی دارد؟

خیر. AI-Native هنوز یک اصطلاح کاملاً استاندارد با تعریف واحد نیست و شرکت‌ها ممکن است آن را با معانی متفاوت به کار ببرند.

برخی آن را برای زیرساخت‌های طراحی‌شده جهت اجرای مدل‌های هوش مصنوعی استفاده می‌کنند. برخی دیگر، محصولاتی را AI-Native می‌دانند که هوش مصنوعی در هسته تجربه کاربر آن‌ها قرار دارد.

در این مقاله، منظور از AI-Native محصولی است که:

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

این مفهوم با Cloud Native AI متفاوت است. CNCF در مقاله Cloud Native AI بیشتر بر زیرساخت لازم برای توسعه، استقرار، اجرا، مقیاس‌پذیری و پایش بارهای کاری هوش مصنوعی در محیط ابری تمرکز دارد.

تفاوت AI-Native، AI-Enabled و AI-First

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

یک قابلیت AI-Enabled می‌تواند ارزشمند باشد و لازم نیست هر محصولی حتماً AI-Native شود.

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

تفاوت محصول AI-Native با چت‌بات چیست؟

وجود صفحه چت به‌تنهایی نشانه AI-Native بودن نیست.

یک چت‌بات ساده معمولاً این مسیر را دارد:

پیام کاربر
↓
مدل زبانی
↓
پاسخ متنی

اما محصول AI-Native می‌تواند از معماری کامل‌تری استفاده کند:

هدف کاربر
↓
تشخیص نوع درخواست
↓
جمع‌آوری زمینه مرتبط
↓
انتخاب مدل یا Workflow
↓
فراخوانی ابزارهای لازم
↓
اعتبارسنجی نتیجه
↓
نمایش خروجی در رابط مناسب
↓
دریافت بازخورد

همچنین رابط یک محصول هوش مصنوعی‌محور الزاماً چت نیست. خروجی ممکن است در قالب‌های زیر نمایش داده شود:

• جدول
• فرم تکمیل‌شده
• گزارش
• فهرست وظایف
• نمودار
• پیشنهاد قابل‌تأیید
• فایل
• محتوای ویرایش‌پذیر
• تغییر پیشنهادی در یک Workflow

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

ویژگی‌های یک محصول AI-Native

هوش مصنوعی در هسته ارزش محصول قرار دارد

ابتدا باید مشخص شود مدل دقیقاً چه ارزش جدیدی ایجاد می‌کند.

پاسخ‌هایی مانند «می‌خواهیم از هوش مصنوعی استفاده کنیم» کافی نیستند. تعریف مناسب‌تر می‌تواند چنین باشد:

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

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

زبان طبیعی بخشی از رابط محصول است

کاربر به‌جای یافتن چندین منو می‌تواند هدف خود را توضیح دهد:

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

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

محصول با ورودی‌های بدون ساختار کار می‌کند

بخش بزرگی از اطلاعات واقعی کسب‌وکار در قالب داده مرتب ثبت نشده است:

• متن پیام‌ها
• یادداشت جلسات
• فایل‌های متنی
• توضیحات محصولات
• مکالمات
• تصویر
• صوت
• درخواست‌های زبان طبیعی

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

رفتار احتمالی مدل در طراحی محصول لحاظ می‌شود

خروجی مدل همیشه کاملاً ثابت نیست. حتی با ورودی مشابه ممکن است تفاوت‌هایی در پاسخ ایجاد شود.

بنابراین محصول باید برای این شرایط طراحی شود:

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

محصول AI-Native نباید فرض کند هر خروجی مدل آماده استفاده مستقیم است.

بازخورد کاربر وارد چرخه بهبود می‌شود

دکمه‌های ساده‌ای مانند این‌ها اطلاعات ارزشمندی تولید می‌کنند:

• تأیید
• ویرایش
• رد
• تولید دوباره
• کوتاه‌تر کن
• رسمی‌تر بنویس
• گزینه دیگری پیشنهاد بده

این رفتارها به تیم محصول نشان می‌دهند مدل در کدام سناریوها مفید یا ضعیف بوده است.

مدل قابل‌تعویض است

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

در معماری مناسب، شناسه مدل در تنظیمات یا لایه مسیریابی قرار می‌گیرد و در تمام بخش‌های کد تکرار نمی‌شود.

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

اجزای معماری یک اپلیکیشن AI-Native

رابط کاربری

رابط باید به کاربر اجازه دهد هدف، اطلاعات و بازخورد خود را به شکل طبیعی وارد کند.

یک رابط مناسب ممکن است ترکیبی از این موارد باشد:

• ورودی زبان طبیعی
• آپلود فایل
• فرم
• جدول
• پیش‌نمایش خروجی
• دکمه تأیید و رد
• تاریخچه تغییرات
• نمایش مرحله فعلی انجام کار

لایه مدیریت Workflow

این لایه تعیین می‌کند درخواست چگونه پردازش شود:

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

برای Workflowهای قطعی، استفاده از کد و قواعد مشخص معمولاً بهتر است. برای انتخاب‌های وابسته به مفهوم متن می‌توان از مدل کمک گرفت.

لایه مدل هوش مصنوعی

این لایه درخواست را به مدل ارسال و نتیجه را دریافت می‌کند.

در یک معماری چندمدلی ممکن است از مدل‌های متفاوتی استفاده شود:

• مدل سریع و اقتصادی برای دسته‌بندی
• مدل قوی‌تر برای استدلال پیچیده
• مدل برنامه‌نویسی برای تولید یا تحلیل کد
• مدل چندوجهی برای تصویر و متن
• مدل صوتی برای گفتار
• مدل تولید تصویر یا ویدئو برای محتوای بصری

لایه Context

مدل فقط براساس اطلاعاتی که دریافت می‌کند پاسخ می‌دهد. Context می‌تواند شامل این موارد باشد:

• هدف کاربر
• وضعیت فعلی Workflow
• اطلاعات مرتبط از پایگاه داده
• دستورالعمل‌های محصول
• نمونه خروجی مناسب
• نتیجه مراحل قبلی
• محدودیت‌های همان وظیفه

ارسال تمام اطلاعات موجود معمولاً راهکار مناسبی نیست. Context باید مرتبط، تازه و متناسب با وظیفه انتخاب شود.

برای آشنایی بیشتر می‌توانید مقاله Context Engineering چیست؟ را مطالعه کنید.

لایه ابزارها

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

برای مثال:

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

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

لایه ارزیابی

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

معیارها می‌توانند شامل این موارد باشند:

• مرتبط‌بودن پاسخ
• رعایت دستور
• کامل‌بودن خروجی
• درستی ساختار
• کیفیت زبان فارسی
• زمان پاسخ
• هزینه هر وظیفه
• درصد نتایج پذیرفته‌شده توسط کاربران
• تعداد ویرایش‌های لازم
• موفقیت کامل Workflow

راهنمای AWS درباره معماری برنامه‌های هوش مصنوعی مولد برای محیط عملیاتی نیز بر معماری ماژولار، مدیریت متمرکز مدل‌ها و بهینه‌سازی عملکرد و هزینه تأکید می‌کند.

لایه ثبت و تحلیل عملکرد

برای بهبود محصول باید بدانید در هر درخواست چه اتفاقی افتاده است:

• قابلیت استفاده‌شده
• مدل انتخاب‌شده
• مدت پاسخ
• میزان مصرف
• وضعیت نهایی
• خطای احتمالی
• بازخورد کاربر
• نسخه Prompt یا Workflow

بدون این اطلاعات، تشخیص اینکه تغییر مدل یا Prompt واقعاً کیفیت را بهتر کرده دشوار خواهد بود.

چه بخش‌هایی را نباید به مدل زبانی واگذار کرد؟

AI-Native بودن به معنی سپردن همه‌چیز به مدل نیست.

بعضی عملیات با کد معمولی بهتر، ارزان‌تر و قابل‌پیش‌بینی‌تر انجام می‌شوند:

• محاسبات عددی قطعی
• بررسی موجودی
• اعمال قیمت و تخفیف
• ثبت تراکنش
• تغییر وضعیت قطعی سفارش
• کنترل محدودیت مصرف
• مرتب‌سازی ساده
• فیلتر براساس مقدار مشخص
• اجرای قواعد ثابت کسب‌وکار

مدل زبانی برای وظایفی مناسب‌تر است که به درک زبان، تفسیر زمینه، تولید محتوا یا انتخاب میان مسیرهای غیرقطعی نیاز دارند.

چگونه یک محصول معمولی را AI-Native کنیم؟

مرحله اول: یک مشکل واقعی انتخاب کنید

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

نمونه‌های مناسب:

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

مرحله دوم: نتیجه مطلوب را تعریف کنید

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

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

اکنون می‌توان کیفیت هر قسمت را جداگانه ارزیابی کرد.

مرحله سوم: کوچک‌ترین Workflow مفید را بسازید

نسخه اولیه لازم نیست Agent پیچیده‌ای باشد.

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

1. دریافت ورودی کاربر
2. ارسال آن به مدل
3. دریافت خروجی ساختاریافته
4. نمایش پیش‌نمایش
5. ویرایش یا تأیید توسط کاربر
6. ذخیره نتیجه

بعد از اثبات ارزش این مسیر می‌توان ابزار، حافظه، RAG یا تصمیم‌گیری چندمرحله‌ای را اضافه کرد.

مرحله چهارم: Prompt را بخشی از محصول بدانید

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

• هدف مشخص داشته باشد.
• نسخه‌بندی شود.
• ورودی و خروجی آن تعریف شود.
• با نمونه‌های واقعی آزمایش شود.
• تغییرات آن قابل‌مقایسه باشد.
• برای زبان فارسی ارزیابی شود.

مرحله پنجم: خروجی قابل‌ویرایش طراحی کنید

در بسیاری از کاربردها، بهترین تجربه این نیست که مدل مستقیماً نتیجه را نهایی کند.

روش مناسب‌تر:

تولید پیشنهاد
↓
نمایش پیش‌نمایش
↓
ویرایش یا تأیید کاربر
↓
ثبت نتیجه

این طراحی امکان استفاده از سرعت مدل و قضاوت کاربر را هم‌زمان فراهم می‌کند.

مرحله ششم: چند مدل را مقایسه کنید

بهترین مدل برای یک وظیفه لزوماً گران‌ترین یا بزرگ‌ترین مدل نیست.

مدل‌ها را با یک مجموعه درخواست ثابت مقایسه کنید:

• کیفیت فارسی
• رعایت قالب
• سرعت
• هزینه
• طول پاسخ
• موفقیت در سناریوهای پیچیده
• نیاز به اصلاح دستی

برای یک وظیفه ساده ممکن است مدل سریع‌تر و اقتصادی‌تر نتیجه مطلوبی ارائه دهد. مدل قدرتمندتر را می‌توان فقط برای درخواست‌های دشوار استفاده کرد.

مرحله هفتم: معیار محصول را اندازه‌گیری کنید

معیار اصلی نباید فقط «پاسخ مدل خوب بود» باشد.

معیارهای تجاری و تجربه کاربر مهم‌ترند:

• زمان انجام کار چقدر کاهش یافت؟
• چند درصد پیشنهادها پذیرفته شدند؟
• کاربر چند بار خروجی را اصلاح کرد؟
• هزینه هوش مصنوعی برای هر نتیجه چقدر بود؟
• چند کاربر دوباره از قابلیت استفاده کردند؟
• آیا نرخ تکمیل Workflow افزایش یافت؟

نقش API در ساخت محصول AI-Native

بیشتر تیم‌ها برای ساخت محصول هوش مصنوعی‌محور نیازی به آموزش مدل از صفر ندارند. آن‌ها می‌توانند از طریق API به مدل‌های آماده متصل شوند.

API هوش مصنوعی به Backend محصول اجازه می‌دهد:

• پیام یا فایل را به مدل ارسال کند.
• مدل مناسب را انتخاب کند.
• پاسخ را دریافت کند.
• خروجی را در Workflow استفاده کند.
• میزان مصرف را ثبت کند.
• مدل را بدون بازنویسی کل محصول تغییر دهد.

در مقاله API هوش مصنوعی چیست؟ سازوکار کامل درخواست و پاسخ API توضیح داده شده است.

استفاده از API درواره برای محصولات AI-Native

درواره یک API یکپارچه و سازگار با OpenAI برای دسترسی به مدل‌های مختلف هوش مصنوعی ارائه می‌کند.

آدرس پایه API:

https://api.darvareh.ir/v1

این ساختار به توسعه‌دهنده اجازه می‌دهد با تغییر Base URL، API Key و شناسه مدل، از ساختار رایج SDKهای سازگار با OpenAI استفاده کند.

مزیت‌های کاربردی این روش برای یک محصول AI-Native عبارت‌اند از:

• آزمایش مدل‌های مختلف با یک ساختار API
• انتخاب مدل متناسب با هر وظیفه
• استفاده از پرداخت و کیف پول ریالی
• مشاهده مصرف پروژه
• کاهش کدهای اتصال جداگانه
• امکان توسعه معماری چندمدلی

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

نمونه اتصال قابلیت AI-Native به API درواره

در این مثال، محصول توضیح آزاد کاربر درباره یک کار را دریافت و آن را به برنامه اجرایی کوتاه تبدیل می‌کند.

ابتدا کتابخانه را نصب کنید:

pip install openai

سپس درخواست را از Backend ارسال کنید:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1"
)

model_id = os.environ["DARVAREH_MODEL"]

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

response = client.chat.completions.create(
    model=model_id,
    messages=[
        {
            "role": "system",
            "content": """
شما دستیار برنامه‌ریزی محصول هستید.
هدف کاربر را به حداکثر پنج کار مشخص تبدیل کنید.
برای هر کار، عنوان، خروجی مورد انتظار و ترتیب انجام را بنویسید.
اطلاعاتی را که در ورودی وجود ندارد حدس نزنید.
اگر اطلاعات ضروری ناقص است، آن را به شکل پرسش مشخص کنید.
پاسخ را به زبان فارسی ارائه دهید.
"""
        },
        {
            "role": "user",
            "content": user_goal
        }
    ],
    temperature=0.2
)

result = response.choices[0].message.content
print(result)

در یک محصول واقعی، این پاسخ می‌تواند در رابط کاربری به فهرست وظایف قابل‌ویرایش تبدیل شود. کاربر هر مورد را تأیید می‌کند و Backend فقط موارد تأییدشده را ذخیره یا اجرا می‌کند.

برای خروجی کاملاً ساختاریافته، در صورت پشتیبانی مدل انتخابی می‌توانید از JSON Schema یا Structured Outputs استفاده کنید. راهنمای Structured Outputs در API هوش مصنوعی جزئیات این روش را توضیح می‌دهد.

معماری چندمدلی برای محصول AI-Native

لازم نیست همه درخواست‌ها به یک مدل ارسال شوند.

برای مثال:

یک Router می‌تواند براساس نوع درخواست، مدل مناسب را انتخاب کند. این انتخاب می‌تواند ابتدا با قواعد ساده انجام شود و بعداً به Auto Routing هوش مصنوعی توسعه پیدا کند.

برای نسخه اولیه، انتخاب صریح مدل برای هر قابلیت معمولاً ساده‌تر و قابل‌ارزیابی‌تر است.

هزینه محصول AI-Native چگونه کنترل می‌شود؟

هزینه باید از مرحله طراحی محصول در نظر گرفته شود، نه پس از انتشار.

روش‌های کاربردی عبارت‌اند از:

• استفاده از مدل سبک‌تر برای وظایف ساده
• محدودکردن طول پاسخ
• حذف Context نامرتبط
• خلاصه‌سازی تاریخچه طولانی
• ذخیره نتایج تکراری
• اجرای عملیات قطعی با کد
• ارسال درخواست به مدل فقط در صورت نیاز
• استفاده از مدل قدرتمندتر برای موارد دشوار
• اندازه‌گیری هزینه هر قابلیت و هر نتیجه موفق

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

اشتباهات رایج در ساخت محصولات AI-Native

اضافه‌کردن چت بدون مسئله مشخص

صفحه چت زمانی ارزشمند است که کار مشخصی را برای کاربر ساده‌تر کند. چت عمومی بدون Workflow و Context معمولاً تفاوت زیادی با ابزارهای عمومی هوش مصنوعی ندارد.

ارسال همه اطلاعات به مدل

Context بیشتر همیشه پاسخ بهتر ایجاد نمی‌کند. اطلاعات نامرتبط می‌توانند هزینه و زمان پاسخ را افزایش دهند و تمرکز مدل را کاهش دهند.

استفاده از یک مدل برای همه وظایف

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

وابستگی منطق محصول به متن آزاد

اگر Backend برای ادامه کار به داده مشخص نیاز دارد، خروجی باید ساختاریافته باشد. تحلیل متن آزاد برای اجرای Workflow می‌تواند شکننده باشد.

نداشتن مجموعه ارزیابی

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

تلاش برای ساخت Agent پیچیده در نسخه اول

محصول را با یک Workflow کوتاه و قابل‌اندازه‌گیری آغاز کنید. افزودن حافظه، ابزارهای متعدد و تصمیم‌گیری خودکار پیش از اثبات مسئله، توسعه و ارزیابی را دشوار می‌کند.

نادیده‌گرفتن تجربه ویرایش

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

چک‌لیست ساخت MVP هوش مصنوعی‌محور

پیش از انتشار نسخه اولیه بررسی کنید:

• مشکل واقعی کاربر مشخص شده است.
• نتیجه مورد انتظار قابل‌اندازه‌گیری است.
• مدل در هسته ارزش محصول نقش دارد.
• Workflow اولیه کوتاه و روشن است.
• مسئولیت مدل و کد از یکدیگر جدا شده‌اند.
• خروجی قابل‌ویرایش یا تأیید است.
• مجموعه‌ای از نمونه‌های واقعی برای ارزیابی وجود دارد.
• کیفیت زبان فارسی بررسی شده است.
• هزینه و زمان پاسخ اندازه‌گیری می‌شوند.
• مدل از طریق تنظیمات قابل‌تغییر است.
• بازخورد کاربر ثبت می‌شود.
• مسیر مناسب برای خروجی ناقص طراحی شده است.
• قابلیت با کاربران واقعی آزمایش شده است.

پرسش‌های متداول

AI-Native به چه معناست؟

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

آیا هر نرم‌افزار دارای چت‌بات AI-Native است؟

خیر. اگر چت‌بات فقط یک قابلیت جانبی باشد، محصول بیشتر AI-Enabled است. در محصول AI-Native، مدل در انجام وظیفه اصلی کاربر نقش اساسی دارد.

تفاوت AI-First و AI-Native چیست؟

AI-First یعنی هنگام طراحی قابلیت‌ها، هوش مصنوعی در اولویت قرار گیرد. AI-Native معمولاً به محصولی اشاره دارد که ساختار اصلی آن از ابتدا حول قابلیت‌های هوش مصنوعی شکل گرفته است.

آیا برای ساخت محصول AI-Native باید مدل اختصاصی آموزش دهیم؟

در بیشتر پروژه‌ها خیر. می‌توان نسخه اولیه را با مدل‌های آماده، Prompt مناسب، Context، RAG، ابزارها و API ساخت. آموزش اختصاصی زمانی مطرح می‌شود که داده، مسئله و معیار ارزیابی مناسب وجود داشته باشد.

آیا محصول AI-Native حتماً به Agent نیاز دارد؟

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

آیا می‌توان محصول AI-Native فارسی ساخت؟

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

درواره چه کمکی به ساخت محصول AI-Native می‌کند؟

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

بهترین مدل برای محصول AI-Native کدام است؟

یک پاسخ ثابت وجود ندارد. مدل مناسب به نوع وظیفه، کیفیت فارسی، سرعت، هزینه، طول Context، ورودی موردنیاز و توانایی پیروی از ساختار بستگی دارد.

جمع‌بندی

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

معماری مناسب چنین محصولی باید مسئولیت‌ها را تفکیک کند:

• مدل برای درک، تولید و استدلال
• کد برای قواعد و عملیات قطعی
• ابزارها برای ارتباط با قابلیت‌های نرم‌افزار
• Context برای ارائه اطلاعات مرتبط
• سیستم ارزیابی برای سنجش کیفیت
• رابط کاربری برای مشاهده، ویرایش و تأیید نتیجه

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

برای ساخت نمونه اولیه می‌توانید در درواره ثبت‌نام کنید، API Key بگیرید و مدل مناسب پروژه را از کاتالوگ جاری انتخاب کنید.

مقالات مرتبط

• API هوش مصنوعی چیست؟ راهنمای دریافت و استفاده
• API سازگار با OpenAI چیست؟
• معماری چندمدلی هوش مصنوعی
• Auto Routing در هوش مصنوعی چیست؟
• AI Agent و Agent Skills چیست؟
• Structured Outputs چیست؟

منابع

• CNCF: Cloud Native Artificial Intelligence Whitepaper
• CNCF: Evolving Platform Engineering for AI-Native Workloads
• AWS: Architecting Generative AI Applications for Production
• AWS: Repeatable Application Patterns for Generative AI

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