چگونه یک پلتفرم داده‌ای هوش مصنوعی سازمانی را بازسازی کنیم؟

این مقاله از سخنرانی نویسنده در کنفرانس معرفی محصول MIP در تاریخ 20 اکتبر استخراج شده است. در تاریخ 20 اکتبر، شرکت Jingzhou Technology کنفرانس معرفی محصول MIP را برگزار کرد و اعلام کرد که استراتژی محصول از تحلیل لحظه‌ای به یک پلتفرم تحلیل داده و هوش مصنوعی یکپارچه تغییر می‌کند و به‌طور رسمی پلتفرم داده‌ای هوش مصنوعی سازمانی MIP را معرفی کرد. MIP بر اساس فناوری StarRocks ساخته شده است و پایه داده یکپارچه، لایه معنایی سازمانی و Data Agent قابل اعتماد را به هم متصل می‌کند و با پشتیبانی از قابلیت‌های حاکمیتی در سراسر پلتفرم، به شرکت‌ها کمک می‌کند تا هوش مصنوعی را بر اساس نیازهای تجاری خود به کار ببرند و نتایج قابل بررسی و پیگیری باشند.

نویسنده|دونگ یینگ تینگ، مسئول محصولات Jingzhou Technology

تولید|صنعت‌خانه

سه سوال برای پیاده‌سازی AI Agent در سازمان

زمانی که Agent به کسب‌وکار واقعی وارد می‌شود، نمی‌تواند از مسائل داده، معیار و دانش فرار کند. با توجه به تجربیات خود، ما سه سوال نسبتاً عمومی را جمع‌بندی کرده‌ایم و در انتهای هر سوال، ایده‌های خود را نوشته‌ایم.

سوال اول: داده‌ها چندمدلی و پراکنده هستند.

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

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

سوال دوم: معیار نیاز به توضیح مکرر دارد.

به‌عنوان مثال در تحلیل داده، "چگونه فروش را محاسبه کنیم" و "کدام سفارشات در محاسبه شرکت می‌کنند" باید به‌طور واضح تعریف شوند. اما این دانش معمولاً در SQLهای تاریخی، اسناد و حتی تجربیات شخصی تحلیلگران پراکنده است. بنابراین، یک سوال مشابه ممکن است پاسخ‌های مختلفی داشته باشد.

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

سوال سوم: فرآیند ساخت تکرار زیادی دارد.

هنگام ساخت چندین Agent، با ورودی‌های داده مختلف مواجه می‌شوید و نیاز به مرتب‌سازی مجدد دانش و زمینه مرتبط وجود دارد. در صورت نیاز به اصلاح، همگام‌سازی بین Agentهای مختلف دشوار است و این منجر به ایجاد کارهای تکراری زیادی در فرآیند ساخت Agent می‌شود.

ایده ما این است: پایگاه داده باید قابلیت مدیریت زمینه‌های سازمانی قابل استفاده مجدد را داشته باشد و توسط MirrorMind دانش و ارتباطات، نسخه‌ها و مجوزهای دسترسی را به‌طور یکپارچه سازماندهی کند تا چندین Agent به‌طور نیازمند از آن استفاده کنند؛ وضعیت جلسات و وظایف توسط MirrorPilot مدیریت می‌شود.

این سه سوال به یک ریشه اشاره دارند: داده، معیار و زمینه، که فاقد یک حامل یکپارچه هستند.

در تاریخ 20 اکتبر، در کنفرانس معرفی محصول Jingzhou Technology، ما به‌طور رسمی MIP را معرفی کردیم------پلتفرم داده‌ای هوش مصنوعی سازمانی یکپارچه و سریع. با تمرکز بر پایگاه داده، طراحی معماری آن در دو جهت گسترش می‌یابد: به سمت پایین: افزودن قابلیت‌های هوش مصنوعی به پایگاه داده، ارتقاء پایه داده؛ به سمت بالا: پایگاه داده برای هوش مصنوعی، به‌طوری که دانش و قابلیت‌های Agent هوش مصنوعی سازمان، به کسب‌وکارهای بیشتری خدمت کند.

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

