Production Backend වල LLM භාවිතා කිරීමේ ගැටලුව
Frontier LLM එකක් production backend service එකකට integrate කරපු ඕනෑම software engineer කෙනෙක් මුහුණ දෙන ප්රධානම ප්රශ්නයක් තියෙනවා. ඒ තමයි latency එක සහ unpredictable outputs. සාමාන්යයෙන් අපිට ඕන වෙන්නේ simple routing decision එකක් හෝ categorization එකක් කරගන්න වුණත්, traditional autoregressive model එකක් තත්පර 3 ඉඳන් තත්පර 30ක් හෝ ඊටත් වඩා වැඩි කාලයක් token by token text generate කරමින් ඉන්නවා.
Structured outputs හෝ JSON schema enforce කළත්, LLMs සමහර වෙලාවට invalid fields දෙනවා, validation fail වෙනවා, නැත්නම් hallucinate වෙනවා. Deterministic uptime සහ strict SLAs බලාපොරොත්තු වෙන enterprise software එකක, simple conditional logic එකක් වෙනුවෙන් conversational chatbot එකක් API එකක් ඇතුළේ run කරන එක practical විසඳුමක් නෙවෙයි.
මොකක්ද මේ System One Model සංකල්පය?
මේ නම හැදිලා තියෙන්නේ Daniel Kahneman ගේ ප්රසිද්ධ Thinking, Fast and Slow පොතේ එන cognitive framework එකෙන්. එතැනදී System 1 කියන්නේ අපේ මොළයේ සිදුවන වේගවත්, intuitive සහ subconscious තීරණ ගැනීමේ ක්රියාවලියටයි. System 2 කියන්නේ සෙමින්, ගැඹුරින් සහ පියවරෙන් පියවර කල්පනා කරලා ගන්නා deliberate reasoning ක්රියාවලියටයි.
දැනට තියෙන frontier LLMs හැම ප්රශ්නයක්ම විසඳන්න උත්සාහ කරන්නේ System 2 විදිහටයි. ඒ කියන්නේ සරල classification හෝ routing වැඩකටත් chain of thought සහ autoregressive token generation run කරනවා.
OpenAI එකේ හිටපු researcher කෙනෙක් වන Diogo Almeida විසින් ආරම්භ කළ TypeSafe AI සමාගම Jev හරහා හඳුන්වා දෙන්නේ dedicated System One model එකක්. මෙහි මූලික න්යාය ඉතාම සරලයි: Jev සම්පූර්ණයෙන්ම arbitrary string generation අතහැරලා තියෙනවා. Jev කවදාවත් essays ලියන්නේ නෑ, chat completions දෙන්නේ නෑ, නැත්නම් freeform text generate කරන්නේ නෑ.
ඒ වෙනුවට Jev වැඩ කරන්නේ high-speed function call එකක් විදිහටයි. ඔයා unstructured program state එක input එකක් විදිහට දුන්නම, ඒකට අදාළ typed probabilistic decisions output එක විදිහට ලැබෙනවා.
Architecture එක: Parallel Sampling සහ Autoregressive Generation අතර වෙනස
සාමාන්ය LLMs ක්රියාත්මක වෙන්නේ autoregressive විදිහටයි. ඒ කියන්නේ ඊළඟ token එක predict කරන්නේ කලින් generate වුණු හැම token එකක්ම sequential විදිහට කියවමින්. මේ නිසා hardware bandwidth සහ network latency එක මත රැඳුණු latency floor එකක් නිර්මාණය වෙනවා.
නමුත් Jev කරන්නේ parallel sampling භාවිත කිරීමයි. මෙහිදී output structure එක කලින්ම define කරලා තියෙන නිසා, model එක තනි execution pass එකකින් සියලුම output probabilities predict කරනවා.
DimensionFrontier LLMsJev (System One)Sampling MethodSequential (token by token)Parallel (single forward pass)Output FormatFreeform stringsType-safe structured valuesEnd-to-End Latencyතත්පර 3 සිට 300+ දක්වා70ms සිට 500ms දක්වාInput Token Cost$0.20 සිට $10.00 / MTok$0.042 / MTokOutput Token Costඉහළයි (input cost එක මෙන් 5x පමණ)Free (zero cost)Type SafetyParse කර validation අවශ්යයිMathematically guaranteedConfidence ScoresUncalibrated සහ inconsistentEpistemically calibrated (RLCD)
Text generation අතහැර දැමීම නිසා sequential overhead එක නැතිවෙලා යනවා. End-to-end response time එක 70ms ඉඳන් 500ms දක්වා අඩු වෙනවා. මේ speed එක නිසා Jev කෙළින්ම synchronous HTTP request pipelines ඇතුළේ භාවිතා කරන්න පුළුවන්.
RLCD හරහා නිවැරදි Calibration එකක්
සාමාන්ය LLMs optimize කරන්නේ RLHF (Reinforcement Learning with Human Feedback) හෝ RLVR (Reinforcement Learning with Verifiable Rewards) හරහායි. මේවායින් කරන්නේ මිනිස්සු කැමති විදිහට පැහැදිලිව කතා කරන conversational responses හදන එකයි. මෙහි තියෙන ප්රධානම අවාසිය තමයි model එක වැරදි උත්තරයක් දෙන වෙලාවටත් ඒක ඉතාම confident විදිහට ඉදිරිපත් කිරීම.
Jev පුහුණු කරන්නේ RLCD (Reinforcement Learning for Calibrated Decisions) ක්රමවේදය මගින්. මෙහිදී optimize කරන්නේ epistemic honesty එකයි. Jev යම් තීරණයකට 90% confidence එකක් දෙනවා නම්, real-world benchmarks වලදීත් ඒ තීරණය 90% ක්ම නිවැරදි බව තහවුරු වෙනවා.
Production systems වලදී මේ calibrated confidence score එක ඉතාම වැදගත්. තමන්ගේ decision එක ගැන model එකටම නිශ්චිත විශ්වාසයක් නැති වෙලාවල් හරියට identify කරගන්න බැරි නම්, automated workflows මිනිස් අධීක්ෂණයකින් තොරව run කරන්න බෑ.
Production Implementation එකක් බලමු
Jev භාවිතා කරන එක LLM එකකට prompt කරනවට වඩා typed microservice එකක් call කරනවා වගේ වැඩක්. Fraud detection සහ ticket routing සඳහා උදාහරණයක් පහතින් බලන්න:
Python
import httpx
# Application runtime එකෙන් ලැබෙන unstructured context එක
context = """
User account created 4 hours ago from a residential IP in Chicago.
Attempted 5 credit card transactions with distinct billing postal codes within 10 minutes.
Customer opened a support chat demanding instant balance clearance.
"""
payload = {
"state": context,
"decisions": {
"risk_level": ["low", "medium", "high", "critical"],
"flag_suspicious": [True, False],
"require_manual_review": [True, False]
}
}
client = httpx.Client(timeout=1.0)
response = client.post("https://api.typesafe.ai/v1/decide", json=payload)
result = response.json()
# Response එකෙන් ලැබෙන්නේ calibrated probabilities සහිත typed decisions
# {
# "risk_level": {"value": "critical", "confidence": 0.96},
# "flag_suspicious": {"value": True, "confidence": 0.99},
# "require_manual_review": {"value": True, "confidence": 0.92}
# }
if result["risk_level"]["value"] == "critical" and result["risk_level"]["confidence"] > 0.90:
print("Action: Lock account immediately and escalate to security team.")
Output schema එක architecture level එකෙන්ම enforce වෙන නිසා malformed JSON, missing fields හෝ parsing runtime errors එන්නේ නෑ.
Tradeoffs සහ සීමාවන්
Jev කියන්නේ general purpose chat models වලට replacement එකක් නෙවෙයි. System One model එකක් තෝරාගනිද්දී සලකා බැලිය යුතු කරුණු කිහිපයක් තියෙනවා:
Freeform Text නොමැති වීම: Jev මගින් emails ලිවීම, documents summarize කිරීම, code ලිවීම හෝ chatbot එකක් run කිරීම කළ නොහැක. Natural language sentences generate කරන්න අවශ්ය තැන්වලදී Jev සුදුසු නෑ.
කලින් තීරණය කළ Decision Space: Model එක call කරන්න කලින් output schema එක සහ branching options define කර තිබිය යුතුයි. Dynamic exploration සඳහා සාම්ප්රදායික System 2 model එකක් අවශ්ය වෙනවා.
Network Latency: Model එකේ internal execution එක 100ms වලට වඩා අඩු වුණත්, public internet network roundtrips මෙයට බලපානවා. අපේ backend servers සහ inference clusters අතර geographical දුර වැඩි නම් network latency එක ප්රධාන සාධකයක් වෙනවා.
Architecture එක ඇතුළේ Jev ගැලපෙන්නේ කොතැනටද?
Jev යන නම යොදාගෙන තිබෙන්නේ සුප්රකට ආර්ථික විද්යාඥ William Stanley Jevons සහ Jevons paradox සංකල්පය සිහිපත් කරමිනුයි. යම් සම්පතක කාර්යක්ෂමතාව වැඩි වී මිල ශීඝ්රයෙන් පහත වැටෙන විට, එම සම්පතේ භාවිතය විශාල වශයෙන් ඉහළ යනවා.
Input tokens මිලියනයක් සඳහා $0.042 ක් සහ output tokens සම්පූර්ණයෙන්ම free වීම නිසා, software architectures ඇතුළේ AI භාවිතා කරන ආකාරය වෙනස් වෙනවා. Background batch jobs වලට සීමා නොවී, inner application loops, input validation pipelines, real-time gaming engines සහ automated triage systems වලට high-speed intelligence එකතු කිරීමට Jev මගින් ඉඩ සැලසෙනවා.