យើងបានផ្តល់ terabytes នៃ CI logs ទៅ LLM

អណ្តូងរ៉ែមាសដែលលាក់ទុកនៅក្នុងបំពង់ CI របស់អ្នក

ក្រុមវិស្វករទាំងអស់បង្កើតពួកគេ។ រាប់លានបន្ទាត់ ជារៀងរាល់ថ្ងៃ — ត្រាពេលវេលា ដានជង់ ដំណោះស្រាយភាពអាស្រ័យ លទ្ធផលតេស្ត បង្កើតវត្ថុបុរាណ និងសារកំហុសសម្ងាត់ដែលរំកិលឆ្លងកាត់លឿនជាងអ្នកណាម្នាក់អាចអានបាន។ កំណត់ហេតុ CI គឺជាផ្សែងនៃការអភិវឌ្ឍន៍កម្មវិធីទំនើប ហើយសម្រាប់ស្ថាប័នភាគច្រើន ពួកគេត្រូវបានចាត់ទុកយ៉ាងពិតប្រាកដដូចជាការហត់នឿយ៖ បញ្ចេញទៅក្នុងកន្លែងផ្ទុក និងបំភ្លេចចោល។ ប៉ុន្តែចុះយ៉ាងណាវិញ ប្រសិនបើកំណត់ហេតុទាំងនោះមានលំនាំដែលអាចទស្សន៍ទាយការបរាជ័យមុនពេលវាកើតឡើង កំណត់បញ្ហារាំងស្ទះដែលនាំឱ្យក្រុមរបស់អ្នករាប់រយម៉ោងក្នុងមួយត្រីមាស និងបង្ហាញពីបញ្ហាជាប្រព័ន្ធដែលមិនមានវិស្វករណាម្នាក់ធ្លាប់ឃើញទេ? យើងបានសម្រេចចិត្តស្វែងរកដោយការផ្តល់ទិន្នន័យកំណត់ហេតុ CI តេរ៉ាបៃទៅជាគំរូភាសាធំមួយ ហើយអ្វីដែលយើងបានរកឃើញបានផ្លាស់ប្តូររបៀបដែលយើងគិតអំពី DevOps ទាំងស្រុង។

ហេតុ​អ្វី​បាន​ជា CI Logs ជា​ទិន្នន័យ​ដែល​មិន​បាន​ប្រើ​ច្រើន​បំផុត​ក្នុង​វិស្វកម្ម​កម្មវិធី

ពិចារណា​កម្រិត​សំឡេង ក្រុមវិស្វករទំហំមធ្យមដែលកំពុងដំណើរការ 200 បង្កើតក្នុងមួយថ្ងៃនៅទូទាំងឃ្លាំងជាច្រើនបង្កើតទិន្នន័យកំណត់ហេតុឆៅប្រហែល 2-4 GB ជារៀងរាល់ថ្ងៃ។ ក្នុងរយៈពេលមួយឆ្នាំ វាលើសពីមួយ terabyte នៃអត្ថបទដែលមានរចនាសម្ព័ន្ធ និងពាក់កណ្តាលរចនាសម្ព័ន្ធ ដែលចាប់យករាល់ការចងក្រង រាល់ការប្រតិបត្តិឈុតសាកល្បង រាល់ជំហាននៃការដាក់ពង្រាយ និងរាល់របៀបបរាជ័យដែលប្រព័ន្ធរបស់អ្នកធ្លាប់ជួបប្រទះ។ វាជាកំណត់ត្រាបុរាណវិទ្យាពេញលេញនៃផលិតភាពរបស់ស្ថាប័នវិស្វកម្មរបស់អ្នក ហើយស្ទើរតែគ្មាននរណាម្នាក់អានវាទេ។

