നേട്ടങ്ങൾ:
- ഒരു LLM API അഭ്യർത്ഥനയുടെ അടിസ്ഥാന ഘടന വിവരിക്കാൻ കഴിയും (എൻഡ് പോയിൻ്റ്, മോഡൽ, സന്ദേശങ്ങൾ, max_tokens)
- സിസ്റ്റം, ഉപയോക്താവ്, അസിസ്റ്റൻ്റ് റോളുകൾ, അവസ്ഥയില്ലാത്ത സംഭാഷണ ചരിത്രം എന്നിവ തമ്മിലുള്ള വ്യത്യാസം മനസ്സിലാക്കുന്നു
- നൽകിയ പ്രതികരണത്തിൻ്റെ ഫീൽഡുകൾ (ഉള്ളടക്ക ബ്ലോക്കുകൾ, stop_reason, ഉപയോഗം) വായിക്കാനും വ്യാഖ്യാനിക്കാനും കഴിയും
മുമ്പത്തെ മൊഡ്യൂളുകളിൽ, ഞങ്ങൾ ഒരു ചാറ്റ് വിൻഡോയിൽ നിന്ന് കൃത്രിമബുദ്ധി ഉപയോഗിച്ചു. എന്നാൽ നിങ്ങളുടെ സ്വന്തം ഉൽപ്പന്നത്തിലോ ഓട്ടോമേഷനിലോ വർക്ക്ഫ്ലോയിലോ AI ഉൾച്ചേർക്കണമെങ്കിൽ, ഒരു ചാറ്റ് ഇൻ്റർഫേസ് അതിനെ വെട്ടിക്കുറയ്ക്കില്ല; നിങ്ങൾ പ്രോഗ്രാമിലേക്ക് മോഡലിലേക്ക് കണക്റ്റുചെയ്യേണ്ടതുണ്ട്, അതായത്, കോഡ് അല്ലെങ്കിൽ ഒരു ഓട്ടോമേഷൻ ടൂൾ. ഈ ബ്രിഡ്ജിൻ്റെ പേര് API (അപ്ലിക്കേഷൻ പ്രോഗ്രാമിംഗ് ഇൻ്റർഫേസ്, രണ്ട് സോഫ്റ്റ്വെയറുകൾ ചില നിയമങ്ങളുമായി സംസാരിക്കാൻ അനുവദിക്കുന്ന കരാർ). നിങ്ങൾ ഈ യൂണിറ്റ് പൂർത്തിയാക്കുമ്പോൾ, ഒരു LLM (ലാർജ് ലാംഗ്വേജ് മോഡൽ) API അഭ്യർത്ഥന എന്താണെന്നും സന്ദേശ റോളുകൾ എന്താണെന്നും പ്രതികരണം എങ്ങനെ വായിക്കാമെന്നും നിങ്ങൾക്കറിയാം. ബാക്കിയുള്ള മൊഡ്യൂൾ നിർമ്മിക്കുന്ന അടിത്തറയാണ് ഇത്.
API എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്?
API-യിലെ അടിസ്ഥാന ഫ്ലോ ഇതാണ്: നിങ്ങൾ ഒരു പ്രത്യേക ഫോർമാറ്റിൽ ഒരു അഭ്യർത്ഥന അയയ്ക്കുന്നു; സെർവർ ഒരു പ്രത്യേക ഫോർമാറ്റിൽ ഒരു പ്രതികരണം നൽകുന്നു. LLM-കളിൽ, ഇത് സാധാരണയായി ഒരു HTTP കോളാണ് (HTTP: വെബിൽ അഭ്യർത്ഥന-പ്രതികരണം കൊണ്ടുപോകുന്നതിനുള്ള സ്റ്റാൻഡേർഡ് പ്രോട്ടോക്കോൾ) ഒരൊറ്റ വിലാസത്തിലേക്ക് (എൻഡ് പോയിൻ്റ്, നിങ്ങളുടെ അഭ്യർത്ഥന കൈകാര്യം ചെയ്യുന്ന സെർവറിലെ സ്ഥിര വിലാസം). ഉദാഹരണത്തിന്, ഒരു സന്ദേശമയയ്ക്കൽ API-യിൽ, എല്ലാ അഭ്യർത്ഥനകളും ഒരൊറ്റ വിലാസത്തിലേക്ക് പോകുകയും ശരീരത്തിൽ JSON (JavaScript ഒബ്ജക്റ്റ് നോട്ടേഷൻ — മനുഷ്യർക്കും യന്ത്രങ്ങൾക്കും വായിക്കാൻ കഴിയുന്ന കീ/മൂല്യം ജോഡികൾ അടങ്ങുന്ന ഒരു ടെക്സ്റ്റ് ഫോർമാറ്റ്) ആയി കൊണ്ടുപോകുകയും ചെയ്യുന്നു.
ഒരു അഭ്യർത്ഥനയിൽ, നിങ്ങൾ ഈ മൂന്ന് കാര്യങ്ങളെങ്കിലും വ്യക്തമാക്കുക:
- മോഡൽ: നിങ്ങൾ ഏത് മോഡൽ ഉപയോഗിക്കും (ഉദാ. വേഗതയേറിയതും വിലകുറഞ്ഞതുമായ മോഡൽ അല്ലെങ്കിൽ ശക്തമായ മോഡൽ).
- max_tokens: മോഡലിന് ഉൽപ്പാദിപ്പിക്കാൻ കഴിയുന്ന പരമാവധി എണ്ണം ടോക്കണുകൾ (ടെക്സ്റ്റ് പ്രോസസ്സ് ചെയ്യുന്ന ഏറ്റവും ചെറിയ യൂണിറ്റ്, അത് അടുത്ത യൂണിറ്റിൽ വിശദമായി പ്രോസസ്സ് ചെയ്യും); അതായത് ഔട്ട്പുട്ട് പരിധി.
- സന്ദേശങ്ങൾ: സംഭാഷണം സൃഷ്ടിക്കുന്ന സന്ദേശങ്ങളുടെ പട്ടിക.
ഘട്ടം ഘട്ടമായി: ഒരു അഭ്യർത്ഥന എങ്ങനെ സജ്ജീകരിക്കാം
- അവസാന പോയിൻ്റും യോഗ്യതാപത്രങ്ങളും തയ്യാറാക്കുക. ഒരു ഹെഡറിലെ അഭ്യർത്ഥനയിലേക്ക് നിങ്ങളുടെ API കീ (നിങ്ങളുടെ ഐഡൻ്റിറ്റി തെളിയിക്കുന്ന രഹസ്യ സ്ട്രിംഗ്) ചേർക്കുക. നിങ്ങൾ ഒരിക്കലും കോഡിൽ കീ ഉൾപ്പെടുത്തിയിട്ടില്ല; യൂണിറ്റ് 9-ൽ ഞങ്ങൾ സുരക്ഷിതമായ സംഭരണം കവർ ചെയ്യും.
- മോഡലും ഔട്ട്പുട്ട് പരിധിയും തിരഞ്ഞെടുക്കുക. ഭാരം കുറഞ്ഞ മോഡൽ + ഒരു ലളിതമായ ടാസ്ക്കിനായി ചെറിയ max_tokens; ശക്തമായ മോഡൽ + സങ്കീർണ്ണമായ ടാസ്ക്കിനുള്ള വലിയ പരിധി.
- സന്ദേശ പട്ടിക സജ്ജീകരിക്കുക. List the system instruction, user message, and past rounds (if any).
- അഭ്യർത്ഥന അയച്ച് പ്രതികരണം പാഴ്സ് ചെയ്യുക. തിരികെ നൽകിയ JSON-ൽ നിന്ന് ടെക്സ്റ്റ് ഉള്ളടക്കം വായിക്കുക, കാരണം നിർത്തുക, ടോക്കൺ ഉപയോഗം.
സന്ദേശ റോളുകൾ: സിസ്റ്റം, ഉപയോക്താവ്, അസിസ്റ്റൻ്റ്
ഒരു സംഭാഷണത്തിൽ ഒരു ക്രമത്തിൽ ക്രമീകരിച്ചിരിക്കുന്ന സന്ദേശങ്ങൾ അടങ്ങിയിരിക്കുന്നു, ഓരോ സന്ദേശത്തിനും ഒരു പങ്കുണ്ട്. ആ വാചകത്തെ മോഡൽ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നുവെന്ന് റോൾ നിർണ്ണയിക്കുന്നു.
പങ്ക്
ആർ എഴുതുന്നു
ഉദ്ദേശം
സിസ്റ്റം
ഡെവലപ്പർ/ഓപ്പറേറ്റർ
മുഴുവൻ സംഭാഷണത്തിലുടനീളം ബാധകമായ സ്ഥിരമായ നിർദ്ദേശങ്ങളും വ്യക്തിത്വവും നിയമങ്ങളും
ഉപയോക്താവ്
അന്തിമ ഉപയോക്താവ്
ഉപയോക്താവിൻ്റെ നിലവിലെ ചോദ്യം അല്ലെങ്കിൽ ഇൻപുട്ട്
സഹായി
മാതൃക
മോഡൽ നിർമ്മിച്ച പ്രതികരണം (മുമ്പത്തെ പ്രതികരണങ്ങളും)
മിക്ക ദാതാക്കളിലും അഭ്യർത്ഥന ബോഡിയിൽ സിസ്റ്റം റോൾ ഒരു പ്രത്യേക സിസ്റ്റം ഫീൽഡായി ലഭ്യമാണ്; സന്ദേശങ്ങളുടെ പട്ടികയിൽ ഉപയോക്താവും സഹായിയും തുടർച്ചയായി പട്ടികപ്പെടുത്തിയിരിക്കുന്നു. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "നിങ്ങൾ ഒരു കോർപ്പറേറ്റ് സപ്പോർട്ട് അസിസ്റ്റൻ്റാണ്. ഹ്രസ്വവും ഔപചാരികവും പരിശോധിച്ചുറപ്പിച്ചതുമായ ഒരു പ്രതികരണം നൽകുക. നിങ്ങൾക്ക് ഉറപ്പില്ലാത്ത വിവരങ്ങൾ ഉണ്ടാക്കരുത്.", "സന്ദേശങ്ങൾ": [ { "role": "ഉപയോക്താവ്": "എൻ്റെ പ്രോസസ്സ് ഞാൻ തിരികെ നൽകണോ?" } ]}
സംസാരം നിലയില്ലാത്തതാണ്
ഏറ്റവും സാധാരണമായ തെറ്റിദ്ധാരണ ഇതാണ്: LLM API കോളുകൾ നിലയില്ലാത്തതാണ് - രണ്ട് അഭ്യർത്ഥനകൾക്കിടയിൽ സെർവർ മെമ്മറി നിലനിർത്തുന്നില്ല. നിങ്ങളുടെ മുൻ അഭ്യർത്ഥന മോഡൽ ഓർക്കുന്നില്ല. നിങ്ങൾ ഒരു മൾട്ടി-റൗണ്ട് ചാറ്റ് സജ്ജീകരിക്കുകയാണെങ്കിൽ, ഓരോ പുതിയ അഭ്യർത്ഥനയ്ക്കൊപ്പവും നിങ്ങൾ കഴിഞ്ഞ റൗണ്ടുകൾ വീണ്ടും അയയ്ക്കേണ്ടതുണ്ട്. മോഡലിൻ്റെ "മെമ്മറി"യിൽ നിങ്ങൾ അയച്ച സന്ദേശങ്ങളുടെ ഒരു ലിസ്റ്റ് അടങ്ങിയിരിക്കുന്നു.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "ഹലോ, എൻ്റെ പേര് ഡെനിസ്." }, { "റോൾ": "അസിസ്റ്റൻ്റ്", "ഉള്ളടക്കം": "ഹലോ ഡെനിസ്, എനിക്ക് നിങ്ങളെ എങ്ങനെ സഹായിക്കാനാകും?" }, { "റോൾ": "ഉപയോക്താവ്", "ഉള്ളടക്കം": "ഞാൻ എൻ്റെ പേര് പറഞ്ഞു, നിങ്ങൾ ഓർക്കുന്നുണ്ടോ?" } ]}
മൂന്നാമത്തെ സന്ദേശത്തിന് ശരിയായി ഉത്തരം നൽകുന്നത് നിങ്ങൾ മുമ്പത്തെ രണ്ട് സന്ദേശങ്ങളും അയയ്ക്കുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. നിങ്ങൾ അത് അയച്ചില്ലെങ്കിൽ, മോഡലിന് "കടൽ" അറിയില്ല, തെറ്റായി ഉത്തരം നൽകും. ഇത് ചെലവിനെയും നേരിട്ട് ബാധിക്കുന്നു: സംഭാഷണം ദൈർഘ്യമേറിയതാണ്, ലിസ്റ്റ് വലുതാണ്, ഓരോ അഭ്യർത്ഥനയും കൂടുതൽ ടോക്കണുകൾ ഉപയോഗിക്കുന്നു.
നുറുങ്ങ്: നീണ്ട സംഭാഷണങ്ങളിൽ, മുഴുവൻ ചരിത്രവും അയയ്ക്കുന്നതിന് പകരം പഴയ റൗണ്ടുകൾ (സംഗ്രഹം + അവസാനത്തെ കുറച്ച് റൗണ്ടുകൾ) സംഗ്രഹിക്കുകയും നീക്കുകയും ചെയ്യുന്നത് ചെലവ് കുറയ്ക്കുകയും സന്ദർഭ വിൻഡോ സംരക്ഷിക്കുകയും ചെയ്യുന്നു. ഞങ്ങൾ ഇത് 6, 11 യൂണിറ്റുകളിൽ കൂടുതൽ ആഴത്തിലാക്കും.
ഉത്തരം വായിക്കുക
മോഡൽ ഒരു പ്രതികരണം നൽകുമ്പോൾ, നിങ്ങൾക്ക് ഒരു ഘടനാപരമായ ഒബ്ജക്റ്റ് ലഭിക്കും, പ്ലെയിൻ ടെക്സ്റ്റല്ല. സാധാരണ പ്രദേശങ്ങൾ:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "ഒരു റിട്ടേൺ ആരംഭിക്കുന്നതിന്, നിങ്ങളുടെ അക്കൗണ്ടിലെ 'എൻ്റെ ഓർഡറുകൾ' പേജിലേക്ക് പോകുക..." {001}{101}, } "input_tokens": 47, "output_tokens": 88 }}
- ഉള്ളടക്കം: പ്രതികരണം തന്നെ; ഇത് ഉള്ളടക്ക ബ്ലോക്കുകളുടെ ഒരു പട്ടികയാണ്. ടെക്സ്റ്റ് ബ്ലോക്കിൻ്റെ ടെക്സ്റ്റ് ഫീൽഡ് യഥാർത്ഥ ഉത്തരമാണ്.
- stop_reason: എന്തുകൊണ്ട് മോഡൽ നിർത്തി. end_turn = സ്വാഭാവിക അവസാനം; max_tokens = ഔട്ട്പുട്ട് പരിധിയിൽ കുടുങ്ങി (പ്രതികരണം അപൂർണ്ണമായിരിക്കാം); നിരസിക്കൽ = സുരക്ഷാ കാരണങ്ങളാൽ നിരസിച്ചു. നിങ്ങളുടെ കോഡ് എപ്പോഴും ആദ്യം stop_reason നോക്കണം.
- ഉപയോഗം: ഇൻപുട്ട്, ഔട്ട്പുട്ട് ടോക്കൺ നമ്പറുകൾ. ഇത് ചെലവിൻ്റെയും പരിധി ട്രാക്കിംഗിൻ്റെയും അടിസ്ഥാനമാണ്.
ശ്രദ്ധിക്കുക: stop_reason max_tokens ആണെങ്കിൽ, പ്രതികരണം പൂർത്തിയായിട്ടില്ല. ഇത് ഒരു "വിജയകരമായ പ്രതികരണം" ആയി കണക്കാക്കുകയും ഉപയോക്താവിന് പകുതി വാചകം കാണിക്കുകയും ചെയ്യുന്നത് നിർമ്മാണത്തിലെ ഏറ്റവും സാധാരണമായ തെറ്റുകളിൽ ഒന്നാണ്. ഒന്നുകിൽ max_tokens വർദ്ധിപ്പിക്കുക അല്ലെങ്കിൽ സ്ട്രീമിംഗ് ഉപയോഗിക്കുക.
ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ്
രണ്ട് വ്യത്യസ്ത സിസ്റ്റം നിർദ്ദേശങ്ങളുള്ള ഒരേ ടാസ്ക്:
# ദുർബലമായ നിങ്ങൾ ഒരു സഹായിയാണ്. ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുക.
# STRONG നിങ്ങളൊരു കോർപ്പറേറ്റ് സപ്പോർട്ട് അസിസ്റ്റൻ്റാണ്. നിയമങ്ങൾ:- നൽകിയിരിക്കുന്ന പോളിസി ഡോക്യുമെൻ്റിലെ വിവരങ്ങളെ മാത്രം ആശ്രയിക്കുക; ഇത് ഡോക്യുമെൻ്റിൽ ഇല്ലെങ്കിൽ, "എനിക്ക് ഈ വിവരങ്ങൾ ഇല്ല, ഞാൻ അത് ബന്ധപ്പെട്ട യൂണിറ്റിലേക്ക് നയിക്കുന്നു" എന്ന് പറയുക. - ഉത്തരങ്ങൾ 3 വാക്യങ്ങളിൽ കവിയരുത്, ഔപചാരികവും വ്യക്തവുമായിരിക്കണം. - വ്യക്തിഗത ഡാറ്റ (TC ID നമ്പർ, കാർഡ് നമ്പർ) ആവശ്യപ്പെടരുത്, ആവർത്തിക്കരുത്. - നിങ്ങൾക്ക് ഉറപ്പില്ലാത്തപ്പോൾ ഊഹിക്കരുത്.
ശക്തമായ പതിപ്പ്; ഇത് വ്യാപ്തി, രൂപം, സുരക്ഷാ മാർജിൻ, അനിശ്ചിതത്വത്തിലെ പെരുമാറ്റം എന്നിവ നിർവ്വചിക്കുന്നു. മോഡൽ ഔട്ട്പുട്ടിൻ്റെ സ്ഥിരത ഈ വ്യക്തതയിൽ നിന്ന് നേരിട്ട് വരുന്നു.
മൂന്ന് മിനി കേസുകൾ
കേസ് 1 - സപ്പോർട്ട് ബോട്ട് (സ്റ്റേറ്റ്ലെസ്സ്നെസ്സ് ട്രാപ്പ്). ഒരു ഇ-കൊമേഴ്സ് ടീം ബോട്ട് ലൈവായി എടുത്തു; ഉപയോക്താവ് "മുമ്പത്തെ ഓർഡർ റദ്ദാക്കുക" എന്ന് പറഞ്ഞപ്പോൾ, ബോട്ട് ഓർഡർ നമ്പർ "മറന്നു". കാരണം: അവർ ഓരോ അഭ്യർത്ഥനയും അവസാന സന്ദേശം മാത്രം അയയ്ക്കുകയായിരുന്നു. പരിഹാരം: അവർ അവസാന 6 റൗണ്ടുകൾ സന്ദേശങ്ങളുടെ പട്ടികയിൽ ചേർത്തു. ഫലം: സന്ദർഭം സംരക്ഷിച്ചിരിക്കുന്നു, എന്നാൽ ഓരോ അഭ്യർത്ഥനയുടെയും ഇൻപുട്ട് 40 ടോക്കണുകളിൽ നിന്ന് ~600 ടോക്കണുകളായി വർദ്ധിച്ചു - ഞങ്ങൾ യൂണിറ്റ് 2-ൽ ചെലവ് പാഠം ഉൾക്കൊള്ളും.
കേസ് 2 - അപൂർണ്ണമായ കരാർ സംഗ്രഹം. ഒരു നിയമസംഘം 10 പേജുള്ള കരാറുകൾ രൂപപ്പെടുത്തിയിരുന്നു; max_tokens: 300 കുറവായി തുടർന്നു, സംഗ്രഹങ്ങൾ മധ്യ വാചകം വെട്ടിക്കളഞ്ഞു. stop_reason ഓരോ തവണയും max_tokens ആയിരുന്നു എന്നാൽ ആരും നോക്കിയില്ല. max_tokens 1500 ആയി വർദ്ധിപ്പിച്ച് stop_reason ചെക്ക് ചേർത്തു; വെട്ടിച്ചുരുക്കിയ സംഗ്രഹ നിരക്ക് 18% ൽ നിന്ന് 0% ആയി കുറഞ്ഞു.
കേസ് 3 - മിക്സിംഗ് റോളുകൾ. ഒരു മാർക്കറ്റിംഗ് ടീം ഉപയോക്തൃ സന്ദേശത്തിലേക്ക് എല്ലാ നിർദ്ദേശങ്ങളും എഴുതുന്നു, സിസ്റ്റം ശൂന്യമാക്കി. ഉപയോക്തൃ ഇൻപുട്ട് നിർദ്ദേശങ്ങളുമായി ഇടകലർന്നാൽ, മോഡൽ ചിലപ്പോൾ "മുമ്പത്തെ നിയമങ്ങൾ മറക്കുക" എന്ന ഉപയോക്താവിൻ്റെ കമാൻഡിന് അനുസൃതമായി പ്രവർത്തിക്കും. അവർ വ്യവസ്ഥിതിയിലേക്ക് സ്ഥിരമായ നിയമങ്ങൾ മാറ്റി; നിർദ്ദേശങ്ങളിൽ നിന്ന് ഉപയോക്തൃ ഇൻപുട്ട് വേർതിരിക്കുന്നതിലൂടെ, നിയമ ലംഘനങ്ങൾ ഗണ്യമായി കുറഞ്ഞു.
സാധാരണ തെറ്റുകൾ
- ഭൂതകാലത്തെ അയയ്ക്കാൻ മറക്കുന്നു: മോഡൽ "ഓർമ്മയില്ല" എന്ന് കരുതുന്നു; അതേസമയം അത് രാജ്യരഹിതമാണ്. നിങ്ങൾ സന്ദർഭം വഹിക്കുന്നു.
- `stop_reason` നോക്കുന്നില്ല: max_tokens ഉപയോഗിച്ച് നിർത്തിയ പ്രതികരണം പൂർത്തിയായതായി കണക്കാക്കുന്നു.
- `ഉപയോക്താവ്` എന്നതിൽ നിർദ്ദേശങ്ങൾ ഉൾച്ചേർക്കുന്നു: സിസ്റ്റത്തിലേക്ക് സ്ഥിരമായ നിയമങ്ങൾ; തൽക്ഷണ ഇൻപുട്ട് ഉപയോക്താവിലേക്ക് പോകുന്നു. മിശ്രണം സുരക്ഷാ പാളിച്ചകൾ സൃഷ്ടിക്കുന്നു.
- 'ഉള്ളടക്കം' ഒരു പ്ലെയിൻ സ്ട്രിംഗായി തെറ്റിദ്ധരിക്കുന്നു: ഉത്തരം ബ്ലോക്കുകളുടെ ഒരു ലിസ്റ്റ് ആണ്; ആദ്യത്തെ ടെക്സ്റ്റ് ബ്ലോക്കിൻ്റെ ടെക്സ്റ്റ് ഫീൽഡ് വായിക്കുക, ഒരു ബ്ലൈൻഡ് ഇൻഡക്സ് ഉപയോഗിച്ച് ഉള്ളടക്കം[0] ലഭിക്കുന്നതിന് മുമ്പ് അതിൻ്റെ തരം പരിശോധിക്കുക.
- കോഡിൽ കീ ഉൾച്ചേർക്കുന്നു: ഒരു പരിസ്ഥിതി വേരിയബിൾ ഉപയോഗിക്കുക (യൂണിറ്റ് 9).
ആഴത്തിലുള്ളത്: ഉള്ളടക്ക ബ്ലോക്കുകളും മൾട്ടി-പാർട്ട് ഉത്തരങ്ങളും
പ്രതികരണത്തിലെ ഉള്ളടക്ക ഫീൽഡ് ഒരു ലിസ്റ്റായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസ്സിലാക്കുന്നത് പിന്നീട് നിങ്ങൾ അഭിമുഖീകരിക്കുന്ന വിപുലമായ ഫീച്ചറുകളുടെ അടിസ്ഥാനമാണ്. ചിലപ്പോൾ മോഡൽ ടെക്സ്റ്റിൻ്റെ ഒരു ബ്ലോക്ക് മാത്രമല്ല, നിരവധി ബ്ലോക്കുകൾ നൽകുന്നു: ചിന്തയുടെ ഒരു ബ്ലോക്ക്, തുടർന്ന് ടെക്സ്റ്റിൻ്റെ ഒരു ബ്ലോക്ക്; അല്ലെങ്കിൽ ടെക്സ്റ്റിൻ്റെ ഒരു ബ്ലോക്ക്, തുടർന്ന് ടൂൾ യൂസ് ബ്ലോക്ക്. അതുകൊണ്ടാണ് ഉള്ളടക്കം[0] ഒരു "ഉത്തരം" എന്ന നിലയിൽ അന്ധമായി കണക്കാക്കുന്നത് ദുർബലമാണ്. ലിസ്റ്റിലൂടെ പോയി തരം അനുസരിച്ച് അടുക്കുക എന്നതാണ് ശരിയായ സമീപനം: ടെക്സ്റ്റ് ടൈപ്പ് ഫീൽഡ് ആയ ബ്ലോക്കുകളുടെ ടെക്സ്റ്റ് ഉള്ളടക്കം നിങ്ങൾ ശേഖരിക്കുകയും മറ്റ് തരങ്ങളെ (ചിന്ത, ഉപകരണം) പ്രത്യേകം പരിഗണിക്കുകയും ചെയ്യുന്നു.
ഈ വ്യത്യാസം പ്രായോഗികമായി ചെയ്യുന്നത്, നിങ്ങൾക്ക് മോഡലിൻ്റെ ന്യായവാദം (എന്തെങ്കിലും ഉണ്ടെങ്കിൽ) ഉപയോക്താവിന് വെളിപ്പെടുത്താതെ തന്നെ ലോഗ് ചെയ്യാനും, പ്രത്യേക ലോജിക്കിലേക്ക് ടൂൾ കോളുകൾ റീഡയറക്ട് ചെയ്യാനും, സ്ക്രീനിൽ യഥാർത്ഥ ഉത്തരം മാത്രം പ്രിൻ്റ് ചെയ്യാനും കഴിയും എന്നതാണ്. മൊഡ്യൂൾ പുരോഗമിക്കുമ്പോൾ (പ്രത്യേകിച്ച് 4, 11 യൂണിറ്റുകളിൽ) ഈ ബ്ലോക്ക് ഘടന ഔട്ട്പുട്ട് സാധൂകരിക്കുന്നതിനും സംവിധാനം ചെയ്യുന്നതിനും എത്രത്തോളം ഉപയോഗപ്രദമാണെന്ന് നിങ്ങൾ കാണും.
മറ്റൊരു പ്രായോഗിക പോയിൻ്റ്: വ്യത്യസ്ത പ്രൊവൈഡർ പ്ലാറ്റ്ഫോമുകളിൽ നിന്ന് നിങ്ങൾക്ക് ഒരേ മോഡൽ ആക്സസ് ചെയ്യാൻ കഴിയും (ഡയറക്ട് എപിഐ, ഒരു ക്ലൗഡ് പ്രൊവൈഡർ വഴി). എൻഡ്പോയിൻ്റ് വിലാസവും പ്രാമാണീകരണ ഫോർമാറ്റും മാറാമെങ്കിലും, സന്ദേശ റോളുകൾ, അവസ്ഥയില്ലായ്മ, പ്രതികരണ ഘടന തുടങ്ങിയ അടിസ്ഥാന ആശയങ്ങൾ അതേപടി തുടരുന്നു. അതിനാൽ നിങ്ങൾ ഏത് പ്ലാറ്റ്ഫോം ഉപയോഗിച്ചാലും ഈ യൂണിറ്റിലെ അടിസ്ഥാനകാര്യങ്ങൾ ബാധകമാണ്.
ചുരുക്കത്തിൽ
ഒരു LLM API അഭ്യർത്ഥനയിൽ മോഡൽ, ഔട്ട്പുട്ട് പരിധി, സന്ദേശ പട്ടിക എന്നിവ അടങ്ങിയിരിക്കുന്നു; റോളുകൾ (സിസ്റ്റം, ഉപയോക്താവ്, അസിസ്റ്റൻ്റ്) മോഡലിൻ്റെ സ്വഭാവം നിർണ്ണയിക്കുന്നു. കോളുകൾ നിലയ്ക്കാത്തതാണ്: ഓരോ അഭ്യർത്ഥനയ്ക്കൊപ്പവും നിങ്ങൾ സന്ദർഭം ഉൾക്കൊള്ളുന്നു. പ്രതികരണം ഒരു ഘടനാപരമായ വസ്തുവാണ്; ഉള്ളടക്കം, stop_reason, യൂസേജ് ഫീൽഡുകൾ എന്നിവ വായിക്കുകയും വ്യാഖ്യാനിക്കുകയും ചെയ്യുന്നതാണ് ഉൽപ്പാദനത്തിലെ ദൈർഘ്യത്തിൻ്റെ അടിസ്ഥാനം.
ആപ്ലിക്കേഷൻ ടാസ്ക്
നിങ്ങളുടെ സ്വന്തം പ്രൊഫഷനിൽ നിന്ന് ഒരു ടാസ്ക്ക് തിരഞ്ഞെടുക്കുക (ഉദാ. ഇൻകമിംഗ് ഇ-മെയിൽ അടുക്കുക, ഹ്രസ്വ സംഗ്രഹങ്ങൾ സൃഷ്ടിക്കുക). ഒരു കടലാസിൽ: (1) 4-5 നിയമങ്ങൾ ഉപയോഗിച്ച് സിസ്റ്റം പ്രോംപ്റ്റ് എഴുതുക, (2) ഒരു സാമ്പിൾ ഉപയോക്തൃ സന്ദേശവും എന്തെങ്കിലും ഉണ്ടെങ്കിൽ 2-റൗണ്ട് ചരിത്രവും സജ്ജീകരിക്കുക, (3) max_tokens ന് ന്യായമായ മൂല്യം നിർണ്ണയിച്ച് ന്യായീകരണം എഴുതുക, (4) നൽകിയ പ്രതികരണത്തിൽ നിങ്ങൾ കൈകാര്യം ചെയ്യുന്ന stop_reason മൂല്യങ്ങൾ, എങ്ങനെ എന്നിവ ലിസ്റ്റ് ചെയ്യുക.
ചെക്ക്ലിസ്റ്റ്
- [ ] എനിക്ക് ഒരു അഭ്യർത്ഥനയുടെ മൂന്ന് നിർബന്ധിത ഭാഗങ്ങൾ കണക്കാക്കാം (മോഡൽ, max_tokens, സന്ദേശങ്ങൾ).
- [ ] സിസ്റ്റം, യൂസർ, അസിസ്റ്റൻ്റ് റോളുകൾ എന്നിവ തമ്മിലുള്ള വ്യത്യാസം എനിക്ക് വിശദീകരിക്കാൻ കഴിയും.
- [ ] കോളുകൾ സ്റ്റേറ്റ്ലെസ് ആണെന്നും എനിക്ക് ഭൂതകാലം കൊണ്ടുപോകേണ്ടതുണ്ടെന്നും എനിക്കറിയാം.
- എനിക്ക് [ ] ഉള്ളടക്കം, stop_reason, ഉപയോഗ ഫീൽഡുകൾ എന്നിവ വായിക്കാനും അഭിപ്രായമിടാനും കഴിയും.
- [ ] max_tokens ഉപയോഗിച്ച് എനിക്ക് വെട്ടിച്ചുരുക്കിയ പ്രതികരണം ശ്രദ്ധിക്കാനും കൈകാര്യം ചെയ്യാനും കഴിയും.