Enhanced Chatbot Agent Workflow का परिचय

शुरुआत#

यह लेख Omnilude के ai-service ने Assistant / Thread / Run संरचना क्यों चुनी और Omnilude के ai-service में Agent इस तरह काम करते हैं का अगला भाग है।

पिछली पोस्टों में मैंने संरचना पर बात की थी। इस बार मैं देखना चाहता हूँ कि वही संरचना backoffice canvas के भीतर वास्तविक रूप में कैसे चल रही है। यहाँ विषय Enhanced Chatbot है।

यह लेख किसी बनावटी अमूर्त उदाहरण पर नहीं टिका है। यह वास्तविक workflow configuration के आधार पर बताता है कि यह agent कौन-सा input लेता है, कहाँ branch करता है, और answer बनाने से पहले किन assistants और tools से होकर गुजरता है।

एक वाक्य में यह enhanced chatbot क्या है#

यह agent एक काफी स्पष्ट branching chatbot है, जो सवालों को चार रास्तों में बाँटकर संभालता है।

• अगर सवाल सामान्य है, तो सीधे जवाब देता है।
• अगर ताज़ा जानकारी चाहिए, तो search path पर भेजता है।
• अगर input YouTube URL है, तो transcript summary path पर भेजता है।
• अगर input सामान्य web URL है, तो article analysis path पर भेजता है।

अगर वास्तविक workflow को सरल करें, तो वह कुछ ऐसा दिखता है।

दूसरे शब्दों में, इस workflow का मूल उद्देश्य एक ही model को ज़बरदस्ती जितना हो सके उतना अच्छा चलाना नहीं है। यह पहले तय करता है कि सवाल किस प्रकार का है, और फिर उसके लिए सही processing pipeline चुनता है।

मैं इसे इस तरह खोलना चाहता हूँ कि लोग सीधे इसे आज़मा सकें, लेकिन LLM usage की वास्तविक लागत है, इसलिए अभी इसे public तौर पर नहीं खोल पाया हूँ। जब थोड़ी और गुंजाइश होगी, तब इसे runnable form में उपलब्ध कराने की कोशिश करूँगा।

शुरुआत एक text input से होती है#

इस agent का start node text-input है, और example value के रूप में हाल की सामाजिक समस्याएँ क्या हैं? रखा गया है। यह सिर्फ demo text नहीं है, बल्कि यह भी दिखाता है कि यह workflow किस तरह की समस्या को हल करना चाहता है।

एक सवाल मिलते ही इसे सीधे LLM में नहीं डाला जाता। पहले इसे router node तक भेजा जाता है। यहाँ इस्तेमाल होने वाला assistant Question Router है, और configured routing sources कुल चार हैं।

• llm_direct: direct answer
• web_search: web search के बाद answer
• youtube_summary: YouTube summary
• article_analyze: web page analysis

यह router कोई साधारण if statement नहीं है। assistant की instructions में साफ लिखा है कि किस स्थिति में कौन-सा source चुना जाना चाहिए, और response को अनिवार्य रूप से JSON में लौटना होता है। उदाहरण के लिए ताज़ा जानकारी, date-sensitive जानकारी, या fact checking की ज़रूरत वाले सवाल web_search पर जाते हैं; YouTube URLs youtube_summary पर; सामान्य URLs article_analyze पर; और बाकी सब llm_direct पर।

यहाँ router केवल source नहीं छोड़ता, बल्कि reason भी छोड़ता है। canvas पर रखा गया एक text-visualize node उसी reason को आँखों से देखने के लिए debug viewer का काम करता है। यानी यह screen सिर्फ design diagram नहीं है; यह execution trace को सीधे देखने की working screen भी है।

direct-answer path सबसे छोटा है#

जब branch llm_direct पर जाती है, तो संरचना सीधी हो जाती है। router का output Question Answer assistant का इस्तेमाल करने वाले generate-text node में जाता है, और उस node का output सीधे finish तक पहुँचता है।

यहाँ महत्वपूर्ण बात यह है कि रास्ता छोटा है, लेकिन इसलिए वह कम structured नहीं हो जाता। generate-text node execution समय aiAssistantId के माध्यम से assistant को फिर से load करता है, system prompt और user prompt को जोड़ता है, और उसके बाद ही actual model call करता है। मतलब canvas में assistant metadata जुड़ा हो, फिर भी runtime का असली आधार assistant id ही रहता है।

Enhanced Chatbot से जुड़े assistants यह हैं।

