Text-to-SQL ត្រូវបានគេសន្មត់ថាជាកម្មវិធីឃាតកររបស់ AI ។ វាមិនមែនទេ។

ក្នុង​ភាព​ក្ដៅ​គគុក​នៃ​ការ​ឆ្កួត ChatGPT ដំបូង ខ្ញុំ​បាន​ទទួល​អត្ថបទ​ពី​អតីត​មិត្ត​រួម​ការងារ។ គាត់ចង់ដំណើរការគំនិតមួយដោយខ្ញុំ។ តែងតែជាមនុស្សម្នាក់ដែលរីករាយនឹងការបំផុសគំនិត ពួកយើងបានហៅទូរសព្ទមួយ ហើយគាត់ចាប់ផ្តើមដោយ "ចងចាំពីរបៀបដែលអ្នកតែងតែសុំឱ្យខ្ញុំទាញទិន្នន័យសម្រាប់អ្នក? ចុះបើអ្នកអាចធ្វើបានដោយខ្លួនឯង? ហើយបន្ទាប់មកគាត់បន្តផ្តល់គំនិតដល់ខ្ញុំដែលមនុស្សរាប់ពាន់នាក់ (រាប់ម៉ឺននាក់?) នៃមនុស្សផ្សេងទៀតកំពុងគិតក្នុងពេលតែមួយ: LLMs អាចត្រូវបានប្រើសម្រាប់អត្ថបទទៅ SQL ដើម្បីជួយអ្នកបច្ចេកទេសតិចឆ្លើយសំណួរទិន្នន័យផ្ទាល់ខ្លួនរបស់ពួកគេ។

ខ្ញុំ​ជាប់​នឹង​គំនិត​នេះ ប៉ុន្តែ​មុន​នឹង​ឈាន​ដល់​ក្បាល​មុន ខ្ញុំ​បាន​ប្រាប់ Lei (ឥឡូវ CTO របស់​ខ្ញុំ) ថា​យើង​ត្រូវ​តែ​ធ្វើ​ការ​បញ្ជាក់​ខ្លះ។ យើងបានទាក់ទងមិត្តភ័ក្តិ និងអតីតមិត្តរួមការងារមកពីឧស្សាហកម្មផ្សេងៗ។ មានចំណាប់អារម្មណ៍យ៉ាងខ្លាំងចំពោះ "ការវិភាគសេវាកម្មខ្លួនឯង" ពិតប្រាកដ។ យើង​បាន​ដឹង​ថា វា​នឹង​មាន​ភាព​ស្មុគស្មាញ​ច្រើន​ជាង​វា​ហាក់​ដូច​ជា ប៉ុន្តែ​ឱកាស​មាន​អារម្មណ៍​ល្អ​ពេក​ក្នុង​ការ​រំលង។ ដូច្នេះ Lei និង​ខ្ញុំ​បាន​ចាក​ចេញ​ពី The Shire ហើយ​ចាប់ផ្តើម​ដំណើរ​របស់​យើង​ដើម្បី​បង្កើត​ចក្ខុវិស័យ​របស់​យើង៖ Fabi.ai .

ការបង្ហោះនេះមិននិយាយអំពីផលិតផលរបស់យើងផ្ទាល់ទេ (ទោះបីជាអ្នកចង់ដឹងចង់ឃើញ អ្នកអាចអានបន្ថែមអំពីរបៀបដែលគំនិតមួយចំនួនខាងក្រោមបានជូនដំណឹងដល់ផលិតផលថ្មីៗរបស់យើង នៅទីនេះ ) ជំនួសមកវិញ ខ្ញុំចង់ចែករំលែកការរៀនសូត្រស្នូលដែលយើងបានប្រមូលបានពីការធ្វើការជាមួយ LLMs សម្រាប់ការវិភាគទិន្នន័យតាមដំណើររបស់យើង។

ចំណាំ៖ ដំណើរ​នេះ​ខ្វះ​អ្នក​ជំនួយការ និង​ការ​ប្រយុទ្ធ​នៅ​មជ្ឈិម​ភព​ផែនដី​យ៉ាង​វេទនា។ 🧙

ហេតុអ្វីត្រូវប្រើ AI សម្រាប់ការវិភាគសេវាកម្មខ្លួនឯង?

យើងនឹងមិនរង់ចាំ "ហេតុអ្វី" យូរពេកទេ។ ប្រសិនបើអ្នកកំពុងអាននេះ អ្នកទំនងជាធ្លាក់ចូលទៅក្នុងក្រុមមួយក្នុងចំណោមពីរក្រុម៖

