اکنون یک الگوی محبوب در صنعت هوش مصنوعی وجود دارد: به مدل زبانی دسترسی به ابزارها بدهید و بگذارید خودش تشخیص دهد چه چیزی را فراخوانی کند. در نمایش‌های آزمایشی عالی عمل می‌کند. در محیط عملیاتی از هم می‌پاشد.
در Atlas Verified، عامل هوش مصنوعی ما به بیش از 100 ابزار تخصصی دسترسی دارد: پایگاه‌های داده دولتی انطباق، APIهای ردیابی کشتی، خدمات غربالگری تحریم‌ها، ارائه‌دهندگان داده‌های تجاری، سامانه‌های ردیابی کانتینر و موارد دیگر. هر ابزار وجود دارد چون یک متخصص انطباق برای تصمیم‌گیری درباره راستی‌آزمایی به همان داده مشخص نیاز دارد. چالش مهندسی، ساختن ابزارها نیست؛ اطمینان یافتن از این است که هر بار، ابزارهای درست با ترتیب درست و ورودی‌های درست فراخوانی شوند.
این مطلب مشکلات واقعی هماهنگ‌سازی ابزارها در مقیاس بزرگ و الگوهای مهندسی‌ای را که برای حل آن‌ها توسعه داده‌ایم تشریح می‌کند.
مشکل رشد انفجاری ابزارها
وقتی عامل شما 5 ابزار دارد، انتخاب ابزار ساده است. مدل توضیح هر ابزار را می‌خواند، ابزار درست را انتخاب می‌کند و آن را فراخوانی می‌کند. اما با عبور از 20، 50 و 100 ابزار، مشکلی پیش می‌آید.
نخست، مشکل پنجره زمینه وجود دارد. هر ابزار به توضیح، طرحواره پارامترها و راهنمای استفاده در دستور سیستمی نیاز دارد. با 100+ ابزار، ده‌ها هزار توکن پیش از آنکه حتی پرسش کاربر وارد زمینه شود مصرف می‌شود. مدل زمان بیشتری را صرف خواندن مستندات ابزار می‌کند تا فکر کردن درباره مسئله.
دوم، مشکل دقت انتخاب وجود دارد. مدل‌های زبانی در انتخاب میان چند گزینه که تفاوت روشنی دارند خوب عمل می‌کنند. اما در انتخاب میان ده‌ها ابزار با نام‌های مشابه ضعیف‌اند. وقتی چند ابزار با نام‌های هم‌پوشان برای بررسی و غربالگری تحریم‌ها دارید، مدل اغلب ابزار اشتباه را انتخاب می‌کند یا چند ابزار را فراخوانی می‌کند که داده‌های هم‌پوشان برمی‌گردانند.
سوم، مشکل هزینه و تأخیر وجود دارد. توضیح هر ابزار در دستور، توکن مصرف می‌کند. هر فراخوانی غیرضروری ابزار، مستلزم فراخوانی API خدمات خارجی است که بسیاری از آن‌ها برای هر درخواست هزینه می‌گیرند. عاملی که 8 ابزار را فراخوانی می‌کند درحالی‌که 3 ابزار کافی است، گران و کند است.
چرا مسیریابی ثابت کار نمی‌کند
راه‌حل ساده‌انگارانه، مسیریابی ثابت است: پرسش کاربر را با الگوها تطبیق دهید و به مجموعه‌های ازپیش‌تعیین‌شده ابزار هدایت کنید. «این شرکت را بررسی کن» غربالگری تحریم‌ها را فعال می‌کند. «این کانتینر را ردیابی کن» ردیابی کشتی را فعال می‌کند. «این گواهی را راستی‌آزمایی کن» جست‌وجوی USDA را فعال می‌کند.
این روش در عمل بلافاصله شکست می‌خورد. این پرسش را در نظر بگیرید: «می‌توانی این گواهی ارگانیک از هند را راستی‌آزمایی کنی؟» مسیریاب ثابت ممکن است جست‌وجو در پایگاه داده ارگانیک USDA را فعال کند، که منطقی است. اما متخصص انطباق می‌خواهد این‌ها را هم بداند: آیا نهاد گواهی‌دهنده تحریم شده است؟ آیا برای محصول وارداتی از آن کشور، هشدار وارداتی فعال FDA وجود دارد؟ آیا صادرکننده در هیچ‌یک از فهرست‌های اشخاص ممنوع از معامله قرار دارد؟ آیا در مسیر اظهارشده ناهنجاری تجاری وجود دارد؟
یک پرسش کاربر می‌تواند به‌درستی به پنج ابزار یا بیشتر در حوزه‌های کاملاً متفاوت نیاز داشته باشد. مسیریابی ثابت یا بررسی‌های حیاتی را از قلم می‌اندازد یا همه‌چیز را بیش از حد فعال می‌کند، که دوباره ما را به مشکلات هزینه و دقت برمی‌گرداند.
زمینه اهمیت بسیار زیادی دارد. «درباره این شرکت به من بگو» بسته به اینکه کاربر به یک بارنامه، گواهی ارگانیک نگاه می‌کند یا در حال گفت‌وگوی پژوهشی عمومی است، معناهای کاملاً متفاوتی دارد. همان چهار واژه در هر زمینه به ابزارهای متفاوتی نیاز دارند.
معماری دولایه: انتخاب و اجرا
راه‌حل ما با استفاده از دو لایه مدل مجزا، انتخاب ابزار را از اجرای آن جدا می‌کند.
لایه انتخاب از یک مدل سریع و کم‌هزینه استفاده می‌کند. تنها وظیفه آن بررسی پرسش کاربر، زمینه گفت‌وگو و فهرستی فشرده از ابزارهای موجود است تا انتخاب کند کدام ابزارها باید برای این تعامل مشخص در دسترس باشند. ابزارها را فراخوانی نمی‌کند؛ فقط تصمیم می‌گیرد مدل اجرا به کدام‌یک دسترسی داشته باشد.
مدل انتخاب، نمایی ساده‌شده از هر ابزار می‌بیند: توضیحی یک‌خطی، داده‌هایی که برمی‌گرداند و محدودیت‌هایش. این نما بسیار فشرده‌تر از طرحواره‌های کامل پارامترهاست، بنابراین مدل انتخاب می‌تواند همه 100+ ابزار را بدون برخورد با محدودیت زمینه ارزیابی کند. معمولاً 8-12 ابزار مرتبط با پرسش فعلی را انتخاب می‌کند.
لایه اجرا از مدل استدلالی توانمندتری استفاده می‌کند. فقط ابزارهایی را دریافت می‌کند که لایه انتخاب برگزیده است، همراه با طرحواره کامل پارامترها و راهنمای استفاده. چون به‌جای کل فهرست، با مجموعه‌ای متمرکز از ابزارها کار می‌کند، درباره اینکه کدام ابزار را با چه ترتیب و چه پارامترهایی فراخوانی کند، تصمیم‌های بهتری می‌گیرد.
این جداسازی مزایای قابل اندازه‌گیری دارد. انتخاب در کسری از ثانیه انجام می‌شود و هزینه بسیار کمی دارد. مدل اجرا زمینه‌ای روشن و متمرکز می‌بیند و خطاهای کمتری مرتکب می‌شود. پس از معرفی این معماری، مجموع فراخوانی‌های ابزار در هر تعامل به‌طور چشمگیری کاهش یافت.
فیلتر کردن بر اساس قابلیت
علاوه بر انتخاب دولایه، هر ابزار در سامانه ما قابلیت‌های خود، یعنی انواع وظایفی را که می‌تواند انجام دهد، اعلام می‌کند. ابزار ممکن است اعلام کند برای بررسی انطباق، اطلاعات تجاری، تحلیل اسناد یا ردیابی محموله مفید است.
وقتی سامانه هدف کاربر را تشخیص می‌دهد، فهرست ابزارها را فیلتر می‌کند تا فقط ابزارهای دارای قابلیت‌های منطبق باقی بمانند. مدل انتخاب حتی ابزارهای نامرتبط با نوع وظیفه فعلی را نمی‌بیند.
این موضوع به دلیلی ظریف مهم است: مدل‌های زبانی تأثیرپذیرند. اگر ابزار غربالگری تحریم‌ها در زمینه باشد، مدل ممکن است تصمیم بگیرد بررسی تحریم‌ها را اجرا کند، حتی وقتی کاربر پرسشی ساده درباره مسیرهای حمل‌ونقل دارد. با حذف ابزارهای نامرتبط پیش از انتخاب، یک دسته کامل از فراخوانی‌های غیرضروری ابزار را کنار می‌گذاریم.
حلقه‌های بازخورد کیفیت
انتخاب ابزار فقط نیمی از کار است. نیم دیگر، اطمینان از این است که ابزارها نتایج مفیدی برگردانند و بدانیم وقتی چنین نمی‌کنند چه باید کرد.
پس از هر اجرای ابزار، سامانه ما کیفیت نتیجه را ارزیابی می‌کند. حالت‌های رایج شکست عبارت‌اند از:
نتایج خالی. ابزار با موفقیت اجرا شده اما داده‌ای برنگردانده است. این می‌تواند به این معنا باشد که نهاد در آن پایگاه داده وجود ندارد، که یافته‌ای معتبر و اطلاع‌رسان است، یا اینکه پرس‌وجو درست شکل نگرفته است، که مشکلی است که باید اصلاح و دوباره امتحان شود.
موارد انطباق با اطمینان پایین. جست‌وجوی تقریبی نام، نتایجی برمی‌گرداند اما امتیاز انطباق کمتر از آستانه است. سامانه باید تصمیم بگیرد آن‌ها را به‌عنوان موارد انطباق احتمالی ارائه کند یا کنار بگذارد و راهبرد جست‌وجوی دیگری را امتحان کند.
اندازه ناکافی نمونه. یک پرس‌وجوی داده تجاری فقط از یک منبع داده نتیجه برمی‌گرداند، درحالی‌که برای قابلیت اتکا باید چند منبع با یکدیگر تطبیق داده شوند. سامانه این شکاف را تشخیص می‌دهد و می‌تواند فراخوانی‌های اضافی ابزار را برای پر کردن آن فعال کند.
وقتی بررسی‌های کیفیت موفق نباشند، سامانه راهنمایی را دوباره به حلقه استدلال عامل تزریق می‌کند. این صرفاً یک تلاش مجدد نیست؛ تلاشی هدایت‌شده است که توضیح می‌دهد چه چیزی اشتباه بوده و پیشنهاد می‌کند پرس‌وجو چگونه بازنویسی شود.
ارائه تدریجی نتایج
راستی‌آزمایی انطباق تجاری ذاتاً چندمرحله‌ای است. کاربر بارنامه‌ای بارگذاری می‌کند و از عامل می‌خواهد آن را راستی‌آزمایی کند. عامل باید فرستنده را در برابر فهرست‌های تحریم بررسی کند، گواهی ارگانیک را راستی‌آزمایی کند، موقعیت فعلی کشتی را پیدا کند، هشدارهای وارداتی FDA برای کالا را بررسی کند و طبقه‌بندی تعرفه را اعتبارسنجی کند. این بررسی‌ها زمان‌های متفاوتی می‌برند.
به‌جای اینکه کاربر تا تکمیل همه بررسی‌ها برای دیدن هرگونه نتیجه منتظر بماند، نتایج را به‌تدریج ارسال می‌کنیم. به‌محض بازگشت پاسخ هر ابزار، نتایجش قالب‌بندی شده و به رابط کاربر ارائه می‌شوند. کاربر ابتدا نتایج تحریم‌ها، سپس داده‌های کشتی و سپس وضعیت گواهی ارگانیک را می‌بیند؛ هرکدام همان لحظه که آماده شوند به‌صورت کارتی ساختاریافته نمایش داده می‌شوند.
گام نهایی ترکیب نتایج، که خلاصه‌ای روایی برای مرتبط کردن همه نتایج تولید می‌کند، فقط پس از پایان کار همه ابزارها اجرا می‌شود.
راستی‌آزمایی خودکار: تکمیل چرخه
وقتی اسناد از خط پردازش OCR ما عبور می‌کنند، سامانه استخراج، داده‌های کلیدی را شناسایی می‌کند: شناسه‌های NOP، نام شرکت‌ها، شناسه‌های کشتی، شماره‌های کانتینر، کدهای بندر و کدهای HS. هر یک از این داده‌ها به ابزارهای مشخص راستی‌آزمایی نگاشت می‌شود.
به‌جای انتظار برای اینکه کاربر بگوید «این سند را راستی‌آزمایی کن»، سامانه نشانه‌های راهنمای راستی‌آزمایی را از پیش محاسبه می‌کند. وقتی کاربر گفت‌وگویی درباره سند باز می‌کند، عامل از قبل می‌داند کدام ابزارها را با چه پارامترهایی فراخوانی کند. این کار زمان رسیدن به راستی‌آزمایی را به‌شدت کاهش می‌دهد: عامل لازم نیست سند را بخواند، نهادها را شناسایی کند و سپس تشخیص دهد چه چیزهایی را بررسی کند. از قبل یک برنامه راستی‌آزمایی آماده اجرا دارد.
اصول
ساخت این سامانه چند اصل را برای ما روشن کرده است که فکر می‌کنیم کاربرد گسترده‌ای در مهندسی عامل‌های هوش مصنوعی دارند:
انتخاب را از اجرا جدا کنید. مدل استدلالی را هم‌زمان به مدل مسیریابی تبدیل نکنید. برای طبقه‌بندی از مدل‌های ارزان و سریع و برای استدلال از مدل‌های گران و توانمند استفاده کنید.
گزینه‌ها را کاهش دهید و دقت را افزایش دهید. مدلی که میان 10 ابزار متناسب انتخاب می‌کند، هر بار از مدلی که میان 100 ابزار انتخاب می‌کند بهتر عمل می‌کند. پیش از انتخاب، روی فیلتر کردن سرمایه‌گذاری کنید.
پس از اجرا اعتبارسنجی کنید، نه فقط پیش از آن. فراخوانی‌های ابزار به شکل‌هایی شکست می‌خورند که نمی‌توانید پیش‌بینی کنید. حلقه‌های بازخورد کیفیتی بسازید که نتایج نامناسب را تشخیص دهند و تلاش‌های مجدد را هدایت کنند.
نتایج را به‌تدریج ارسال کنید، نه به‌صورت یک‌جا. کاربران باید نتایج را هنگام رسیدن ببینند. ارائه تدریجی فقط بهبود تجربه کاربری نیست؛ اساساً نحوه تعامل کاربران با داده‌های راستی‌آزمایی را تغییر می‌دهد.
هدف را صریح بیان کنید. نگذارید مدل خودش استنباط کند «خوب» چه شکلی است. به آن بگویید. برنامه‌ریزی هدف، کاوش بی‌انتها را به راستی‌آزمایی هدایت‌شده تبدیل می‌کند.
عامل هوش مصنوعی Atlas Verified، تعداد 100+ ابزار تخصصی راستی‌آزمایی را هماهنگ می‌کند تا بررسی‌های انطباق تجاری در سراسر زنجیره تأمین جهانی خودکار شوند.