Router: Question Router (assistantId=1)
Direct answer: Question Answer (assistantId=2)
Search query writer: Web Search Expert (assistantId=12)
Search-based answer: AdaptiveAnswerer (assistantId=3)
YouTube writer: YoutubeSummarizer (assistantId=15)
Article writer: ArticleAnalizer (assistantId=16)

इसी वजह से वही generate-text node, उसमें लगाए गए assistant के अनुसार पूरी तरह अलग भूमिका निभा सकता है। node generic executor है; भूमिका assistant तय करता है।

search path दो नहीं, चार चरणों की है#

इस agent का वास्तविक केंद्र web_search path है। मौजूदा implementation देखें तो search-based answer एक ही बार में नहीं बनता। इसे जान-बूझकर कई चरणों में बाँटा गया है।

पहला चरण Web Search Expert है। यह assistant user के सवाल को उस query में बदलता है जिसे सीधे search engine में डाला जा सके। raw question को वैसे ही search नहीं किया जाता; उसे search-friendly line में बदला जाता है।

दूसरा चरण web-search-tool है। saved workflow config में यह node searchTool: "searx" के साथ रखा गया है, और वास्तविक implementation SearXng को call करती है, अधिकतम दस result snippets जुटाती है, और 200-second timeout लगाती है ताकि यह अनंत प्रतीक्षा में न फँसे।

तीसरा चरण prompt-crafter है। यह node search results को सीधे final answer में नहीं चिपकाता। यह {{results}} को पहले से saved template में inject करता है और एक answering system prompt बनाता है। उस template में current time, reference material, answer rules और writing tone पहले से शामिल हैं।

चौथा चरण AdaptiveAnswerer है। यहाँ दिलचस्प बात यह है कि original user question prompt के रूप में बना रहता है, जबकि search से बनाया गया context system में जाता है। यानी search results को बस जोड़ नहीं दिया जाता; question और evidence को अलग रखकर एक writer assistant final answer फिर से लिखता है।

अगर इस flow को फिर से खींचें, तो यह कुछ ऐसा दिखता है।

मेरे हिसाब से यही हिस्सा बहुत महत्वपूर्ण है। सिर्फ search जुड़ जाने भर से इसे तुरंत RAG जैसा opaque block नहीं बनाया गया। question refinement, evidence assembly और final writing को अलग रखा गया है। इससे operation के दौरान यह देखना भी आसान हो जाता है कि कौन-सा चरण डगमगा रहा है।

YouTube और Article path tool-first हैं#

URL based branches ज़्यादा सीधी हैं।

अगर input YouTube URL है, तो पहले youtube-summary-tool चलता है। यह node YoutubeTranscriptTool का इस्तेमाल करके time information के साथ transcript लाता है। उसके बाद YoutubeSummarizer assistant उस transcript को readable content में बदल देता है।

अगर input सामान्य web URL है, तो पहले article-analyzer-tool चलता है। यह node Crawl4Ai से page crawl करता है और जहाँ संभव हो, Readability4J से केवल main body निकालकर title और text वाले markdown में बदल देता है। उसके बाद ArticleAnalizer assistant इसे readable article की तरह पुनर्गठित करता है।

दूसरे शब्दों में, दोनों URL paths एक ही दर्शन का पालन करती हैं।

• पहले tool raw material लाता है।
• उसके बाद assistant उसे इंसान के पढ़ने लायक परिणाम में बदलता है।

यह search path से भी मिलता-जुलता है। Omnilude के वर्तमान agent design में tool और assistant एक-दूसरे के प्रतिद्वंद्वी नहीं हैं। tool सामग्री लाता है; assistant उस सामग्री की व्याख्या और पुनर्संरचना करता है।

यह screen सिर्फ एक सुंदर diagram नहीं है#

Backoffice canvas को देखें तो बीच-बीच में text-visualize nodes दिखाई देते हैं। ये final result के लिए अनिवार्य नहीं हैं। इनका काम यह दिखाना है कि इस समय graph के भीतर कौन-सी value बह रही है।

Frontend implementation भी इसी दिशा में बनी है। जब workflow execution को NODE_COMPLETED event मिलता है, तो frontend उस node के output value को canvas state में inject कर देता है। text-visualize node उस value को जैसा है वैसा दिखाता है, और अगर streaming deltas आते हैं, तो text को accumulate करता जाता है।

