ලාභ:
- LLM API ඉල්ලීමක මූලික ව්යුහය විස්තර කළ හැකිය (අවසන් ලක්ෂ්යය, ආකෘතිය, පණිවිඩ, max_tokens)
- පද්ධතිය, පරිශීලක සහ සහකාර භූමිකාවන් සහ අස්ථායී සංවාද ඉතිහාසය අතර වෙනස තේරුම් ගනී
- ආපසු ලබා දුන් ප්රතිචාරයේ ක්ෂේත්ර (අන්තර්ගත අවහිර කිරීම්, නැවතුම්_හේතුව, භාවිතය) කියවීමට සහ අර්ථ දැක්වීමට හැකිය
පෙර මොඩියුලවල, අපි කතාබස් කවුළුවකින් කෘතිම බුද්ධිය භාවිතා කළෙමු. නමුත් ඔබට ඔබේම නිෂ්පාදනයක්, ස්වයංක්රීයකරණයක් හෝ කාර්ය ප්රවාහයක් තුළට AI කාවැද්දීමට අවශ්ය නම්, කතාබස් අතුරුමුහුණත එය කපා හරිනු නොලැබේ; ඔබට ක්රමලේඛනාත්මකව, එනම් කේතය හෝ ස්වයංක්රීය මෙවලමක් සමඟ ආකෘතියට සම්බන්ධ විය යුතුය. මෙම පාලමේ නම API (යෙදුම් ක්රමලේඛන අතුරුමුහුණත, මෘදුකාංග දෙකකට යම් නීතිරීති සමඟ කතා කිරීමට ඉඩ සලසන ගිවිසුම). ඔබ මෙම ඒකකය අවසන් කරන විට, LLM (විශාල භාෂා ආකෘතිය) API ඉල්ලීමක් යනු කුමක්ද, පණිවිඩ භූමිකාවන් කරන්නේ කුමක්ද සහ ප්රතිචාරය කියවන ආකාරය ඔබ දැන ගනු ඇත. ඉතිරි මොඩියුලය ගොඩනගනු ලබන පදනම මෙයයි.
API ක්රියා කරන්නේ කෙසේද?
API හි මූලික ප්රවාහය මෙයයි: ඔබ යම් ආකෘතියකින් ඉල්ලීමක් යවයි; සේවාදායකය නිශ්චිත ආකෘතියකින් ප්රතිචාරයක් ලබා දෙයි. LLM වල, මෙය සාමාන්යයෙන් HTTP ඇමතුමකි (HTTP: වෙබයේ ඉල්ලීම්-ප්රතිචාර රැගෙන යාම සඳහා සම්මත ප්රොටෝකෝලය) තනි ලිපිනයකට (අවසන් ලක්ෂ්යය, ඔබගේ ඉල්ලීම හසුරුවන සේවාදායකයේ ස්ථාවර ලිපිනය). උදාහරණයක් ලෙස, පණිවිඩකරණ API එකක, සියලුම ඉල්ලීම් තනි ලිපිනයකට ගොස් JSON (JavaScript Object Notation — මිනිසුන්ට සහ යන්ත්ර දෙකටම කියවිය හැකි යතුරු/අගය යුගලවලින් සමන්විත පෙළ ආකෘතියක්) ලෙස ශරීරය තුළ ගෙන යනු ලැබේ.
ඉල්ලීමකදී, ඔබ අවම වශයෙන් මෙම කරුණු තුන සඳහන් කරන්න:
- ආකෘතිය: ඔබ භාවිතා කරන ආකෘතිය (උදා: වේගවත් සහ ලාභ ආකෘතියක් හෝ බලවත් ආකෘතියක්).
- 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": "ඔබ ආයතනික සහායකයෙක්. කෙටි, විධිමත් සහ සත්යාපිත ප්රතිචාරයක් දෙන්න. ඔබට විශ්වාස නැති තොරතුරු සාදන්න එපා.", "පණිවිඩ": [ { "භූමිකාව": "පරිශීලක": "මම මගේ ක්රියාවලිය ආරම්භ කරන්නේද?", "මම නැවත ආරම්භ කරන්නේද?" } ]}
කථාව රාජ්ය විරහිත ය
මෙන්න වඩාත් පොදු වැරදි වැටහීම: LLM API ඇමතුම් අස්ථායි - ඉල්ලීම් දෙකක් අතර සේවාදායකය මතකය රඳවා නොගනී. ආකෘතියට ඔබගේ පෙර ඉල්ලීම මතක නැත. ඔබ බහු-වට කතාබස් සකසන්නේ නම්, ඔබට සෑම නව ඉල්ලීමක් සමඟම පසුගිය වට නැවත යැවීමට අවශ්ය වනු ඇත. ආකෘතියේ "මතකය" ඔබ යවා ඇති පණිවිඩ ලැයිස්තුවකින් සමන්විත වේ.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Hello, my name is Deniz." }, { "භූමිකාව": "සහායක", "අන්තර්ගතය": "හෙලෝ ඩෙනිස්, මම ඔබට උදව් කරන්නේ කෙසේද?" }, { "භූමිකාව": "පරිශීලක", "අන්තර්ගතය": "මම දැන් මගේ නම කිව්වා, ඔයාට මතකද?" } ]}
තෙවන පණිවිඩයට නිවැරදිව පිළිතුරු දීම ඔබ පෙර පණිවිඩ දෙකම යැවීම මත රඳා පවතී. ඔබ එය නොයවන්නේ නම්, ආකෘතිය "මුහුද" නොදන්නා අතර වැරදි ලෙස පිළිතුරු දෙනු ඇත. මෙය ද පිරිවැයට සෘජුවම බලපායි: සංවාදය දිගු වන තරමට, ලැයිස්තුව විශාල වන අතර, එක් එක් ඉල්ලීම් වැඩි ටෝකන පරිභෝජනය කරයි.
ඉඟිය: දිගු සංවාද වලදී, සම්පූර්ණ ඉතිහාසය යැවීම වෙනුවට පැරණි වට (සාරාංශය + අවසාන වට කිහිපය) සාරාංශ කිරීම සහ චලනය කිරීම පිරිවැය අඩු කරන අතර සන්දර්භය කවුළුව ආරක්ෂා කරයි. අපි මෙය ඒකක 6 සහ 11 තුළ ගැඹුරු කරන්නෙමු.
පිළිතුර කියවන්න
ආකෘතිය ප්රතිචාරයක් ලබා දෙන විට, ඔබට ලැබෙන්නේ ව්යුහගත වස්තුවක් මිස සරල පෙළක් නොවේ. සාමාන්ය ප්රදේශ:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "සහායක", "අන්තර්ගතය": [ { "type": "text", "text": "ආපසු පැමිණීමක් ආරම්භ කිරීමට, ඔබගේ ගිණුමේ 'My Orders' පිටුවට යන්න..." {turn_reason:", "stopend_reason:" "stopend_reason:" "input_tokens": 47, "output_tokens": 88 }}
- අන්තර්ගතය: ප්රතිචාරයම; එය අන්තර්ගත වාරණ ලැයිස්තුවකි. Text block එකේ text field එක තමයි නියම උත්තරේ.
- 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 දක්වා වැඩි කර නැවතුම්_හේතු පරීක්ෂාව එක් කළා; කප්පාදු කළ සාරාංශ අනුපාතය 18% සිට 0% දක්වා අඩු විය.
නඩුව 3 - භූමිකාවන් මිශ්ර කිරීම. අලෙවිකරණ කණ්ඩායමක් පරිශීලක පණිවිඩයට සියලුම උපදෙස් ලිවීමෙන් පද්ධතිය හිස්ව තබා ඇත. පරිශීලක ආදානය උපදෙස් සමඟ මිශ්ර වූ විට, ආකෘතිය සමහර විට "පෙර නීති අමතක කරන්න" යන පරිශීලකයාගේ විධානයට අනුකූල වේ. ඔවුන් ස්ථිර නීති පද්ධතියට ගෙන ගියා; පරිශීලක ආදානය උපදෙස් වලින් වෙන් කිරීමෙන්, රීති උල්ලංඝනය කිරීම් සැලකිය යුතු ලෙස අඩු විය.
පොදු වැරදි
- අතීතය යැවීමට අමතක වීම: ආකෘතිය "මතක නැත" ලෙස සැලකේ; එය රාජ්ය විරහිත වන අතර. ඔබ සන්දර්භය රැගෙන යයි.
- `stop_reason` දෙස නොබලයි: max_tokens සමඟ නතර වූ ප්රතිචාරය සම්පූර්ණ ලෙස සැලකේ.
- 'පරිශීලක' හි උපදෙස් කාවැද්දීම: පද්ධතියට ස්ථිර නීති; ක්ෂණික ආදානය පරිශීලකයා වෙත යයි. මිශ්ර කිරීම ආරක්ෂක දුර්වලතා ඇති කරයි.
- සරල තන්තුවක් සඳහා `අන්තර්ගතය` වරදවා වටහා ගැනීම: පිළිතුර බ්ලොක් ලැයිස්තුවකි; පළමු පෙළ කොටසෙහි පෙළ ක්ෂේත්රය කියවන්න, අන්ධ දර්ශකයක් සමඟ අන්තර්ගතය[0] ලබා ගැනීමට පෙර එහි වර්ගය තහවුරු කරන්න.
- කේතයේ යතුර එබ්බවීම: පරිසර විචල්යයක් භාවිතා කරන්න (ඒකක 9).
ගැඹුරු: අන්තර්ගත කොටස් සහ බහු-කොටස් පිළිතුරු
ප්රතිචාරයේ අන්තර්ගත ක්ෂේත්රය ලැයිස්තුවක් වන්නේ මන්දැයි තේරුම් ගැනීම ඔබට පසුව හමුවන උසස් විශේෂාංග සඳහා මූලික වේ. සමහර විට ආකෘතිය එක් පෙළ කොටසක් නොව, බ්ලොක් කිහිපයක් ආපසු ලබා දෙයි: සිතීමේ වාරණයක්, පසුව පෙළ කොටස; හෝ පෙළ කොටසකට පසුව මෙවලම් භාවිත අවහිරයක්. අන්තර්ගතය[0] "පිළිතුරක්" ලෙස අන්ධ ලෙස ගණන් කිරීම බිඳෙනසුලු වන්නේ එබැවිනි. නිවැරදි ප්රවේශය නම් ලැයිස්තුව හරහා ගොස් එය වර්ගය අනුව වර්ග කිරීමයි: ඔබ අකුරු ක්ෂේත්රය වන බ්ලොක් වල පෙළ අන්තර්ගතය එකතු කර, වෙනත් වර්ගවලට (චින්තනය, මෙවලම) වෙන වෙනම සලකන්න.
මෙම වෙනස ප්රායෝගිකව සිදු කරන්නේ, ඔබට ආකෘතියේ තර්කය පරිශීලකයාට හෙළි නොකර (ඇත්නම්) ලොග් කළ හැකි අතර, මෙවලම් ඇමතුම් වෙනම තර්කනයට හරවා යැවීමට සහ තිරය මත සත්ය පිළිතුර පමණක් මුද්රණය කළ හැකිය. මොඩියුලය ඉදිරියට යන විට (විශේෂයෙන් ඒකක 4 සහ 11) මෙම බ්ලොක් ව්යුහය ප්රතිදානය වලංගු කිරීම සහ මෙහෙයවීම සඳහා කෙතරම් ප්රයෝජනවත් දැයි ඔබට පෙනෙනු ඇත.
තවත් ප්රායෝගික කරුණක්: ඔබට විවිධ සැපයුම් වේදිකා වලින් එකම ආකෘතියට ප්රවේශ විය හැකිය (සෘජු API, වලාකුළු සපයන්නා හරහා). අවසාන ලක්ෂ්ය ලිපිනය සහ සත්යාපන ආකෘතිය වෙනස් විය හැකි වුවද, පණිවිඩ භූමිකාවන්, අස්ථායීභාවය සහ ප්රතිචාර ව්යුහය වැනි මූලික සංකල්ප එලෙසම පවතී. එබැවින් ඔබ කුමන වේදිකාවක් භාවිතා කළත් මෙම ඒකකයේ මූලික කරුණු අදාළ වේ.
සාරාංශයක් ලෙස
LLM API ඉල්ලීමක් ආකෘතිය, ප්රතිදාන සීමාව සහ පණිවිඩ ලැයිස්තුවෙන් සමන්විත වේ; භූමිකාවන් (පද්ධතිය, පරිශීලක, සහායක) ආකෘතියේ හැසිරීම තීරණය කරයි. ඇමතුම් අස්ථායි: ඔබ එක් එක් ඉල්ලීම සමඟ සන්දර්භය රැගෙන යයි. ප්රතිචාරය ව්යුහගත වස්තුවකි; අන්තර්ගතය, stop_reason සහ භාවිත ක්ෂේත්ර කියවීම සහ අර්ථ නිරූපණය කිරීම නිෂ්පාදනයේ කල්පැවැත්මේ පදනම වේ.
යෙදුම් කාර්යය
ඔබගේම වෘත්තියෙන් කාර්යයක් තෝරන්න (උදා. එන ඊමේල් වර්ග කිරීම, කෙටි සාරාංශ නිර්මාණය කිරීම). කඩදාසි කැබැල්ලක: (1) 4-5 රීති සමඟ පද්ධති විමසුම ලියන්න, (2) නියැදි පරිශීලක පණිවිඩයක් සහ වට 2ක ඉතිහාසයක් තිබේ නම්, (3) max_tokens සඳහා සාධාරණ අගයක් තීරණය කර සාධාරණීකරණය ලියන්න, (4) ආපසු ලැබෙන ප්රතිචාරයේදී ඔබ හැසිරවිය යුතු stop_reason අගයන් සහ කෙසේද යන්න ලැයිස්තුව.
පිරික්සුම් ලැයිස්තුව
- [ ] මට ඉල්ලීමක අනිවාර්ය කොටස් තුන ගණන් කළ හැකිය (ආකෘතිය, max_tokens, පණිවිඩ).
- [ ] මට පද්ධතිය, පරිශීලක සහ සහකාර භූමිකාවන් අතර වෙනස පැහැදිලි කළ හැකිය.
- [ ] ඇමතුම් ස්ථාවර නොවන බවත් මට අතීතය රැගෙන යා යුතු බවත් මම දනිමි.
- මට [ ] අන්තර්ගතය, stop_reason සහ භාවිත ක්ෂේත්ර කියවා අදහස් දැක්වීමට හැකිය.
- [ ] max_tokens සමඟින් මට කප්පාදු කළ ප්රතිචාරය දැකීමට සහ හැසිරවීමට හැකිය.