LangFlow-இல் வெற்றி பெற்று, n8n Production-இல் தோல்வியடையும் 3 சோதனைகள்
நீங்கள் ஒரு LangFlow முன்மாதிரியை (prototype) உருவாக்கினீர்கள். ஒவ்வொரு சோதனையும் வெற்றியடைந்தது. அந்தப் போக்கை (flow) தயாரிப்புப் பயன்பாட்டிற்காக (production) n8n-க்கு மாற்றினீர்கள். முதல் முறையே அது செயலிழந்துவிட்டது.
இது ஒரு பிழை (bug) அல்ல. இது ஒரு தொடர் நிகழ்வு (pattern).
LangFlow என்பது ஒரு மேம்பாட்டுச் சூழல் (development environment). நீங்கள் அதைக் கவனித்துக் கொண்டிருப்பீர்கள் என்று அது கருதுகிறது. பிழைகள் மற்றும் மறுமுயற்சிகளுக்கு (retries) அது சகிப்புத்தன்மையுடன் செயல்படுகிறது.
n8n என்பது ஒரு தயாரிப்பு இயந்திரம் (production engine). இது எவ்வித மேற்பார்வையும் இன்றி இயங்குகிறது. ஒவ்வொரு நோடும் (node) ஒரு சரியான பரிவர்த்தனையாக (transaction) இருக்க வேண்டும் என்று அது எதிர்பார்க்கிறது. ஒரு தோல்வியைக் கையாளவில்லை என்றால், பணிப்பாய்வு (workflow) நின்றுவிடும்.
முன்மாதிரியிலிருந்து தயாரிப்பு நிலைக்கு மாறும்போது தோல்வியடையும் மூன்று சோதனைகள் இதோ:
1. JSON Parsing
LangFlow-இல், நீங்கள் JSON-ஐக் கேட்கிறீர்கள். மாடல் ஒரு சரத்தை (string) வழங்குகிறது. நீங்கள் அதைத் தொகுக்கிறீர்கள் (parse). அது வேலை செய்கிறது.
n8n-இல், மாடல் markdown fences, ஒரு முன்னுரை (preamble) அல்லது இறுதியில் ஒரு கமா (trailing comma) ஆகியவற்றைச் சேர்க்கக்கூடும். LangFlow இத்தகைய சிறிய பிழைகளைப் புறக்கணிக்கும். ஆனால் n8n அப்படிச் செய்யாது. இதனால் JSON நோடு தோல்வியடைந்து முழு பணிப்பாய்வும் நின்றுவிடும்.
தீர்வு: சிறந்த ப்ராம்ப்ட்டை (prompt) மட்டும் நம்பியிருக்க வேண்டாம். ஒரு சரிபார்ப்பு அடுக்கை (validation layer) உருவாக்குங்கள். அதைத் தொகுப்பதற்கு (parse) முன்னதாக, markdown-ஐ நீக்கி சரத்தைச் சுத்திகரிக்க ஒரு utility நோடைப் பயன்படுத்துங்கள்.
2. Context Limits
LangFlow-இல், நீங்கள் 8,000 டோக்கன்கள் (tokens) கொண்ட ஒரு ஆவணத்தைச் சோதிக்கிறீர்கள். அது வேலை செய்கிறது. 12,000 டோக்கன்களைச் சோதிக்கிறீர்கள். அதுவும் வேலை செய்கிறது.
n8n-இல், உங்கள் பணிப்பாய்வு நிலைகளைச் (state) சேகரிக்கிறது. துணைப் பணிப்பாய்வுகள் (sub-workflows), வரலாறு (history) மற்றும் மெட்டாடேட்டா (metadata) ஆகியவை சேர்ந்து கொண்டே இருக்கும். தனித்து இயங்கும்போது சரியாக இருந்த ஒரு ஆவணம், முழுமையான குழாயின் (pipeline) ஒரு பகுதியாக இருக்கும்போது வரம்பைத் (limit) தாண்டிவிடக்கூடும். இதனால் மாடல் உரையைத் துண்டித்துவிடும் (truncate), உங்கள் வெளியீடு பயனற்றதாக மாறிவிடும்.
தீர்வு: ஒரு context budget checker-ஐச் செயல்படுத்துங்கள். LLM அழைப்பிற்கு முன்னதாக உங்கள் டோக்கன்களை அளவிடுங்கள். நீங்கள் வரம்பைத் தாண்டினால், தெளிவான பிழைச் செய்தியுடன் பணிப்பாய்வை முன்கூட்டியே நிறுத்துங்கள்.
3. Transient Failures
LangFlow-இல், ஒரு அழைப்பு தோல்வியடைந்தால், நீங்கள் மீண்டும் "Run" என்பதைக் கிளிக் செய்கிறீர்கள். அது ஒரு தற்காலிக நெட்வொர்க் கோளாறு என்று நீங்கள் கருதுகிறீர்கள்.
n8n-இல், அதிகாலை 2 மணிக்கு ஒரு அழைப்பு தோல்வியடைந்தால், பணிப்பாய்வு நின்றுவிடும். "Run" என்பதைக் கிளிக் செய்ய யாரும் இருக்க மாட்டார்கள். உங்கள் தரவு ஒரு பிழை வரிசையில் (error queue) சிக்கிக்கொள்ளும்.
தீர்வு: ஒரு சாதாரண மறுமுயற்சியை (retry) மட்டும் சேர்க்காதீர்கள். exponential backoff முறையைப் பயன்படுத்துங்கள். மிக முக்கியமாக, ஒரு dead-letter queue-ஐப் பயன்படுத்துங்கள். இது தோல்வியடைந்த உள்ளீட்டைச் சேமித்து வைக்கும், இதன் மூலம் நீங்கள் சிக்கலைச் சரிசெய்து பின்னர் அதை மீண்டும் இயக்க முடியும்.
முன்மாதிரியிலிருந்து தயாரிப்பு நிலைக்கு மாறுவதற்கான சுருக்கம்: • ஒவ்வொரு LLM வெளியீட்டிற்கும் ஒரு சரிபார்ப்பு அடுக்கைச் சேர்க்கவும். • ஒவ்வொரு அழைப்பிற்கும் முன்னதாக context பயன்பாட்டை அளவிடவும். • dead-letter queue உடன் மறுமுயற்சிகளைச் செயல்படுத்தவும்.
முன்மாதிரி என்பது ஒரு வரைபடம் (sketch). தயாரிப்பு என்பது ஒரு கட்டிடம். இரண்டையும் குழப்பிக்கொள்ளாதீர்கள்.
Source: https://dev.to/qawalah/3-tests-that-pass-in-langflow-but-fail-in-n8n-production-22i7
Optional learning community: https://t.me/GyaanSetuAi