معماری سه‌لایه: MIP داده‌ها و دانش را به قابلیت‌های مشترک سازماندهی می‌کند

MIP داده‌ها و دانش سازمان را به سه لایه سازماندهی می‌کند و یک مجموعه قابلیت مشترک تشکیل می‌دهد.

لایه پایینی MirrorData است، که یک موتور جستجوی داده‌ای سازمانی با هسته StarRocks منبع باز است و قابلیت جستجوی سریع و تحلیل چندمدلی را ارائه می‌دهد.

لایه میانی MirrorMind است، که با تمرکز بر Semantic View، دانش تجاری مربوطه و تجربیات شخصی تحلیلگران را به هم مرتبط می‌کند تا به‌طور نیازمند توسط Agent استفاده شود.

لایه بالایی MirrorPilot است، که محیط اجرایی Agentهای تجاری است.

بالای این سه لایه، انواع برنامه‌های تجاری وجود دارد. تحلیل‌های تجاری، تشخیص پس از فروش و انتخاب محصولات که در مدیریت سازمان معمولاً استفاده می‌شوند، می‌توانند با استفاده از این پایگاه یکپارچه ساخته شوند.

فصل‌های بعدی به‌طور لایه‌ای این سه لایه را گسترش می‌دهند و نحوه استفاده از کل پایگاه را نمایش می‌دهند.

• با استفاده از "تصاویر پس از فروش" جستجوی چندمدلی MirrorData و ارتباط تجاری را نمایش دهید

• با استفاده از "مقایسه بودجه فعالیت" نقش تعریف معنایی در MirrorMind را توضیح دهید

• با استفاده از "تحلیل تجاری خرده‌فروشی" فرآیند کامل استفاده از پیکربندی، جستجو، تحلیل و گزارش را به هم متصل کنید.

MirrorData: پایگاه داده یکپارچه

دسترسی استاندارد SQL، یک مجموعه قابلیت محاسباتی برای تمام برنامه‌ها

MirrorData پایگاه داده MIP است و هسته آن یک موتور جستجو است.

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

موتور جستجو قابلیت‌های جستجوی با عملکرد بالا StarRocks را ادامه می‌دهد. بر این اساس، ما تقویت‌های سازمانی را انجام داده‌ایم: مدیریت مجوزها، کنترل منابع و جداسازی منابع.

دسترسی یکپارچه به جداول داخلی، جداول دریاچه و محتوای چندمدلی

دسترسی به داده‌ها از سه طریق انجام می‌شود.

1. جداول داخلی سنتی. جداول داخلی شامل فیلدهای تجاری، JSON، متن و داده‌های برداری قابل جستجو هستند؛ برای تصاویر، اسناد و محتوای مشابه، می‌توان از طریق ارجاع فایل و شناسه شیء تجاری، ارتباط با نمایه‌های مشتق و سوابق تجاری برقرار کرد.

2. داده‌های دریاچه. بسیاری از داده‌های مشتریان در دریاچه داده‌ها ذخیره شده‌اند. MirrorData از طریق Catalog خارجی به‌طور یکپارچه متصل می‌شود و از فرمت‌های اصلی جداول دریاچه مانند Paimon، Iceberg و Hive پشتیبانی می‌کند و قابلیت دسترسی به جداول دریاچه را به‌طور کارآمد فراهم می‌کند.

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

یک SQL، جستجوی ترکیبی را کامل می‌کند

بر اساس تحلیل سریع و جستجوی دریاچه داده‌ها، MirrorData جستجوی چندمدلی و تحلیل ارتباطی را بیشتر گسترش می‌دهد. یک شیء تجاری می‌تواند به‌طور همزمان دارای فیلدهای ساختاری، ویژگی‌های JSON، متن، Embedding و ارجاعات فایل باشد و از طریق شناسه شیء تجاری محتوا و واقعیت تجاری را متصل کند تا نتایج جستجو بتوانند به‌طور ادامه‌دار در تحلیل شرکت کنند.

پایه سه نوع قابلیت جستجو است:

• داده‌های ساختاری: با ترکیب برش‌های تقسیم‌بندی و اسکن ستونی، تحلیل سریع را کامل می‌کند.

• جستجوی متنی: بر اساس ایندکس معکوس برای تطابق واژه‌ها، به‌عنوان مثال با استفاده از MATCH_ANY برای تطابق رکوردهایی که شامل "باز کردن جعبه" یا "باز کردن" هستند.

• جستجوی برداری: بر اساس شباهت یا فاصله، محتوای مرتبط را جستجو می‌کند.

یک SQL می‌تواند این سه را به هم متصل کند و مسیر دسترسی خاص بستگی به روش جستجو و روش ایندکس دارد.

نمایش: جستجوی سفارشات پس از فروش

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

ابتدا عکس مرجع به یک بردار جستجو تبدیل می‌شود و به‌عنوان پارامتر برای SQL جستجو استفاده می‌شود. سپس در SQL، شباهت تصاویر محاسبه می‌شود و از طریق ارتباط بین سفارشات و جزئیات سفارش، اطلاعات دسته، حمل‌کننده و بازپرداخت تکمیل می‌شود و زمان، دسته و شرایط متنی "باز کردن جعبه/باز کردن" اضافه می‌شود.

این شرایط در نهایت یک SQL کامل را تشکیل می‌دهند. به عبارت دیگر، یک SQL می‌تواند جستجوی یکپارچه داده‌های ساختاری و غیرساختاری را کامل کند.

جستجوی تصاویر سفارش

MirrorMind: اجازه دهید Agent با معیار درست کار کند

پس از اینکه داده‌ها قابل جستجو شدند، مرحله بعدی: Agent باید تعاریف تجاری و دانش زمینه‌ای شرکت را درک کند. MirrorMind با تمرکز بر Semantic View، این مشکل را حل می‌کند.

برای اطلاعات بیشتر، می‌توانید مقالات سری Semantic View را مطالعه کنید

• تحلیل فنی Semantic View (یک)

• تحلیل فنی Semantic View (دو)

• تحلیل فنی Semantic View (سه)

چه چیزی در Semantic View تعریف می‌شود

Semantic View تعاریف ساختاری مورد نیاز Agent برای درک کسب‌وکار را ثبت می‌کند، از جمله:

• جداول و ارتباطات: دامنه جداول داده و ارتباطات بین جداول را تعریف می‌کند.

• ابعاد: معیارها می‌توانند بر اساس چه ابعادی بالا و پایین بروند. به‌عنوان مثال، بودجه فعالیت می‌تواند بر اساس کانال، نوع فعالیت تقسیم‌بندی شود یا بر اساس تاریخ جمع‌آوری شود.

• معیارها: عبارات و توضیحات محاسبات هر معیار. علاوه بر معیارهای اتمی، می‌توان معیارهای مشتق و منطق محاسبات پیچیده مانند توابع پنجره‌ای را نیز تعریف کرد.

• مترادف‌ها: برای معیارها نام‌های تجاری، نام‌های مستعار و توضیحات را نگهداری می‌کند، به‌عنوان مثال "کل بودجه بازار" و "کل مبلغ یارانه تبلیغاتی". Agent می‌تواند با ترکیب این تعاریف، معیارهای مورد نظر کاربر را شناسایی کند و تفاوت‌های درک ناشی از عادات بیان مختلف را کاهش دهد.