បញ្ហាមិនមែនថាទិន្នន័យខ្វះតម្លៃនោះទេ។ វាគឺថាសមាមាត្រសញ្ញាទៅសំឡេងគឺឃោរឃៅ។ ការរត់ CI ធម្មតាបង្កើតបានរាប់ពាន់បន្ទាត់នៃលទ្ធផល ហើយប្រហែលជា 3-5 នៃបន្ទាត់ទាំងនោះមានព័ត៌មានដែលអាចធ្វើសកម្មភាពបាន។ វិស្វកររៀនស្កេនរកអក្សរក្រហម grep សម្រាប់ "FAILED" ហើយបន្តទៅមុខទៀត។ ប៉ុន្តែគំរូដែលមានសារៈសំខាន់បំផុត — ការធ្វើតេស្តមិនច្បាស់លាស់ដែលបរាជ័យរៀងរាល់ថ្ងៃអង្គារ ភាពអាស្រ័យដែលបន្ថែម 40 វិនាទីទៅរាល់ការស្ថាបនា ការលេចធ្លាយអង្គចងចាំដែលលេចឡើងតែនៅពេលដែលសេវាកម្មជាក់លាក់បីដំណើរការដំណាលគ្នា - លំនាំទាំងនោះគឺមើលមិនឃើញនៅកម្រិតកំណត់ហេតុបុគ្គល។ ពួកវាលេចឡើងក្នុងទំហំប៉ុណ្ណោះ។

ឧបករណ៍វិភាគកំណត់ហេតុបែបប្រពៃណីដូចជា ELK stacks និង Datadog អាចប្រមូលផ្តុំម៉ែត្រ និងការផ្គូផ្គងពាក្យគន្លឹះលើផ្ទៃ ប៉ុន្តែពួកគេតស៊ូជាមួយនឹងភាពស្មុគស្មាញនៃអត្ថន័យនៃលទ្ធផល CI ។ សារបរាជ័យក្នុងការបង្កើតដែលអាន "ការតភ្ជាប់បានបដិសេធនៅលើច្រក 5432" និងមួយដែលអានថា "FATAL: ការផ្ទៀងផ្ទាត់ពាក្យសម្ងាត់បានបរាជ័យសម្រាប់អ្នកប្រើប្រាស់ 'ដាក់ពង្រាយ'" គឺជាការបរាជ័យដែលទាក់ទងនឹងមូលដ្ឋានទិន្នន័យ ប៉ុន្តែពួកគេមានមូលហេតុ និងដំណោះស្រាយខុសគ្នាទាំងស្រុង។ ការ​យល់​ថា​ភាព​ខុស​គ្នា​តម្រូវ​ឱ្យ​មាន​ប្រភេទ​នៃ​ហេតុផល​បរិបទ​ដែល​រហូត​មក​ដល់​ពេល​ថ្មី​ៗ​នេះ មាន​តែ​មនុស្ស​ប៉ុណ្ណោះ​ដែល​អាច​ផ្តល់​ជូន។

ការពិសោធន៍៖ ការផ្តល់ចំណី 3.2 Terabytes នៃប្រវត្តិសាងសង់ទៅ LLM

ការ​រៀបចំ​នេះ​គឺ​ត្រង់​ក្នុង​គំនិត និង​សុបិន្តអាក្រក់​ក្នុង​ការ​ប្រតិបត្តិ។ យើងបានប្រមូលកំណត់ហេតុ CI រយៈពេល 14 ខែពីវេទិកាដែលបម្រើអ្នកប្រើប្រាស់ជាង 138,000 នាក់ — គ្របដណ្តប់លើការស្ថាបនានៅទូទាំងសេវាកម្មជាច្រើន បរិស្ថាន និងគោលដៅនៃការប្រើប្រាស់។ សំណុំទិន្នន័យឆៅបានមកដល់ 3.2 terabytes: ប្រហែល 847 លានបន្ទាត់កំណត់ហេតុបុគ្គលដែលលាតសន្ធឹង 1.6 លានបំពង់ CI ដំណើរការ។ យើង​បាន​បំបែក បង្កប់ និង​ធ្វើ​លិបិក្រម​ទិន្នន័យ​នេះ បន្ទាប់​មក​បាន​បង្កើត​បំពង់​បញ្ជូន​បន្ត​ជំនាន់ (RAG) ដែល​អាច​ឆ្លើយ​សំណួរ​ភាសា​ធម្មជាតិ​អំពី​ប្រវត្តិ​បង្កើត​របស់​យើង។

បញ្ហាប្រឈមដំបូងគឺកំពុងដំណើរការជាមុន។ កំណត់ហេតុ CI មិនមែនជាអត្ថបទស្អាតទេ។ ពួកវាមានលេខកូដពណ៌ ANSI របារវឌ្ឍនភាពដែលសរសេរជាន់លើខ្លួនគេ ការត្រួតពិនិត្យវត្ថុបុរាណគោលពីរ និងត្រាពេលវេលាក្នុងទម្រង់យ៉ាងតិចបួនផ្សេងគ្នា អាស្រ័យលើឧបករណ៍ណាដែលបង្កើតពួកវា។ យើងបានចំណាយពេលបីសប្តាហ៍លើការធ្វើឱ្យមានលក្ខណៈធម្មតា — ការដកសំលេងរំខាន ការកំណត់ពេលវេលាស្តង់ដារ និងការដាក់ស្លាកផ្នែកកំណត់ហេតុនីមួយៗជាមួយនឹងទិន្នន័យមេតាអំពីដំណាក់កាលបំពង់បង្ហូរ ឃ្លាំង សាខា និងបរិស្ថានដែលវាជាកម្មសិទ្ធិ។

បញ្ហាប្រឈមទីពីរគឺការចំណាយ។ ការដំណើរការការសន្និដ្ឋានលើ terabytes នៃអត្ថបទគឺមិនថោកទេ សូម្បីតែជាមួយនឹងការដាក់កំណាត់ដ៏ខ្លាំងក្លា និងការបង្កើនប្រសិទ្ធភាពការទាញយកមកវិញក៏ដោយ។ យើងបានដុតបំផ្លាញឥណទានគណនាសំខាន់ៗក្នុងកំឡុងខែដំបូងតែម្នាក់ឯង ភាគច្រើនដោយសារតែវិធីសាស្រ្តដំបូងរបស់យើងគឺឆោតល្ងង់ពេក — ផ្ញើបរិបទច្រើនពេកក្នុងមួយសំណួរ ហើយមិនបានជ្រើសរើសគ្រប់គ្រាន់អំពីផ្នែកកំណត់ហេតុដែលពាក់ព័ន្ធ។ នៅចុងខែទីពីរ យើងនឹងកាត់បន្ថយការចំណាយក្នុងមួយសំណួរចំនួន 87% តាមរយៈយុទ្ធសាស្ត្របង្កប់កាន់តែប្រសើរ និងប្រព័ន្ធទាញយកពីរដំណាក់កាល ដែលបានប្រើគំរូតូចជាងមុន ដើម្បីត្រងជាមុន មុនពេលផ្ញើទៅលេខធំជាង។

គំរូទាំងប្រាំដែល LLM បានរកឃើញថាមនុស្សមិនអាច

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

1. The phantom dependency cascade។ ការធ្វើបច្ចុប្បន្នភាពកញ្ចប់ npm តែមួយកាលពី 9 ខែមុនបានណែនាំការពន្យារពេល 22 វិនាទីចំពោះរាល់ការបង្កើត JavaScript។ ការពន្យារពេលនេះត្រូវបានបិទបាំង ព្រោះវាស្របគ្នានឹងការធ្វើឱ្យប្រសើរឡើងនូវហេដ្ឋារចនាសម្ព័ន្ធ CI ដែលធ្វើឲ្យការស្ថាបនាកាន់តែលឿន។ Net-net, builds បានបង្ហាញខ្លួនលឿនជាង ប៉ុន្តែពួកគេអាចលឿនជាង 22 វិនាទី។ នៅទូទាំង 400+ JS builds ក្នុងមួយថ្ងៃ នោះគឺ 2.4 ម៉ោងនៃការគណនាដែលខ្ជះខ្ជាយប្រចាំថ្ងៃ។
2. តំបន់ពេលវេលា។ ឈុតសាកល្បងមួយមានអត្រាបរាជ័យ 4.7% — ខ្ពស់ល្មមនឹងរំខាន កម្រិតទាបល្មមដែលគ្មាននរណាម្នាក់កំណត់អាទិភាពក្នុងការជួសជុលវា។ LLM បានកំណត់អត្តសញ្ញាណថាការបរាជ័យទាក់ទងស្ទើរតែឥតខ្ចោះជាមួយនឹងការបង្កើតដែលបង្កឡើងនៅចន្លោះម៉ោង 23:00 និង 01:00 UTC នៅពេលដែលមុខងារប្រៀបធៀបកាលបរិច្ឆេទឆ្លងកាត់ព្រំដែនមួយថ្ងៃ។ ការជួសជុលពីរជួរបានលុបបំបាត់ស្នាមប្រេះទាំងស្រុង។
3. លំនាំរំកិលត្រឡប់មកវិញដោយស្ងៀមស្ងាត់។ ការដាក់ពង្រាយទៅដំណាក់កាលជោគជ័យ 99.2% នៃពេលវេលា ប៉ុន្តែ LLM បានកត់សម្គាល់ថា 31% នៃការដាក់ពង្រាយដំណាក់កាល "ជោគជ័យ" ត្រូវបានបន្តដោយការដាក់ពង្រាយសេវាកម្មដូចគ្នាមួយផ្សេងទៀតក្នុងរយៈពេល 45 នាទី ដោយបង្ហាញថាការដាក់ពង្រាយដំបូងត្រូវបានខូចមុខងារ បើទោះបីជាឆ្លងកាត់ការត្រួតពិនិត្យទាំងអស់។ នេះនាំឱ្យមានការរកឃើញថាការធ្វើតេស្តរួមបញ្ចូលមួយត្រូវបានឆ្លងកាត់ដោយសារតែការឆ្លើយតបក្នុងឃ្លាំងសម្ងាត់ពីសេវាកម្មក្លែងក្លាយ។
4. ការជាប់គាំងនៅព្រឹកថ្ងៃចន្ទ។ ពេលវេលានៃការបង្កើតជួរបានកើនឡើង 340% រៀងរាល់ថ្ងៃច័ន្ទចន្លោះម៉ោង 9:00 ដល់ 10:30 ព្រឹក ម៉ោងក្នុងស្រុក ពីព្រោះអ្នកអភិវឌ្ឍន៍ដែលធ្វើការនៅចុងសប្តាហ៍ទាំងអស់បានជំរុញការផ្លាស់ប្តូររបស់ពួកគេមុនពេលឈរ។ ការជួសជុលនេះមិនមែនជាលក្ខណៈបច្ចេកទេសទេ វាមានដំណើរការ៖ ធ្វើឱ្យកាលវិភាគនៃការធ្វើមាត្រដ្ឋានក្រុមអ្នករត់ CI មានភាពភ្ញាក់ផ្អើល ដើម្បីរំពឹងថានឹងមានការកើនឡើងនៅថ្ងៃច័ន្ទ។
5. ទង់អ្នកចងក្រងដែលគ្មាននរណាម្នាក់កំណត់។ 67% នៃ C++ builds កំពុងដំណើរការដោយមិនបានបើកការចងក្រងបន្ថែម ដោយបន្ថែមជាមធ្យម 3.8 នាទីក្នុងមួយ build។ ទង់ជាតិត្រូវបានចងក្រងជាឯកសារនៅក្នុងការណែនាំអំពីការចាប់ផ្តើម ប៉ុន្តែមិនត្រូវបានបន្ថែមទៅគំរូកំណត់រចនាសម្ព័ន្ធ CI ដែលបានចែករំលែកទេ។

"កំហុសដែលថ្លៃបំផុត មិនមែនជាកំហុសដែលធ្វើអោយកម្មវិធីរបស់អ្នកគាំងនោះទេ។ ពួកវាជាអ្នកលួច 30 វិនាទីដោយស្ងៀមស្ងាត់ពីរាល់ការបង្កើត ជារៀងរាល់ថ្ងៃ អស់រយៈពេលជាច្រើនឆ្នាំ រហូតដល់មាននរណាម្នាក់សួរសំណួរត្រឹមត្រូវនៃសំណុំទិន្នន័យត្រឹមត្រូវ។"

ការកសាងស្រទាប់ CI Intelligence ជាក់ស្តែង

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

យើងបានដោះស្រាយលើវិធីសាស្រ្តបីជាន់។ កម្រិតទីមួយគឺ ការស្វ័យប្រវត្ត៖ រាល់ការស្ថាបនាដែលបរាជ័យត្រូវបានចាត់ថ្នាក់ដោយស្វ័យប្រវត្តិតាមប្រភេទមូលហេតុដើម (ហេដ្ឋារចនាសម្ព័ន្ធ ភាពអាស្រ័យ តក្កវិជ្ជាសាកល្បង ការកំណត់រចនាសម្ព័ន្ធ ឬ flake) ជាមួយនឹងពិន្ទុទំនុកចិត្ត។ នេះតែម្នាក់ឯងបានកាត់បន្ថយពេលវេលាជាមធ្យមក្នុងការជួសជុលសម្រាប់ការបរាជ័យក្នុងការសាងសង់ចំនួន 34% ដោយសារតែវិស្វករមិនចាំបាច់ចំណាយពេល 10 នាទីដើម្បីអានកំណត់ហេតុដើម្បីស្វែងរកកន្លែងដែលត្រូវចាប់ផ្តើមស្វែងរក។ កម្រិតទីពីរគឺ ការរកឃើញនិន្នាការ៖ ការសង្ខេបប្រចាំសប្តាហ៍ដែលបង្ហាញពីគំរូដែលកំពុងលេចចេញ — ការកើនឡើងអត្រាបរាជ័យ ការបង្កើនរយៈពេលសាងសង់ ហត្ថលេខាកំហុសថ្មី — មុនពេលវាក្លាយជាការរិះគន់។ កម្រិតទីបីគឺ ការស៊ើបអង្កេតអន្តរកម្ម៖ ចំណុចប្រទាក់ដែលវិស្វករអាចសួរសំណួរជាភាសាធម្មជាតិអំពីប្រវត្តិស្ថាបនា ដូចជា "ហេតុអ្វីបានជាសេវាកម្ម X បរាជ័យញឹកញាប់ជាងបន្ទាប់ពីការចេញផ្សាយខែមីនា?" ឬ "តើអ្វីជាមូលហេតុទូទៅបំផុតនៃកំហុសក្នុងការអស់ពេលនៅក្នុងបំពង់ទូទាត់?"

សម្រាប់ក្រុមដែលកំពុងដំណើរការប្រតិបត្តិការស្មុគ្រស្មាញ - ជាពិសេសអ្នកដែលគ្រប់គ្រងមុខងារអាជីវកម្មជាច្រើនដូចជា CRM វិក្កយបត្រ បញ្ជីប្រាក់បៀវត្សរ៍ និងការវិភាគតាមរយៈវេទិកាដូចជា Mewayz ដែលរៀបចំម៉ូឌុលរួមបញ្ចូលគ្នាចំនួន 207 — ប្រភេទនៃការសង្កេតនេះកាន់តែមានសារៈសំខាន់។ នៅពេលដែលការដាក់ពង្រាយតែមួយប៉ះលំហូរការងារដែលប្រឈមមុខនឹងអតិថិជន តក្កកម្មវិក័យប័ត្រ និងប្រព័ន្ធធនធានមនុស្សក្នុងពេលដំណាលគ្នា ការយល់ដឹងអំពីភាពអាស្រ័យគ្នានៅក្នុងបំពង់ CI របស់អ្នកមិនមែនជាជម្រើសទេ។ វាចាំបាច់សម្រាប់រក្សាភាពជឿជាក់ដែលអ្នកប្រើប្រាស់ 138,000+ ពឹងផ្អែកលើ។

អ្វី​ដែល​មិន​ដំណើរការ (នៅឡើយ)

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

មាត្រដ្ឋាននៅតែជាបញ្ហាប្រឈម។ ខណៈពេលដែលប្រព័ន្ធទាញយកអាចដោះស្រាយសំណួរប្រកបដោយប្រសិទ្ធភាព ការបង្កើតលិបិក្រមដំបូង និងការបង្កប់កំណត់ហេតុថ្មីមានតម្លៃថ្លៃក្នុងការគណនា។ យើងដំណើរការបន្ទាត់កំណត់ហេតុថ្មីប្រហែល 800,000 ជារៀងរាល់ថ្ងៃ ហើយការរក្សាសន្ទស្សន៍ថ្មីតម្រូវឱ្យមានហេដ្ឋារចនាសម្ព័ន្ធដែលខិតខំប្រឹងប្រែង។ សម្រាប់ក្រុមតូចៗ ការគណនាតម្លៃអត្ថប្រយោជន៍ប្រហែលជាមិនពេញចិត្តចំពោះវិធីសាស្រ្តនេះទេ យ៉ាងហោចណាស់មិនទាន់មាននៅឡើយ។ ដោយសារតម្លៃគំរូបន្តធ្លាក់ចុះ (ពួកគេបានធ្លាក់ចុះប្រហែល 90% ក្នុងរយៈពេល 18 ខែចុងក្រោយនេះ សម្រាប់សមត្ថភាពសមមូល) សេដ្ឋកិច្ចនឹងផ្លាស់ប្តូរ។

ក៏មានសំណួរអំពីសុវត្ថិភាពផងដែរ។ កំណត់ហេតុ CI អាចមានអាថ៌កំបាំង — គ្រាប់ចុច API, ខ្សែតភ្ជាប់, URL ខាងក្នុង — ទោះបីជាមានការខិតខំប្រឹងប្រែងយ៉ាងល្អបំផុតដើម្បីបោសសម្អាតពួកវាក៏ដោយ។ ការបញ្ជូនទិន្នន័យនេះទៅ LLM APIs ខាងក្រៅបង្ហាញពីហានិភ័យ។ យើងកាត់បន្ថយបញ្ហានេះជាមួយនឹងបំពង់បង្ហូរប្រេងក្នុងតំបន់ និងដោយការដំណើរការការសន្និដ្ឋានលើគំរូដែលបង្ហោះដោយខ្លួនឯងសម្រាប់ឃ្លាំងរសើប ប៉ុន្តែវាបន្ថែមភាពស្មុគស្មាញ និងការចំណាយ។ ក្រុម​គួរ​វាយ​តម្លៃ​គំរូ​ការ​គំរាម​កំហែង​របស់​ពួក​គេ​ដោយ​ប្រុង​ប្រយ័ត្ន មុន​នឹង​អនុវត្ត​អ្វី​ដែល​ស្រដៀង​គ្នា។

ការចាប់ផ្តើមដោយគ្មាន Terabytes

អ្នកមិនត្រូវការសំណុំទិន្នន័យដ៏ធំ ឬក្រុមវិស្វកម្ម ML ដែលខិតខំប្រឹងប្រែងដើម្បីចាប់ផ្តើមទាញយកតម្លៃពីកំណត់ហេតុ CI របស់អ្នក។ នេះ​ជា​ចំណុច​ចាប់ផ្តើម​ជាក់ស្តែង​ដែល​ក្រុម​ណា​ដែល​មាន​ការ​បង្កើត​ពីរបីរយ​ក្នុង​មួយ​សប្តាហ៍​អាច​អនុវត្ត​បាន៖

• ចាប់ផ្តើមជាមួយនឹងការចាត់ថ្នាក់បរាជ័យ។ នាំចេញកំណត់ហេតុការស្ថាបនាដែលបរាជ័យ 90 ថ្ងៃចុងក្រោយរបស់អ្នក។ ប្រើ LLM API ណាមួយដើម្បីចាត់ថ្នាក់ការបរាជ័យនីមួយៗទៅជាប្រភេទ។ សូម្បីតែការចាត់ថ្នាក់សាមញ្ញមួយ (អ៊ីនហ្វ្រាធៀបនឹងលេខកូដធៀបនឹងការកំណត់រចនាសម្ព័ន្ធធៀបនឹង flake) ផ្តល់នូវតម្លៃភ្លាមៗសម្រាប់ការកំណត់អាទិភាព។
• តាមដាននិន្នាការរយៈពេលសាងសង់។ ញែកត្រាពេលវេលាពីកំណត់ហេតុរបស់អ្នក ដើម្បីបង្កើតស៊េរីពេលវេលានៃរយៈពេលសាងសង់ក្នុងមួយដំណាក់កាលនៃបំពង់បង្ហូរប្រេង។ ផ្តល់ភាពមិនប្រក្រតីដល់ LLM ដែលមានបរិបទកំណត់ហេតុជុំវិញ ហើយសួររកសម្មតិកម្មមូលហេតុដើម។
• ធ្វើឱ្យសំណួរ "ជាក់ស្តែង" ដោយស្វ័យប្រវត្តិ។ រៀបចំទំពក់ក្រោយការបរាជ័យ ដែលបញ្ជូន 500 ជួរចុងក្រោយនៃការស្ថាបនាដែលបរាជ័យទៅ LLM ជាមួយនឹងការជម្រុញថា: "សង្ខេបការបរាជ័យ CI នេះក្នុងមួយប្រយោគ និងណែនាំការដោះស្រាយដែលទំនងបំផុត"។ វាជួយសន្សំសំចៃ 5-10 នាទីក្នុងមួយការបរាជ័យសម្រាប់វិស្វករទាំងអស់នៅក្នុងក្រុម។
• បង្កើតបណ្ណសារដែលអាចស្វែងរកបាន។ ប្រើការបង្កប់ដើម្បីធ្វើឱ្យប្រវត្តិកំណត់ហេតុរបស់អ្នកអាចសាកសួរបានតាមភាសាធម្មជាតិ។ ឧបករណ៍ដូចជា LangChain និង LlamaIndex ធ្វើឱ្យវាអាចចូលដំណើរការបានគួរឱ្យភ្ញាក់ផ្អើល សូម្បីតែក្រុមដែលមិនមានបទពិសោធន៍ ML ក៏ដោយ។

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

អនាគត​គឺ​ប្រតិបត្តិការ​ឆ្លាតវៃ

អ្វី​ដែល​យើង​ពិត​ជា​កំពុង​និយាយ​គឺ​មិន​គ្រាន់​តែ​ជា​ការ​វិភាគ​កំណត់​ហេតុ​ប៉ុណ្ណោះ​ទេ - វា​ជា​ការ​ផ្លាស់​ប្តូរ​មូលដ្ឋាន​ឆ្ពោះ​ទៅ​រក ប្រតិបត្តិការ​ស៊ើបការណ៍​សម្ងាត់។ វិធីសាស្រ្តដូចគ្នាដែលដំណើរការសម្រាប់កំណត់ហេតុ CI អនុវត្តចំពោះសំបុត្រជំនួយអតិថិជន ទិន្នន័យបំពង់លក់ ប្រតិបត្តិការហិរញ្ញវត្ថុ និងលំហូរការងារប្រតិបត្តិការ។ ខ្សែស្រឡាយទូទៅគឺថាអង្គការបង្កើតទិន្នន័យអត្ថបទពាក់កណ្តាលរចនាសម្ព័ន្ធយ៉ាងច្រើនដែលមានលំនាំដែលអាចធ្វើសកម្មភាពបាន ហើយ LLMs គឺសមស្របនឹងការស្វែងរកគំរូទាំងនោះ។

នេះ​ជា​មូលហេតុ​ដែល​វេទិកា​ដែល​គ្រប់គ្រង​ប្រតិបត្តិការ​អាជីវកម្ម​កណ្តាល​មាន​អត្ថប្រយោជន៍​ជា​រចនាសម្ព័ន្ធ។ នៅពេលដែលទិន្នន័យ CRM របស់អ្នក ការគ្រប់គ្រងគម្រោង វិក្កយបត្រ កំណត់ត្រាធនធានមនុស្ស និងការវិភាគទាំងអស់រស់នៅក្នុងប្រព័ន្ធតែមួយ — ដូចដែលពួកគេធ្វើសម្រាប់ក្រុមដែលប្រើប្រាស់ស្ថាបត្យកម្មម៉ូឌុលរួមបញ្ចូលគ្នារបស់ Mewayz — សក្តានុពលសម្រាប់ការបង្កើនភាពវៃឆ្លាតឆ្លងដែន។ គំរូនៅក្នុងកំណត់ហេតុ CI របស់អ្នកអាចទាក់ទងជាមួយការកូរអតិថិជន។ ការកើនឡើងនៃសំបុត្រគាំទ្រអាចព្យាករណ៍ពីការបរាជ័យក្នុងការដាក់ពង្រាយ។ ការតភ្ជាប់ទាំងនេះអាចមើលឃើញតែនៅពេលដែលទិន្នន័យរស់នៅក្នុងប្រព័ន្ធដែលបានតភ្ជាប់ជាជាង silos ដាច់ដោយឡែក។

ក្រុម​ដែល​នឹង​រីក​ចម្រើន​ក្នុង​ទសវត្សរ៍​ក្រោយ មិន​ចាំ​បាច់​ជា​ក្រុម​ដែល​មាន​វិស្វករ​ច្រើន​បំផុត ឬ​មាន​ថវិកា​ច្រើន​បំផុត​នោះ​ទេ។ ពួកគេគឺជាអ្នកដែលរៀនស្តាប់ទិន្នន័យផ្ទាល់ខ្លួនរបស់ពួកគេ — រួមទាំង terabytes របស់វាដែលពួកគេត្រូវបានគេបោះចោល។ កំណត់ហេតុ CI របស់អ្នកកំពុងនិយាយ។ សំណួរ​គឺ​ថា​តើ​អ្នក​ត្រៀម​ខ្លួន​ហើយ​ឬ​នៅ​ក្នុង​ការ​ស្តាប់​អ្វី​ដែល​ពួកគេ​ត្រូវ​និយាយ។

សំណួរដែលគេសួរញឹកញាប់

តើ LLMs ពិតជាអាចរកឃើញគំរូដែលមានប្រយោជន៍នៅក្នុងកំណត់ហេតុ CI ដែរឬទេ?

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

តើការបរាជ័យ CI ប្រភេទណាខ្លះដែលអាចព្យាករណ៍បានដោយប្រើការវិភាគកំណត់ហេតុ?

ការវិភាគកំណត់ហេតុដែលជំរុញដោយ LLM អាចទស្សន៍ទាយការអស់ពេលដែលទាក់ទងនឹងហេដ្ឋារចនាសម្ព័ន្ធ ការបរាជ័យនៃដំណោះស្រាយភាពអាស្រ័យដដែលៗ ការគាំងនៃការបង្កើតអង្គចងចាំ និងការធ្វើតេស្តមិនប្រក្រតីដែលបង្កឡើងដោយផ្លូវកូដជាក់លាក់។ វាក៏កំណត់ការតំរែតំរង់យឺត ៗ ដែលពេលវេលាសាងសង់កើនឡើងជាលំដាប់ក្នុងរយៈពេលជាច្រើនសប្តាហ៍។ ក្រុមដែលប្រើវិធីសាស្រ្តនេះ ជាធម្មតាចាប់បានលំនាំនៃការបរាជ័យជាបណ្តើរៗពី 2 ទៅ 3 ដង មុនពេលពួកគេក្លាយជាឧប្បត្តិហេតុរារាំងនៅក្នុងការដាក់ពង្រាយផលិតកម្ម។

តើអ្នកត្រូវការទិន្នន័យកំណត់ហេតុ CI ប៉ុន្មាន មុនពេលការវិភាគមានតម្លៃ?

លំនាំដ៏មានអត្ថន័យជាធម្មតាលេចឡើងបន្ទាប់ពីការវិភាគពី 30 ទៅ 90 ថ្ងៃនៃប្រវត្តិបំពង់បន្តបន្ទាប់គ្នានៅទូទាំងសាខាជាច្រើន។ សំណុំទិន្នន័យតូចៗផ្តល់ការយល់ដឹងអំពីកម្រិតផ្ទៃ ប៉ុន្តែតម្លៃពិតបានមកពីការយោងឆ្លងកាត់ការដំណើរការរាប់ពាន់។ សម្រាប់ក្រុមដែលគ្រប់គ្រងលំហូរការងារស្មុគ្រស្មាញរួមជាមួយនឹងបំពង់ CI របស់ពួកគេ វេទិកាដូចជា Mewayz ផ្តល់ជូន 207 ម៉ូឌុលរួមបញ្ចូលគ្នាដែលចាប់ផ្តើមពី $19/mo ដើម្បីធ្វើមជ្ឈមណ្ឌលទិន្នន័យប្រតិបត្តិការនៅ app.mewayz.com

តើការផ្តល់កំណត់ហេតុ CI ទៅកាន់ LLM ជាហានិភ័យសុវត្ថិភាពដែរឬទេ?

វា​អាច​ជា​ប្រសិន​បើ​ដោះស្រាយ​ដោយ​មិន​ប្រុងប្រយ័ត្ន។ កំណត់ហេតុ CI ជាញឹកញាប់មានអថេរបរិស្ថាន សោ API, URL ខាងក្នុង និងព័ត៌មានលម្អិតអំពីហេដ្ឋារចនាសម្ព័ន្ធ។ មុននឹងដំណើរការកំណត់ហេតុតាមរយៈ LLM ណាមួយ អ្នកត្រូវតែអនុវត្តបំពង់បង្ហូរប្រតិកម្មដ៏រឹងមាំដែលដកចេញនូវអាថ៌កំបាំង លិខិតសម្គាល់ និងព័ត៌មានដែលអាចកំណត់អត្តសញ្ញាណផ្ទាល់ខ្លួន។ ការ​ដាក់​ឱ្យ​ប្រើ​គំរូ​ដែល​បង្ហោះ​ដោយ​ខ្លួន​ឯង ឬ​នៅ​ក្នុង​បរិវេណ​កាត់​បន្ថយ​ការ​ប៉ះពាល់​យ៉ាង​ខ្លាំង​បើ​ធៀប​នឹង​ការ​ផ្ញើ​កំណត់ហេតុ​ឆៅ​ទៅ​ចំណុច​បញ្ចប់​ការ​សន្និដ្ឋាន​ផ្អែក​លើ​ពពក​ភាគី​ទីបី។