وقتی فهمیدم هوش مصنوعی خوب، لزوماً هوش مصنوعی پرحرف نیست! تجربه من در توسعه ایده عینک هوشمند نابینایان: اوایل کار روی سیستم‌های هوشمند کمکی، ناخودآگاه فکر می‌کردم هرچه مدل من اشیای بیشتری را تشخیص بدهد، محصول هم بهتر است. سیستم مدام می‌گفت: صندلی را دیدم! ماشین را دیدم! آدم‌ها را دیدم! حداقل ۱۸ شئی برای تشخیص آموزش داده شده بود! درخت، دیوار، پله، در، تابلو و هر چیزی که جلوی دوربین قرار می‌گیرد را اعلام میکرد! روی کاغذ، این یعنی یک مدل قدرتمندتر. اما دیدم وقتی همین خروجی را وارد تجربه واقعی کاربر می‌کنی، ماجرا کاملاً عوض می‌شود. فرض کن کاربر در حال حرکت است و سیستم پشت سر هم می‌گوید: «آدم در سمت راست.» «ماشین در سمت چپ.» «صندلی روبه‌رو.» «تابلو در بالا.» «مانع نزدیک.» «آدم در سمت راست.» از نگاه مدل، همه‌چیز درست است. اما از نگاه کاربر، این دیگر کمک نیست؛ یک صدای دائمی و خسته‌کننده است که اجازه نمی‌دهد روی اطلاعات مهم تمرکز کند. همان‌جا به یک نکته مهم رسیدم: در محصولات هوش مصنوعی، مسئله فقط این نیست که مدل چه چیزی را می‌بیند؛ مسئله این است که کاربر واقعاً به دانستن کدام بخش از آن نیاز دارد. مدل فقط اطلاعات تولید نکند، مدل بداند چه موقع، چه اطلاعاتی را تولید کند! مدلی که همه‌چیز را اعلام می‌کند، الزاماً باهوش‌تر نیست، گاهی فقط بلد نیست اولویت‌بندی کند. برای همین، در طراحی چنین سیستم‌هایی باید چند سؤال مهم‌تر از Accuracy پرسید: - آیا این هشدار برای کاربر ضروری است؟ - آیا الان زمان مناسبی برای اعلام آن است؟ - آیا این شیء واقعاً در مسیر حرکت قرار دارد؟ - آیا این هشدار تکراری است؟ - آیا گفتن این اطلاعات، تصمیم‌گیری را راحت‌تر می‌کند یا سخت‌تر؟ اینجا بود که فهمیدم یکی از مهم‌ترین بخش‌های سیستم من، خود مدل تشخیص اشیا نیست؛ لایه تصمیم‌گیری بعد از مدل است. مدل‌ من می‌گوید: «من یک مانع پیدا کردم.» اما سیستم محصول باید تصمیم بگیرد: «آیا الان باید درباره این مانع صحبت کنم؟» پس برای حل این مشکل شروع به تحقیق کردم و یه سری ابزار و راهکار پیدا کردم. یکی از این ابزارهایی که می‌تواند خیلی کمک‌کننده باشد FiftyOne است. FiftyOne: فقط برای دیدن چند تصویر و چند Bounding Box نیست. می‌توانی با آن نمونه‌هایی را پیدا کنی که مدل در آن‌ها: - یک شیء را مدام شناسایی و حذف می‌کند؛ - اشیای غیرضروری را بیش از حد گزارش می‌دهد؛ - در نور کم یا زاویه خاص دچار خطا می‌شود؛ - یک هشدار مهم را با اطمینان پایین تولید می‌کند؛ - یا بین چند کلاس مشابه اشتباه می‌کند. این نوع بررسی، یک تفاوت مهم با نگاه‌کردن به عدد Accuracy دارد. چون ممکن است مدل روی دیتاست به دقت ۹۰ درصد برسد، اما همان ۱۰ درصد خطا دقیقاً در لحظه‌ای اتفاق بیفتد که کاربر به آن هشدار وابسته است. در فناوری سلامت و ابزارهای کمکی، همه خطاها وزن یکسانی ندارند. اشتباه گرفتن یک صندلی با یک نیمکت شاید آزاردهنده باشد. اما ندیدن یک مانع در مسیر حرکت می‌تواند کاملاً متفاوت باشد. پس شاید معیار واقعی یک محصول AI این نباشد که: «مدل چند درصد درست پیش‌بینی می‌کند؟» بلکه این باشد که: وقتی مدل اشتباه می‌کند، محصول چقدر خوب از کاربر محافظت می‌کند؟ این نگاه، طراحی محصول را از یک مسابقه برای ساختن مدل بزرگ‌تر، به مسئله‌ای انسانی‌تر تبدیل می‌کند. ما قرار نیست فقط به ماشین یاد بدهیم که دنیا را ببیند. باید به آن یاد بدهیم که: - چه چیزی مهم‌تر است؛ - چه زمانی باید هشدار بدهد؛ - چه زمانی باید سکوت کند؛ - و چطور اطلاعات را طوری منتقل کند که کاربر کنترل بیشتری داشته باشد، نه اضطراب بیشتر. به نظرم یکی از خطرناک‌ترین اشتباهات در ساخت محصولات هوش مصنوعی این است که فکر کنیم: هر خروجی بیشتر، یعنی ارزش بیشتر. مخصوصا در حوزه سلامت که جزئیات و پیچیدگی هم وجود داره هم مهمه! گاهی بهترین خروجی مدل، چیزی نیست که با صدای بلند اعلام می‌کند. گاهی بهترین خروجی، همان هشداری است که به‌موقع، کوتاه و قابل اعتماد به کاربر کمک می‌کند یک تصمیم بهتر بگیرد. ابزارهایی مثل FiftyOne کمک می‌کنند خطاهای مدل را ببینیم. اما دیدن خطا کافی نیست. باید از خودمان بپرسیم: این خطا برای چه کسی، در چه لحظه‌ای و با چه هزینه‌ای اتفاق می‌افتد؟ لینک ابزار: github.com/voxel51/fiftyone ➖➖➖➖➖➖ 🔺 @hitwithit