Agent یک سوال را دریافت می‌کند، ابتدا در Semantic View تعاریف مناسب را پیدا می‌کند و سپس بر اساس این معیار به عبارات اجرایی تبدیل می‌کند و به پایگاه داده ارسال می‌کند.

مقایسه: آیا Semantic View وجود دارد؟

با استفاده از یک سوال مشابه برای مقایسه: "بودجه فعالیت شرکت چقدر است؟"

زمانی که Semantic View وجود ندارد، Agent به‌طور مستقیم به جداول پایینی جستجو می‌کند. در جدول چهار فیلد مبلغ وجود دارد، Agent نمی‌فهمد کدام یک بودجه فعالیت است، بنابراین تمام فیلدهای مبلغ را جمع می‌کند و به حدود 29,161,800 یوان می‌رسد. این نتیجه نادرست است و فیلدهای نامربوط نیز در آن محاسبه شده‌اند.

در نمایش استفاده از campaign_analytics، "بودجه کل فعالیت" معادل total_bbbb_amount است و عبارت محاسباتی آن SUM(bbbb_amount) می‌باشد. عامل (Agent) پس از خواندن این تعریف، فیلدهای مربوطه را جمع می‌کند و به مقدار 1,980,000 یوان می‌رسد؛ بدون اینکه سایر فیلدهای مبلغ را اضافه کند. در ویدیو، در نهایت SQL پایگاه داده اجرا می‌شود و Semantic View مبنای انتخاب و محاسبه شاخص‌ها را فراهم می‌کند.

Semantic View نام‌های تجاری، فرمول‌های شاخص و ابعاد تحلیلی را به صورت تعاریف قابل استفاده مجدد سازماندهی می‌کند، به طوری که عوامل مختلف از مبنای محاسبات مشترکی استفاده کنند و انحرافات ناشی از تفسیرهای مختلف فیلدها و مسیرهای اتصال را کاهش دهند. نتایج جستجو می‌تواند با تعاریف شاخص و SQL اجرایی بررسی شود.

مثال: دامنه سفارشات مشتریان خرده‌فروشی

به عنوان مثال، در تحلیل سفارشات یک مشتری خرده‌فروشی. در دامنه سفارشات، ابتدا باید بین سفارش و جزئیات سفارش تمایز قائل شد. یک سفارش ممکن است شامل چندین جزئیات محصول باشد و آمار این دو از نظر دقت یکسان نیست. Semantic View موضوعات تجاری را بر اساس سفارش و جزئیات محصول ایجاد می‌کند:

• تعریف موضوع سفارش "تعداد سفارشات" و "نرخ لغو"، بر اساس فروشگاه و ماه تحلیل می‌شود؛
• تعریف موضوع جزئیات فروش "مبلغ واقعی پس از تخفیف"، بر اساس کانال، دسته‌بندی و محصول تحلیل می‌شود.

مرزهای آماری دو موضوع نیز در تعریف مشخص شده است: آمار فروش شامل سفارشات پرداخت شده است و از مبلغ واقعی پس از تخفیف موضوع جزئیات فروش استفاده می‌کند؛ نرخ لغو برابر با تعداد سفارشات لغو شده تقسیم بر تعداد کل سفارشات است.

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

مدیریت دانش به مانند مدیریت کد

زمینه‌ای که عامل به آن نیاز دارد، تنها شامل یک Semantic View نیست. به عنوان مثال، برای تحلیل یک تغییر شاخص، معمولاً باید دانش تجاری و فرآیندهای تحلیلی استاندارد را نیز مرتبط کرد. ما این را به عنوان زمینه شرکتی می‌نامیم. MirrorMind این زمینه‌ها را به طور مرکزی مدیریت می‌کند: ارتباطات محتوا، منابع و نسخه‌ها، مجوزهای دسترسی.

