கருவி அழைப்பு (Tool Call) வெற்றியடைந்தது. அதன் விளைவு தோல்வியடைந்தது.

பொறியியல் குழுக்கள் பெரும்பாலும் தவறான சிக்னல்களைத் தேடுகிறார்கள்.

நீங்கள் கிராஷ்களைத் (crashes) தேடுகிறீர்கள். நீங்கள் எக்ஸெப்ஷன்களைத் (exceptions) தேடுகிறீர்கள். நீங்கள் சிவப்பு நிற டாஷ்போர்டுகளைத் தேடுகிறீர்கள்.

சில மோசமான தோல்விகள் தோல்வி போலத் தெரியாது. அவை வெற்றியைப் போலவே தோன்றும்.

AI agents மற்றும் MCP servers உடன் பணியாற்றும் போது நான் இந்த முறையைக் கண்டேன். ஒரு ஏஜென்ட் (agent) ஒரு கருவியை (tool) அழைக்கிறது. அந்த கருவி ஒரு வெற்றிகரமான பதிலை அளிக்கிறது. அங்கு பிழை (error) ஏதுமில்லை. காலதாமதமும் (timeout) இல்லை. சிஸ்டம் ஆரோக்கியமாகத் தெரிகிறது.

ஆனால் அந்தப் பணி தோல்வியடைந்தது. அந்தச் செயல் நடக்கவே இல்லை. பயனர் தவறான முடிவைப் பெறுகிறார்.

உங்கள் குழுவைக் காட்டிலும் வாடிக்கையாளரே முதலில் இந்தப் பிரச்சனையைத் கண்டறிகிறார்.

பெரும்பாலான மென்பொருள்கள் ஒரு கருத்தை அடிப்படையாகக் கொண்டு இயங்குகின்றன: கோரிக்கை (request) வெற்றியடைந்தால், அதன் விளைவும் (outcome) வெற்றியடையும்.

நீங்கள் வெளிப்புற அமைப்புகளைப் (external systems) பயன்படுத்தும் போது இந்த கருத்து தோல்வியடைகிறது. AI agents, APIs, தரவுத்தளங்கள் (databases) மற்றும் SaaS தளங்களைச் சார்ந்துள்ளன. ஒவ்வொரு சார்புத் தன்மையும் (dependency) கோரிக்கைக்கும் யதார்த்தத்திற்கும் இடையே ஒரு இடைவெளியை உருவாக்குகிறது.

சிஸ்டம் வெற்றியைத் தெரிவிக்கிறது. ஆனால் யதார்த்தம் ஒரு தோல்வி.

உதாரணச் சூழல்கள்:

• கருவி ஒரு சரியான பதிலை அளிக்கிறது, ஆனால் முடிவு 'null' ஆக உள்ளது. ஏஜென்ட் முழுமையற்ற தரவுகளுடன் தொடர்கிறது. • ஒரு கோரிக்கை மூன்று செயல்களைத் தூண்டுகிறது. அதில் ஒன்று மட்டுமே முடிகிறது. இருப்பினும் கருவி வெற்றியைத் தெரிவிக்கிறது. இப்போது உங்கள் பணிப்பாய்வு (workflow) உடைந்துவிட்டது. • பதில் வெற்றிகரமாக வந்துவிடுகிறது, ஆனால் தரவு பழையது. ஏஜென்ட் காலாவதியான உண்மைகளின் அடிப்படையில் முடிவுகளை எடுக்கிறது. • ஒரு புலத்தின் (field) வடிவம் மாறுகிறது. சிஸ்டம் இன்னும் தரவைப் பெறுகிறது, ஆனால் அதன் பொருள் தவறானது. பணிப்பாய்வு அமைதியிலேயே (silently) உடைந்துவிடுகிறது.

கிராஷ்களைக் கண்டறிவது எளிது. அமைதியான தோல்விகளைக் (silent failures) கண்டறிவது கடினம்.

ஒரு கிராஷ் எச்சரிக்கையை (alert) உருவாக்குகிறது. ஒரு அமைதியான தோல்வி பயனர் நம்பிக்கையைச் சிதைக்கிறது. பாதிப்பு ஏற்பட்ட பிறகு பொறியாளர்கள் பிழைத்திருத்தத்திற்காக (debugging) பல மணிநேரங்களைச் செலவிடுகிறார்கள்.

பொதுவாக ஒரு வாடிக்கையாளர் புகார் அளிக்கும் போதுதான் விசாரணை தொடங்குகிறது. நம்பகத்தன்மைப் பிரச்சனையை (reliability problem) கண்டறிய இதுவே மிகவும் செலவு மிகுந்த வழியாகும்.

வெற்றிகரமான கோரிக்கைகளை மட்டும் நம்புவதை நிறுத்துங்கள். வெற்றிகரமான விளைவுகளைச் சரிபார்க்கத் தொடங்குங்கள்.

ஒரு பதில் குறியீடு (response code) தகவல் தொடர்பு நடந்ததா என்பதை மட்டுமே சொல்கிறது. இலக்கு எட்டப்பட்டதா என்பதை அது சொல்லாது.

உங்கள் கடைசி 10 புரொடக்ஷன் (production) கருவி அழைப்புகளைப் (tool calls) பரிசீலியுங்கள். இந்தக் கேள்விகளைக் கேளுங்கள்:

  • கோரிக்கை வெற்றியடைந்ததா?
  • திட்டமிட்ட முடிவு நிகழ்ந்ததா?
  • அது தோல்வியடைந்தால் நாம் எப்படித் தெரிந்துகொள்வோம்?

பதில்கள் வேறுபட்டால், உங்களிடம் ஒரு நம்பகத்தன்மை இடைவெளி (reliability gap) உள்ளது என்று அர்த்தம். நீங்கள் கண்டறியாவிட்டால், உங்கள் பயனர்கள் விரைவில் அதைக் கண்டறிந்துவிடுவார்கள்.

Source: https://dev.to/sasi_sundar/the-tool-call-succeeded-the-outcome-failed-3l59

Optional learning community: https://t.me/GyaanSetuAi