README.md

ភ្នាក់ងារ AI ក្នុងផលិតកម្ម: ការអាចសង្កេតឃើញ និងការវាយតម្លៃ

ពេលដែលភ្នាក់ងារ AI pind ឡើងពីគំរូសាកល្បងទៅកាន់អនុប្រតិបត្តិក្នុងពិភពពិត សមត្ថភាពក្នុងការយល់ដឹងអំពីអាកប្បកិរិយារបស់ពួកវា តាមដានការសម្តែង និងវាយតម្លៃលទ្ធផលយ៉ាងប្រពៃណីក្លាយទៅជាអ្វីដែលមានសារៈសំខាន់។

គោលបំណងការសិក្សា

បន្ទាប់ពីបញ្ចប់មេរៀននេះ អ្នកនឹងដឹងពី/យល់ពី៖

• แนวคิด핵심 នៃការអាចសង្កេតឃើញ និងការវាយតម្លៃភ្នាក់ងារ
• បច្ចេកទេសសម្រាប់ធ្វើឲ្យការសម្តែង ការចំណាយ និងប្រសិទ្ធភាពរបស់ភ្នាក់ងារកាន់តែប្រសើរ
• មាតិកាអ្វី និងធ្វើដូចម្តេចដើម្បីវាយតម្លៃភ្នាក់ងារ AI របស់អ្នកយ៉ាងប្រពៃណី
• របៀបគ្រប់គ្រងការចំណាយពេលប្រគល់ភ្នាក់ងារ AI ទៅក្នុងផលិតកម្ម
• របៀបដាក់ឧបករណ៍សម្រាប់ភ្នាក់ងារ ដែលបានបង្កើតជាមួយ Microsoft Agent Framework

គោលបំណងគឺដើម្បីផ្តល់ឱ្យអ្នកនូវចំណេះដឹងដើម្បីបម្លែងភ្នាក់ងារ "ប្រអប់ខ្មៅ" របស់អ្នកឲ្យទៅជាប្រព័ន្ធភ្លឺច្បាស់, អាចគ្រប់គ្រង, និងអាចយកចិត្តទុកដាក់បាន។

ចំណាំ៖ វាសំខាន់ក្នុងការបង្ហោះភ្នាក់ងារ AI ដែលមានសុវត្ថិភាព និងគួរឱ្យទុកចិត្ត។ សូមពិនិត្យមេរៀន ការសាងសង់ភ្នាក់ងារ AI ដែលគួរឱ្យទុកចិត្ត ផងដែរ។

Traces and Spans

ឧបករណ៍សង្កេត such as Langfuse ឬ Microsoft Foundry ជាទូទៅបង្ហាញពីការរត់ភ្នាក់ងារជា traces និង spans ។

• Trace បង្ហាញពីភារកិច្ចភ្នាក់ងារពេញលេញពីចាប់ផ្ដើមដល់ចប់ (ដូចជា ការដោះស្រាយសំណួរអ្នកប្រើ)។
• Spans ជជែកជាទន្ទឹមជំហាននីមួយៗក្នុង trace (ដូចជា ការហៅមូឌែលភាសា ឬការទាញទិន្នន័យ)។

ចំពោះគ្មានការអាចសង្កេតឃើញ ឧបករណ៍ AI អាចនឹងមានអារម្មណ៍ដូចជា "ប្រអប់ខ្មៅ" - ស្ថានភាព និងហេតុផលផ្ទុកខាងក្នុងរបស់វាមានភាពមិនច្បាស់, ធ្វើឲ្យវាមានការលំបាកក្នុងការធ្វើវិភាគបញ្ហាឬបង្កើនប្រសិទ្ធភាព។ ជាមួយនឹងការអាចសង្កេតឃើញ ភ្នាក់ងារខ្លះៗក្លាយជារាង "ប្រអប់កញ្ចក់", ផ្តល់ភាពច្បាស់លាស់ដែលមានសារៈសំខាន់សម្រាប់ការសាងសង់ទំនុកចិត្ត និងធានាថាវាធ្វើការតាមដែលបានចង់បាន។

ហេតុអ្វីការអាចសង្កេតឃើញមានសារៈសំខាន់ក្នុងបរិយាកាសផលិតកម្ម

ការផ្លាស់ទីភ្នាក់ងារ AI ទៅក្នុងបរិយាកាសផលិតកម្មបង្ហាញពីបញ្ហា និងតម្រូវការថ្មីៗ។ ការអាចសង្កេតឃើញមិនមែនគ្រាន់តែ "ល្អដើម្បីមាន" ទេ ប៉ុន្តែគឺជាសមត្ថភាពសំខាន់៖

• ការទូរកំហុស និងវិភាគមូលហេតុ: ពេលដែលភ្នាក់ងារ បរាជ័យ ឬបង្ហាញលទ្ធផលដែលមិនគិតទុកជានិយម ឧបករណ៍សង្កេតឃើញផ្តល់ trace ដែលចាំបាច់ដើម្បីកំណត់ប្រភពកំហុស។ នេះមានសារៈសំខាន់ជាពិសេសសម្រាប់ភ្នាក់ងារស្មុគស្មាញដែលអាចជាប់នូវការហៅ LLM ច្រើន ការទំនាក់ទំនងជាមួយឧបករណ៍ផ្សេងៗ និងតុបតែងលក្ខខណ្ឌ។
• ការគ្រប់គ្រងពេលឆ្លើយ និងចំណាយ: ភ្នាក់ងារ AI ភាគច្រើនពឹងផ្អែកលើ LLM និង API ខាងក្រៅដែលគិតតាម token ឬតាមការហៅ។ ការអាចសង្កេតឃើញអនុញ្ញាតឲ្យតាមដានការហៅទាំងនេះយ៉ាងច្បាស់ ដើម្បីកំណត់ប្រតិបត្តិការណ៍ដែលយឺតឬចំណាយលើស។ នេះជួយឲ្យក្រុមអាចបង្កើនប្រសិទ្ធភាព prompt ជ្រើសម៉ូឌែលមានប្រសិទ្ធភាព ឬរចនាប្រតិបត្តិការឡើងវិញដើម្បីគ្រប់គ្រងចំណាយ និងធានានូវបទពិសោធន៍អ្នកប្រើល្អ។
• ទំនុកចិត្ត សុវត្ថិភាព និងការអនុលោម: នៅក្នុងកម្មវិធីជាច្រើន វាសំខាន់ក្នុងការធានាថា ភ្នាក់ងារ​ធ្វើឲ្យមានសុវត្ថិភាព និងសុចរិត។ ការអាចសង្កេតឃើញផ្តល់ជាតំណរ audit នៃសកម្មភាព និងសេចក្តីសម្រេចរបស់ភ្នាក់ងារ។ នេះអាចប្រើដើម្បីរកឃើញ និងកាត់ទុកបញ្ហាទូលាយដូចជា prompt injection, ការបង្កើតមាតិកាអាក្រក់, ឬការរំលោភព័ត៌មានបុគ្គល (PII)។ ឧទាហរណ៍ អ្នកអាចពិនិត្យ traces ដើម្បីយល់ថាហេតុអ្វីភ្នាក់ងារ បានផ្តល់ចម្លើយណាមួយ ឬបានប្រើឧបករណ៍ណាមួយ។
• ខ្សែប្រតិបត្តិការកែលម្អដោយបន្ត: ទិន្នន័យ observability ជាគ្រឹះនៃដំណើរការវិវត្តន៍។ ដូចជា តាមដានរបៀបដែលភ្នាក់ងារធ្វើការនៅពិភពពិត ក្រុមអាចកំណត់ចំណុចដែលត្រូវកែលម្អ សង្សោធទិន្នន័យសម្រាប់ការសម្រួលម៉ូឌែល និងផ្ទៀងផ្ទាត់ផលប៉ះពាល់នៃការផ្លាស់ប្តូរ។ នេះបង្កើតខ្សែប្រតិបត្តិដែលពីរវគ្គនៅក្នុងផលិតកម្ម ព័ត៌មានពីការវាយតម្លៃបណ្ដាញជួយផ្គត់ផ្គង់ឲ្យការប្រមាណក្រៅបណ្ដាញ និងការប្រែប្រួល ដើម្បីធ្វើឲ្យការសម្តែងភ្នាក់ងារកាន់តែប្រសើរ។

មាត្រដ្ឋានសំខាន់ៗដែលត្រូវតាមដាន

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

នេះជាមាត្រដ្ឋានទូទៅដែលឧបករណ៍ observability តាមដាន៖

Latency: ភ្នាក់ងារឆ្លើយតបយ៉ាងលឿនប៉ុណ្ណា? ចំណាយពេលយូរ ប៉ះពាល់អវិជ្ជមានដល់បទពិសោធន៍អ្នកប្រើ។ អ្នកគួរតែលេខាផល latency សម្រាប់ភារកិច្ច និងជំហានជាក់លាក់ដោយ tracing រត់ភ្នាក់ងារ។ ឧទាហរណ៍ ភ្នាក់ងារមួយដែលចំណាយ 20 វិនាទីសម្រាប់ការហៅម៉ូឌែលទាំងអស់ អាចលឿនឡើងបានដោយប្រើម៉ូឌែលលឿនជាង ឬដោយរត់ការហៅម៉ូឌែលជាប្រភេទ parallel។

Costs: តើចំណាយប៉ុន្មានក្នុងមួយការរត់ភ្នាក់ងារ? ភ្នាក់ងារ AI ពឹងផ្អែកលើការហៅ LLM ដែលគិតតាម token ឬ API ខាងក្រៅ។ ការប្រើឧបករណ៍ញឹកញាប់ ឬការបញ្ចាប់ prompt មួយច្រើនអាចបង្កើនចំណាយយ៉ាងលឿន។ ឧទាហរណ៍ ប្រសិនបើភ្នាក់ងារ ហៅ LLM ឡើង ៥ ដង ដើម្បីទទួលបានការកែលម្អគុណភាពតិចតួច អ្នកត្រូវវាយតម្លៃថាតើចំណាយនេះសាកសមឬអត់ ឬអាចកាត់បន្ថយចំនួនការហៅ ឬប្រើម៉ូឌែលថោកជាង។ ការតាមដានពេលពិតក៏ជួយសម្គាល់ការកើនឡើងចៃដន្យ (ឧ. bug ធ្វើឲ្យមាន loop API លើស)។

Request Errors: ភ្នាក់ងារបរាជ័យក្នុងការស្នើប៉ុន្មានដង? នេះអាចរួមមានកំហុស API ឬការហៅឧបករណ៍បរាជ័យ។ ដើម្បីធ្វើឲ្យភ្នាក់ងាររឹងមាំជាងនេះនៅក្នុងផលិតកម្ម អ្នកអាចដាក់ fallback ឬ retries។ ឧ. ប្រសិនបើ LLM provider A ផុតស្រាប់ អ្នកអាចផ្លាស់ទៅ provider B ជាឧបករណ៍ជំនួយ។

User Feedback: ការអនុវត្តវាយតម្លៃដោយអ្នកប្រើផ្ទាល់ផ្តល់ចំណេះដឹងមានតម្លៃ។ នេះអាចរួមមានការវាយតម្លៃបង្ហាញដោយច្បាស់ (👍thumbs-up/👎down, ⭐1-5 stars) ឬមតិយោបល់ជាអត្ថបទ។ មតិកោននៅលើដើមបណ្តាលប៉ះពាល់អវិជ្ជមានជាប់ប្រហែលគួរឱ្យត្រួតពិនិត្យព្រោះនេះជាសញ្ញាថា ភ្នាក់ងារមិនធ្វើការតាមដែលបានរំពឹកទេ។

Implicit User Feedback: អាកប្បកម្មអ្នកប្រើផ្តល់មតិទាំងអនិច្ច័យទោះបីមិនមានការវាយតម្លៃបង្ហាញដោយផ្ទាល់ក៏ដោយ។ វាអាចរួមមានការពន្យាពេលបំរែបំរួលសំណួរ បញ្ចូនសំណួររង ឬចុចប៊ូតុង retry។ ឧ. ប្រសិនបើអ្នកឃើញថាអ្នកប្រើសំណើសំណួរដដែល ជាច្រើនដង នេះជាសញ្ញាថា ភ្នាក់ងារមិនបានបំពេញការងារដូចដែលបានរំពឹងទុក។

Accuracy: ភាគរយដែលភ្នាក់ងារបង្កើតលទ្ធផលត្រឹមត្រូវ ឬចង់បានប៉ុណ្ណា? ការបកស្រាយភាពត្រឹមត្រូវអាចខុសគ្នា (ឧ. ភាពត្រឹមត្រូវក្នុងដោះស្រាយបញ្ហា, ភាពត្រឹមត្រូវក្នុងទាញយកព័ត៌មាន, ភាពពេញចិត្តរបស់អ្នកប្រើ)។ ជំហានដំបូងគឺកំណត់ថា សេចក្តីជោគជ័យមានរាងដូចម្តេចសម្រាប់ភ្នាក់ងាររបស់អ្នក។ អ្នកអាចតាមដានភាពត្រឹមត្រូវតាមការត្រួតពិនិត្យអូតូម៉ាទិក, ពិន្ទុវាយតម្លៃ, ឬស្លាកការបញ្ចប់ភារកិច្ច។ ឧ. កំណត់ traces ជា "succeeded" ឬ "failed"។

Automated Evaluation Metrics: អ្នកក៏អាចដាក់ evals ដោយស្វ័យប្រវត្តិ។ ឧ. អ្នកអាចប្រើ LLM មួយសម្រាប់ផ្ដល់ពិន្ទុលទ្ធផលពីភ្នាក់ងារ ដូចជា តើវាមានប្រយោជន៍ ទែនឬមិនទេ បើនិយាយពីភាពត្រឹមត្រូវ។ មានបណ្ណាល័យមួយចំនួនក្នុងទូលាយចំហដែលជួយអ្នកវាយតម្លៃផ្នែកខុសៗគ្នានៃភ្នាក់ងារ។ ឧ. RAGAS សម្រាប់ភ្នាក់ងារ RAG ឬ LLM Guard ដើម្បីសម្គាល់ភាសាហានិភ័យ ឬ prompt injection។

ក្នុងការអនុវត្តពិត សមាសភាពនៃមាត្រដ្ឋានទាំងនេះផ្តល់ការកម្មវិធីគ្រប់គ្រាន់ល្អបំផុតចំពោះសុខភាពភ្នាក់ងារ AI។ ក្នុងវិញ្ញាសានេះ example notebook យើងនឹងបង្ហាញអ្នកពីរបៀបដែលមាត្រដ្ឋានទាំងនេះមើលទៅក្នុងឧទាហរណ៍ពិត ប៉ុន្តែមុននោះ យើងនឹងរៀនពីរបៀបធម្មតានៃដំណើរការវាយតម្លៃ។

បំពាក់ភ្នាក់ងារ​របស់អ្នក

ដើម្បីប្រមូលទិន្នន័យ tracing អ្នកត្រូវបំពាក់កូដរបស់អ្នក។ គោលបំណងគឺដើម្បីបំពាក់កូដភ្នាក់ងារ ដើម្បីបញ្ចេញ traces និង metrics ដែលអាចត្រូវបានចាប់យក ប្រមូល និងបង្ហាញដោយវេទិការសង្កេត។

OpenTelemetry (OTel): OpenTelemetry បានក្លាយជាស្តង់ដារពាណិជ្ជកម្មសម្រាប់ observability របស់ LLM។ វាប្រើប្រាស់ជាសេត API, SDKs និងឧបករណ៍សម្រាប់បង្កើត ប្រមូល និងនាំចេញទិន្នន័យ telemetry។

មានបណ្ណាល័យ instrumentation ជាច្រើនដែលបិទជុំរួម agent frameworks ដែលមានស្រាប់ និងធ្វើឲ្យងាយសម្រាប់នាំចេញ OpenTelemetry spans ទៅឧបករណ៍ observability។ Microsoft Agent Framework រៀបចំរួមជាមួយ OpenTelemetry ជាលំនាំដើម។ ខាងក្រោមជាឧទាហរណ៍ពីរបៀបបំពាក់ភ្នាក់ងារ MAF:

from agent_framework.observability import get_tracer, get_meter

tracer = get_tracer()
meter = get_meter()

with tracer.start_as_current_span("agent_run"):
    # ការប្រតិបត្តិរបស់ភ្នាក់ងារ ត្រូវបានតាមដានដោយស្វ័យប្រវត្តិ
    pass

The example notebook in this chapter will demonstrate how to instrument your MAF agent.

Manual Span Creation: ខណៈពេលដែលបណ្ណាល័យ instrumentation ផ្តល់មូលដ្ឋានល្អ មានករណីជាច្រើនដែលត្រូវការព័ត៌មានលម្អិតឬប៊ិចផ្ទាល់ខ្លួនបន្ថែម។ អ្នកអាចបង្កើត spans ដោយដៃដើម្បីបន្ថែមលូresentation លក្ខណៈពិសេសដល់កម្មវិធី។ ជាសំខាន់រូបិយវត្ថុនេះ អ្នកអាចសម្បូរព័ត៌មាន spans ដែលបានបង្កើតដោយស្វ័យប្រវត្តិឬដោយដៃជាមួយទ្រង់ទ្រាយចំណុចផ្សេងៗ (ដែលគេស្គាល់ថា tags ឬ metadata)។ ទ្រង់ទ្រាយទាំងនេះអាចរួមមានទិន្នន័យជាក់ស្តែងរបស់អាជីវកម្ម ការគណនាត្រឹមចន្លោះ ឬបរិបទណាមួយដែលអាចមានប្រយោជន៍សម្រាប់ស្វែងរកកំហុសឬវិភាគ ដូចជា user_id, session_id, ឬ model_version។

ឧទាហរណ៍ពីការបង្កើត traces និង spans ដោយដៃជាមួយ Langfuse Python SDK:

from langfuse import get_client
 
langfuse = get_client()
 
span = langfuse.start_span(name="my-span")
 
span.end()

ការវាយតម្លៃភ្នាក់ងារ

ការអាចសង្កេតឃើញផ្តល់មាត្រដ្ឋាន ឯណោះការវាយតម្លៃគឺជាដំណើរការវិភាគទិន្នន័យនោះ (និងអនុវត្តតេស្ត) ដើម្បីកំណត់ថាតើភ្នាក់ងារ AI កំពុងបំពេញការងារយ៉ាងល្អ និងរបៀបណាដែលអាចកែលម្អបាន។ ពោលគឺ បន្ទាប់ពីអ្នកមាន traces និង metrics នោះ តើធ្វើដូចម្តេចដើម្បីប្រើពួកវាដើម្បីវាយតម្លៃភ្នាក់ងារ និងធ្វើសំណើសម្រេចចិត្ត?

ការវាយតម្លៃទៀងទាត់មានសារៈសំខាន់ព្រោះភ្នាក់ងារ AI ជាទូទៅមិនទុកចិត្តនិងអាចផ្លាស់ប្ដូរជាមួយពេល (តាមរយៈអាប់ដេត ឬការរីកឡើងនៃអាកប្បកិរិយាម៉ូឌែល) — ពុំមានការវាយតម្លៃ អ្នកនឹងមិនដឹងថា "ភ្នាក់ងារឆ្លាហាន" របស់អ្នកកំពុងបំពេញការងារយ៉ាងល្អឬបានចុះថយ។

មានពីរប្រភេទនៃការវាយតម្លៃសម្រាប់ភ្នាក់ងារ AI: online evaluation និង offline evaluation។ ទាំងពីរមានតម្លៃ និងបិទបញ្ចូលគ្នា។ យើងជាទូទៅចាប់ផ្តើមជាមួយ offline evaluation ព្រោះនេះជាជំហានអប្បបរមាដែលចាំបាច់ មុនពេលដាក់ភ្នាក់ងារណាមួយ។

វាយតម្លៃក្រៅបណ្តាញ

នេះជាការវាយតម្លៃភ្នាក់ងារនៅក្នុងបរិយាកាសត្រួតត្រា ជារឿយៗប្រើឡើង dataset សាកល្បង មិនមែនសំណួរអ្នកប្រើនៅពេលជាក់ស្ដែង។ អ្នកប្រើ dataset ដែលបានរៀបចំដែលអ្នកដឹងពីលទ្ធផលដែលរំពឹង ឬឥរិយាបថត្រឹមត្រូវ ហើយបន្ទាប់មករត់ភ្នាក់ងាររបស់អ្នកលើនោះ។

ឧទាហរណ៍ បើអ្នកបានបង្កើតភ្នាក់ងារដោះស្រាយបញ្ហាពាក្យគណិត អ្នកអាចមាន test dataset ១០០ បញ្ហាមួយដែលមានចម្លើយដឹង។ វាយតម្លៃក្រៅបណ្ដាញត្រូវបានអនុវត្តនៅពេលអភិវឌ្ឍ (និងអាចជាផ្នែកនៃ CI/CD) ដើម្បីពិនិត្យកែលម្អ ឬការការពារការធ្លាក់ចុះ។ អត្ថប្រយោជន៍គឺវា អាចធ្វើឡើងឡើងវិញបាន និងអ្នកអាចទទួលបានមាត្រដ្ឋានភាពត្រឹមត្រូវច្បាស់លាស់ពីព្រោះអ្នកមាន ground truth។ អ្នកអាចសម្រួលសំណើរអ្នកប្រើនិងវាស់ប្រតិបត្តិការឆ្លើយតបរបស់ភ្នាក់ងារប៉ុន្តែក្រោយគោលដៅឬប្រើមាត្រដ្ឋានស្វ័យប្រវត្តិដូចបានពិពណ៌នា។

បញ្ហាសំខាន់របស់ offline eval គឺការធ្វើឲ្យ dataset សាកល្បងរបស់អ្នកពេញលេញ និងនៅតែកាន់សុពលភាព — ភ្នាក់ងារអាចអនុវត្តបានល្អលើកញ្ចប់សាកល្បងថេរ ប៉ុន្តែប្រឈមមុខនឹងសំណួរផ្សេងៗនៅក្នុងផលិតកម្ម។ ដូច្នេះ អ្នកគួរតែរក្សាសំណុំពិសេសសាកល្បងឲ្យទាន់សម័យជាមួយករណីដាច់ស្រយាលថ្មីៗ និងឧទាហរណ៍ដែលពាក់ព័ន្ធនឹងពិភពពិត។ ការលាយបញ្ចូលរវាងករណី "smoke test" តូចៗ និងសំណុំវិមាត្រធំធេងមានប្រយោជន៍៖ សំណុំតូចសម្រាប់ត្រួតពិនិត្យរហ័ស និងសំណុំធំនៅសម្រាប់មាត្រដ្ឋានទូលំទូលាយ។

វាយតម្លៃក្នុងបណ្តាញ

នេះសំដៅទៅការវាយតម្លៃភ្នាក់ងារនៅក្នុងបរិយាកាសពិត កើតឡើងក្នុងការប្រើប្រាស់ពិត ក្នុងផលិតកម្ម។ វាយតម្លៃក្នុងបណ្តាញរួមមានការតាមដានសមត្ថភាពភ្នាក់ងារលើអន្តរកម្មអ្នកប្រើពិត និងវិភាគលទ្ធផលជាបន្តបន្ទាប់។

ឧ. អ្នកអាចតាមដានអត្រាជោគជ័យ ពិន្ទុផ្ទាល់ពីអ្នកប្រើ ឬមាត្រដ្ឋានផ្សេងៗលើចរាចរណ៍ពិត។ អត្ថប្រយោជន៍នៃវាយតម្លៃក្នុងបណ្តាញគឺវា ចាប់យកអ្វីដែលអ្នកប្រហែលមិនបានរំពឹងក្នុងបរិយាកាសមន្ទីរពិសោធន៍ — អ្នកអាចឃើញភាពជ្រុលចែកម៉ូឌែល (model drift) ជាមួយពេល (បើប្រសិទ្ធភាពភ្នាក់ងារធ្លាក់ចុះពេលលំដាប់បញ្ចូលផ្លាស់ប្ដូរ) និងចាប់យកសំណួរឬស្ថានភាពអចិន្រ្តៃយ៍ដែលមិនមានក្នុងទិន្ននយ៍សាកល្បង។ វាបង្ហាញផ្ទាល់រូបភាពថាតើភ្នាក់ងារប្រព្រឹត្តខ្លួនយ៉ាងដូចម្តេចនៅក្នុងពន្ធដារ​ពិត។

វាយតម្លៃក្នុងបណ្តាញជាញឹកញាប់រួមមានការប្រមូលមតិយោបល់ទាំងបង្ហាញ និងអនិច្ច័យ ដូចបានពិភាក្សា ជាមួយនឹងការប្រតិបត្តិ shadow tests ឬ A/B tests (ដែលជារៀបចំឲ្យជំនាន់ថ្មីរត់ជារួមជាមួយនឹងជំនាន់ចាស់ ដើម្បីប្រៀបធៀប)។ បញ្ហាគឺវាអាចពិបាកក្នុងការទទួលបានស្លាក ឬពិន្ទុដែលទុកចិត្តបានសម្រាប់អន្តរកម្មរស់ — អ្នកអាចពឹងផ្អែកលើមតិយោបល់អ្នកប្រើ ឬមាត្រ downstream (ដូចជា តើអ្នកប្រើបានចុចលទ្ធផលឬអត់)។

ការរួមបញ្ចូលពីរ

វាយតម្លៃក្នុងបណ្តាញ និងក្រៅបណ្តាញមិនមែនត្រូវចែកចាយគ្នាទេ; ពួកវាបំពេញគ្នាដូចគ្នា។ ទិន្នន័យពីការត្រួតពិនិត្យក្នុងបណ្តាញ (ឧ. ប្រភេទសំណួរថ្មីៗដែលភ្នាក់ងារកำลังធ្វើការយ៉ាងមិនល្អ) អាចប្រើដើម្បីបន្ថែម និងកែលម្អសំណុំសាកល្បងក្រៅបណ្តាញ។ ផ្ទុយទៅវិញភ្នាក់ងារដែលធ្វើបានល្អក្នុងការធ្វើតេស្តក្រៅបណ្តាញអាចត្រូវបានដាក់ចេញដោយមានទំនុកចិត្តខ្ពស់ក្នុងបណ្តាញ។

ពិតណាស់ ក្រុមជាច្រើនអនុវត្តខ្សែប្រតិបត្តិ៖

evaluate offline -> deploy -> monitor online -> collect new failure cases -> add to offline dataset -> refine agent -> repeat.

បញ្ហាទូទៅ

ពេលដែលអ្នកដាក់ភ្នាក់ងារ AI ទៅផលិតកម្ម អ្នកអាចប្រឈមមុខនឹងបញ្ហាផ្សេងៗ។ នេះជាបញ្ហាទូទៅ និងដំណោះស្រាយដែលអាចធ្វើបាន៖

បញ្ហា	ដំណោះស្រាយសក្តានុពល
ភ្នាក់ងារ AI មិនអនុវត្តភារកិច្ចយ៉ាងមានស្ថេរភាព	- កែប្រែ prompt ដែលផ្តល់ទៅភ្នាក់ងារ AI; ជាក់លាក់ទៅលើគោលបំណង។ - កំណត់ទីកន្លែងដែលការបែងចែកភារកិច្ចទៅជាផ្នែកតូចៗ និងដោះស្រាយដោយភ្នាក់ងារច្រើនអាចជួយបាន។
ភ្នាក់ងារ AI រត់ចូលក្នុងវដ្ដបន្តទៀត	- ធានាថាអ្នកមានលក្ខខណ្ឌបញ្ចប់ច្បាស់លាស់ ដើម្បីឲ្យភ្នាក់ងារទទួលដឹងពេលត្រូវបញ្ឈប់ដំណើរការ។ - សម្រាប់ភារកិច្ចស្មុគស្មាញដែលទាមទារការគិតនិងផែនការ ប្រើម៉ូឌែលធំដែលមានជំនាញក្នុងការគិតវិចារ។
ការហៅឧបករណ៍ដោយភ្នាក់ងារ AI មិនប្រតិបត្តិបានល្អ	- សាកល្បង និងផ្ទៀងផ្ទាត់លទ្ធផលឧបករណ៍នៅក្រៅប្រព័ន្ធភ្នាក់ងារ។ - កែសម្រួលប៉ារ៉ាម៉ែត្រ ដែលបានកំណត់, prompt, និងឈ្មោះឧបករណ៍។
ប្រព័ន្ធភ្នាក់ងារ​ច្រើន​មិនអនុវត្តយ៉ាងមានស្ថេរភាព	- កែ prompt ដែលផ្តល់ទៅភ្នាក់ងារ និមួយៗ ដើម្បីធានាថាវាមានលក្ខណៈពិសេស និងប្រែផ្សេងពីគ្នា។ - សាងសង់ប្រព័ន្ធតាមជាន់ (hierarchical) ដោយប្រើភ្នាក់ងារ "routing" ឬ controller ដើម្បីកំណត់ថា ភ្នាក់ងារ​ដែលត្រូវបានប្រើគឺជាប់គ្នា និងសមស្រប។

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

ការគ្រប់គ្រងចំណាយ

នេះ​ជា​យុទ្ធសាស្ត្រ​ខ្លះ​ក្នុង​ការ​គ្រប់គ្រង​ចំណាយ​សម្រាប់​ការ​ដាក់ប្រើ​ភ្នាក់ងារ AI នៅក្នុងផលិតកម្ម:

ការប្រើម៉ូឌែលទំហំតូច: ម៉ូឌែលភាសាតូច (SLMs) អាចធ្វើការបានល្អលើករណីប្រើប្រាស់ជាភ្នាក់ងារ និងនឹងកាត់បន្ថយចំណាយយ៉ាងសំខាន់។ ដូចដែលបានរំលឹកមុននេះ ការបង្កើតប្រព័ន្ធវាយតម្លៃដើម្បីកំណត់ និងប្រៀបធៀបការសមត្ថភាពជាមួយម៉ូឌែលដ៏ធំគឺជាវិធីល្អបំផុតក្នុងការយល់ថាតើ SLM នឹងធ្វើបានល្អប៉ុណ្ណា សម្រាប់ករណីប្រើប្រាស់របស់អ្នក។ សូមពិចារណាការ​ប្រើ SLMs សម្រាប់ភារកិច្ចសាមញ្ញដូចជា ការបែងចែកគោលដៅ (intent classification) ឬការដកយកប៉ារ៉ាម៉ែត្រ (parameter extraction) ខណៈដែលរក្សាម៉ូឌែលធំសម្រាប់ការវិចារណាស្មុគស្មាញ។

ការប្រើម៉ូឌែលរ៉ោទ័រ: យុទ្ធសាស្ត្រស្រដៀងគ្នានេះគឺការប្រើម៉ូឌែលនានា និងទំហំផ្សេងៗគ្នា។ អ្នកអាចប្រើ LLM/SLM ឬ serverless function ដើម្បីរ៉ោតសំណើតាមកម្រិតស្មុគស្មាញទៅម៉ូឌែលដែលសមស្របបំផុត។ វានឹងជួយកាត់បន្ថយចំណាយ ខណៈដែលធានាសមត្ថភាពលើភារកិច្ចត្រឹមត្រូវផងដែរ។ ឧទាហរណ៍ រ៉ោតសំណួรงាយៗទៅម៉ូឌែលទំហំតូច និងលឿន ហើយប្រើម៉ូឌែលធំដែលមានថ្លៃសម្រាប់ភារកិច្ចវិចារណាស្មុគស្មាញតែប៉ុណ្ណោះ។

ការផ្ទុកចម្លើយក្នុង cache (Caching Responses): ការកំណត់សំណើ និងភារកិច្ចដែលមានជាញឹកញាប់ ហើយផ្តល់ចម្លើយមុនពេលពួកវាត្រូវឆ្លងតាមប្រព័ន្ធភ្នាក់ងារ របស់អ្នក គឺជាវិធីល្អក្នុងការកាត់បន្ថយបរិមាណនៃសំណើស្រដៀងគ្នា។ អ្នកក៏អាចអនុវត្តលំហូរមួយដើម្បីកំណត់ថា សំណើមួយស្រដៀងយ៉ាងដូចម្តេចនឹងសំណើដែលបានផ្ទុកក្នុង cache របស់អ្នក ដោយប្រើម៉ូឌែល AI មូលដ្ឋាន។ យុទ្ធសាស្ត្រនេះអាចកាត់បន្ថយចំណាយយ៉ាងសំខាន់សម្រាប់សំណួរដែលសួរញឹកញាប់ ឬវត្ថុធ្វើការដែលទូទៅ។

មកមើលថាវាដំណើរការយ៉ាងដូចម្តេចក្នុងការអនុវត្ត

ក្នុង example notebook of this section, យើងនឹងឃើញឧទាហរណ៍ពីរបៀបដែលយើងអាចប្រើឧបករណ៍ observability ដើម្បីតាមដាន និងវាយតម្លៃភ្នាក់ងារ​របស់យើង។

មានសំណួរបន្ថែមអំពីការដាក់ប្រើភ្នាក់ងារ AI នៅក្នុងផលិតកម្មទេ?

ចូលរួមនៅក្នុង Microsoft Foundry Discord ដើម្បីជួបជាមួយអ្នករៀនផ្សេងទៀត ចូលរួមម៉ោងពិគ្រោះយោបល់ និងទទួលចម្លើយសម្រាប់សំណួរអំពីភ្នាក់ងារ AI របស់អ្នក។

Previous Lesson

Metacognition Design Pattern

Next Lesson

Agentic Protocols

---

Disclaimer: ឯកសារ​នេះ​ត្រូវបាន​បកប្រែ​ដោយ​ប្រើ​សេវាកម្ម​បកប្រែ AI Co-op Translator. ខណៈ​ពេល​យើង​ព្យាយាម​សម្រាប់​ការត្រឹមត្រូវ សូម​សម្គាល់​ថា​ការ​បកប្រែ​ដោយ​ស្វ័យ​ប្រវត្តិ​អាច​មាន​កំហុស ឬ​មានភាព​មិន​ត្រឹមត្រូវ។ ឯកសារ​ដើម​នៅក្នុង​ភាសា​ដើម​គួរត្រូវ​បានទុក​ជា​ប្រភព​ផ្លូវការ។ សម្រាប់ព័ត៌មាន​សំខាន់ យើង​សូម​ផ្ដល់​អនុសាសន៍​ឱ្យ​ប្រើ​ការ​បកប្រែ​ដោយអ្នកបកប្រែ​ជំនាញ​មនុស្ស។ យើង​មិន​ទទួល​ខុសត្រូវចំពោះ​ការ​យល់​ច្រឡំ ឬ​ការ​បកស្រាយខុសណាមួយ​ដែល​កើត​មាន​ពី​ការ​ប្រើប្រាស់​ការ​បកប្រែ​នេះ​ទេ។