روش مدیریت شبیه به کد است، ما از ایده Git الهام گرفته‌ایم: دانش می‌تواند شاخه‌هایی ایجاد کند و هر شاخه نسخه‌های مختلفی داشته باشد؛ می‌توان به نسخه‌ها بازگشت و هر نسخه را در یک زمان خاص مشاهده کرد؛ پس از تأیید تجاری، نسخه صحیح دوباره به کار گرفته می‌شود. کسب‌وکار در حال تکرار است و دانش نیز در حال تکرار است، اما هر عامل نسخه‌ای را دریافت می‌کند که تأیید شده و به کار گرفته شده است. بازخورد کاربران یک رکورد کامل از trace را به جا می‌گذارد که ورودی برای دور بعدی تکرار دانش می‌شود.

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

MirrorPilot: محیط اجرای عامل و تحویل

داده‌ها قابل جستجو هستند، معیارها قابل اعتماد هستند و آخرین مرحله این است که آن‌ها را به صورت یک عامل سازماندهی کرده و به کسب‌وکار تحویل دهیم. این وظیفه MirrorPilot است. این محیط اجرای عامل و تحویل در شرکت است که MirrorData و MirrorMind را به هم متصل می‌کند و نتایج را به بیرون تحویل می‌دهد.

چهار مرحله برای انجام یک وظیفه

در سمت کاربر دو مسیر برای صدور وظیفه وجود دارد. یکی گفتگوی مستقیم است که از طریق میز کار محصول تحلیل انجام می‌شود؛ دیگری از طریق API به سیستم‌های تجاری موجود متصل می‌شود و از قابلیت‌های عامل استفاده می‌کند.

اجرای یک وظیفه به چهار مرحله تقسیم می‌شود. ابتدا هدف را درک کنید؛ سپس با توجه به زمینه و مهارت‌های موجود، برنامه اجرایی را سازماندهی کنید؛ سپس ابزارهایی را فراخوانی کنید، مانند جستجوی تعریف خاص در Semantic View؛ و در نهایت نتایج را پردازش کنید. وظایف ساده در اینجا مستقیماً تحویل داده می‌شوند، در حالی که وظایف پیچیده ممکن است نیاز به جستجوهای مکرر و اجرای چند مرحله‌ای داشته باشند و سپس نتایج نهایی را به کسب‌وکار بازگردانند.

MirrorMind بر اساس نیازهای وظیفه زمینه را فراهم می‌کند و MirrorData مسئول جستجو و تأیید نتایج است. در اطراف خود اجرا نیز یک مجموعه کامل از مدیریت‌های جانبی وجود دارد: مدیریت جلسه، وضعیت وظیفه، دامنه منابع، بودجه، زمان‌های اضافی و سوابق اجرایی، که همه در MirrorPilot گنجانده شده‌اند.

تحویل تنها پاسخ نیست

تحویل MirrorPilot می‌تواند یک پاسخ باشد یا می‌تواند گزارشی و API باشد. فرآیند اجرا به دقت ثبت می‌شود: این محاسبه از کدام SQL استفاده کرده است، قوانین معیار چیست، همه به وضوح قابل جستجو هستند. کاربران می‌توانند ادامه دهند و سوالات بیشتری بپرسند یا به کل وظیفه بازگردند.

دسترسی باز، رسوب قابلیت‌ها

دسترسی باز است. MirrorPilot API عامل را ارائه می‌دهد و شرکت‌ها می‌توانند از BI موجود، درگاه‌های تجاری یا سیستم‌های تجاری برای صدور وظیفه استفاده کنند و پس از تأیید اعتبار از سمت سرور، نتایج وظیفه یا لینک جلسه را دریافت کنند و با روش‌های تعامل موجود در برنامه‌های خود یکپارچه‌سازی کنند. مهارت‌های سفارشی برای گسترش مراحل تحلیلی استفاده می‌شوند و MCP برای اتصال به ابزارهای خارجی استفاده می‌شود.

