എൻഡ്-ടു-എൻഡ് പ്രൊഡക്ഷൻ: വെരിഫിക്കേഷൻ, മോണിറ്ററിംഗ്, എത്തിക്സ്

നേട്ടങ്ങൾ:

• ആശയത്തിൽ നിന്ന് നിർമ്മാണത്തിലേക്ക് ഒരു LLM ഫീച്ചർ എടുക്കുന്ന എൻഡ്-ടു-എൻഡ് ആർക്കിടെക്ചർ രൂപകൽപ്പന ചെയ്യാൻ കഴിയും
• സ്ഥിരീകരണ എൻഫോഴ്‌സ്‌മെൻ്റ്, മനുഷ്യ അംഗീകാരം, ട്രാക്കിംഗ് (ലോഗിംഗ്/മെട്രിക്‌സ്) എന്നിവയുടെ പാളികൾ സ്ഥാപിക്കുന്നു
• അതിരുകൾ നൈതികതയെയും സ്വകാര്യത തത്വങ്ങളെയും ഉൽപ്പാദന തീരുമാനങ്ങളാക്കി മാറ്റുന്നു

മുമ്പത്തെ പത്ത് യൂണിറ്റുകളിൽ, ഞങ്ങൾ ഭാഗങ്ങൾ ഓരോന്നായി പഠിച്ചു: അഭ്യർത്ഥന ഘടന, ടോക്കൺ ഇക്കണോമിക്സ്, ഫ്ലോ, സിസ്റ്റം പ്രോംപ്റ്റ്, മോഡൽ തിരഞ്ഞെടുക്കൽ, കാഷെ, ബാച്ച്, പിശക് മാനേജ്മെൻ്റ്, സുരക്ഷിത കീ, ഓട്ടോമേഷൻ. ഈ അവസാന യൂണിറ്റിൽ, ഞങ്ങൾ ഭാഗങ്ങൾ സംയോജിപ്പിച്ച് ആശയത്തിൽ നിന്ന് ഉൽപ്പാദനത്തിലേക്ക് ഒരു LLM സവിശേഷത വഹിക്കുന്ന ഹോളിസ്റ്റിക് ആർക്കിടെക്ചർ സ്ഥാപിക്കുന്നു. ഉൽപ്പാദനം ഒരു "വർക്കിംഗ് ഡെമോ" യിൽ നിന്ന് വ്യത്യസ്തമാണ്: പരിശോധന നിർബന്ധമാണ്, ഔട്ട്പുട്ട് നിരീക്ഷിക്കണം, അതിരുകളും ധാർമ്മിക തത്വങ്ങളും തീരുമാനങ്ങളിൽ ഉൾപ്പെടുത്തിയിരിക്കണം. ഈ യൂണിറ്റ് മൊഡ്യൂളിൻ്റെ കാരിയർ കോളമാണ്; മുമ്പുള്ളവരെല്ലാം ഇവിടെ ഒത്തുചേരുന്നു.

പ്രൊഡക്ഷൻ ആർക്കിടെക്ചറിൻ്റെ പാളികൾ

ഒരു സോളിഡ് എൽഎൽഎം യോഗ്യത ഏകദേശം അഞ്ച് പാളികൾ ഉൾക്കൊള്ളുന്നു:

1. ഇൻപുട്ട് ലെയർ: ഡാറ്റ ശേഖരിക്കുക, അത് വൃത്തിയാക്കുക, സെൻസിറ്റീവ് ഏരിയകൾ മാസ്ക് ചെയ്യുക, ആവശ്യമുള്ളത് മാത്രം കൈമാറുക.
2. മോഡൽ ലെയർ: ശരിയായ മോഡൽ തിരഞ്ഞെടുക്കുക (യൂണിറ്റ് 5), സിസ്റ്റം പ്രോംപ്റ്റും പാരാമീറ്ററുകളും സജ്ജമാക്കുക (യൂണിറ്റ് 4), കാഷെ (യൂണിറ്റ് 6).
3. മൂല്യനിർണ്ണയ പാളി: സ്കീമ/റൂൾ, ഉറവിടം, ആവശ്യമെങ്കിൽ മനുഷ്യ അംഗീകാരം എന്നിവയ്‌ക്കെതിരായ ഔട്ട്‌പുട്ട് പരിശോധിക്കുക.
4. പ്രവർത്തന പാളി: സാധുതയുള്ള ഔട്ട്പുട്ട് ഉപയോഗിച്ച് പ്രവർത്തനം നടത്തുക; ഉയർന്ന ഇംപാക്ട് പ്രവർത്തനങ്ങൾ ക്യാപ്ചർ ചെയ്യുക.
5. മോണിറ്ററിംഗ് ലെയർ: ഓരോ കോളും ചെലവും പിശകും ഗുണനിലവാരവും റെക്കോർഡ് ചെയ്യുകയും അളക്കുകയും ചെയ്യുക.

ഈ പാളികൾ ഒരു പൈപ്പ്ലൈൻ ആണ്; ഓരോന്നും മുമ്പത്തേതിൻ്റെ ഔട്ട്പുട്ട് പരിശോധിക്കുന്നു.

എന്തുകൊണ്ടാണ് സ്ഥിരീകരണം ആവശ്യമായി വരുന്നത്?

LLM-കൾക്ക് ഒഴുക്കുള്ളതും എന്നാൽ ചിലപ്പോൾ കൃത്യമല്ലാത്തതുമായ ഔട്ട്പുട്ട് ഉണ്ടാക്കാൻ കഴിയും. ഇതിനെ ഹാലുസിനേഷൻ എന്ന് വിളിക്കുന്നു: മോഡൽ സത്യമെന്ന് തോന്നിക്കുന്നതും എന്നാൽ അല്ലാത്തതുമായ വിവരങ്ങൾ കെട്ടിച്ചമച്ചേക്കാം. ഒരു ചാറ്റ് ഗെയിമിൽ ഇത് സഹനീയമാണ്; ഒരു പ്രൊഡക്ഷൻ സിസ്റ്റത്തിൽ (ഇൻവോയ്സ്, ആരോഗ്യം, നിയമപരമായ, ധനകാര്യം) സഹിക്കാനാവില്ല. അങ്ങനെ അത് അന്ധമായി വിശ്വസനീയമല്ലെന്ന് തെളിഞ്ഞു; സ്ഥിരീകരിച്ചിട്ടുണ്ട്.

സ്ഥിരീകരണ പാളികൾ (ആഘാതം അനുസരിച്ച് വർദ്ധിക്കുന്നു):

• ഫോർമാറ്റ്/സ്കീമ മൂല്യനിർണ്ണയം: ഔട്ട്‌പുട്ട് പ്രതീക്ഷിക്കുന്ന JSON സ്കീമയുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ? (ഘടനാപരമായ ഔട്ട്പുട്ട് ഇതിന് വലിയ തോതിൽ ഉറപ്പ് നൽകുന്നു.)
• റൂൾ/ലോജിക് സ്ഥിരീകരണം: മൂല്യങ്ങൾ ന്യായമാണോ? (തുക നെഗറ്റീവ് ആണോ, ഭാവിയിലെ തീയതിയാണോ, വിഭാഗം സാധുതയുള്ളതാണോ?)
• ഉറവിട പരിശോധന: ക്ലെയിം നൽകിയിട്ടുള്ള ഡോക്യുമെൻ്റേഷൻ അടിസ്ഥാനമാക്കിയാണോ? ഡോക്യുമെൻ്റിൽ ഇല്ലാത്ത എന്തെങ്കിലും മോഡൽ പറയുമോ?
• മാനുഷിക അംഗീകാരം: ഉയർന്ന സ്വാധീനമുള്ളതോ അവ്യക്തമായതോ ആയ തീരുമാനങ്ങൾ ഒരു വിദഗ്ദ്ധൻ അവലോകനം ചെയ്യുന്നു.

മുന്നറിയിപ്പ്: "മോഡൽ വളരെ മികച്ചതാണ്, കൂടുതൽ പരിശോധന ആവശ്യമില്ല" എന്നതാണ് ഏറ്റവും അപകടകരമായ ഉൽപ്പാദന വീഴ്ച. മോഡൽ എത്ര മികച്ചതാണെങ്കിലും, ഉയർന്ന സ്വാധീനമുള്ള തീരുമാനങ്ങളിൽ വെരിഫിക്കേഷൻ ലെയർ ഒരു സുരക്ഷാ വലയാണ്. ഒരു തെറ്റായ യാന്ത്രിക തീരുമാനം പോലും ലാഭിച്ച മുഴുവൻ സമയവും ഇല്ലാതാക്കും.

ഹ്യൂമൻ-ഇൻ-ദി-ലൂപ്പ്

എല്ലാ തീരുമാനങ്ങളും പൂർണ്ണമായും യാന്ത്രികമാകണമെന്നില്ല. ഹ്യൂമൻ-ഇൻ-ദി-ലൂപ്പ് സമീപനത്തിൽ, മോഡൽ ജോലിയെ വേഗത്തിലാക്കുകയും മനുഷ്യൻ അത് അംഗീകരിക്കുകയും ചെയ്യുന്നു. ശരിയായ ബാലൻസ് തീരുമാനത്തിൻ്റെ സ്വാധീനത്തെയും ആ ചുമതലയിലെ മോഡലിൻ്റെ വിശ്വാസ്യതയെയും ആശ്രയിച്ചിരിക്കുന്നു.

തീരുമാനത്തിൻ്റെ ആഘാതം

സമീപിക്കുക

കുറവ് (ലേബൽ നിർദ്ദേശം, ഡ്രാഫ്റ്റ്)

പൂർണ്ണ ഓട്ടോമേഷൻ; പിശക് വിലകുറഞ്ഞതും പഴയപടിയാക്കാവുന്നതുമാണ്

മീഡിയം (റൂട്ടിംഗ്, മുൻഗണന)

ഓട്ടോമേഷൻ + സാമ്പിൾ നിയന്ത്രണം

ഉയർന്നത് (പണം, കരാർ, ആരോഗ്യം, ഇല്ലാതാക്കൽ)

മനുഷ്യൻ്റെ സമ്മതം നിർബന്ധമാണ്; മോഡൽ മാത്രം നിർദ്ദേശിക്കുന്നു

നിരീക്ഷണം: നിങ്ങൾ കാണാത്തത് നിങ്ങൾക്ക് നിയന്ത്രിക്കാൻ കഴിയില്ല

നിർമ്മാണത്തിൽ, നിങ്ങൾ ഓരോ കോളും നിരീക്ഷിക്കണം. നിരീക്ഷണം കൂടാതെ, നിങ്ങൾക്ക് ചെലവ്, ഗുണമേന്മ മെച്ചപ്പെടുത്താൻ അല്ലെങ്കിൽ ഒരു പ്രശ്നം നേരത്തെ കണ്ടെത്താനാവില്ല. രേഖപ്പെടുത്താനുള്ള പ്രധാന മെട്രിക്കുകൾ:

• ഉപയോഗം/ചെലവ്: ഓരോ അഭ്യർത്ഥനയും മൊത്തം ടോക്കണുകളും, മോഡൽ വിതരണം, ദൈനംദിന ചെലവ്.
• ലേറ്റൻസി: ശരാശരി, മോശം പ്രതികരണ സമയം.
• പിശക് നിരക്ക്: 429/500 നിരക്കുകൾ, വീണ്ടും ശ്രമിക്കൽ, ഉപേക്ഷിക്കലുകൾ.
• ഗുണനിലവാരം: സ്ഥിരീകരണ ലെയറിലെ നിരസിച്ച ഔട്ട്‌പുട്ട് നിരക്ക്, മനുഷ്യ അംഗീകാരത്തിൽ തിരുത്തൽ നിരക്ക്, ഉപയോക്തൃ ഫീഡ്‌ബാക്ക്.

നുറുങ്ങ്: ലോഗുകൾ നിരീക്ഷിക്കുന്നതിന് സെൻസിറ്റീവ് ഡാറ്റ (വ്യക്തിഗത വിവരങ്ങൾ, കീകൾ) എഴുതരുത്. രഹസ്യാത്മകതയുടെ പരിധിയിലുള്ള ലോഗുകൾ പരിഗണിക്കുക; ആവശ്യമെങ്കിൽ മാസ്ക് ചെയ്തുകൊണ്ട് രേഖപ്പെടുത്തുക (യൂണിറ്റ് 9).

നൈതികതയും അതിരുകളും

സാങ്കേതിക കൃത്യത പോലെ ഉൽപ്പാദന തീരുമാനത്തിൻ്റെ ഭാഗമാണ് ധാർമ്മിക ഉത്തരവാദിത്തം:

• സുതാര്യത: ആർട്ടിഫിഷ്യൽ ഇൻ്റലിജൻസിനോടോ മനുഷ്യനോടോ ആണോ സംസാരിക്കുന്നതെന്ന് ഉപയോക്താവ് അറിഞ്ഞിരിക്കണം.
• ന്യായവും പക്ഷപാതവും: മോഡൽ അത് പരിശീലിപ്പിച്ച ഡാറ്റയിൽ നിന്ന് പക്ഷപാതം വഹിച്ചേക്കാം; ഉയർന്ന സ്വാധീനമുള്ള തീരുമാനങ്ങളിൽ (നിയമനം, ക്രെഡിറ്റ്) വിവേചനപരമായ പ്രത്യാഘാതങ്ങൾ നിരീക്ഷിക്കുക.
• ബാധ്യത: ഒരു യാന്ത്രിക തീരുമാനം ദോഷം വരുത്തിയാൽ, നിങ്ങൾ ഉത്തരവാദിയാണ്; "മോഡൽ അങ്ങനെ പറഞ്ഞു" ഒരു പ്രതിരോധമല്ല.
• പരിധികളുടെ സ്വീകാര്യത: മോഡലിന് ചില ജോലികൾ വിശ്വസനീയമായി ചെയ്യാൻ കഴിയില്ല; അവയെ യാന്ത്രികമാക്കാതിരിക്കുന്നതും ഒരു ഡിസൈൻ തീരുമാനമാണ്.

പകർത്താവുന്ന ടെംപ്ലേറ്റുകൾ

# മൂല്യനിർണ്ണയ ചെക്ക്‌ലിസ്റ്റ് (ഔട്ട്‌പുട്ട് ജനറേഷന് ശേഷം)1) സ്കീമ സാധുവാണോ? (ഘടനാപരമായ ഔട്ട്‌പുട്ട് മൂല്യനിർണ്ണയം)2) മൂല്യങ്ങൾ അർത്ഥമാക്കുന്നുണ്ടോ? (റൂൾ ചെക്ക്: ശ്രേണി, തീയതി, enum)3) ക്ലെയിം ഉറവിടത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണോ? (രേഖയിൽ ഇല്ലെങ്കിൽ നിരസിക്കുക)4) ആഘാതം കൂടുതലാണോ? → മാനുഷിക അംഗീകാരത്തിനായി അയയ്‌ക്കുക5) എല്ലാം പാസായെങ്കിൽ → പ്രവർത്തനം അനുവദിക്കുക, സംരക്ഷിക്കുക

# നൽകിയിരിക്കുന്ന ഡോക്യുമെൻ്റിലെ വിവരങ്ങളിൽ മാത്രം ആശ്രയിക്കുന്ന ഉറവിടത്തെ ആശ്രയിക്കുന്ന സിസ്റ്റം പ്രോംപ്റ്റ്. പ്രമാണത്തിൽ ഇല്ലാത്തതൊന്നും ചേർക്കരുത്. ഒരു വിവരം പ്രമാണത്തിൽ ഇല്ലെങ്കിൽ, "രേഖയിൽ കണ്ടെത്തിയില്ല" എന്ന് എഴുതുക. ഒരിക്കലും കാര്യങ്ങൾ ഊഹിക്കുകയോ ഉണ്ടാക്കുകയോ ചെയ്യരുത്.

# മനുഷ്യ അംഗീകാര പരിധി (തീരുമാന നിയമം)IF തീരുമാനം_തരം [പണം, കരാർ, ഇല്ലാതാക്കൽ, ആരോഗ്യം] → മാനുഷിക അംഗീകാരം നിർബന്ധമാണ്IF model_trust < പരിധി അല്ലെങ്കിൽ മൂല്യനിർണ്ണയം "അനിശ്ചിതത്വം" → മനുഷ്യൻ്റെ അംഗീകാരത്തിന് സമർപ്പിക്കുകOTHER → സ്വയമേവ പ്രയോഗിക്കുക + സാമ്പിൾ നിയന്ത്രണം

# ട്രേസ് ലോഗ് ടെംപ്ലേറ്റ് (സെൻസിറ്റീവ് ഡാറ്റ എഴുതുന്നു){ "സമയം":"...", "മോഡൽ":"...", "ഇൻപുട്ട്_ടോക്കൺ":..., "ഔട്ട്‌പുട്ട്_ടോക്കൺ":..., "delay_ms":..., "stop_reason":"...", "ആധികാരികത":"പാസായി|നിരസിക്കപ്പെട്ടു":", ":co... ഒരിക്കലും എഴുതിയിട്ടില്ല

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ് (ഉൽപാദന വിശ്വാസ്യത)

# വീക്ക് (പരിശോധിച്ചിട്ടില്ല, ഉറവിടമില്ല, സ്വയമേവ ബാധകമല്ല) ഈ അഭ്യർത്ഥന വിലയിരുത്തി, റീഫണ്ട് തീരുമാനം എടുത്ത് അപേക്ഷിക്കുക.

# STRONG (ഉറവിടാധിഷ്‌ഠിതം, ശുപാർശ ജനറേറ്റുചെയ്യുന്നു, മാനുഷിക അംഗീകാരത്തിലേക്ക് പോകുന്നു) റിട്ടേൺ പോളിസി ഡോക്യുമെൻ്റിനെ അടിസ്ഥാനമാക്കി മാത്രം ഈ റിട്ടേൺ അഭ്യർത്ഥന വിലയിരുത്തുക. ന്യായീകരണത്തോട് കൂടിയ തീരുമാനം ശുപാർശ ചെയ്യുക, എന്നാൽ നടപ്പിലാക്കരുത്: {"ശുപാർശ":"അംഗീകരിക്കുക|നിരസിക്കുക","കാരണം":"...","policy_clause":"..."}. പോളിസി ഡോക്യുമെൻ്റിൽ വ്യക്തമായ അടിസ്ഥാനമില്ലെങ്കിൽ, "വ്യക്തമല്ലാത്തത്" നൽകുക. അന്തിമ തീരുമാനം ഒരു പ്രതിനിധി അംഗീകരിക്കും.

ശക്തമായ പതിപ്പ്; ഇത് തീരുമാനത്തെ ഉറവിടത്തിലേക്ക് ആട്രിബ്യൂട്ട് ചെയ്യുന്നു, മോഡലിനെ "ചെയ്യുന്നയാൾ" എന്നതിലുപരി "നിർദ്ദേശകൻ" ആയി സ്ഥാപിക്കുകയും മനുഷ്യൻ്റെ അംഗീകാരത്തിന് പിന്നിൽ ഉയർന്ന സ്വാധീനം ചെലുത്തുകയും ചെയ്യുന്നു. ഉൽപ്പാദന വിശ്വാസ്യതയുടെ സാരാംശം ഇതാണ്.

മൂന്ന് മിനി കേസുകൾ

കേസ് 1 - സ്ഥിരീകരണ ലെയർ സംരക്ഷിച്ച ദിവസം. ഇടപാട് വിവരണങ്ങളെ തരംതിരിക്കുകയും ഓട്ടോമാറ്റിക് അക്കൗണ്ടിംഗ് റെക്കോർഡുകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്ന മോഡൽ ഒരു ഫിൻടെക്കിന് ഉണ്ടായിരുന്നു. അവർ റൂൾ മൂല്യനിർണ്ണയം ചേർത്തു: ഒരിക്കൽ മോഡൽ തുക തെറ്റായി ഔട്ട്പുട്ട് ചെയ്താൽ (ഡോക്യുമെൻ്റിൽ 1,250 എന്നതിന് പകരം 12,500), "തുക ഡോക്യുമെൻ്റുമായി പൊരുത്തപ്പെടുന്നില്ല" എന്ന നിയമം ഔട്ട്പുട്ടിനെ നിരസിക്കുകയും റെക്കോർഡ് മനുഷ്യനിലേക്ക് വീഴുകയും ചെയ്തു. സ്ഥിരീകരണം ഇല്ലെങ്കിൽ, തെറ്റായ റെക്കോർഡ് നിശബ്ദമായി സിസ്റ്റത്തിൽ പ്രവേശിക്കും.

കേസ് 2 - ഒളിച്ചോടിയയാൾ നിരീക്ഷണത്തിൽ കുടുങ്ങി. ഒരു SaaS ടീം ഒരു നിരീക്ഷണ പാനൽ രൂപീകരിച്ചു; ഒരു പ്രഭാതത്തിൽ പ്രതിദിന ചെലവ് മൂന്നിരട്ടിയായി. ഒരു ക്ലയൻ്റ് ഒരു ലൂപ്പിൽ പ്രവേശിച്ച് ഒരേ അഭ്യർത്ഥന ആയിരക്കണക്കിന് തവണ അയച്ചതായി ലോഗുകളിൽ നിന്ന് കാണപ്പെട്ടു. അവർ ക്വാട്ടയും ഡ്യൂപ്ലിക്കേഷനും ചേർത്തു; മണിക്കൂറുകൾക്കകം പ്രശ്നം പരിഹരിച്ചു. ട്രാക്ക് ചെയ്യാതെ, മാസാവസാനം ബിൽ അതിശയിപ്പിക്കുന്നതാണ്.

കേസ് 3 - പരിധി അംഗീകരിക്കുന്നു. ഒരു ഹെൽത്ത് കെയർ സ്റ്റാർട്ടപ്പ് ഒരു രോഗനിർണ്ണയ ശുപാർശ പൂർണ്ണമായും സ്വയമേവ തയ്യാറാക്കി രോഗിയെ കാണിക്കാൻ പദ്ധതിയിട്ടിരുന്നു. ഒരു ധാർമ്മിക ബാധ്യതാ അവലോകനത്തിൽ, ഇത് പരിധിയില്ലാത്തതാണെന്ന് അവർ തീരുമാനിച്ചു: മോഡൽ ഒരു ഡോക്ടർക്ക് ഒരു സംഗ്രഹവും സാധ്യമായ പോയിൻ്റുകളും മാത്രമേ നൽകുന്നുള്ളൂ, ഫിസിഷ്യൻ രോഗനിർണയം നടത്തുന്നു. ഒരു ജോലി ഓട്ടോമേറ്റ് ചെയ്യാതിരിക്കുന്നതും മുതിർന്ന ഒരു ഡിസൈൻ തീരുമാനമാണ്.

സാധാരണ തെറ്റുകൾ

• മൂല്യനിർണ്ണയം ഒഴിവാക്കുന്നു: "മോഡൽ നല്ലതാണ്" എന്ന് പറഞ്ഞ് ഔട്ട്പുട്ട് അന്ധമായി പ്രയോഗിക്കുന്നു.
• ഉയർന്ന സ്വാധീനമുള്ള തീരുമാനം ഓട്ടോമേറ്റ് ചെയ്യുന്നു: പണം/ആരോഗ്യം/നിയമം എന്നിവയിൽ മനുഷ്യൻ്റെ അംഗീകാരം അത്യാവശ്യമാണ്.
• മോണിറ്ററിംഗ് അല്ല: ചെലവും ഗുണനിലവാര പ്രശ്നങ്ങളും വൈകിയാണ് കണ്ടെത്തുന്നത്.
• ലോഗുകളിലേക്ക് സെൻസിറ്റീവ് ഡാറ്റ എഴുതുന്നു: സ്വകാര്യത ലംഘനം; ഇത് മാസ്ക് ചെയ്ത് സംരക്ഷിക്കുക.
• ഉറവിടത്തെ ആശ്രയിക്കാൻ ശ്രമിക്കുന്നില്ല: ഡോക്യുമെൻ്റിൽ ഇല്ലാത്തത് മോഡൽ ഉണ്ടാക്കിയേക്കാം.
• പരിധികൾ അവഗണിക്കുന്നു: ചില ജോലികൾ ഓട്ടോമേറ്റ് ചെയ്യാതിരിക്കുന്നതാണ് ശരിയായ തീരുമാനം; സുതാര്യതയും ഉത്തരവാദിത്തവും നിങ്ങളുടേതാണ്.

ആഴത്തിലുള്ളത്: റിലീസ് മാനേജ്മെൻ്റ്, റോൾബാക്ക്, ഇൻക്രിമെൻ്റൽ ഡിപ്ലോയ്മെൻ്റ്

നിർമ്മാണത്തിലേക്ക് ഒരു LLM ഫീച്ചർ എടുക്കുന്നത് അത് സജ്ജീകരിച്ച് അതിനെക്കുറിച്ച് മറക്കുന്നതിനല്ല; കാലക്രമേണ ഒരു ലൈവ് സിസ്റ്റം സുരക്ഷിതമായി പരിഷ്കരിക്കുക എന്നതാണ്. ഇതിന് മൂന്ന് തൂണുകൾ ഉണ്ട്.

പതിപ്പ്. നിങ്ങളുടെ സിസ്റ്റം പ്രോംപ്റ്റ്, മോഡൽ തിരഞ്ഞെടുക്കൽ, സ്ഥിരീകരണ നിയമങ്ങൾ എന്നിവ കാലത്തിനനുസരിച്ച് മാറുന്നു. ഓരോ പ്രധാന മാറ്റവും പതിപ്പിച്ച് ഏത് പതിപ്പാണ് തത്സമയം എന്ന് രേഖപ്പെടുത്തുക. ഒരു ദിവസം ഗുണനിലവാരം കുറയുകയാണെങ്കിൽ, "ഞങ്ങൾ എന്താണ് മാറ്റിയത്?" മിനിറ്റുകൾക്കുള്ളിൽ നിങ്ങൾക്ക് ചോദ്യത്തിന് ഉത്തരം നൽകാൻ കഴിയണം. ഒരു പതിപ്പില്ലാത്ത സിസ്റ്റത്തിൽ, ഒരു റിഗ്രഷൻ്റെ മൂലകാരണം കണ്ടെത്തുന്നതിന് ദിവസങ്ങളെടുക്കും.

റോൾബാക്ക്. ഒരു പുതിയ പ്രോംപ്റ്റോ മോഡലോ തത്സമയത്തിൽ പ്രതീക്ഷിച്ചതിലും മോശമായി പെരുമാറുകയാണെങ്കിൽ, നിങ്ങൾക്ക് മുമ്പത്തെ അറിയപ്പെടുന്ന പതിപ്പിലേക്ക് വേഗത്തിൽ മടങ്ങാൻ കഴിയും. ഒരു റോൾബാക്ക് പ്ലാനില്ലാത്ത മാറ്റം ഒരു തത്സമയ റിസ്ക് അന്ധമായി സ്വീകരിക്കുന്നതാണ്. "ഞാൻ എന്തെങ്കിലും മാറ്റി, അത് മോശമായി, എനിക്ക് തിരികെ പോകാൻ കഴിയില്ല" എന്നതാണ് ഏറ്റവും ചെലവേറിയ നിർമ്മാണ രംഗം.

ക്രമാനുഗതമായ റോൾഔട്ട്. എല്ലാ ട്രാഫിക്കിലും ഒരേസമയം മാറ്റം വരുത്തുന്നതിനുപകരം, നിങ്ങൾ ആദ്യം അത് ഒരു ചെറിയ ശതമാനത്തിലേക്ക് (ഉദാ. 5%) ഉരുട്ടി, അളവുകൾ (ഗുണനിലവാരം, ചെലവ്, പിശകുകൾ) നിരീക്ഷിക്കുക. ഇത് നല്ലതാണെങ്കിൽ, നിങ്ങൾ ശതമാനം വർദ്ധിപ്പിക്കുക; ഇത് മോശമാണെങ്കിൽ, ഒരു ചെറിയ വിഭാഗത്തെ മാത്രം ബാധിച്ചാൽ നിങ്ങൾക്കത് തിരികെ ലഭിക്കും. ഇത് അപകടസാധ്യതയെ വളരെയധികം പരിമിതപ്പെടുത്തുന്നു.

ഈ മൂന്ന് സമ്പ്രദായങ്ങളും മുമ്പത്തെ എല്ലാ യൂണിറ്റുകളിൽ നിന്നുമുള്ള സാങ്കേതിക വിദ്യകൾ സംയോജിപ്പിക്കുന്നു: eval (യൂണിറ്റ് 5) അളവുകൾ മുൻകൂട്ടി മാറ്റുന്നു, നിരീക്ഷണം (ഈ യൂണിറ്റ്) പ്രചരിക്കുമ്പോൾ മുൻകൂട്ടി മുന്നറിയിപ്പ് നൽകുന്നു, സ്ഥിരീകരണ പാളി അവ പ്രവർത്തനക്ഷമമാകുന്നതിന് മുമ്പ് തെറ്റായ ഔട്ട്പുട്ടുകൾ പിടിക്കുന്നു. ഉൽപ്പാദനം ഒരൊറ്റ ശരിയായ സജ്ജീകരണമല്ല; ആത്മവിശ്വാസത്തോടെ അളക്കുകയും നിരീക്ഷിക്കുകയും മാറ്റുകയും ചെയ്യുന്ന തുടർച്ചയായ അച്ചടക്കമാണിത്. മുഴുവൻ മൊഡ്യൂളും ഈ അച്ചടക്കം സ്ഥാപിക്കാനുള്ളതാണ്.

ചുരുക്കത്തിൽ

പ്രൊഡക്ഷൻ ഒരു വർക്കിംഗ് ഡെമോയെക്കാൾ കൂടുതലാണ്: ഇത് ഇൻപുട്ട്, മോഡൽ, വെരിഫിക്കേഷൻ, ആക്ഷൻ, മോണിറ്ററിംഗ് ലെയറുകളുടെ ഒരു പൈപ്പ് ലൈനാണ്. പരിശോധന കൂടാതെ ഔട്ട്പുട്ട് വിശ്വസനീയമല്ല; ഉയർന്ന സ്വാധീനമുള്ള തീരുമാനങ്ങൾ മനുഷ്യൻ്റെ അംഗീകാരവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു; ഓരോ കോളും ചെലവ്, പിശകുകൾ, ഗുണനിലവാരം എന്നിവയ്ക്കായി നിരീക്ഷിക്കുന്നു. നൈതികത, സുതാര്യത, പക്ഷപാത നിയന്ത്രണം, ഉത്തരവാദിത്തം, പരിധികളുടെ സ്വീകാര്യത എന്നിവ സാങ്കേതിക തീരുമാനങ്ങളിൽ അവിഭാജ്യമാണ്. ഈ മൊഡ്യൂളിൽ പഠിക്കുന്ന ഓരോ ഭാഗവും ഈ സമഗ്രമായ രൂപകൽപ്പനയിൽ ഒത്തുചേരുന്നു.

ആപ്ലിക്കേഷൻ ടാസ്ക്

ഒരു LLM ഫീച്ചർ എൻഡ്-ടു-എൻഡ് ഡിസൈൻ ചെയ്യുക. (1) നിങ്ങളുടെ നിർദ്ദിഷ്ട ടാസ്ക്കിനായി അഞ്ച് ലെയറുകൾ (ഇൻപുട്ട്, മോഡൽ, വെരിഫിക്കേഷൻ, ആക്ഷൻ, മോണിറ്ററിംഗ്) പൂരിപ്പിക്കുക. (2) ഏത് തീരുമാനങ്ങൾക്ക് മനുഷ്യൻ്റെ അംഗീകാരം ആവശ്യമാണ് എന്ന് സ്വാധീനം ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുക. (3) കുറഞ്ഞത് മൂന്ന് മൂല്യനിർണ്ണയ ചെക്കുകളെങ്കിലും എഴുതുക (സ്കീമ, റൂൾ, ഉറവിടം). (4) നിങ്ങൾ ട്രാക്ക് ചെയ്യുന്ന പ്രധാന മെട്രിക്കുകളും നിങ്ങൾ ലോഗിൻ ചെയ്യാത്തതും നിർണ്ണയിക്കുക. (5) ഈ ഫീച്ചറിൽ നിങ്ങൾ അംഗീകരിക്കുന്ന ഒരു പരിധിയും നൈതിക തത്വവും എഴുതുക.

ചെക്ക്ലിസ്റ്റ്

• [ ] എനിക്ക് പ്രൊഡക്ഷൻ പൈപ്പ് ലൈനിൻ്റെ അഞ്ച് പാളികൾ രൂപകൽപ്പന ചെയ്യാൻ കഴിയും.
• [ ] എനിക്ക് സ്കീമ, റൂൾ, സോഴ്സ് എന്നിവയ്ക്കെതിരായ ഔട്ട്പുട്ട് സാധൂകരിക്കാനാകും.
• [ ] തീരുമാനത്തിൻ്റെ ആഘാതത്തെ അടിസ്ഥാനമാക്കി എനിക്ക് ഒരു മനുഷ്യ അംഗീകാര പരിധി സജ്ജീകരിക്കാനാകും.
• [ ] ഞാൻ ചെലവ്, പിശക്, ഗുണനിലവാരം എന്നിവ നിരീക്ഷിക്കുകയും ലോഗുകളിൽ സെൻസിറ്റീവ് ഡാറ്റ എഴുതാതിരിക്കുകയും ചെയ്യുന്നു.
• [ ] എനിക്ക് ധാർമ്മികത, ഉത്തരവാദിത്തം, അതിരുകൾ എന്നിവ ഉൽപ്പാദന തീരുമാനങ്ങളാക്കി മാറ്റാൻ കഴിയും.

മൊഡ്യൂൾ പരീക്ഷ

1. ഒരു LLM ചാറ്റ് API-ൽ 'സിസ്റ്റം' റോൾ എന്താണ് ചെയ്യുന്നത്?

• എ) മുഴുവൻ സംഭാഷണത്തിലുടനീളം ബാധകമായ സ്ഥിരമായ നിർദ്ദേശങ്ങളും പെരുമാറ്റ നിയമങ്ങളും മോഡലിന് നൽകുന്നു ✔
• ബി) ഉപയോക്താവ് എഴുതിയ അവസാന ചോദ്യം സൂക്ഷിക്കുന്നു
• സി) മോഡൽ നിർമ്മിച്ച പ്രതികരണം സംഭരിക്കുന്നു
• D) API കീ എൻക്രിപ്റ്റ് ചെയ്യുന്നു

വിവരണം: സിസ്റ്റം റോൾ മോഡലിന് സ്ഥിരമായ നിർദ്ദേശങ്ങളും വ്യക്തിത്വവും മുഴുവൻ സംഭാഷണത്തിലുടനീളം ബാധകമായ നിയമങ്ങളും നൽകുന്നു; ഇത് ഉപയോക്തൃ സന്ദേശങ്ങളിൽ നിന്ന് വേറിട്ട് ഉയർന്ന തലത്തിലുള്ള റീഡയറക്‌ടാണ്.

2. ഒരു API അഭ്യർത്ഥനയിൽ ഓരോ തവണയും സംഭാഷണ ചരിത്രം (മുമ്പത്തെ സന്ദേശങ്ങൾ) വീണ്ടും അയയ്ക്കുന്നത് എന്തുകൊണ്ട്?

• എ) സെർവർ ചരിത്രം ഇല്ലാതാക്കുന്നതിനാൽ ബാക്കപ്പ് ചെയ്യേണ്ടത് ആവശ്യമാണ്
• ബി) എപിഐ കോളുകൾ നിലയില്ലാത്തതാണ്; ✔ മോഡൽ ചരിത്രം ഓർക്കാത്തതിനാൽ ഓരോ അഭ്യർത്ഥനയിലും സന്ദർഭം വീണ്ടും അയയ്ക്കുന്നു
• സി) ഇൻവോയ്‌സിന് മാത്രം ആവശ്യമാണ്, മോഡലിനെ ബാധിക്കില്ല
• ഡി) പ്രതികരണം മന്ദഗതിയിലാകാതിരിക്കാൻ ചരിത്രം അയയ്ക്കുന്നത് നിർബന്ധമാണ്

വിശദീകരണം: LLM API കോളുകൾ അവസ്ഥയില്ലാത്തതാണ്; മോഡൽ മുമ്പത്തെ റൗണ്ടുകൾ ഓർക്കുന്നില്ല, അതിനാൽ സന്ദർഭം സംരക്ഷിക്കുന്നതിനുള്ള എല്ലാ അഭ്യർത്ഥനയിലും പ്രസക്തമായ എല്ലാ ചരിത്രവും വീണ്ടും അയയ്ക്കുന്നു.

3. LLM വിലനിർണ്ണയത്തിൽ ഒരു 'ടോക്കൺ' എന്താണ്?

• A) API-യിൽ ലോഗിൻ ചെയ്യാൻ ഉപയോഗിക്കുന്ന ഒറ്റത്തവണ പാസ്‌വേഡ്
• ബി) ഓരോ അഭ്യർത്ഥനയിലും ഒരു നിശ്ചിത ഫീസ് അടച്ചു
• സി) മോഡൽ ടെക്സ്റ്റ് പ്രോസസ്സ് ചെയ്യുന്ന ഏറ്റവും ചെറിയ യൂണിറ്റ്; സാധാരണയായി പദഭാഗവുമായി പൊരുത്തപ്പെടുന്നു ✔
• D) ഔട്ട്പുട്ടിൻ്റെ ദൈർഘ്യം മാത്രം അളക്കുന്ന ഒരു യൂണിറ്റ്

വിവരണം: മോഡൽ ടെക്സ്റ്റ് പ്രോസസ്സ് ചെയ്യുന്ന ഏറ്റവും ചെറിയ യൂണിറ്റാണ് ടോക്കൺ; ഇത് സാധാരണയായി ഒരു പദത്തിൻ്റെ ഒരു ശകലവുമായി പൊരുത്തപ്പെടുന്നു, കൂടാതെ ഇൻപുട്ടും ഔട്ട്പുട്ടും ടോക്കണുകളുടെ എണ്ണത്തെ അടിസ്ഥാനമാക്കി ചാർജ് ചെയ്യപ്പെടും.

4. മിക്ക LLM ദാതാക്കളിലും ഇൻപുട്ട് ടോക്കണുകളേക്കാൾ വില കൂടുതലാണ് ഔട്ട്പുട്ട് ടോക്കണുകൾ?

• എ) ഔട്ട്പുട്ട് ടോക്കണുകൾ എല്ലായ്പ്പോഴും ഇൻപുട്ടിനെക്കാൾ ദൈർഘ്യമേറിയതാണ്
• ബി) ഇൻപുട്ട് ടോക്കണുകൾ സൗജന്യമാണ്
• സി) ഔട്ട്‌പുട്ട് ടോക്കണുകൾ ഇൻറർനെറ്റിലൂടെ രണ്ടുതവണ അയയ്ക്കുന്നു
• D) യൂണിറ്റ് ചെലവ് കൂടുതലാണ്, കാരണം ഔട്ട്‌പുട്ട് ഉൽപ്പാദനത്തിന് ഓരോ ടോക്കണിനും അധിക കണക്കുകൂട്ടലുകൾ ആവശ്യമാണ് ✔

വിവരണം: ഓരോ ഔട്ട്‌പുട്ട് ടോക്കണുകൾക്കും ഘട്ടം ഘട്ടമായുള്ള ജനറേഷൻ (കമ്പ്യൂട്ടേഷൻ) നടത്താൻ മോഡൽ ആവശ്യമാണ്; ഈ ഉൽപ്പാദനച്ചെലവ് ഒറ്റയടിക്ക് ഇൻപുട്ട് പ്രോസസ്സ് ചെയ്യുന്നതിനേക്കാൾ കൂടുതലാണ്, അതിനാൽ ഔട്ട്പുട്ട് യൂണിറ്റ് വില സാധാരണയായി കൂടുതലാണ്.

5. ഏത് സാഹചര്യത്തിലാണ് സ്ട്രീമിംഗ് ഉപയോഗിക്കുന്നത് ഏറ്റവും പ്രയോജനപ്രദം?

• എ) നീണ്ട ഉത്തരങ്ങളിൽ; മനസ്സിലാക്കിയ കാലതാമസം കുറയ്ക്കുകയും സമയപരിധി തടയുകയും ചെയ്യുന്നു ✔
• ബി) വളരെ ഹ്രസ്വമായ ഒറ്റവാക്കിൽ മാത്രം
• സി) ചെലവ് പൂജ്യമായി കുറയ്ക്കുക
• D) API കീ മറയ്ക്കാൻ

വിവരണം: ദൈർഘ്യമേറിയ പ്രതികരണങ്ങളിൽ, ആദ്യ വാക്കുകൾ ഉടനടി ദൃശ്യമാക്കുന്നതിലൂടെ സ്ട്രീമിംഗ് തിരിച്ചറിയുന്ന ലേറ്റൻസി കുറയ്ക്കുകയും വലിയ max_tokens മൂല്യങ്ങളിൽ HTTP സമയപരിധി തടയുകയും ചെയ്യുന്നു.

6. ആധുനിക മോഡലുകളിൽ 'പ്രയത്നം' പാരാമീറ്റർ വർദ്ധിപ്പിക്കുന്നത് പൊതുവെ എന്ത് ബാധിക്കുന്നു?

• എ) ഉത്തരം എപ്പോഴും ചുരുക്കുക
• B) API കീ യാന്ത്രികമായി തിരിക്കുന്നു
• സി) ഇത് ഇൻപുട്ട് ടോക്കൺ വില കുറയ്ക്കുന്നു
• ഡി) ചിന്തയുടെ ആഴവും ടോക്കൺ ചെലവും വർദ്ധിപ്പിക്കുന്നു; ഇത് ഗുണനിലവാരം മെച്ചപ്പെടുത്തിയേക്കാം, എന്നാൽ ഇത് കാലതാമസവും ചെലവും വർദ്ധിപ്പിക്കുന്നു ✔

വിവരണം: ഒരു ടാസ്‌ക്കിനെക്കുറിച്ച് മോഡൽ എത്ര ആഴത്തിൽ ചിന്തിക്കുമെന്നും അത് എത്ര ടോക്കണുകൾ ചെലവഴിക്കുമെന്നും പരിശ്രമത്തിൻ്റെ പാരാമീറ്റർ ക്രമീകരിക്കുന്നു; അപ്‌ഗ്രേഡുചെയ്യുന്നത് ഗുണനിലവാരം മെച്ചപ്പെടുത്തിയേക്കാം, എന്നാൽ ഇത് കാലതാമസവും ചെലവും വർദ്ധിപ്പിക്കുന്നു. ലളിതമായ ജോലികൾക്ക്, കുറഞ്ഞ പരിശ്രമം മതിയാകും.

7. ലളിതവും ഉയർന്ന അളവിലുള്ള വർഗ്ഗീകരണ ടാസ്ക്കിലേക്കുള്ള ഏറ്റവും ചെലവ് കുറഞ്ഞ സമീപനം എന്താണ്?

• എ) എപ്പോഴും ഏറ്റവും ചെലവേറിയതും ശക്തവുമായ മോഡൽ ഉപയോഗിക്കുക
• ബി) ഓരോ അഭ്യർത്ഥനയ്ക്കും ഒരേ സമയം എല്ലാ മോഡലുകളേയും വിളിക്കുന്നു
• സി) ഒരു ചെറിയ eval ഉപയോഗിച്ച് പരിശോധിച്ച് ചുമതല നിർവഹിക്കുന്ന ഏറ്റവും ഭാരം കുറഞ്ഞ/വിലകുറഞ്ഞ മോഡൽ തിരഞ്ഞെടുക്കുന്നു ✔
• D) max_tokens മൂല്യം അനാവശ്യമായി വളരെ ഉയർന്ന നിലയിൽ നിലനിർത്തുന്നു

വിശദീകരണം: ടാസ്‌ക് സങ്കീർണ്ണമല്ലെങ്കിൽ, ഏറ്റവും ചെലവേറിയതും ശക്തവുമായ മോഡൽ ഉപയോഗിക്കുന്നതിനുപകരം ടാസ്‌ക് എളുപ്പത്തിൽ പൂർത്തിയാക്കുന്ന വേഗതയേറിയതും വിലകുറഞ്ഞതുമായ മോഡൽ തിരഞ്ഞെടുക്കുന്നത് (ഉദാ: ഹൈക്കു ക്ലാസ്) ചെലവ് ഗണ്യമായി കുറയ്ക്കും.

8. ഏത് സാഹചര്യത്തിലാണ് പ്രോംപ്റ്റ് കാഷിംഗ് ചെലവ് ഏറ്റവും കുറയ്ക്കുന്നത്?

• എ) വലുതും സ്ഥിരവുമായ സന്ദർഭം പല അഭ്യർത്ഥനകളിലും ആവർത്തിച്ച് ഉപയോഗിക്കുമ്പോൾ ✔
• ബി) ഓരോ അഭ്യർത്ഥനയ്‌ക്കൊപ്പവും തികച്ചും വ്യത്യസ്തമായ ഒരു വാചകം അയയ്‌ക്കുമ്പോൾ
• സി) ഒരൊറ്റ അഭ്യർത്ഥന മാത്രം ചെയ്യുമ്പോൾ
• ഡി) ഔട്ട്പുട്ട് ടോക്കണുകൾ കുറയ്ക്കുന്നതിന്

വിവരണം: കാഷിംഗ് ഒരു പ്രിഫിക്സ് പൊരുത്തം; നിരവധി അഭ്യർത്ഥനകളിലുടനീളം വലിയതും മാറ്റമില്ലാത്തതുമായ സന്ദർഭം (സിസ്റ്റം പ്രോംപ്റ്റ്, പ്രമാണങ്ങൾ) വീണ്ടും ഉപയോഗിക്കുന്ന സന്ദർഭങ്ങളിൽ, കാഷെയിൽ നിന്ന് വായിക്കുന്നത് പൂർണ്ണ വിലയുടെ ഒരു ചെറിയ ഭാഗം (~0.1x) ആണ്.

9. പ്രോംപ്റ്റ് കാഷെ ഹിറ്റാകുന്ന തരത്തിൽ ഞാൻ എങ്ങനെയാണ് പ്രോംപ്റ്റ് എഡിറ്റ് ചെയ്യേണ്ടത്?

• എ) തുടക്കത്തിൽ വേരിയബിൾ ഉള്ളടക്കവും അവസാനം സ്ഥിരമായ ഉള്ളടക്കവും ഇടുക
• ബി) ഓരോ അഭ്യർത്ഥനയ്ക്കും സിസ്റ്റം പ്രോംപ്റ്റിൽ നിലവിലെ തീയതിയും സമയവും ഉൾപ്പെടുത്തുക
• സി) സ്ഥിരമായ ഉള്ളടക്കം (സിസ്റ്റം പ്രോംപ്റ്റ്, ഡോക്യുമെൻ്റുകൾ) തുടക്കത്തിലും വേരിയബിൾ ഉള്ളടക്കം അവസാനം ✔
• D) ഓരോ അഭ്യർത്ഥനയ്‌ക്കൊപ്പവും ടൂൾ ലിസ്റ്റിൻ്റെ ക്രമം മാറ്റുന്നു

വിശദീകരണം: കാഷെ ഒരു പ്രിഫിക്സ് പൊരുത്തം ആയതിനാൽ, സ്ഥിരമായ/മാറ്റമില്ലാത്ത ഉള്ളടക്കം (സിസ്റ്റം പ്രോംപ്റ്റ്, പ്രമാണങ്ങൾ) ആരംഭിക്കുന്നു; വേരിയബിൾ ഉള്ളടക്കം (തീയതി, ഉപയോക്തൃ ചോദ്യം, അഭ്യർത്ഥന ഐഡി) അവസാനം ഇട്ടു. തുടക്കത്തിൽ ഒരു ബൈറ്റ് മാറിയാലും കാഷെ അസാധുവാകും.

10. ഏത് തരത്തിലുള്ള ജോലിഭാരത്തിനാണ് ബാച്ച് പ്രോസസ്സിംഗ് ഏറ്റവും അനുയോജ്യം?

• എ) ഉപയോക്താവ് സ്ക്രീനിൽ തൽക്ഷണ പ്രതികരണം പ്രതീക്ഷിക്കുന്ന തത്സമയ ചാറ്റ്
• ബി) ഒരു ചെറിയ ചോദ്യം മാത്രം
• സി) API കീ ജനറേറ്റുചെയ്യുന്നു
• D) കാലതാമസം സഹിഷ്ണുതയുള്ളതും വലിയ വോളിയവും ഉടനടി ഫലങ്ങൾ ആവശ്യമില്ലാത്തതുമായ ജോലികൾ ✔

വിവരണം: ഉടനടി പ്രതികരണം ആവശ്യമില്ലാത്തതും കാലതാമസം സഹിക്കാവുന്നതുമായ വലിയ അളവിലുള്ള ജോലികൾക്ക് ബാച്ച് പ്രോസസ്സിംഗ് അനുയോജ്യമാണ്; കുറച്ച് സമയത്തിന് ശേഷം ഫലങ്ങൾ ഡെലിവർ ചെയ്യപ്പെടും, എന്നാൽ യൂണിറ്റ് ചെലവ് സാധാരണയായി കുറവാണ്.

11. ഒരു ബാച്ചിലെ ഏത് അഭ്യർത്ഥനയുടെ ഫലങ്ങളാണ് ആത്മവിശ്വാസത്തോടെ പൊരുത്തപ്പെടുത്താൻ ഉപയോഗിക്കുന്നത്?

• എ) അഭ്യർത്ഥനകളുടെ ഓർഡർ (സ്ഥാനം) അയയ്ക്കുന്നു
• ബി) ഉത്തരങ്ങളുടെ ദൈർഘ്യം
• C) API കീയുടെ അവസാന 4 അക്കങ്ങൾ
• D) ഓരോ അഭ്യർത്ഥനയ്ക്കും നൽകിയിട്ടുള്ള ഒരു തനതായ കസ്റ്റം_ഐഡി ✔

കുറിപ്പ്: സമർപ്പണ ക്രമത്തിൽ നിന്ന് വ്യത്യസ്തമായ ക്രമത്തിൽ ബൾക്ക് ഫലങ്ങൾ നൽകാം; അതിനാൽ ഓരോ അഭ്യർത്ഥനയ്ക്കും നൽകിയിട്ടുള്ള തനത് കസ്റ്റം_ഐഡി ഉപയോഗിച്ച് ലൊക്കേഷനല്ല, ഐഡി പ്രകാരം ഫലങ്ങൾ പൊരുത്തപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്.

12. API-യിൽ നിന്ന് നിങ്ങൾക്ക് 429 (റേറ്റ് പരിധി) പിശക് ലഭിക്കുമ്പോൾ ശുപാർശ ചെയ്യുന്ന പെരുമാറ്റം എന്താണ്?

• എ) ഒരേ സമയം കൂടുതൽ അഭ്യർത്ഥനകൾ അയച്ചുകൊണ്ട് നിർബന്ധിക്കുക
• B) ✔ എന്ന തലക്കെട്ടിന് ശേഷം വീണ്ടും ശ്രമിക്കുമ്പോൾ എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കുന്നു
• സി) അഭ്യർത്ഥന പൂർണ്ണമായും റദ്ദാക്കി ഉപയോക്താവിന് ഒരു ക്രാഷായി പിശക് കാണിക്കുക
• D) API കീ മാറ്റുന്നു

വിശദീകരണം: 429 വീണ്ടും ശ്രമിക്കാവുന്ന പിശകാണ്; റിട്രി-ആഫ്റ്റർ ഹെഡറിനെ മാനിച്ച് എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കുക എന്നതാണ് ശരിയായ സമീപനം. മിക്ക ഔദ്യോഗിക SDK-കളും ഇത് സ്വയമേവ ചെയ്യുന്നു.

13. താഴെപ്പറയുന്നവയിൽ ഏതൊക്കെ HTTP പിശക് കോഡുകളാണ് സാധാരണയായി വീണ്ടും ശ്രമിക്കാവുന്നത്?

• എ) 400 (അസാധുവായ അഭ്യർത്ഥന)
• ബി) 401 (ആധികാരികത ഉറപ്പാക്കൽ പിശക്)
• സി) 529 (സെർവർ ഓവർലോഡഡ്) ✔
• ഡി) 404 (കണ്ടെത്തിയിട്ടില്ല)

വിശദീകരണം: 429 (വേഗത പരിധി), 500 (സെർവർ പിശക്), 529 (ഓവർലോഡ്) എന്നിവ താത്കാലിക പിശകുകളാണ്, ബാക്ക് ഓഫ് ചെയ്ത് വീണ്ടും ശ്രമിക്കാവുന്നതാണ്. 400, 401 എന്നിവ പോലുള്ള പിശകുകൾ അഭ്യർത്ഥന/ഐഡൻ്റിറ്റി പ്രശ്‌നങ്ങളാണ്; വീണ്ടും ശ്രമിക്കുന്നത് പരിഹരിക്കില്ല.

14. API കീകൾ നിയന്ത്രിക്കുന്നതിനുള്ള സുരക്ഷിതമായ മാർഗ്ഗം ഇനിപ്പറയുന്നവയിൽ ഏതാണ്?

• എ) എൻവയോൺമെൻ്റ് വേരിയബിളിൽ/മറഞ്ഞിരിക്കുന്ന മാനേജറിൽ സംഭരിക്കുന്നു, അത് കോഡിൽ ഉൾപ്പെടുത്താതെ പതിവായി കറങ്ങുന്നു ✔
• ബി) സോഴ്സ് കോഡിലേക്ക് കീ നേരിട്ട് എഴുതി ശേഖരത്തിലേക്ക് അയയ്ക്കുക
• സി) ക്ലയൻ്റ് സൈഡിൽ (ബ്രൗസർ) ജാവാസ്ക്രിപ്റ്റിൽ കീ ഇടുന്നു
• D) ഇമെയിൽ വഴി മുഴുവൻ ടീമുമായും ഒരൊറ്റ കീ പങ്കിടൽ

വിവരണം: കീകൾ ഒരിക്കലും സോഴ്സ് കോഡിലോ റിപ്പോസിറ്ററിയിലോ എഴുതില്ല; ഇത് ഒരു എൻവയോൺമെൻ്റ് വേരിയബിളിലോ മറഞ്ഞിരിക്കുന്ന മാനേജുമെൻ്റ് ടൂളിലോ സംഭരിച്ചിരിക്കുന്നു, കുറഞ്ഞ പ്രത്യേകാവകാശങ്ങൾ നൽകുകയും പതിവായി തിരിക്കുകയും ചെയ്യുന്നു.

15. സ്വകാര്യതയുടെ കാര്യത്തിൽ ഒരു ഓട്ടോമേഷൻ ടൂളുമായി (n8n, Zapier, Make) LLM സംയോജനത്തിനുള്ള ഏറ്റവും മികച്ച സമീപനം ഏതാണ്?

• എ) ആവശ്യമില്ലെങ്കിൽപ്പോലും എല്ലാ അസംസ്‌കൃത ഡാറ്റയും മോഡലിലേക്ക് അയയ്ക്കുന്നു
• B) ഫ്ലോ സ്റ്റെപ്പിനുള്ളിൽ പ്ലെയിൻ ടെക്സ്റ്റിൽ API കീ എഴുതുന്നു
• സി) സെൻസിറ്റീവ് ഡാറ്റ ചെറുതാക്കുകയും മറയ്ക്കുകയും കീ രഹസ്യ ക്രെഡൻഷ്യലുകളായി സൂക്ഷിക്കുകയും ചെയ്യുക ✔
• ഡി) വ്യക്തിഗത ഡാറ്റ ഫ്ലോ ചരിത്രത്തിൽ സ്ഥിരമായി സൂക്ഷിക്കുക

വിവരണം: ഓട്ടോമേഷനിലേക്ക് പ്രവേശിക്കുന്ന ഡാറ്റ മൂന്നാം കക്ഷി സിസ്റ്റങ്ങളിലൂടെയും മോഡലിലൂടെയും കടന്നുപോകുമ്പോൾ, സെൻസിറ്റീവ്/വ്യക്തിഗത ഡാറ്റ ചെറുതാക്കുകയും മാസ്ക് ചെയ്യുകയും ആവശ്യമുള്ള ഫീൽഡുകൾ മാത്രം അയയ്ക്കുകയും വേണം; API കീ ഉപകരണത്തിനുള്ളിൽ രഹസ്യ ക്രെഡൻഷ്യലുകളായി സംഭരിച്ചിരിക്കുന്നു.

16. LLM അടിസ്ഥാനമാക്കിയുള്ള പ്രൊഡക്ഷൻ ഫീച്ചറിൽ ഔട്ട്‌പുട്ടിൻ്റെ മൂല്യനിർണ്ണയം നിർബന്ധമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

• എ) മോഡൽ ഒരിക്കലും തെറ്റുകൾ വരുത്താത്തതിനാൽ ഫോർമാറ്റിംഗ് മാത്രം ആവശ്യമാണ്
• ബി) കാരണം മോഡലിന് ദ്രാവകം ഉൽപ്പാദിപ്പിക്കാൻ കഴിയും, പക്ഷേ ചിലപ്പോൾ തെറ്റായി; സ്‌കീമ/റൂൾ റിസോഴ്‌സും മാനുഷിക അംഗീകാരവും ഉപയോഗിച്ച് ഓഡിറ്റ് ചെയ്യണം ✔
• സി) മൂല്യനിർണ്ണയം ഒഴിവാക്കണം, കാരണം ഇത് ചെലവ് വർദ്ധിപ്പിക്കുന്നു
• ഡി) പരിശോധന ടോക്കണുകളുടെ എണ്ണം കുറയ്ക്കാൻ മാത്രമാണ്

വിവരണം: LLM-കൾക്ക് ഒഴുക്കുള്ളതും എന്നാൽ ചിലപ്പോൾ കൃത്യമല്ലാത്തതുമായ (ഭ്രമാത്മക) ഔട്ട്പുട്ട് ഉണ്ടാക്കാൻ കഴിയും; അതിനാൽ അത് ഉയർന്ന സ്വാധീനമുള്ള തീരുമാനങ്ങളിൽ പുറത്തുവന്നു; സ്കീമ/റൂൾസ് പരിശോധന, ഉറവിട മൂല്യനിർണ്ണയം, ആവശ്യമുള്ളപ്പോൾ മനുഷ്യ അംഗീകാരം എന്നിവയിലൂടെ ഇത് ഓഡിറ്റ് ചെയ്യണം.