بچه این ریپازیتوری واقعا برگ ریزونه! بجای اینکه API گرون برای ایجنت بخرید، این وصل میشه به صفحه چتتون و دیگه از اعتبار و توکن API استفاده نمیکنه و تموم مکالمات در سطح صفحه چت انجام میشه منتهی بصورت ایجنت میتونه براتون کد بزنه و تسک انجام بده. اینطوری وقتی یه اکانت بخرید ( یا حتی نخرید و رایگان باشه) هم میتونید از ایجنتی که بهتون میده استفاده کنید هم با این پروژه میتونید از قابلیت چت به عنوان ایجنت استفاده کنید (روش mcp): https://github.com/totec448-spec/chat-on-steroids اینو از دست ندینااا 🔥 حتمااا نصبش کنین و باهاش ور برین، خیلی چیز خفنیه 🤌 ➖➖➖➖➖➖ 🔺@hitwithit

مدل های زبانی برای تعامل و دستیار بودن عالین، ولی برای اتوماسیون و کار های نرم افزاری، دیگه با یه انسان طرف نیستیم و یک سیستم صفر و یک دنبال جواب قطعیه! راه حل چیه؟ اخیراً شرکت TypeSafe مدلی معرفی کرده به اسم Jev که کاملاً قاعده بازی مدل‌های زبانی رو عوض کرده. اگر توی حوزه توسعه نرم‌افزار یا سلامت دیجیتال کار می‌کنید، این دقیقاً چیزیه که مدت‌ها منتظرش بودیم. 🧐بیاید چند دقیقه بازش کنیم ببینیم ماجرا چیه: ۱. اصلاً Jev چیه و چه فرقی با بقیه مدل‌ها داره؟ مدل Jev یک LLM معمولی نیست که براش پرامپت بنویسید و براتون انشا یا مقاله تولید کنه! تیم سازنده بهش می‌گن System One Model (با الهام از تفکر سریع و غریزی دانیل کانمن، کتاب تفکر سریع و کند رو میتونید بخونید). کار Jev متن نوشتن نیست؛ کارش «تصمیم‌گیری ساختاریافته (Typed Decision) با احتمال دقیق» برای دل کدها و پایپ‌لاین‌های نرم‌افزاریه. خروجی اون متن آزاد نیست، بلکه دیتای تایپ‌شده است: بولین (True/False)، امتیاز، دسته‌بندی و احتمال آماری کالیبره‌شده. ۲. چه مشکلی رو حل می‌کنه؟ اگر تا حالا سعی کرده باشید یک LLM رو به بک‌اند یا دیتابیس وصل کنید، این دردهای مشترک رو لمس کردید: - کند بودن: برای یک تصمیم ساده بله/خیر، باید ثانیه‌ها منتظر تولید توکن‌های متنی می‌موندیم. - هزینه بالا: هزینه سنگین سرور و توکن‌ها برای تصمیم‌های روتین. - شکنندگی فرمت خروجی: مدل قرار بود فقط JSON معتبر بده، ولی وسطش یه کلمه جا می‌انداخت و کل کد کِرَش می‌کرد! - هذیان (Hallucination) و عدم قطعیت: نمی‌شد صددرصد روی خروجی‌اش برای منطق سیستم حساب باز کرد. بنابراین مدل Jev وارد بازی شد تا تصمیم احتمالاتی برای مجموعه داده بگیره. ۳. مکانیزم کارش چطوریه؟ خیلی سرراست و مهندسی‌شده: ورودی ساختاریافته رو می‌گیره (مثلاً لاگ، دیتا یا پرسش‌های فرمت‌دار)، به جای اینکه دونه‌دونه کلمات متنی بعدی رو پیش‌بینی کنه، مستقیماً احتمال یک تصمیم رو محاسبه می‌کنه و نتیجه رو در قالب مقادیر مشخص، استاندارد و با دوز مشخصی از اطمینان (Confidence Score) تحویل برنامه می‌ده. یعنی هیچ توکن متنی الکی تولید نمی‌شه! ۴. این دقیقاً کجای «سیستم‌های سلامت و پزشکی» به کار میاد؟ 🩺 حوزه سلامت جایی نیست که شما حوصله هذیان گویی یا تأخیر چت‌بات‌ها رو داشته باشید؛ شما نیاز به قطعیت، سرعت و تصمیم‌های شفاف دارید: ۱. تریاژ سریع و تصمیم‌گیری اورژانسی: تعیین اینکه آیا بر اساس علائم حیاتی و گزارش ورودی، بیمار وضعیت بحرانی دارد یا خیر (True/False در چند میلی‌ثانیه). ۲. رووتینگ و فیلترینگ داده‌های پزشکی: آیا این سیگنال یا تصویر نویز دارد؟ آیا این ریکوئست باید به رادیولوژیست پاس داده بشه یا نرم‌افزار اتوماسیون؟ ۳. سیستم‌های کمکی و لایه لبه (Edge AI): فرض کنید در گجت‌های کمکی توانبخشی یا ابزارهای بینایی نابینایان، نیاز دارید در لحظه تصمیم بگیرید: «آیا این مانع پرخطر است؟» در اینجا شما ۵ ثانیه وقت چت کردن با هوش مصنوعی ندارید! ۴. اعتبارسنجی لاگ‌ها و سوابق پرونده الکترونیک سلامت (EHR): پیدا کردن ناسازگاری‌ها و تضادهای ساختاریافته در نسخه‌ها و داده‌های آزمایشگاهی. ➖➖➖➖➖ جمع‌بندی: ما از دوره‌ی هیجان «چت‌کردن با مدل‌ها» وارد دوره‌ی «مهندسیِ تصمیم‌گیری هوشمند در نرم‌افزارها» شدیم. ابزارهایی مثل Jev دقیقاً پلی هستن که هوش مصنوعی رو از یک اسباب‌بازی جالب، به یک جزء قابل اعتماد، پایدار و مهندسی‌شده در بک‌اند نرم‌افزارهای حیاتی (مخصوصاً سلامت) تبدیل می‌کنن. ➖➖➖➖➖➖ 🔺@hitwithit