قابلیت‌ها می‌توانند رسوب کنند. منطق تحلیلی موجود می‌تواند به عنوان الگوهای SQL رسوب کند و مسائل مشابه بر اساس زمان، ابعاد و سایر پارامترها از منطق جستجو استفاده کنند و پس از اجرا نتایج را بازگردانند و کار تولید مجدد جستجو را کاهش دهند. دانش تجاری، الگوهای SQL و مهارت‌ها می‌توانند به طور مداوم مورد استفاده مجدد و تکرار قرار گیرند و همچنین از اتصال و مدیریت مهارت‌های سفارشی پشتیبانی می‌کنند.

بنابراین، MirrorPilot می‌تواند به طور مستقل اجرا شود و همچنین می‌تواند به برنامه‌های موجود در شرکت متصل شود و به تدریج قابلیت‌های تحلیلی را گسترش دهد.

MirrorControl: پنل مدیریت کنترل مرتبط

همراه با MirrorPilot، پنل مدیریت کنترل MirrorControl وجود دارد.

هنگام پیکربندی عامل، در اینجا دامنه داده، پایگاه دانش و Semantic View و مهارت‌های مورد نیاز انتخاب می‌شود. همچنین قابلیت جستجوی دانش را فراهم می‌کند، به عنوان مثال "نرخ لغو در داخل شرکت چگونه تعریف شده است"، با وارد کردن سوال می‌توان تعریف و راهنمایی را دریافت کرد.

مثال: یک عامل تحلیل کسب‌وکار مشتری خرده‌فروشی

در نهایت با یک مورد حساس، سه لایه را به هم متصل می‌کنیم: یک مشتری از MIP برای پیکربندی عامل تحلیل کسب‌وکار خود استفاده کرده است.

پیکربندی: ابتدا دامنه را مشخص کنید

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

سپس پیکربندی نقش‌ها، قوانین پاسخ و مهارت‌ها انجام می‌شود. به عنوان مثال، در زمان پیگیری و کاوش، چه فرآیند استانداردی باید دنبال شود و گزارش‌ها با چه شکلی باید خروجی داده شوند، همه در اینجا تعریف می‌شوند. ابزارهای جستجو و بازیابی درون عامل گنجانده شده‌اند و می‌توانند به طور مستقیم دانش داخلی شرکت و Semantic View را جستجو کنند.

نمایش: از یک سوال تا یک گزارش

پس از اتمام پیکربندی، یک فرآیند کامل استفاده را مشاهده می‌کنیم.

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

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

سپس سوال می‌پرسیم: "آیا این شاخص نرمال است؟ آیا تفکیک بر اساس بخش منطقی است؟" عامل فرآیندهای استاندارد و SOP موجود در زمینه شرکتی را فراخوانی می‌کند، به عنوان مثال برای شناسایی انحراف در نرخ لغو سفارشات. قوانین تعیین انحراف و روش‌های تحلیلی توسط MirrorMind به عنوان زمینه شرکتی به طور مرکزی مدیریت می‌شوند، و MirrorPilot در وظیفه اطلاعات مرتبط را می‌خواند، مراحل را سازماندهی می‌کند و از MirrorData برای اجرای جستجو استفاده می‌کند.

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

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

ویدیو نمایش

بازگشت به سه سوال ابتدایی

MirrorData اجازه می‌دهد نتایج جستجو همچنان در ارتباط با SQL و تحلیل شرکت کنند؛ MirrorMind به طور متمرکز معیارهای تجاری و دانش شرکتی را نگهداری می‌کند تا چندین عامل از تعاریف و مبانی مشترک استفاده کنند؛ MirrorPilot داده‌ها، Context و روش‌های تحلیلی را به وظایف تجاری سازماندهی می‌کند و پاسخ‌ها و گزارش‌های قابل بررسی و قابل ردیابی را تحویل می‌دهد.

این سه سوال بر روی یک پایه مشترک قرار دارند و این پایه MIP است.

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