ក្នុងភាពក្ដៅគគុកនៃការឆ្កួត ChatGPT ដំបូង ខ្ញុំបានទទួលអត្ថបទពីអតីតមិត្តរួមការងារ។ គាត់ចង់ដំណើរការគំនិតមួយដោយខ្ញុំ។ តែងតែជាមនុស្សម្នាក់ដែលរីករាយនឹងការបំផុសគំនិត ពួកយើងបានហៅទូរសព្ទមួយ ហើយគាត់ចាប់ផ្តើមដោយ "ចងចាំពីរបៀបដែលអ្នកតែងតែសុំឱ្យខ្ញុំទាញទិន្នន័យសម្រាប់អ្នក? ចុះបើអ្នកអាចធ្វើបានដោយខ្លួនឯង? ហើយបន្ទាប់មកគាត់បន្តផ្តល់គំនិតដល់ខ្ញុំដែលមនុស្សរាប់ពាន់នាក់ (រាប់ម៉ឺននាក់?) នៃមនុស្សផ្សេងទៀតកំពុងគិតក្នុងពេលតែមួយ: LLMs អាចត្រូវបានប្រើសម្រាប់អត្ថបទទៅ SQL ដើម្បីជួយអ្នកបច្ចេកទេសតិចឆ្លើយសំណួរទិន្នន័យផ្ទាល់ខ្លួនរបស់ពួកគេ។
ខ្ញុំជាប់នឹងគំនិតនេះ ប៉ុន្តែមុននឹងឈានដល់ក្បាលមុន ខ្ញុំបានប្រាប់ Lei (ឥឡូវ CTO របស់ខ្ញុំ) ថាយើងត្រូវតែធ្វើការបញ្ជាក់ខ្លះ។ យើងបានទាក់ទងមិត្តភ័ក្តិ និងអតីតមិត្តរួមការងារមកពីឧស្សាហកម្មផ្សេងៗ។ មានចំណាប់អារម្មណ៍យ៉ាងខ្លាំងចំពោះ "ការវិភាគសេវាកម្មខ្លួនឯង" ពិតប្រាកដ។ យើងបានដឹងថា វានឹងមានភាពស្មុគស្មាញច្រើនជាងវាហាក់ដូចជា ប៉ុន្តែឱកាសមានអារម្មណ៍ល្អពេកក្នុងការរំលង។ ដូច្នេះ Lei និងខ្ញុំបានចាកចេញពី The Shire ហើយចាប់ផ្តើមដំណើររបស់យើងដើម្បីបង្កើតចក្ខុវិស័យរបស់យើង៖
ការបង្ហោះនេះមិននិយាយអំពីផលិតផលរបស់យើងផ្ទាល់ទេ (ទោះបីជាអ្នកចង់ដឹងចង់ឃើញ អ្នកអាចអានបន្ថែមអំពីរបៀបដែលគំនិតមួយចំនួនខាងក្រោមបានជូនដំណឹងដល់ផលិតផលថ្មីៗរបស់យើង
ចំណាំ៖ ដំណើរនេះខ្វះអ្នកជំនួយការ និងការប្រយុទ្ធនៅមជ្ឈិមភពផែនដីយ៉ាងវេទនា។ 🧙
ហេតុអ្វីត្រូវប្រើ AI សម្រាប់ការវិភាគសេវាកម្មខ្លួនឯង?
យើងនឹងមិនរង់ចាំ "ហេតុអ្វី" យូរពេកទេ។ ប្រសិនបើអ្នកកំពុងអាននេះ អ្នកទំនងជាធ្លាក់ចូលទៅក្នុងក្រុមមួយក្នុងចំណោមពីរក្រុម៖
- អ្នកគឺជាមនុស្សម្នាក់ដែលប្រាថ្នាឱ្យអ្នកមានការវិភាគលើសេវាកម្មខ្លួនឯង ហើយមិនចង់ឱ្យត្រូវរង់ចាំក្រុមទិន្នន័យរបស់អ្នកជានិច្ច
- អ្នកស្ថិតនៅក្នុងក្រុមទិន្នន័យ ហើយបាននិងកំពុងឮអំពីរបៀបដែល AI នឹងអាចជួយអ្នកដោះស្រាយបញ្ហាសំណើរសុំផ្សព្វផ្សាយរបស់អ្នក។
ដោយព្រងើយកន្តើយនឹងការព្រួយបារម្ភចំពោះតួនាទីរបស់អ្នកវិភាគទិន្នន័យ និងអ្នកវិទ្យាសាស្ត្រ គំនិតនៃ AI ដែលដឹងគ្រប់បែបយ៉ាង ដែលអាចឆ្លើយសំណួរណាមួយអំពីទិន្នន័យរបស់ស្ថាប័នមួយ ស្តាប់ទៅល្អណាស់។ ឬយ៉ាងហោចណាស់ វាស្តាប់ទៅល្អសម្រាប់ស្ថាប័ន និងអ្នកដឹកនាំអាជីវកម្មរបស់ខ្លួន ដែលគំនិតច្នៃប្រឌិតសម្រាប់វិធីថ្មីនៃការសួរសំណួរមិនដឹងព្រំដែន។ AI នេះអាចជាដំណោះស្រាយក្នុងការបង្កើតអង្គការ "ជំរុញដោយទិន្នន័យ" ដែលអ្នកដឹកនាំគ្រប់រូបពឹងផ្អែកលើភស្តុតាងជាក់ស្តែងដើម្បីធ្វើការសម្រេចចិត្តជាយុទ្ធសាស្ត្ររបស់ពួកគេ។ ហើយទាំងអស់នៅប្រភាគនៃការចំណាយដែលជាធម្មតាត្រូវចំណាយ។ ទីបំផុត! អង្គការអាចទាញយកប្រយោជន៍ពី "ប្រេងថ្មី" ដែលពួកគេបានឮតាំងពីឆ្នាំ 2010 ។
ប៉ុន្តែប្រសិនបើនេះជាបញ្ហាដ៏មានតម្លៃក្នុងការដោះស្រាយ ហើយ AI ទទួលបានលទ្ធផលល្អ ហេតុអ្វីបានជាគ្មានផលិតផលណាមួយ អាច ដោះស្រាយវាបាន?
ហេតុអ្វីបានជា AI សម្រាប់ការវិភាគសេវាកម្មខ្លួនឯងបានបរាជ័យរហូតមកដល់ពេលនេះ
ការស្ទង់មតិក្នុងឧស្សាហកម្មថ្មីៗនេះបានគូររូបភាពស្មុគស្មាញនៃការទទួលយក AI នៅក្នុងសហគ្រាស។
អ្នកទទួលយក AI ជាពិសេសនៅក្នុងសហគ្រាសមានរបារខ្ពស់នៅពេលនិយាយអំពីការរំពឹងទុកនៃបច្ចេកវិទ្យា។ នៅក្នុងបរិបទនៃការវិភាគទិន្នន័យ និងក្តីសុបិននៃការបម្រើដោយខ្លួនឯង យើងរំពឹងថាឧបករណ៍ AI របស់យើងគឺ៖
- ផ្តល់ការយល់ដឹង៖ តារាង និងគំនូសតាងគឺអស្ចារ្យណាស់ ប៉ុន្តែទាំងនេះគឺជាសំណុំរងនៃអ្វីដែលគេហៅថា "ការយល់ដឹង"។ ការយល់ដឹងគឺ "អាហា!" គ្រាដែលមកពីការប្រទះឃើញវត្ថុនៅក្នុងទិន្នន័យរបស់អ្នកដែលប្រឆាំងនឹងវិចារណញាណរបស់អ្នក ហើយនឹងមិនបានពិចារណាផ្សេងទៀតទេ។ ពេលខ្លះ SQL query ឬ pivot អាចបញ្ចេញពន្លឺលើការយល់ដឹងទាំងនេះ ប៉ុន្តែជាទូទៅវាមានអារម្មណ៍ដូចជាការស្វែងរកម្ជុលនៅក្នុងវាលស្មៅ។
- ធ្វើការដែលអាចទុកចិត្តបានជិត 100% នៃពេលវេលា៖ រឿងតែមួយគត់ដែលអាក្រក់ជាងគ្មានទិន្នន័យគឺទិន្នន័យអាក្រក់។ ប្រសិនបើ AI មិនអាចជឿទុកចិត្តបាន ឬបំភ័ន្តចម្លើយ និងទិន្នន័យ នោះជាដំណឹងអាក្រក់សម្រាប់អ្នករាល់គ្នា។ នេះមានន័យថានៅពេលដែល AI មានទិន្នន័យ វាគួរតែប្រើវាឱ្យបានត្រឹមត្រូវ។ ប៉ុន្តែនៅពេលដែលវាខ្វះទិន្នន័យ វាគួរតែជៀសវាងការផ្តល់ចម្លើយ (អ្វីមួយដែល LLMs មានកេរ្តិ៍ឈ្មោះមិនល្អ)។
- អាចចូលទៅប្រើប្រាស់ឈុតជំនាញបច្ចេកទេសជាច្រើន៖ ភាពស្រស់ស្អាតនៃ 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 ដើម្បីស្វែងរកផ្នែកខាងក្រៅ និន្នាការ ឬការយល់ដឹងប្លែកៗ ដែលជាធម្មតាអ្នកត្រូវរកមើលដោយដៃ។
ប៉ុន្តែយើងនៅតែមានបញ្ហាមួយ៖ ទិន្នន័យសហគ្រាសរញ៉េរញ៉ៃ។ យើងជឿថាអង្គការអាចដោះស្រាយបញ្ហានេះដោយប្រើការអនុវត្តវិស្វកម្មទិន្នន័យដ៏រឹងមាំ ដូចជា ក
នៅពេលដែលក្រុមហ៊ុនរីកចម្រើន ពួកគេគ្រប់គ្រងទិន្នន័យកាន់តែច្រើន និងមានអ្នកប្រើប្រាស់កាន់តែច្រើន។ គំនិតសំណាញ់ភ្នាក់ងារជួយធ្វើឱ្យមានតុល្យភាពក្នុងការសម្រេចចិត្តរហ័សជាមួយនឹងការគ្រប់គ្រងដែលត្រូវការសម្រាប់អភិបាលកិច្ច។ ភ្នាក់ងារឯកទេសជួយកំណត់ព្រំដែនច្បាស់លាស់ និងទំនួលខុសត្រូវសម្រាប់ AI នីមួយៗ។ ពួកគេក៏បង្កើតវិធីដែលអាចធ្វើមាត្រដ្ឋានបានសម្រាប់ភ្នាក់ងារទំនាក់ទំនង។ លើសពីនេះ ពួកគេអាចជួយគ្រប់គ្រងធនធានប្រកបដោយប្រសិទ្ធភាពនៅទូទាំងក្រុម និងក្រុមហ៊ុន។
ភ្នាក់ងារ AI ឯកទេស
គំនិតនៅពីក្រោយភ្នាក់ងារឯកទេសគឺថាភ្នាក់ងារនេះអាច និងនឹងឆ្លើយសំណួរតែលើសំណុំទិន្នន័យដែលបានកំណត់យ៉ាងតឹងរ៉ឹងប៉ុណ្ណោះ។ ឧទាហរណ៍ អ្នកអាចបង្កើត និងបើកដំណើរការភ្នាក់ងារ AI ដែលឆ្លើយសំណួរអំពីយុទ្ធនាការទីផ្សារ។ ឬអ្នកអាចសាងសង់មួយផ្សេងទៀតដើម្បីឆ្លើយសំណួរអំពីបំពង់បង្ហូរប្រេងទីផ្សារជាដើម។
មានគុណវិបត្តិតែមួយ៖ អ្នកប្រើប្រាស់ត្រូវដឹងថាភ្នាក់ងារណាដែលត្រូវទៅសួរសំណួរណាមួយ។ វាដូចជាត្រូវការស្គាល់អ្នកវិភាគទីផ្សារត្រឹមត្រូវដើម្បីសួរសំណួរធៀបនឹងការសួរសំណួរទូទៅ។ ជាមួយនឹងសំណួរទូទៅ នរណាម្នាក់នៅក្នុងក្រុមអាចដឹកនាំវាទៅមនុស្សត្រឹមត្រូវ។ នេះគឺជាកន្លែងដែលគំនិតនៃ "សំណាញ់ភ្នាក់ងារ" ចូលមកលេង។
ការភ្ជាប់ភ្នាក់ងារជាមួយគ្នា
ប្រសិនបើភ្នាក់ងារតែមួយអាចឆ្លើយសំណួរជាក់លាក់នៃដែនបាន នោះហេតុអ្វីមិនអនុញ្ញាតឱ្យភ្នាក់ងារនិយាយគ្នាទៅវិញទៅមក? ជាឧទាហរណ៍ ហេតុអ្វីមិនអាច ភ្នាក់ងារយុទ្ធនាការទីផ្សារគ្រាន់តែសួរភ្នាក់ងារបំពង់ដោយផ្ទាល់ ប្រសិនបើពួកគេអាចឆ្លើយសំណួរកាន់តែងាយស្រួល? យើងជឿថាវាគួរតែអាចធ្វើបាន។ តាមការពិតយើងគិតថានៅពេលអនាគតនឹងមានបណ្តាញភ្នាក់ងារដែលមានរចនាសម្ព័ន្ធឋានានុក្រម។ អ្នកអាចរូបភាព "ភ្នាក់ងារ GTM" ដែលហៅ "ភ្នាក់ងារទីផ្សារ" ។ បន្ទាប់មកភ្នាក់ងារនេះហៅទាំង "ភ្នាក់ងារបំពង់" និង "ភ្នាក់ងារយុទ្ធនាការទីផ្សារ" ។
គំនិតនេះគឺដូចជាគំនិតទូទៅដែលអណ្តែតជុំវិញ 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 ។
