عامل‌های هوش مصنوعی اغلب قربانی داده‌های قدیمی، ناقص و ناسازگار می‌شوند

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

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

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

وقتی این اتفاق برای عامل‌های هوش مصنوعی رخ می‌دهد، شرکت‌ها معمولاً دو تشخیص اشتباه می‌دهند. ابتدا مدل را مقصر می‌دانند، مدل زبانی دیگری امتحان می‌کنند یا پرامپت را تغییر می‌دهند. بعد سراغ لایه بازیابی می‌روند و تصور می‌کنند یک پایگاه برداری یا لایه زمینه بهتر مشکل را حل می‌کند. خدمات وب آمازون (Amazon Web Services) با گراف دانشی مبتنی بر استفاده عامل‌ها وارد رقابت لایه زمینه شده و اسنوفلیک (Snowflake) نیز با Horizon Context و Cortex Sense سراغ همین مسئله رفته است. این محصولات به یک درد واقعی پاسخ می‌دهند، اما همچنان یک طبقه بالاتر از ریشه مشکل قرار دارند؛ گراف دانشی هم اگر با داده قدیمی تغذیه شود، فقط نقشه منظم‌تری از اطلاعات اشتباه می‌سازد.

آنچه کم است، مشاهده‌پذیری داده (Data Observability) است؛ یعنی شرکت بتواند نه‌فقط حرکت داده، بلکه سلامت خود داده را ببیند. اوبر مدت‌ها پیش از رواج تولید تقویت‌شده با بازیابی، پلتفرم اختصاصی کیفیت داده ساخت. سامانه Unified Data Quality این شرکت بیش از ۲,۰۰۰ مجموعه‌داده حیاتی را پوشش می‌دهد و حدود ۹۰ درصد رخدادهای کیفیت را پیش از رسیدن به مصرف‌کنندگان پایین‌دستی تشخیص می‌دهد. نتفلیکس بخش دیگری از معما را حل کرده است: سامانه تبار داده‌ای که نشان می‌دهد هر مجموعه‌داده از کجا آمده، از چه تبدیل‌هایی گذشته و به کدام موضوعات کافکا، مدل‌های یادگیری ماشین و آزمایش‌ها متصل شده است.

برای ساخت داده قابل‌اعتماد باید چهار ویژگی جداگانه کنترل شود: صحت، یعنی نوع فیلدها، مقادیر خالی و محدوده‌ها مطابق انتظار باشند؛ تازگی، یعنی هر منبع متناسب با نیاز خودش به‌روزرسانی شود؛ سازگاری، یعنی یک واقعیت در پایگاه‌ها و نمایه‌های مختلف دو پاسخ متفاوت نداشته باشد؛ و تبار، یعنی هر خروجی تا منبع و تمام تبدیل‌هایش قابل‌ردیابی باشد. ابزارهایی مانند گریت اکسپکتیشنز (Great Expectations) و سودا (Soda) می‌توانند اعتبارسنجی خودکار را انجام دهند. در سکیور (Socure) نیز داده ابتدا وارد محیط موقت می‌شد، بررسی و حسابرسی می‌شد و فقط پس از قبولی منتشر می‌شد. نتیجه فقط عامل هوش مصنوعی بهتر نبود؛ گزارش‌ها و مدل‌های یادگیری ماشین هم دقیق‌تر شدند. پرسش درست برای صبح دوشنبه این نیست که کدام مدل را جایگزین کنیم، بلکه این است که قدیمی‌ترین محتوایی که هنوز با اطمینان نمایش می‌دهیم چیست و آیا می‌توانیم مسیرش را تا منبع اصلی دنبال کنیم؟