1. អ្នកគឺជាមនុស្សម្នាក់ដែលប្រាថ្នាឱ្យអ្នកមានការវិភាគលើសេវាកម្មខ្លួនឯង ហើយមិនចង់ឱ្យត្រូវរង់ចាំក្រុមទិន្នន័យរបស់អ្នកជានិច្ច
2. អ្នកស្ថិតនៅក្នុងក្រុមទិន្នន័យ ហើយបាននិងកំពុងឮអំពីរបៀបដែល AI នឹងអាចជួយអ្នកដោះស្រាយបញ្ហាសំណើរសុំផ្សព្វផ្សាយរបស់អ្នក។

ដោយព្រងើយកន្តើយនឹងការព្រួយបារម្ភចំពោះតួនាទីរបស់អ្នកវិភាគទិន្នន័យ និងអ្នកវិទ្យាសាស្ត្រ គំនិតនៃ AI ដែលដឹងគ្រប់បែបយ៉ាង ដែលអាចឆ្លើយសំណួរណាមួយអំពីទិន្នន័យរបស់ស្ថាប័នមួយ ស្តាប់ទៅល្អណាស់។ ឬយ៉ាងហោចណាស់ វាស្តាប់ទៅល្អសម្រាប់ស្ថាប័ន និងអ្នកដឹកនាំអាជីវកម្មរបស់ខ្លួន ដែលគំនិតច្នៃប្រឌិតសម្រាប់វិធីថ្មីនៃការសួរសំណួរមិនដឹងព្រំដែន។ AI នេះអាចជាដំណោះស្រាយក្នុងការបង្កើតអង្គការ "ជំរុញដោយទិន្នន័យ" ដែលអ្នកដឹកនាំគ្រប់រូបពឹងផ្អែកលើភស្តុតាងជាក់ស្តែងដើម្បីធ្វើការសម្រេចចិត្តជាយុទ្ធសាស្ត្ររបស់ពួកគេ។ ហើយទាំងអស់នៅប្រភាគនៃការចំណាយដែលជាធម្មតាត្រូវចំណាយ។ ទីបំផុត! អង្គការអាចទាញយកប្រយោជន៍ពី "ប្រេងថ្មី" ដែលពួកគេបានឮតាំងពីឆ្នាំ 2010 ។

ប៉ុន្តែប្រសិនបើនេះជាបញ្ហាដ៏មានតម្លៃក្នុងការដោះស្រាយ ហើយ AI ទទួលបានលទ្ធផលល្អ ហេតុអ្វីបានជាគ្មានផលិតផលណាមួយ អាច ដោះស្រាយវាបាន?

ហេតុអ្វីបានជា AI សម្រាប់ការវិភាគសេវាកម្មខ្លួនឯងបានបរាជ័យរហូតមកដល់ពេលនេះ

ការស្ទង់មតិក្នុងឧស្សាហកម្មថ្មីៗនេះបានគូររូបភាពស្មុគស្មាញនៃការទទួលយក AI នៅក្នុងសហគ្រាស។ 61 ភាគរយនៃក្រុមហ៊ុន កំពុងសាកល្បងភ្នាក់ងារ AI ។ ទោះយ៉ាងណាក៏ដោយ មនុស្សជាច្រើនព្រួយបារម្ភអំពីភាពជឿជាក់ និងសុវត្ថិភាព។ តាមពិត ២១% នៃអង្គការមិនប្រើវាទាល់តែសោះ។ ការស្ទាក់ស្ទើរទាំងនេះត្រូវបានទទួលអារម្មណ៍យ៉ាងខ្លាំងជាពិសេសនៅក្នុងក្រុមទិន្នន័យ ដែលភាពត្រឹមត្រូវ និងភាពជឿជាក់ គឺជាបេសកកម្មដ៏សំខាន់ចំពោះសមត្ថភាពរបស់យើងក្នុងការធ្វើការងារ។

អ្នកទទួលយក AI ជាពិសេសនៅក្នុងសហគ្រាសមានរបារខ្ពស់នៅពេលនិយាយអំពីការរំពឹងទុកនៃបច្ចេកវិទ្យា។ នៅក្នុងបរិបទនៃការវិភាគទិន្នន័យ និងក្តីសុបិននៃការបម្រើដោយខ្លួនឯង យើងរំពឹងថាឧបករណ៍ AI របស់យើងគឺ៖

1. ផ្តល់ការយល់ដឹង៖ តារាង និងគំនូសតាងគឺអស្ចារ្យណាស់ ប៉ុន្តែទាំងនេះគឺជាសំណុំរងនៃអ្វីដែលគេហៅថា "ការយល់ដឹង"។ ការយល់ដឹងគឺ "អាហា!" គ្រា​ដែល​មក​ពី​ការ​ប្រទះ​ឃើញ​វត្ថុ​នៅ​ក្នុង​ទិន្នន័យ​របស់​អ្នក​ដែល​ប្រឆាំង​នឹង​វិចារណញាណ​របស់​អ្នក ហើយ​នឹង​មិន​បាន​ពិចារណា​ផ្សេង​ទៀត​ទេ។ ពេលខ្លះ SQL query ឬ pivot អាចបញ្ចេញពន្លឺលើការយល់ដឹងទាំងនេះ ប៉ុន្តែជាទូទៅវាមានអារម្មណ៍ដូចជាការស្វែងរកម្ជុលនៅក្នុងវាលស្មៅ។
2. ធ្វើការដែលអាចទុកចិត្តបានជិត 100% នៃពេលវេលា៖ រឿងតែមួយគត់ដែលអាក្រក់ជាងគ្មានទិន្នន័យគឺទិន្នន័យអាក្រក់។ ប្រសិនបើ AI មិន​អាច​ជឿ​ទុក​ចិត្ត​បាន ឬ​បំភ័ន្ត​ចម្លើយ និង​ទិន្នន័យ នោះ​ជា​ដំណឹង​អាក្រក់​សម្រាប់​អ្នក​រាល់​គ្នា។ នេះមានន័យថានៅពេលដែល AI មានទិន្នន័យ វាគួរតែប្រើវាឱ្យបានត្រឹមត្រូវ។ ប៉ុន្តែនៅពេលដែលវាខ្វះទិន្នន័យ វាគួរតែជៀសវាងការផ្តល់ចម្លើយ (អ្វីមួយដែល LLMs មានកេរ្តិ៍ឈ្មោះមិនល្អ)។
3. អាចចូលទៅប្រើប្រាស់ឈុតជំនាញបច្ចេកទេសជាច្រើន៖ ភាពស្រស់ស្អាតនៃ LLMs គឺថាអ្នកអាចប្រាស្រ័យទាក់ទងជាមួយពួកគេដូចដែលអ្នកចង់បានជាមួយមិត្តរួមការងារជាង Slack ។ អ្នកអាចប្រើភាសាមិនច្បាស់លាស់។ បុគ្គល ឬវត្ថុផ្សេងទៀតអាចយល់អំពីសំណើរបស់អ្នកនៅក្នុងបរិបទអាជីវកម្ម។ ផ្ទុយទៅវិញ ប្រព័ន្ធតម្រូវឱ្យប្រើប្រាស់ពាក្យជាក់លាក់ក្នុងទម្រង់ជាក់លាក់មួយ នោះប្រព័ន្ធកាន់តែអាចចូលដំណើរការបានកាន់តែតិច។ ប្រព័ន្ធ​ប្រភេទ​នេះ​ទាមទារ​ការ​បណ្តុះបណ្តាល និង​ការ​ពង្រឹង ដែល​យើង​ដឹង​ថា​អាច​ជា​បញ្ហា​ប្រឈម។

គួរឱ្យស្តាយ ដំណោះស្រាយបច្ចុប្បន្នភាគច្រើនប្រើក្របខ័ណ្ឌ AI បែបប្រពៃណី ដែលជារឿយៗមិនបំពេញតាមការរំពឹងទុក។ ប៉ុន្មានឆ្នាំចុងក្រោយនេះ ក្រុមការងារ Fabi.ai និងខ្ញុំបានធ្វើការយ៉ាងលំបាកលើបញ្ហានេះ។ យើងបានបង្កើតគំរូដើមសម្រាប់សហគ្រាស និងស្វែងរកជម្រើសជាច្រើន។ នៅទីបញ្ចប់ យើងបានដឹងថា ទាំង Retrieval Augment Generation (RAG) ឬការលៃតម្រូវការផាកពិន័យមិនអាចដោះស្រាយបញ្ហានេះជាមួយនឹងក្របខ័ណ្ឌ monolithic បច្ចុប្បន្នបានទេ។

នៅពេល​យើង​សាកល្បង​វិធីសាស្ត្រ​នេះ រឿង​មួយ​ចំនួន​បាន​ច្បាស់​សម្រាប់​យើង៖

• RAG មានភាពផុយស្រួយ។ បរិបទតិចតួចពេក ហើយ AI មិនអាចឆ្លើយសំណួរ និងប្រថុយប្រថានធ្វើឱ្យមានការយល់ច្រលំ។ បរិបទច្រើនពេក ហើយ AI មានភាពច្របូកច្របល់ និងបាត់បង់ភាពត្រឹមត្រូវរបស់វា។
• AI បាញ់តែមួយដងមិននាំអ្នកទៅណាទេ។ AI ដ៏ល្អបំផុតនៅក្នុងពិភពលោកនឹងមិនអាចទាញ និងវិភាគទិន្នន័យបានត្រឹមត្រូវក្នុងការថតតែមួយនោះទេ។ មាន nuances ច្រើនពេកនៅក្នុងទិន្នន័យ និងសំណួរ។ ចូរយើងយកឧទាហរណ៍ដ៏សាមញ្ញបំផុតដែលអាចធ្វើទៅបាន៖ អ្នកមានវាល "ប្រភេទគណនី" ដែលមានចំនួន 95% ដែលមានតម្លៃ 10 ផ្សេងគ្នា។ ប្រសិនបើអ្នកស្នើឱ្យ AI ត្រងលើសំណុំនៃប្រភេទគណនី វាអាចនឹងបរាជ័យក្នុងការទទួលស្គាល់ថាមានតម្លៃទទេ ដូច្នេះបង្កើតសំណួរ SQL ដែលមិនត្រឹមត្រូវ។ "ប្រាកដណាស់" អ្នកអាចនិយាយថា "ប៉ុន្តែយើងអាចគណនាស្ថិតិសម្រាប់វាលនីមួយៗ និងតម្លៃគំរូ ហើយរក្សាទុកវានៅក្នុងហាងវ៉ិចទ័របរិបទរបស់យើង។" ប្រភេទ​នៃ​បញ្ហា​គឺ​ស្ទើរតែ​គ្មាន​ដែន​កំណត់ ហើយ​ទាំងអស់​មាន​លក្ខណៈ​ពិសេស​តាម​វិធី​ផ្ទាល់​របស់​ពួកគេ។
• ទិន្នន័យសហគ្រាសមានភាពរញ៉េរញ៉ៃ។ នេះ​ទាក់ទង​នឹង​ចំណុច​ពីរ​ដំបូង ប៉ុន្តែ​គួរ​បញ្ជាក់។ ទោះបីជាមួយភ្លែតក៏ដោយ ស្ថាប័នមួយអាចមានតារាងមាសមួយចំនួនជាមួយនឹងស្រទាប់ semantic ដែលបានកំណត់យ៉ាងល្អឥតខ្ចោះ ដែលអ្វីៗទាំងអស់នឹងធ្លាក់ចុះភ្លាមៗនៅពេលដែលអ្នកដឹកនាំ RevOps សម្រេចចិត្តកែតម្រូវគំរូអាជីវកម្ម។ ខ្ញុំចូលចិត្តគូរភាពស្រដៀងគ្នានៃផ្ទះមួយ៖ ជាទូទៅអ្នកអាចរក្សាផ្ទះបានស្អាតល្អ ប៉ុន្តែតែងតែមាន អ្វី ដែលត្រូវសម្អាត ឬជួសជុល។
• Text-to-SQL មានកម្រិតពេក។ សម្រាប់សំណួរវិភាគទិន្នន័យភាគច្រើន ការសរសេរ SQL ដើម្បីទាញទិន្នន័យគឺគ្រាន់តែជាជំហានដំបូងប៉ុណ្ណោះ។ នេះជាជំហានដែលអ្នកត្រូវធ្វើ មុនពេលអ្នកក៏អាចចាប់ផ្តើមសួរសំណួរដែលគួរឱ្យចាប់អារម្មណ៍ថែមទៀត។ SQL មិនអាចដោះស្រាយការវិភាគស្មុគស្មាញដែលអ្នកប្រើប្រាស់អាជីវកម្មកំពុងសួរនោះទេ។ ម្យ៉ាងវិញទៀត LLMs និង Python គឺសមឥតខ្ចោះសម្រាប់កិច្ចការ។ ឧបករណ៍ទាំងនេះអាចយកលទ្ធផល SQL របស់អ្នក និងស្វែងរកម្ជុលនោះនៅក្នុងវាលស្មៅ។ ពួកគេក៏អាចដំណើរការការវិភាគតំរែតំរង់ដើម្បីបង្ហាញពីនិន្នាការធំជាងនេះ។

បន្ទាប់ពីពិនិត្យមើលបញ្ហាទាំងនេះ យើងបានគិតអំពីរបៀបធ្វើឱ្យ AI សម្របខ្លួនបានប្រសើរជាងបញ្ហា។ នោះហើយជាពេលដែលភ្នាក់ងារ AI បានចូលមកលេង និងពង្រឹងគំនិតនេះសម្រាប់ពួកយើង។

អនាគត៖ សំណាញ់ភ្នាក់ងារ

នាទីដែលយើងបានដាក់ភ្នែកលើក្របខ័ណ្ឌភ្នាក់ងារ យើងដឹងថាវានឹងផ្លាស់ប្តូរហ្គេម។ ភ្លាមៗនោះ យើងមានអារម្មណ៍ថា យើងអាចអនុញ្ញាតឱ្យ AI សម្រេចចិត្តពីរបៀបឆ្លើយសំណួរ។ វាអាចដំណើរការតាមជំហាន និងដោះស្រាយបញ្ហាដោយខ្លួនឯង។ ប្រសិនបើ AI សរសេរសំណួរ SQL ដែលបាត់តម្លៃ null នៅក្នុងវាល "ប្រភេទគណនី" វាអាចដំណើរការសំណួរស្ងួត រកមើលកំហុស និងជួសជុលវាដោយខ្លួនឯង។ ប៉ុន្តែចុះយ៉ាងណាបើយើងអាចបោះជំហានមួយជំហានទៀត ហើយអនុញ្ញាតឱ្យ AI ដំណើរការភាគច្រើននៅក្នុង Python និងប្រើប្រាស់ LLMs? ឥឡូវនេះ AI ធ្វើច្រើនជាងការទាញទិន្នន័យ។ វាអាចប្រើកញ្ចប់ Python ឬ LLMs ដើម្បីស្វែងរកផ្នែកខាងក្រៅ និន្នាការ ឬការយល់ដឹងប្លែកៗ ដែលជាធម្មតាអ្នកត្រូវរកមើលដោយដៃ។

ប៉ុន្តែយើងនៅតែមានបញ្ហាមួយ៖ ទិន្នន័យសហគ្រាសរញ៉េរញ៉ៃ។ យើងជឿថាអង្គការអាចដោះស្រាយបញ្ហានេះដោយប្រើការអនុវត្តវិស្វកម្មទិន្នន័យដ៏រឹងមាំ ដូចជា ក ស្ថាបត្យកម្មមេដាយ និងស្រទាប់ semantic តឹងរឹង។ ទោះជាយ៉ាងណាក៏ដោយ យើងកម្ររកឃើញអង្គការដែលធ្វើបែបនេះក្នុងជីវិតពិតណាស់។ ស្ថាប័នភាគច្រើនប្រើសៀវភៅបញ្ជី តារាងពាក់កណ្តាលដុតនំ និងគំរូទិន្នន័យដែលផ្លាស់ប្តូរជានិច្ច។ ពីទីនេះ យើងបានបង្កើតគំនិតបង្កើតភ្នាក់ងារ AI ឯកទេស ដែលអាចបង្កើតបានយ៉ាងឆាប់រហ័ស ដើម្បីឆ្លើយសំណួរជាក់លាក់មួយ។

នៅពេលដែលក្រុមហ៊ុនរីកចម្រើន ពួកគេគ្រប់គ្រងទិន្នន័យកាន់តែច្រើន និងមានអ្នកប្រើប្រាស់កាន់តែច្រើន។ គំនិតសំណាញ់ភ្នាក់ងារជួយធ្វើឱ្យមានតុល្យភាពក្នុងការសម្រេចចិត្តរហ័សជាមួយនឹងការគ្រប់គ្រងដែលត្រូវការសម្រាប់អភិបាលកិច្ច។ ភ្នាក់ងារឯកទេសជួយកំណត់ព្រំដែនច្បាស់លាស់ និងទំនួលខុសត្រូវសម្រាប់ AI នីមួយៗ។ ពួកគេក៏បង្កើតវិធីដែលអាចធ្វើមាត្រដ្ឋានបានសម្រាប់ភ្នាក់ងារទំនាក់ទំនង។ លើសពីនេះ ពួកគេអាចជួយគ្រប់គ្រងធនធានប្រកបដោយប្រសិទ្ធភាពនៅទូទាំងក្រុម និងក្រុមហ៊ុន។

ភ្នាក់ងារ AI ឯកទេស

គំនិតនៅពីក្រោយភ្នាក់ងារឯកទេសគឺថាភ្នាក់ងារនេះអាច និងនឹងឆ្លើយសំណួរតែលើសំណុំទិន្នន័យដែលបានកំណត់យ៉ាងតឹងរ៉ឹងប៉ុណ្ណោះ។ ឧទាហរណ៍ អ្នកអាចបង្កើត និងបើកដំណើរការភ្នាក់ងារ AI ដែលឆ្លើយសំណួរអំពីយុទ្ធនាការទីផ្សារ។ ឬអ្នកអាចសាងសង់មួយផ្សេងទៀតដើម្បីឆ្លើយសំណួរអំពីបំពង់បង្ហូរប្រេងទីផ្សារជាដើម។

ថ្មីៗ​នេះ យើង​បាន​បើក​ដំណើរការ​អ្នក​វិភាគ​ភ្នាក់ងារ ដោយប្រើស្ថាបត្យកម្មនេះ។ សញ្ញាដំបូងគឺល្អខ្លាំងណាស់។ នៅពេលដែលសំណុំទិន្នន័យត្រូវបានរៀបចំយ៉ាងប្រុងប្រយ័ត្ន និងនៅកម្រិត granularity ត្រឹមត្រូវ ភ្នាក់ងារទាំងនេះអាចឆ្លើយសំណួរជាក់លាក់មួយយ៉ាងគួរឱ្យទុកចិត្តបំផុត។ អ្នកបង្កើតភ្នាក់ងារទាំងនេះអាចចែករំលែកវាជាមួយអ្នកប្រើប្រាស់ដែលមិនមែនជាបច្ចេកទេស ហើយងាយស្រួលសម្រាកដោយដឹងថា AI នឹងមិនឆ្លើយសំណួរដែលហួសពីវិសាលភាពនោះទេ។

មានគុណវិបត្តិតែមួយ៖ អ្នកប្រើប្រាស់ត្រូវដឹងថាភ្នាក់ងារណាដែលត្រូវទៅសួរសំណួរណាមួយ។ វាដូចជាត្រូវការស្គាល់អ្នកវិភាគទីផ្សារត្រឹមត្រូវដើម្បីសួរសំណួរធៀបនឹងការសួរសំណួរទូទៅ។ ជាមួយនឹងសំណួរទូទៅ នរណាម្នាក់នៅក្នុងក្រុមអាចដឹកនាំវាទៅមនុស្សត្រឹមត្រូវ។ នេះគឺជាកន្លែងដែលគំនិតនៃ "សំណាញ់ភ្នាក់ងារ" ចូលមកលេង។

ការភ្ជាប់ភ្នាក់ងារជាមួយគ្នា

ប្រសិនបើភ្នាក់ងារតែមួយអាចឆ្លើយសំណួរជាក់លាក់នៃដែនបាន នោះហេតុអ្វីមិនអនុញ្ញាតឱ្យភ្នាក់ងារនិយាយគ្នាទៅវិញទៅមក? ជាឧទាហរណ៍ ហេតុអ្វីមិនអាច ភ្នាក់ងារយុទ្ធនាការទីផ្សារគ្រាន់តែសួរភ្នាក់ងារបំពង់ដោយផ្ទាល់ ប្រសិនបើពួកគេអាចឆ្លើយសំណួរកាន់តែងាយស្រួល? យើងជឿថាវាគួរតែអាចធ្វើបាន។ តាមការពិតយើងគិតថានៅពេលអនាគតនឹងមានបណ្តាញភ្នាក់ងារដែលមានរចនាសម្ព័ន្ធឋានានុក្រម។ អ្នកអាចរូបភាព "ភ្នាក់ងារ GTM" ដែលហៅ "ភ្នាក់ងារទីផ្សារ" ។ បន្ទាប់មកភ្នាក់ងារនេះហៅទាំង "ភ្នាក់ងារបំពង់" និង "ភ្នាក់ងារយុទ្ធនាការទីផ្សារ" ។

គំនិតនេះគឺដូចជាគំនិតទូទៅដែលអណ្តែតជុំវិញ AI ដែលគេស្គាល់ថាជា " អ៊ីធឺណិតនៃភ្នាក់ងារ " វាជាអនាគតមួយដែលភ្នាក់ងារ AI សហការគ្នាយ៉ាងរលូននៅទូទាំងស្ថាប័នផ្សេងៗ។ ពួកគេធ្វើដូចនេះខណៈពេលដែលធានាថាសុវត្ថិភាព និងការជឿទុកចិត្តនៅតែរឹងមាំ។

វិធីសាស្រ្តសំណាញ់នេះផ្តល់នូវអត្ថប្រយោជន៍សំខាន់ៗមួយចំនួនលើ AI monolithic (នៅលើស្រទាប់ semantic ដ៏បរិសុទ្ធ):

• ការសង្កេត៖ ដោយសារភ្នាក់ងារតែមួយផ្តល់ចម្លើយដោយផ្អែកលើទិន្នន័យជាក់លាក់ អ្នកអាចតាមដានចម្លើយនីមួយៗត្រឡប់ទៅភ្នាក់ងារនោះ។ នេះជួយធានាបាននូវភាពត្រឹមត្រូវតាមរយៈការធ្វើសវនកម្ម។ ដើម្បីបង្ហាញជាក់ស្តែង ទោះបីសាមញ្ញពេកក្តី ស្រមៃថាអ្នកមានតារាងព្រឹត្តិការណ៍ពីរ៖ មួយសម្រាប់ទីផ្សារ និងមួយទៀតសម្រាប់ផលិតផល។ ប្រសិនបើអ្នកប្រើសួរថា "តើព្រឹត្តិការណ៍ណាដែលបង្កើតប្រាក់ចំណូលច្រើនជាងគេ?" AI អាចសន្មត់ថាពួកគេមានន័យថាព្រឹត្តិការណ៍ផលិតផល។ ទោះបីជាវាខុសក៏ដោយ អ្នកប្រើប្រាស់អាចមើលឃើញថាភ្នាក់ងារណាមួយបានឆ្លើយតប និងអាចណែនាំ AI បាន។
• ការថែរក្សា៖ ដូចគ្នានឹងម៉ាស៊ីនរថយន្តដែរ ប្រសិនបើអ្នកអាចស្វែងរកបញ្ហាបានយ៉ាងងាយស្រួល និងផ្លាស់ប្តូរគ្រឿងបន្លាស់បានលឿន នោះរថយន្តកាន់តែមានភាពជឿជាក់។ ប្រសិនបើភ្នាក់ងារមួយចាប់ផ្តើមបរាជ័យដោយសារតែការផ្លាស់ប្តូរគំរូទិន្នន័យ នោះអាចត្រូវបានគេប្រទះឃើញយ៉ាងឆាប់រហ័ស ហើយភ្នាក់ងារនោះអាចត្រូវបានធ្វើបច្ចុប្បន្នភាព។
• ភាពត្រឹមត្រូវ៖ ជាមួយនឹងភ្នាក់ងារនីមួយៗដែលប្រតិបត្តិការក្នុងដែនកំណត់របស់វា វាគ្មានកន្លែងសម្រាប់វាចេញពីផ្លូវរថភ្លើងនោះទេ។ វាប្រហែលជាមិនមានចម្លើយទេ ប៉ុន្តែវានឹងមិនធ្វើឱ្យមានអ្វីដែលអស្ចារ្យនោះទេ។

នៅចុងបញ្ចប់នៃថ្ងៃ គំនិតនៃសំណាញ់នេះមិនមែនជារឿងប្រលោមលោកទេ។ នេះឆ្លុះបញ្ចាំងពីគំនិតនៃល្បាយនៃអ្នកជំនាញដែលត្រូវបានបង្ហាញដើម្បីកែលម្អភាពត្រឹមត្រូវសម្រាប់ LLMs ។ វាគ្រាន់តែយកគំនិតដូចគ្នានោះ ហើយនាំយកវាទៅភ្នាក់ងារ AI ។

បញ្ហាប្រឈមបច្ចេកទេសនៃសំណាញ់ភ្នាក់ងារ

នៅ Fabi.ai យើង​មាន​ផ្លូវ​វែង​ឆ្ងាយ​ក្នុង​ការ​ធ្វើ​ដូច​យើង​បង្កើត​សំណាញ់​ភ្នាក់ងារ​អ្នក​វិភាគ។ ប៉ុន្តែ យើង​បាន​ជម្នះ​បញ្ហា​ប្រឈម​ផ្នែក​ហេដ្ឋារចនាសម្ព័ន្ធ​បច្ចេកទេស​ធំៗ​មួយ​ចំនួន​រួច​ហើយ​នៅ​តាម​ផ្លូវ។

ភ្នាក់ងារអ្នកវិភាគទិន្នន័យ AI ត្រូវការស្ថាបត្យកម្មតែមួយគត់។ ការរចនានេះត្រូវតែអនុញ្ញាតឱ្យពួកគេប្រើ Python ឬ LLMs ដើម្បីឆ្លើយសំណួរ រក្សាសមកាលកម្មជាមួយប្រភពទិន្នន័យ និងសមទៅនឹងវេទិកាសហការ ខណៈពេលដែលនៅតែរក្សាសុវត្ថិភាព និងអាចធ្វើមាត្រដ្ឋានបាន។ ភ្នាក់ងារនីមួយៗត្រូវប្រតិបត្តិការនៅក្នុងខឺណែល Python របស់ខ្លួន ដែលចាំបាច់ត្រូវបង្វិលឬចុះក្រោមយ៉ាងលឿន ដើម្បីកាត់បន្ថយការចំណាយ និងរក្សាសមកាលកម្មជាមួយទិន្នន័យប្រភព។

ស្ថាបត្យកម្មដែលមិនផ្តល់ខឺណែលនីមួយៗដល់ភ្នាក់ងារនីមួយៗអាចប្រឈមនឹងហានិភ័យមួយដូចខាងក្រោម៖

• ជម្លោះរដ្ឋសម្រាប់អថេររវាងភ្នាក់ងារ AI ។ ភ្នាក់ងារពីរដាច់ដោយឡែកពីគ្នាអាចបង្កើតអថេរ "foo" ដើម្បីឆ្លើយសំណួរដែលបណ្តាលឱ្យមានការប៉ះទង្គិច។ វា​អាច​មាន​វិធី​ផ្សេង​ទៀត​ក្នុង​ការ​បង្កើត​ឧបករណ៍​កំណត់​អត្តសញ្ញាណ​តែ​មួយ​គត់ ប៉ុន្តែ​ទាំងនេះ​បង្កើន​ឱកាស​នៃ​ការ​បង្កើត​កូដ​មិន​ត្រឹមត្រូវ AI ។
• ហានិភ័យសុវត្ថិភាពដែលបណ្តាលមកពីការចែករំលែកទិន្នន័យរវាងក្រុមផ្សេងៗគ្នា ឬសូម្បីតែអង្គការផ្សេងៗគ្នា។
• ការរាំងស្ទះដំណើរការ ប្រសិនបើភ្នាក់ងារណាមួយយកធនធានគណនាមិនសមាមាត្រ។

បញ្ហាប្រឈមនៃការបង្កើតវេទិកាប្រភេទនេះគឺបញ្ហាប្រឈម AI ច្រើនដូចដែលវាគឺជាបញ្ហាប្រឈមរបស់ DevOps ។

សម្លឹងទៅមុខ៖ ទទួលយកភ្នាក់ងារ AI ដែលមានឯកទេស និងគ្រប់គ្រងនៅក្នុងទិន្នន័យ

នៅពេលដែលក្រុមហ៊ុនសហគ្រាសគ្រប់គ្រងកម្មវិធី AI កាន់តែច្រើននៅក្នុងប្រតិបត្តិការរបស់ពួកគេ ពួកគេត្រូវការវិធីសាស្រ្តពិសេស និងគ្រប់គ្រងយ៉ាងល្អ។ ក្របខ័ណ្ឌសំណាញ់ភ្នាក់ងារប្រើប្រាស់ភ្នាក់ងារទិន្នន័យ AI ឯកទេសជាមធ្យោបាយសម្រាប់ធ្វើមាត្រដ្ឋាន AI ក្នុងការវិភាគទិន្នន័យ។ វិធីសាស្រ្តនេះរក្សាសុវត្ថិភាព ភាពជឿជាក់ និងការអនុវត្តនៅដដែល។

យើងប្រហែលជារំពឹងថា AI នឹងនៅគ្រប់ទីកន្លែងនៅពេលឥឡូវនេះ ដោយឆ្លើយសំណួរទិន្នន័យភាគច្រើន។ ប៉ុន្តែប្រសិនបើយើងមើលឱ្យដិតដល់ ការរីកចម្រើនក្នុងរយៈពេលត្រឹមតែ 2 ឆ្នាំចាប់តាំងពី ChatGPT បានចាប់ផ្តើមគឺគួរអោយចាប់អារម្មណ៍។ យើង​នៅ​មាន​អ្វី​ជាច្រើន​ដែល​ត្រូវ​រៀន​ក្នុង​ដំណើរ​នេះ។ ទោះជាយ៉ាងណាក៏ដោយនៅក្នុងគំនិតរបស់ខ្ញុំ ភ្នាក់ងារ និងភ្នាក់ងារសំណាញ់ក្របខ័ណ្ឌនឹងជាគន្លឹះសម្រាប់សហគ្រាស AI ។