تصور کنید معماری نرمافزاری شما بهگونهای باشد که ارائهدهندگان هوش مصنوعی بهجای وابستگیهای سخت، مانند قطعات یدکی قابل تعویض باشند. این دقیقاً همان رویکردی است که استارتاپ حوزه سلامت، MyVitals، برای مدیریت مدلهای Gemini، OpenAI، Anthropic و Mistral به کار گرفته است.
به لطف این ساختار، تیم توسعه میتواند تنها با تغییر یک متغیر محیطی و بدون نیاز به بازنویسی کدها، مدل فعال را عوض کند. این استراتژی پاسخی است به یکی از بزرگترین چالشهای تولیدی: موازنه بین استدلالهای گرانقیمت و چتهای ارزانقیمت. همانطور که در پوشش پیشین ما از Oxlo.ai و مدیریت استقرارها برای کاهش هزینهها دیدیم، MyVitals نیز بار کاری خود را به دو نقش مجزا تقسیم کرده است. این رویکرد یادآور استراتژی توزیع هوشمند وظایف میان مدلهای محلی و ابری است که برای بهینهسازی جریان کاری توسعهدهندگان پیشنهاد شده است.
یک نقش بر استخراج دقیق دادهها از فایلهای PDF و تطبیق معیارها تمرکز دارد و نقش دیگر، تعاملات سریع و ارزان با کاربر را مدیریت میکند.
به نقل از گزارشی در وبسایت dev.to که در ۳ سپتامبر ۲۰۲۶ منتشر شد، این سامانه از یک طرحواره (Schema) استاندارد برای مدیریت فرمتهای مختلف JSON استفاده میکند. پیادهسازی فنی این سیستم بر سه متد اصلی استوار است:
- extractReport (استخراج گزارش)
- matchUnmatchedMetrics (تطبیق معیارهای یافتنشده)
- chat (گفتگو)
این متدها در هر چهار آداپتور (Adapter) — شبیه به تبدیلهای برق که اجازه میدهند یک دستگاه با پریزهای مختلف کار کند — پیاده شدهاند. این ساختار مشابه استفاده از Endpointهای سازگار با OpenAI است که انعطافپذیری سیستمهای CRM را در برابر تغییر مدلها افزایش میدهد. بر اساس مستندات این پروژه، تفاوتهای مالی بین ارائهدهندگان بسیار زیاد است؛ برای مثال، Mistral هزینه نویسهخوانی نوری (OCR) — یعنی تبدیل عکس متن به متن قابل ویرایش — را بهازای هر صفحه میگیرد، در حالی که دیگران بر اساس توکن (Token) — تکههای کوچکی از متن شبیه برشهای کیک — صورتحساب میفرستند.
این تفاوت باعث یک واقعیت اقتصادی متناقض شده است: کاربرانی که بیشتر با سیستم میمانند، گرانترین کاربران هستند؛ زیرا برای حفظ دقت در چتها، باید کل تاریخچه معیارها در هر نوبت به پرامپت اضافه شود. در واقع، این چالش تفاوتهای بنیادین مدلهای هزینه بر اساس درخواست در برابر توکن را در تحلیل متون حجیم برجسته میکند.
یک خطای بحرانی زمانی رخ داد که نام مستعار یک مدل بهاشتباه برای یک ماه روی مدلی تنظیم شد که فقط قابلیت OCR داشت. چون خط لوله (Pipeline) بهگونهای طراحی شده بود که در صورت خطا، بهجای توقف، ورودیهای جدید را در دیکشنری ثبت کند، این نقص برای مدتی پنهان ماند. این اتفاق نشان میدهد که «تخریب تدریجی» (Graceful Degradation) میتواند یک نقطه کور خطرناک باشد، زیرا وضعیت «موفقیت» در لاگها، شکست در مسیر دقت بالا را میپوشاند.
برای جلوگیری از این اتفاق، تیم اکنون نسخه دقیق مدل (مثلاً mistral-small-2603) را در کنار نام مستعار ثبت میکند تا تاریخچه هزینه و عملکرد حتی با بهروزرسانیهای خودکار ارائهدهندگان، قابل ردیابی باشد.
گام بعدی شما
- اگر از چندین مدل استفاده میکنید، لایه آداپتور را برای جلوگیری از انحصار ارائهدهنده (Vendor Lock-in) پیاده کنید.
- معیارهای شکست خود را بازبینی کنید تا مطمئن شوید «موفقیت» در لاگها به معنای انتخاب دقیقترین مسیر است، نه صرفاً اجرا شدن کد.
- نسخههای دقیق مدلها را لاگ کنید تا اثر بهروزرسانیهای پنهان ارائهدهندگان بر هزینه و کیفیت را بسنجید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو