ایجاد لبه اطلاعات با دسترسی مکالمه به داده ها

شکل 1: نمایش جریان Text2SQL

همانطور که دنیای ما جهانی تر و پویاتر می شود، کسب و کارها برای تصمیم گیری آگاهانه، عینی و به موقع به داده ها بیشتر و بیشتر وابسته می شوند. با این حال، در حال حاضر، آزاد کردن پتانسیل کامل داده های سازمانی اغلب از امتیازات تعداد انگشت شماری از دانشمندان و تحلیلگران داده است. اکثر کارمندان به ابزارهای علوم داده معمولی (SQL، Python، R و غیره) تسلط ندارند. برای دسترسی به داده های مورد نظر، آنها از طریق یک لایه اضافی می روند که در آن تحلیلگران یا تیم های BI، نثر سوالات تجاری را به زبان داده ها "ترجمه" می کنند. پتانسیل اصطکاک و ناکارآمدی در این سفر زیاد است - برای مثال، داده‌ها ممکن است با تأخیر یا حتی زمانی که سؤال قبلاً منسوخ شده است ارائه شود. هنگامی که الزامات به طور دقیق به پرس و جوهای تحلیلی ترجمه نمی شوند، ممکن است اطلاعات در طول مسیر گم شوند. علاوه بر این، ایجاد بینش با کیفیت بالا نیاز به یک رویکرد تکراری دارد که با هر مرحله اضافی در حلقه از آن جلوگیری می شود. از طرف دیگر، این تعاملات موقتی برای استعدادهای داده های گران قیمت اختلال ایجاد می کند و آنها را از کار داده های استراتژیک تر منحرف می کند، همانطور که در این "اعترافات" یک دانشمند داده توضیح داده شده است:

وقتی من در Square بودم و تیم کوچک‌تر بود، چرخش «تحلیلی در حال تماس» وحشتناکی داشتیم. این به طور دقیق به صورت هفتگی تغییر می کرد، و اگر نوبت شما بود، می دانستید که در آن هفته کار "واقعی" بسیار کمی انجام خواهید داد و بیشتر وقت خود را صرف سوالات ویژه از تیم های مختلف محصول و عملیات می کنید. شرکت (SQL monkeying، ما آن را نامیدیم). رقابت شدیدی برای نقش‌های مدیر در تیم تحلیل وجود داشت و من فکر می‌کنم این کاملاً نتیجه معافیت مدیران از این چرخش بود - هیچ جایزه‌ای نمی‌توانست با هویج انجام ندادن کار حین کار رقابت کند.[1]

در واقع، آیا این کار جالبی نیست که به جای اینکه مجبور شوید چندین دور تعامل با کارکنان داده خود را طی کنید، مستقیماً با داده های خود صحبت کنید؟ این چشم انداز توسط رابط های مکالمه ای پذیرفته شده است که به انسان اجازه می دهد با استفاده از زبان، شهودی ترین و جهانی ترین کانال ارتباطی ما، با داده ها تعامل داشته باشد. پس از تجزیه یک سوال، یک الگوریتم آن را در یک فرم منطقی ساختاریافته در زبان پرس و جو انتخابی، مانند SQL رمزگذاری می کند. بنابراین، کاربران غیر فنی می توانند با داده های خود چت کنند و به سرعت اطلاعات خاص، مرتبط و به موقع را بدون انجام انحراف از طریق یک تیم BI به دست آورند. در این مقاله، جنبه‌های مختلف پیاده‌سازی Text2SQL را در نظر می‌گیریم و روی رویکردهای مدرن با استفاده از مدل‌های زبان بزرگ (LLM) تمرکز می‌کنیم، که بهترین عملکرد را تا کنون به دست می‌آورند (برای بررسی روی رویکردهای جایگزین، رجوع کنید به [2]). فراتر از LLM ها، خوانندگان به [3] ارجاع داده می شوند. این مقاله بر اساس "مدل ذهنی" زیر از عناصر اصلی که هنگام برنامه ریزی و ساخت یک ویژگی هوش مصنوعی باید در نظر گرفته شود، ساختار یافته است:

بیایید با پایان در ذهن شروع کنیم و ارزش را دوباره جمع بندی کنیم - چرا باید یک ویژگی Text2SQL را در محصول داده یا تجزیه و تحلیل خود ایجاد کنید. سه مزیت اصلی عبارتند از:

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

حال، سناریوهای محصولی که ممکن است Text2SQL را در نظر بگیرید چیست؟ سه تنظیمات اصلی عبارتند از:

• شما در حال ارائه یک محصول مقیاس پذیر داده/BI و می خواهند کاربران بیشتری را قادر سازند تا به داده های خود به روشی غیر فنی دسترسی داشته باشند، بنابراین هم استفاده و هم پایگاه کاربر را افزایش می دهند. به عنوان مثال، ServiceNow دارد پرس و جوهای داده را در یک پیشنهاد مکالمه بزرگتر یکپارچه می کندو آتلانتا اخیراً کاوش داده های زبان طبیعی را اعلام کرد.
• شما به دنبال ایجاد چیزی در فضای داده / هوش مصنوعی برای دموکراتیک کردن دسترسی به داده ها در شرکت ها هستید، در این صورت می توانید به طور بالقوه MVP با Text2SQL در هسته. ارائه دهندگان دوست دارند AI2SQL و Text2sql.ai در حال حاضر در حال ایجاد یک ورودی در این فضا هستند.
• شما در حال کار بر روی یک سیستم BI سفارشی و می خواهند استفاده از آن را در شرکت های فردی به حداکثر و دموکراتیزه کنند.

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

• بزرگ و در حال رشد، به طوری که Text2SQL می تواند ارزش خود را در طول زمان آشکار کند، زیرا داده ها بیشتر و بیشتر می شوند.
• با کیفیت بالا، به طوری که الگوریتم Text2SQL مجبور نباشد با نویز بیش از حد (ناسازگاری، مقادیر خالی و غیره) در داده‌ها مقابله کند. به طور کلی، داده هایی که به طور خودکار توسط برنامه ها تولید می شوند، نسبت به داده هایی که توسط انسان ایجاد و نگهداری می شوند، کیفیت و سازگاری بالاتری دارند.
• از نظر معنایی بالغ شده است برخلاف خام، به طوری که انسان ها می توانند داده ها را بر اساس مفاهیم مرکزی، روابط و معیارهایی که در مدل ذهنی آنها وجود دارد، جستجو کنند. توجه داشته باشید که بلوغ معنایی را می توان با یک مرحله تبدیل اضافی که داده های خام را با یک ساختار مفهومی مطابقت می دهد به دست آورد (به بخش "غنی سازی درخواست با اطلاعات پایگاه داده" مراجعه کنید).

در ادامه، به داده ها، الگوریتم، تجربه کاربر و همچنین الزامات غیر کاربردی مربوط به یک ویژگی Text2SQL خواهیم پرداخت. این مقاله برای مدیران محصول، طراحان UX و آن دسته از دانشمندان و مهندسان داده که در ابتدای سفر Text2SQL خود هستند، نوشته شده است. برای این افراد، نه تنها راهنمایی برای شروع، بلکه یک زمینه مشترک دانش برای بحث در مورد رابط بین محصول، فناوری و کسب و کار، از جمله مبادلات مربوطه، فراهم می کند. اگر قبلاً در اجرای خود پیشرفته تر هستید، مراجع در پایان طیف وسیعی از غواصی های عمیق را برای کاوش ارائه می دهند.

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

1 داده ها

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

1.1 قالب و ساختار داده ها

به طور معمول، یک جفت ورودی-خروجی Text2SQL خام شامل یک سؤال به زبان طبیعی و پرس و جوی SQL مربوطه است، برای مثال:

سوال: "نام و تعداد فالوورهای هر کاربر را فهرست کنید."

پرس و جو SQL:

نام، دنبال کنندگان را از user_profiles انتخاب کنید

در فضای داده های آموزشی، نگاشت بین سوالات و پرس و جوهای SQL چند به چند است:

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

مجموعه دستی داده های آموزشی برای Text2SQL به خصوص خسته کننده است. این نه تنها به تسلط بر SQL از طرف حاشیه نویس نیاز دارد، بلکه به زمان بیشتری برای هر مثال نسبت به کارهای زبانی عمومی مانند تجزیه و تحلیل احساسات و طبقه بندی متن نیاز دارد. برای اطمینان از تعداد کافی مثال‌های آموزشی، می‌توان از تقویت داده‌ها استفاده کرد - برای مثال، LLM‌ها را می‌توان برای تولید جملات برای همان سؤال استفاده کرد. [3] بررسی کامل تری از تکنیک های افزایش داده Text2SQL ارائه می دهد.

1.2 غنی سازی درخواست با اطلاعات پایگاه داده

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

• ستون ها و جداول پایگاه داده
• روابط بین جداول (کلیدهای خارجی)
• محتوای پایگاه داده

دو گزینه برای ترکیب دانش پایگاه داده وجود دارد: از یک طرف، داده های آموزشی را می توان به نمونه هایی که برای پایگاه داده خاص نوشته شده اند محدود کرد، در این صورت طرح واره مستقیماً از پرس و جوی SQL و نگاشت آن به سؤال یاد می شود. این تنظیم تک پایگاه داده امکان بهینه سازی الگوریتم را برای یک پایگاه داده و/یا شرکت فردی فراهم می کند. با این حال، هر گونه جاه طلبی برای مقیاس پذیری را از بین می برد، زیرا مدل باید برای هر مشتری یا پایگاه داده به خوبی تنظیم شود. متناوباً، در تنظیمات چند پایگاه داده، طرح پایگاه داده می تواند به عنوان بخشی از ورودی ارائه شود و به الگوریتم اجازه می دهد تا به طرحواره های پایگاه داده جدید و دیده نشده «تعمیم» کند. در حالی که اگر می‌خواهید از Text2SQL در پایگاه‌های داده مختلف استفاده کنید، قطعاً باید این رویکرد را دنبال کنید، به خاطر داشته باشید که به تلاش مهندسی سریع و قابل توجهی نیاز دارد. برای هر پایگاه داده تجاری منطقی، از جمله اطلاعات کامل در اعلان، به دلیل محدودیت‌های طول سریع، بسیار ناکارآمد و به احتمال زیاد غیرممکن خواهد بود. بنابراین، تابعی که مسئول فرمول‌بندی سریع است باید به اندازه کافی هوشمند باشد تا زیرمجموعه‌ای از اطلاعات پایگاه داده را انتخاب کند که برای یک سؤال معین «مفید» است، و این کار را برای پایگاه‌های داده بالقوه دیده نشده انجام دهد.

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

2. الگوریتم

Text2SQL یک نوع است تجزیه معنایی - نگاشت متون به نمایش های منطقی. بنابراین، الگوریتم نه تنها باید زبان طبیعی را "یاد بگیرد"، بلکه باید نمایش هدف را نیز بیاموزد - در مورد ما، SQL. به طور خاص، باید دانش زیر را کسب کند:

• نحو و معناشناسی SQL
• ساختار پایگاه داده
• درک زبان طبیعی (NLU)
• نگاشت بین زبان طبیعی و پرس و جوهای SQL ( نحوی، واژگانی و معنایی)

2.1 حل تنوع زبانی در ورودی

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

LLMهایی مانند مدل‌های GPT، T5 و CodeX به حل این چالش نزدیک‌تر و نزدیک‌تر می‌شوند. آنها با یادگیری از مقادیر زیادی متن متنوع، یاد می گیرند که با تعداد زیادی الگوهای زبانی و بی نظمی برخورد کنند. در پایان، آنها قادر به تعمیم سوالاتی هستند که علیرغم داشتن اشکال سطحی متفاوت، از نظر معنایی مشابه هستند. LLM ها را می توان خارج از جعبه (صفر شات) یا پس از تنظیم دقیق اعمال کرد. اولی، در حالی که راحت است، منجر به دقت کمتری می شود. مورد دوم به مهارت و کار بیشتری نیاز دارد، اما می تواند دقت را به میزان قابل توجهی افزایش دهد.

از نظر دقت، همانطور که انتظار می رود، بهترین مدل ها آخرین مدل های خانواده GPT از جمله مدل های CodeX هستند. در آوریل 2023، GPT-4 منجر به افزایش چشمگیر دقت بیش از 5 درصدی نسبت به حالت پیشرفته قبلی شد و به دقت 85.3 درصد (در متریک "اجرا با مقادیر") دست یافت.[4] در اردوگاه منبع باز، تلاش‌های اولیه برای حل پازل Text2SQL بر روی مدل‌های رمزگذاری خودکار مانند BERT متمرکز بود که در وظایف NLU برتری دارند. در مدل های اتورگرسیو مانند مدل T5. T6 با استفاده از یادگیری چند وظیفه ای از قبل آموزش دیده است و بنابراین به راحتی با وظایف زبانی جدید، از جمله، سازگار می شود. انواع مختلف تجزیه معنایی با این حال، مدل‌های اتورگرسیو هنگام انجام وظایف تجزیه معنایی یک نقص ذاتی دارند: آن‌ها فضای خروجی نامحدود و حفاظ معنایی دارند که خروجی‌شان را محدود کند، به این معنی که می‌توانند به طرز خیره‌کننده‌ای در رفتار خود خلاق باشند. در حالی که این چیز شگفت انگیزی برای تولید محتوای آزاد است، اما برای کارهایی مانند Text7SQL که در آن انتظار خروجی هدف محدود و ساختار یافته را داریم، آزاردهنده است.

2.2 اعتبار سنجی و بهبود پرس و جو

برای محدود کردن خروجی LLM، می‌توانیم مکانیسم‌های دیگری را برای اعتبارسنجی و بهبود پرس و جو معرفی کنیم. این می تواند به عنوان یک مرحله اعتبار سنجی اضافی، همانطور که در سیستم PICARD پیشنهاد شده است، اجرا شود.[8] PICARD از یک تجزیه کننده SQL استفاده می کند که می تواند بررسی کند که آیا یک پرس و جو SQL جزئی می تواند پس از تکمیل به یک پرس و جو SQL معتبر منجر شود یا خیر. در هر مرحله تولید توسط LLM، نشانه هایی که پرس و جو را باطل می کنند رد می شوند و نشانه های معتبر با بیشترین احتمال حفظ می شوند. با قطعیت، این رویکرد اعتبار 100٪ SQL را تا زمانی که تجزیه کننده قوانین صحیح SQL را رعایت کند تضمین می کند. همچنین اعتبار پرس و جو را از نسل جدا می کند، بنابراین امکان حفظ هر دو مؤلفه مستقل از یکدیگر و ارتقا و اصلاح LLM را فراهم می کند.

رویکرد دیگر، ترکیب دانش ساختاری و SQL به طور مستقیم در LLM است. برای مثال، Graphix [9] از لایه‌های graph-aware برای تزریق دانش ساختار یافته SQL به مدل T5 استفاده می‌کند. به دلیل ماهیت احتمالی این رویکرد، سیستم را به سمت پرس و جوهای صحیح سوگیری می کند، اما تضمینی برای موفقیت ارائه نمی دهد.

در نهایت، LLM می تواند به عنوان یک عامل چند مرحله ای استفاده شود که می تواند به طور مستقل پرس و جو را بررسی و بهبود بخشد.[10] با استفاده از چندین مرحله در یک دستور زنجیره ای فکری، می توان به عامل وظیفه داد تا صحت پرس و جوهای خود را بررسی کند و هرگونه نقص را بهبود بخشد. اگر پرس و جوی تایید شده هنوز نمی تواند اجرا شود، ردیابی استثنا SQL می تواند به عنوان یک بازخورد اضافی برای بهبود به عامل ارسال شود.

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

2.3 ارزیابی

برای ارزیابی الگوریتم Text2SQL، باید یک مجموعه داده آزمایشی (اعتبارسنجی) تولید کنیم، الگوریتم خود را روی آن اجرا کنیم و معیارهای ارزیابی مربوطه را روی نتیجه اعمال کنیم. یک مجموعه داده ساده که به داده‌های آموزش، توسعه و اعتباربخشی تقسیم می‌شود، براساس جفت‌های پرسش-پرسش است و منجر به نتایج غیربهینه می‌شود. پرس و جوهای اعتبارسنجی ممکن است در طول آموزش برای مدل آشکار شود و منجر به دید بیش از حد خوش بینانه در مورد مهارت های تعمیم آن شود. آ تقسیم مبتنی بر پرس و جو، که در آن مجموعه داده به گونه ای تقسیم می شود که هیچ درخواستی هم در حین آموزش و هم در حین اعتبار سنجی ظاهر نمی شود، نتایج واقعی تری ارائه می دهد.

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

• دقت تطابق مجموعه دقیق: پرس و جوهای SQL تولید شده و هدف به اجزای سازنده خود تقسیم می شوند و مجموعه های حاصل از نظر هویت مقایسه می شوند.[11] نقصی که در اینجا وجود دارد این است که فقط تغییرات ترتیب در پرس و جوی SQL را در نظر می گیرد، اما نه برای تفاوت های نحوی بارزتر بین پرس و جوهای معادل معنایی.
• دقت اجرا: مجموعه داده های حاصل از پرس و جوهای SQL تولید شده و هدف از نظر هویت مقایسه می شوند. با خوش شانسی، پرس و جوهایی با معنایی متفاوت همچنان می توانند این آزمون را در یک نمونه پایگاه داده خاص بگذرانند. به عنوان مثال، با فرض یک پایگاه داده که در آن همه کاربران بالای 30 سال سن دارند، دو پرس و جو زیر نتایج یکسانی را علیرغم داشتن معنایی متفاوت نشان می دهند:
  * از کاربر را انتخاب کنید
  * از کاربرانی که سن آنها > 30 سال است را انتخاب کنید
• دقت مجموعه تست: دقت مجموعه تست یک نسخه پیشرفته تر و کمتر مجاز از دقت اجرا است. برای هر پرس و جو، مجموعه ای ("مجموعه تست") از پایگاه های داده تولید می شود که با توجه به متغیرها، شرایط و مقادیر موجود در پرس و جو بسیار متمایز هستند. سپس دقت اجرا بر روی هر یک از این پایگاه‌های داده آزمایش می‌شود. در حالی که نیاز به تلاش بیشتری برای مهندسی تولید مجموعه تست دارد، این معیار همچنین به طور قابل توجهی خطر مثبت کاذب در ارزیابی را کاهش می دهد..[12]

3. تجربه کاربری

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

3.1 مدیریت شکست

Text2SQL می تواند در دو حالت شکست بخورد، که باید به روش های مختلف دستگیر شوند:

• خطاهای SQL: پرس و جو تولید شده معتبر نیست - یا SQL نامعتبر است یا به دلیل نقص واژگانی یا معنایی نمی توان آن را در برابر پایگاه داده خاص اجرا کرد. در این حالت هیچ نتیجه ای به کاربر برگردانده نمی شود.
• خطاهای معنایی: پرس و جو ایجاد شده معتبر است اما معنایی سوال را منعکس نمی کند، بنابراین منجر به یک مجموعه داده بازگشتی اشتباه می شود.

حالت دوم به ویژه دشوار است زیرا خطر "شکست های خاموش" - خطاهایی که توسط کاربر شناسایی نمی شوند - زیاد است. کاربر نمونه اولیه نه زمان و نه مهارت فنی برای تأیید صحت پرس و جو و/یا داده های حاصل را خواهد داشت. هنگامی که از داده ها برای تصمیم گیری در دنیای واقعی استفاده می شود، این نوع شکست می تواند عواقب مخربی داشته باشد. برای جلوگیری از این امر، آموزش کاربران و ایجاد آن بسیار مهم است نرده های محافظ در سطح تجاری که تأثیر بالقوه را محدود می کند، مانند بررسی داده های اضافی برای تصمیم گیری با تأثیر بیشتر. از طرف دیگر، ما همچنین می توانیم از رابط کاربری برای مدیریت تعامل انسان و ماشین استفاده کنیم و به کاربر کمک کنیم تا درخواست های مشکل دار را شناسایی و بهبود بخشد.

3.2 تعامل انسان و ماشین

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

ساده ترین و کم درگیرترین راه کار با نمرات اعتماد به نفس است. در حالی که محاسبه ساده اطمینان به عنوان میانگین احتمالات توکن های تولید شده بیش از حد ساده است، می توان از روش های پیشرفته تری مانند بازخورد شفاهی استفاده کرد. [13] اطمینان را می توان در رابط نمایش داده و با یک هشدار صریح در صورتی که به طور خطرناکی کم است برجسته شود. به این ترتیب، مسئولیت یک پیگیری مناسب در "دنیای واقعی" - اعم از رد، پذیرش یا بررسی اضافی داده ها - بر دوش کاربر شما قرار می گیرد. در حالی که این یک شرط مطمئن برای شما به عنوان یک فروشنده است، انتقال این اثر به کاربر نیز می تواند ارزش محصول شما را کاهش دهد.

امکان دوم این است که کاربر را در یک گفتگوی شفاف سازی در مورد سؤالات کم اعتماد، مبهم یا مشکوک درگیر کنید. به عنوان مثال، سیستم شما ممکن است تصحیحات املایی یا دستوری را در ورودی پیشنهاد دهد و از کلمات یا ساختارهای گرامری خاص ابهام‌زدایی کند. همچنین ممکن است به کاربر این امکان را بدهد که فعالانه درخواست اصلاحات در پرس و جو کند:[14]

کاربر: وظایف جان را در این سرعت به من نشان دهید.

دستیار: آیا دوست دارید کارهایی را که جان ساخته است یا کارهایی را که روی آنها کار می کند ببینید؟

کاربر: وظایفی که جان ایجاد کرد

دستیار: خوب، در اینجا شناسه های کار وجود دارد:

کاربر: با تشکر، من همچنین می خواهم اطلاعات بیشتری در مورد وظایف ببینم. لطفاً بر اساس فوریت نیز مرتب کنید.

دستیار: مطمئناً، در اینجا وظایف به همراه توضیحات کوتاه، مأمورین و مهلت‌ها، بر اساس مهلت مرتب شده‌اند.

در نهایت، برای سهولت درک پرس‌و‌جوها توسط کاربر، سیستم شما همچنین می‌تواند یک فرمول مجدد متنی صریح از پرس و جو ارائه کند و از کاربر بخواهد آن را تأیید یا تصحیح کند.[15]

4. الزامات غیر کاربردی

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

4.1 دقت

برای Text2SQL، الزامات مربوط به دقت بالا است. اول، Text2SQL معمولاً در تنظیمات مکالمه که پیش‌بینی‌ها یک به یک انجام می‌شوند، اعمال می‌شود. بنابراین، «قانون اعداد بزرگ» که معمولاً به تعادل خطا در پیش‌بینی‌های دسته‌ای کمک می‌کند، کمکی نمی‌کند. دوم، اعتبار نحوی و واژگانی یک شرط "سخت" است: مدل باید یک پرس و جوی SQL به خوبی شکل گرفته، به طور بالقوه با نحو و معنایی پیچیده ایجاد کند، در غیر این صورت درخواست نمی تواند در مقابل پایگاه داده اجرا شود. و اگر این به خوبی پیش برود و پرس و جو قابل اجرا باشد، همچنان می تواند حاوی خطاهای معنایی باشد و منجر به یک مجموعه داده بازگشتی اشتباه شود (به بخش 3.1 مدیریت شکست مراجعه کنید).

4.2 مقیاس پذیری

ملاحظات اصلی مقیاس پذیری این است که آیا می خواهید Text2SQL را بر روی یک یا چند پایگاه داده اعمال کنید - و در مورد دوم، اینکه آیا مجموعه پایگاه داده ها شناخته شده و بسته هستند یا خیر. اگر بله، زمان آسان تری خواهید داشت زیرا می توانید اطلاعات مربوط به این پایگاه های داده را در طول آموزش درج کنید. با این حال، در سناریویی از یک محصول مقیاس پذیر - چه یک برنامه کاربردی Text2SQL مستقل باشد یا یک ادغام در یک محصول داده موجود - الگوریتم شما باید با هر طرح پایگاه داده جدید در پرواز کنار بیاید. این سناریو همچنین به شما این فرصت را نمی دهد که ساختار پایگاه داده را تغییر دهید تا آن را برای یادگیری بصری تر کنید (لینک!). همه اینها منجر به یک مبادله سنگین با دقت می شود، که ممکن است توضیح دهد که چرا ارائه دهندگان Text2SQL فعلی که پرس و جوی موقت از پایگاه های داده جدید را ارائه می دهند، هنوز به نفوذ قابل توجهی در بازار دست پیدا نکرده اند.

سرعت 4.3

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

4.4 قابلیت توضیح و شفافیت

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

4.5 حریم خصوصی

تابع Text2SQL را می توان از اجرای پرس و جو جدا کرد، بنابراین اطلاعات پایگاه داده برگشتی را می توان نامرئی نگه داشت. با این حال، سوال مهم این است که چه مقدار اطلاعات در مورد پایگاه داده در درخواست گنجانده شده است. سه گزینه (با کاهش سطح حریم خصوصی) عبارتند از:

• بدون اطلاعات
• شمای پایگاه داده
• محتوای پایگاه داده

حریم خصوصی با دقت کاهش می یابد - هرچه در گنجاندن اطلاعات مفید در اعلان محدودیت کمتری داشته باشید، نتایج بهتری خواهید داشت.

4.6 سازگاری در طول زمان

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

نتیجه

بیایید نکات کلیدی مقاله را خلاصه کنیم:

• Text2SQL اجازه می دهد تا دسترسی بصری و دموکراتیک به داده ها را در یک تجارت پیاده سازی کند، بنابراین ارزش داده های موجود را به حداکثر می رساند.
• داده های Text2SQL شامل سوالات در ورودی و پرس و جوهای SQL در خروجی است. نگاشت بین سوالات و پرس و جوهای SQL چند به چند است.
• ارائه اطلاعات در مورد پایگاه داده به عنوان بخشی از اعلان مهم است. علاوه بر این، ساختار پایگاه داده را می توان بهینه کرد تا یادگیری و درک الگوریتم برای آن آسان تر شود.
• در ورودی، چالش اصلی، تنوع زبانی سوالات زبان طبیعی است که می‌توان با استفاده از LLMهایی که از قبل بر روی طیف گسترده‌ای از سبک‌های متنی مختلف آموزش دیده بودند، به آن نزدیک شد.
• خروجی Text2SQL باید یک درخواست SQL معتبر باشد. این محدودیت را می توان با "تزریق" دانش SQL به الگوریتم گنجاند. به طور متناوب، با استفاده از یک رویکرد تکراری، پرس و جو را می توان در چند مرحله بررسی و بهبود بخشید.
• با توجه به تأثیر بالقوه بالای «شکست‌های بی‌صدا» که داده‌های اشتباه را برای تصمیم‌گیری برمی‌گرداند، مدیریت خرابی یک نگرانی اصلی در رابط کاربری است.
• به روش "افزوده شده"، کاربران می توانند به طور فعال در اعتبارسنجی تکراری و بهبود پرس و جوهای SQL شرکت کنند. در حالی که این باعث می شود برنامه کاربردی کمتر روان باشد، همچنین میزان خرابی را کاهش می دهد، به کاربران اجازه می دهد داده ها را به روشی انعطاف پذیرتر کاوش کنند و سیگنال های ارزشمندی برای یادگیری بیشتر ایجاد می کند.
• الزامات غیر کاربردی اصلی که باید در نظر گرفته شوند عبارتند از دقت، مقیاس پذیری، سرعت، توضیح پذیری، حریم خصوصی و سازگاری در طول زمان. مبادلات اصلی بین دقت از یک سو و مقیاس پذیری، سرعت و حریم خصوصی از سوی دیگر است.

منابع

[1] کن ون هارن. 2023. جایگزینی یک تحلیلگر SQL با 26 دستور GPT بازگشتی

[2] نیترشان راجکومار و همکاران. 2022. ارزیابی قابلیت های Text-to-SQL مدل های زبان بزرگ

[3] Naihao Deng et al. 2023. پیشرفت های اخیر در Text-to-SQL: بررسی آنچه که ما داریم و آنچه انتظار داریم

[4] محمدرضا پوررضا و همکاران. 2023. DIN-SQL: یادگیری درون متنی تجزیه شده متن به SQL با خود تصحیح

[5] ویکتور ژونگ و همکاران. 2021. اقتباس پایه برای تجزیه معنایی اجرایی صفر شات

[6] شی ویکتوریا لین و همکاران. 2020. پل زدن داده های متنی و جدولی برای تجزیه معنایی متن به SQL بین دامنه ای

[7] تانگ گوو و همکاران. 2019. تولید متن به SQL مبتنی بر BERT ارتقا یافته محتوا

[8] تورستن شولاک و همکاران. 2021. PICARD: تجزیه تدریجی برای رمزگشایی خودکار رگرسیون محدود از مدل‌های زبان

[9] جین یانگ لی و همکاران. 2023. Graphix-T5: ترکیب ترانسفورماتورهای از پیش آموزش دیده با لایه های Graph-Aware برای تجزیه متن به SQL

[10] LangChain. 2023. LLM و SQL

[11] تائو یو و همکاران. 2018. عنکبوت: مجموعه داده با برچسب انسانی در مقیاس بزرگ برای تجزیه معنایی پیچیده و متقاطع و کار متن به SQL

[12] Ruiqi Zhong و همکاران. 2020. ارزیابی معنایی برای تبدیل متن به SQL با مجموعه‌های تست مقطر

[13] کاترین تیان و همکاران. 2023. فقط کالیبراسیون بخواهید: استراتژی‌هایی برای استخراج امتیازهای اعتماد کالیبره‌شده از مدل‌های زبانی که با بازخورد انسانی تنظیم شده‌اند.

[14] برادن هنکاک و همکاران. 2019. یادگیری از گفتگو پس از استقرار: خود را تغذیه کنید، چت بات!

[15] احمد الگهری و همکاران. 2020. با تجزیه کننده خود صحبت کنید: متن به SQL تعاملی با بازخورد زبان طبیعی

[16] جانا لیپنکووا. 2022. با من حرف بزن! مکالمات Text2SQL با داده های شرکت شما، در جلسه پردازش زبان طبیعی نیویورک صحبت کنید.

تمامی تصاویر توسط نویسنده است.

این مقاله در اصل در تاریخ منتشر شد به سمت علم داده و با اجازه نویسنده مجدداً در TOPBOTS منتشر شد.

از این مقاله لذت می برید؟ برای به روز رسانی های بیشتر تحقیقات هوش مصنوعی ثبت نام کنید.

زمانی که مقالات خلاصه بیشتری مانند این مقاله منتشر کنیم، به شما اطلاع خواهیم داد.

مربوط

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. خودرو / خودروهای الکتریکی، کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• BlockOffsets. نوسازی مالکیت افست زیست محیطی. دسترسی به اینجا.
• منبع: https://www.topbots.com/conversational-ai-for-data-analysis/