यह अंतर दिखने से ज्यादा महत्वपूर्ण है। बहुत-से workflow tools nodes को draw करने तक ही रुक जाते हैं। लेकिन Omnilude का वर्तमान backoffice agent screen दो कामों को साथ रखता है: saved graph देखना और real execution के intermediate values को observe करना। इसलिए यह canvas diagram भी है और debugger भी।

execution engine इसे इस तरह देखता है#

अब canvas से बाहर निकलकर देखें। यह workflow DB में ai.ai_agent.workflow JSONB के रूप में store होता है। यह अलग-अलग node tables में नहीं बँटा है; इसे एक single graph JSON की तरह रखा गया है।

Execution शुरू होते ही BasicWorkflowEngine पहले उस node को खोजता है जिसका type -input पर खत्म होता हो और startNode=true हो। यहाँ वह start point text-input है। उसके बाद NodeExecutorFactory हर node type के लिए सही executor चुनता है और execution को आगे बढ़ाता है।

Enhanced Chatbot में महत्वपूर्ण executors को मोटे तौर पर इस तरह समेटा जा सकता है।

• TextInputNode: प्रारंभिक input तैयार करता है
• RouterNode: assistant की मदद से branch चुनता है
• GenerateTextNode: assistant आधारित text generation
• WebSearchToolNode: SearXng search चलाता है
• YoutubeSummaryToolNode: YouTube transcript निकालता है
• ArticleAnalyzerToolNode: web body text साफ करता है
• PromptCrafterNode: template आधारित system prompt बनाता है
• FinishNode: branch results इकट्ठा कर execution समाप्त करता है

यहाँ सबसे महत्वपूर्ण बात यह है कि generate-text और router दोनों execution समय assistant को फिर से load करते हैं। agent खुद intelligence का मालिक नहीं है। हर node ज़रूरत पड़ने पर assistant को खींचकर इस्तेमाल करता है। अंत में, agent orchestration है और actual inference अभी भी assistants ही करते हैं।

finish node दिखने से कम सरल नहीं है#

अंतिम finish node सिर्फ एक end button नहीं है। यह incoming edges को देखता है, अगर अभी कुछ input handles चल रहे हों तो इंतज़ार करता है, और केवल उन्हीं source nodes के outputs को final result के रूप में आगे भेजता है जो वास्तव में तैयार हैं।

यह संरचना branching की वजह से ज़रूरी है। router का चार paths में बाँटना यह नहीं कहता कि वे चारों paths हमेशा एक ही तरीके से पूरी होंगी। कुछ सवाल direct answer पर खत्म हो जाते हैं, और कुछ search और summary से होकर गुजरते हैं। finish वही अंतिम collector है जो इन अंतरों को absorb करता है।

इसलिए यह agent सिर्फ ऐसा function नहीं है जो एक सवाल ले और एक जवाब दे दे। यह एक graph executor with branching, waiting, and merging के ऊपर चल रहा है।

इस agent की मंशा#

मेरे हिसाब से यह सरल agent भी Omnilude की वर्तमान AI दिशा को काफी साफ़ रूप से दिखाता है।

पहला, यह general-purpose agent के विचार को बढ़ा-चढ़ाकर पेश नहीं करता। पहले सवाल के प्रकार को अलग करता है, फिर उसके लिए सही tool और writer जोड़ता है।

दूसरा, यह search path को एक opaque block में नहीं दबाता। question refinement, search, context assembly और final answer writing अलग-अलग रखे गए हैं।

तीसरा, backoffice canvas सिर्फ editor नहीं है। यह execution के intermediate values भी दिखाता है, ताकि prompt experiments और debugging एक ही screen पर हो सकें।

चौथा, assistant और agent की भूमिकाएँ साफ़ हैं। assistant inference component है, और agent उन components को जोड़ने वाला workflow है।

इसी वजह से मुझे यह implementation "हमने एक AI agent बना लिया" से ज्यादा "हमने question-processing pipeline को visually operable form में बदल दिया" के करीब लगती है।

समापन#

अगर पिछली पोस्टों में assistant, thread, run और agent की संरचना समझाई गई थी, तो यह लेख उस व्याख्या का वास्तविक उदाहरण है, जहाँ वही बात एक असली canvas और असली node graph के रूप में दिखाई देती है। Enhanced Chatbot एक router, कई writer assistants और search, YouTube, article tools को जोड़कर पहले से ही काफी practical chatbot की तरह काम कर रहा है।

जब थोड़ा और समय और गुंजाइश होगी, तब मैं images और वास्तविक running screen के आधार पर इस agent की composition और implementation को और सरल तरीके से फिर से समझाना चाहूँगा।