LLM (Large Language Model) යෙදුමක් වෙනත් සැපයුම්කරුගේ OpenAI‑ගැලපෙන API එකකට මාරු කළ පසු, සාර්ථක HTTP ඇමතුමක්, නිවැරදි JSON ප්රතිචාරයක්, SDK එකෙන් යම් දෝෂයක් නොදැක්වීමත් සමඟම යෙදුම බිඳ වැටුණා. මෙය සරලව base URL එක වෙනස් කර, API key එක නවත්තලා, ඉල්ලුම් ශරීරය ඒකම තබා ඉදිරිපත් කිරීමෙන් සාර්ථක වූ පළමු ප්රෝම්ප්ට් එකේ පමණක් ක්රියාත්මක වුණා.
කැමති පරිදි, "OpenAI‑compatible" කියන API එකක් ඉල්ලුම් ආකෘතිය එකක් (model, messages) පිළිගැනීමේ හැකියාව පමණක් නොව, සැපයුම්කරුගේ අභ්යන්තර හැසිරීමත් එකසේ නොවේ. content වර්ගය (string, array, null), tool‑call arguments serialization, finish_reason, usage fields ඇතුළත් කිරීම, streaming සංකේතනය, structured‑output constraints, error handling වගේ දේවල් සැපයුම්කරු අනුව වෙනස් විය හැක.
මෙම ප්රතිචාර පාර්සරයේ වැරදි අනුමානයක් නිසා බග් එක පළ වුණා. මුල් කේතයේ const text = response.choices[0].message.content.trim(); යන ලයින් එක, tool‑call ආපසු එන විට message.content null වීමත්, සැබෑ ප්රතිඵලය message.tool_calls තුළ ඇති වීමත් හඳුනා ගැනීමට නොහැකි වුණා. එම නිසා පාර්සරය අසාර්ථක වුණා, API එකේ නොව. ප්රථම විසඳුම ලෙස response parser එක නවීකරණය කර, tool‑calls සහ text දෙකම හඳුනා ගන්නා ලදි.
ශ්රී ලංකාවට ඇති වැදගත්කම
LLM සැපයුම්කරු මාරුවීමේදී මෙවැනි සුක්ෂ්ම බග් එකක් පෙනී යාම, ශ්රී ලංකාවේ සංවර්ධකයන්, විද්යාලීය සිසුන්, ව්යාපාරිකයින් සඳහා වැදගත් පණිවිඩයක් වේ. පළමුව, API එකේ සමාන ඉල්ලුම් ආකෘතියක් භාවිතා කරන විටත්, ප්රතිචාරයේ ගැඹුරු ව්යුහය පරීක්ෂා නොකිරීමේ අවදානම ඉහළ යයි. දෙවැනි, tool‑call සහ JSON arguments පරික්ෂා කිරීමේ නියමිත පියවර අත්හැරීමෙන්, නිෂ්පාදන පද්ධති අසාර්ථක වීමේ අවදානම වැඩි වේ. තෙවැනි, නිවැරදි error handling සහ validation ක්රම රචනා කිරීම, ශ්රී ලංකාවේ තාක්ෂණික නිෂ්පාදනවල ගුණාත්මකභාවය සහ විශ්වාසය වැඩි කරයි. ඒ නිසා, දේශීය සංවර්ධකයන්ට API compatibility පරීක්ෂා කිරීම, response schema validation, tool‑call arguments JSON parsing වැනි පියවරයන් අනිවාර්යයි.
අවසන් වශයෙන්, LLM සැපයුම්කරු මාරුවීමේදී “compatible request ≠ compatible behavior” යන සත්යය මත අවධානය යොමු කර, සියලුම අතුරුදන්වීම් (null, empty, array) හඳුනා ගැනීමට කේතය සකස් කිරීම, දේශීය තාක්ෂණ වර්ධනයේ ගුණාත්මක පියවරක් වේ.
