تصور کنید یک مدیر مالی برای گزارش درآمد ماهانه به هوش مصنوعی تکیه کند و پاسخی دریافت کند که از نظر برنامه‌نویسی بی‌نقص است، اما ارقامی کاملاً اشتباه را نمایش می‌دهد. این همان نقطه‌ای است که اکثر دموهای تجاری هوش مصنوعی در مواجهه با دنیای واقعی سقوط می‌کنند.
به گزارش dev.to در ۲۰ ژوئیه ۲۰۲۶، بسیاری از سامانه‌های فعلی زمانی که با پیچیدگی و «نا düzenی» داده‌های دنیای واقعی روبرو می‌شوند، دچار اختلال شده و فرو می‌پاشند. مشکل بنیادین این است که یک پرس‌وجوی SQL (SQL Query) که از نظر فنی معتبر است (یعنی بدون خطا اجرا می‌شود)، لزوماً با منطق تجاری سازمان هم‌راستا نیست.
شکاف میان طرح‌واره و منطق
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی توهمات مدل‌های زبانی اشاره کردیم، مدل‌ها تمایل دارند در نبودِ داده‌های قطعی، حدس بزنند. در محیط‌های سازمانی، این حدس زدن در سطح داده‌ها رخ می‌دهد. تصور کنید یک هوش مصنوعی با چهار جدول مختلف از مشتریان مواجه شود: crm_customer ،customer_master ،customer_profile و dim_customer. از دیدگاه مدل، هر چهار جدول مرتبط به نظر می‌رسند، زیرا مدل تنها می‌تواند نام‌ها، انواع داده‌ها، محدودیت‌ها (Constraints) و مقادیر نمونه را بررسی کند.
این موضوع تأییدی بر این واقعیت است که آگاهی از طرح‌واره (Schema) در ابزارهای SQL تا حد زیادی بر اندازه مدل برتری دارد و صرفاً افزایش پارامترهای مدل، مشکل درک ساختاری را حل نمی‌کند.
با این حال، یک توسعه‌دهنده انسانی از زمینه (Context) تجاری خاص خبر دارد و می‌داند که:
- جدول
customer_masterمنبع مرجع و معتبر است. - جدول
crm_customerتنها شامل فعالیت‌های فروش است. - جدول
customer_profileناقص است. - جدول
dim_customerبه‌طور خاص برای گزارش‌گیری آماده شده است.
این شکاف باعث ایجاد یک مرحله خطرناک از «حدس‌وگمان» می‌شود که در آن هوش مصنوعی زمینه تجاری را توهم می‌زند. بدون این دانش، مدل ممکن است SQL معتبری تولید کند که نتیجه تجاری کاملاً غلطی را ارائه دهد.
پیچیدگی روابط در سازمان‌ها
روابط داده‌ها در سازمان‌ها به‌ندرت به سادگی کلیدهای خارجی (Foreign Keys) هستند. اگرچه پایگاه‌های داده رابطه‌ای از کلیدهای خارجی پشتیبانی می‌کنند، اما داده‌های واقعی بسیار آشفته‌تر هستند. بسیاری از پیوندها تنها در کدهای قدیمی ETL یا در مرزهای بین سیستمی با استفاده از کلیدهای ترکیبی (Composite Keys) وجود دارند. برخی پیوندها حتی بر اساس فیلدهایی با نام‌های متفاوت است که اتفاقاً مقادیر یکسانی دارند.
برای مثال، یک درخواست ساده برای گزارش پرداخت ممکن است نیازمند یک مسیر پیچیده باشد: مشتری $\rightarrow$ سفارش $\rightarrow$ صورت‌حساب $\rightarrow$ پرداخت. در حالی که ممکن است چندین مسیر از نظر فنی امکان‌پذیر باشد، تنها یکی از آن‌ها با منطق گزارش‌گیری مورد استفاده در واحد مالی مطابقت دارد. این انتخاب خاص را نمی‌توان به‌طور قابل‌اعتماد تنها از روی نام جداول بازیابی کرد.
برای حل این بحران، بر اساس مستندات منتشرشده، پیشنهاد می‌شود از راهکارهای «فقط پرامپت» (Prompt-only) فاصله بگیریم و لایه‌های تخصصی را جایگزین کنیم:
- Arisyn-IntaLink: این ابزار بر کشف روابط در سطح جدول و فیلد، ارزیابی پیوندهای احتمالی و ارائه مسیرهای ارتباطی قابل‌استفاده برای سامانه‌های تحلیلی و هوش مصنوعی متمرکز است.
- Arisyn-Semora: یک لایه معنایی (Semantic Layer) است که تعاریف تجاری و نگاشت آن‌ها به داده‌های زیربنایی را مدیریت می‌کند. این لایه تضمین می‌کند که اصطلاحاتی مانند «درآمد» (Revenue) — اینکه آیا به معنای
SUM(invoice_amount)است، یاSUM(payment_amount)، و یاSUM(invoice_amount - refunds)— سازگار بمانند و با تعریف رسمی شرکت مطابقت داشته باشند.
افزودن یک مدل قوی‌تر یا مهندسی پرامپت (Prompt Engineering) — یا همان هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — این مشکل روابط گمشده را حل نمی‌کند. یک مدل قدرتمندتر شاید کد تمیزتری بنویسد، اما همچنان نمی‌تواند بداند کدام مسیر پیوند (Join) مورد اعتماد است، آیا رابطه یک‌به-یک است یا یک‌به-بسیار، یا اینکه آیا اتصال دو جدول باعث تکرار تصادفی رکوردها (Duplicate) می‌شود یا خیر. این‌ها مسائل حاکمیتی (Governance) هستند، نه مسائل زبانی.
جریان پرس‌وجوی قابل‌اتکا
یک جریان پرس‌وجوی سازمانی قابل‌اعتماد باید پیش از تولید هرگونه کد SQL، معنای تجاری را رمزگشایی کرده و موجودیت‌های مورد اعتماد را شناسایی کند. ترتیب dependable باید به این صورت باشد:
پرسش تجاری $\rightarrow$ رمزگشایی معنای تجاری $\rightarrow$ شناسایی موجودیت‌های مرتبط $\rightarrow$ انتخاب روابط مورد اعتماد $\rightarrow$ تولید SQL $\rightarrow$ اعتبارسنجی و اجرا.
بیشتر شکست‌ها در مراحل اولیه این زنجیره رخ می‌دهند. اگر معیار (Metric) اشتباه انتخاب شود یا یک پیوند غیرقابل‌اعتماد برگزیده شود، پاسخ حتی پیش از آنکه SQL تولید شود، در مسیر اشتباه قرار گرفته است.
برای توسعه‌کنندگان حرفه‌ای، این یعنی حیاتی‌ترین بخش پشته‌ی فناوری (Tech Stack)، نه خودِ مدل، بلکه تمام زیرساخت‌های زیر آن است. هوش مصنوعی سازمانی به یک نمایش صریح از نحوه اتصال داده‌ها و معنای آن‌ها نیاز دارد. کاهش حدس‌وگمان در سیستم‌های داده تولیدی، بسیار ارزشمندتر از تولید سریع‌تر کد در چند میلی‌ثانیه است.
گام بعدی شما
- اگر در حال ساخت عامل‌های (Agents) متصل به پایگاه‌داده هستید، پیچیدگی طرح‌واره (Schema) خود را بررسی کنید تا ببینید آیا یک لایه‌ی معنایی اکنون برای دقت سیستم شما یک ضرورت است یا خیر.
- به جای ارتقای مدل (مثلاً مهاجرت به مدل‌های بزرگ‌تر)، روی مستندسازی روابط داده‌ای در یک لایه واسط تمرکز کنید.
- فرآیند اعتبارسنجی خروجی‌های SQL را از حالت «بررسی سینتکس» به «بررسی منطق تجاری» تغییر دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو