संरचित प्रक्रियाएं

परिचय

संरचित प्रक्रिया एक प्रक्रिया है, जो चरणों का एक तय क्रम चलाती है। फ्री-फ़ॉर्म प्रक्रिया प्राकृतिक भाषा में दिया गया मार्गदर्शन है, जिसे एजेंट समझकर स्थिति के अनुसार ढालता है। संरचित प्रक्रिया, टाइप किए गए चरणों की एक क्रमबद्ध सूची है, जिसे प्रक्रिया लागू होने पर एजेंट हर बार क्रम से चलाता है।

जब हर कॉल पर खास चरण एक ही तरह होने चाहिए, तब संरचित प्रक्रिया इस्तेमाल करें: जैसे कॉलर की पहचान सत्यापित करना, टिकट एस्केलेट करना या भुगतान लेना। आप इसे सामान्य भाषा में लिखे छोटे चरणों की सूची के रूप में बनाते हैं।

हर प्रक्रिया की तरह, संरचित प्रक्रिया का भी एक ट्रिगर होता है, जो बताता है कि यह कब लागू होती है। बातचीत ट्रिगर से मेल खाने पर एजेंट प्रक्रिया के चरण क्रम से चलाता है, फिर बाकी बातचीत पर लौट आता है।

संरचित प्रक्रिया का उपयोग कब करें

जब खास चरणों को हर बार एक ही तरह चलना हो, लेकिन आप उन्हें सामान्य चरणों में जल्दी लिखना चाहते हों, तब संरचित प्रक्रिया इस्तेमाल करें। संरचित प्रक्रियाएं workflow की तुलना में लिखना आसान हैं, लेकिन कम अभिव्यक्तिपूर्ण हैं। फ्री-फ़ॉर्म प्रक्रियाओं, workflows और सिस्टम प्रॉम्प्ट के साथ इनकी तुलना के लिए प्रक्रियाओं का उपयोग कब करें देखें।

संरचित प्रक्रिया की संरचना

संरचित प्रक्रिया के तीन भाग होते हैं: नाम, ट्रिगर और चरणों की एक क्रमबद्ध सूची।

नाम

डैशबोर्ड में प्रक्रिया की पहचान करने वाला छोटा लेबल। नाम कभी LLM को नहीं भेजा जाता, इसलिए यह एजेंट के व्यवहार को प्रभावित नहीं करता।

ट्रिगर

एजेंट को यह प्रक्रिया कब चलानी चाहिए, इसका सामान्य भाषा में विवरण, जैसे जब यूज़र किसी ऑर्डर का रिफंड मांगे। एजेंट यूज़र के इरादे की तुलना हर प्रक्रिया के ट्रिगर से करता है और मेल खाने वाली प्रक्रिया चलाता है, इसलिए ट्रिगर स्पष्ट और अलग-अलग होने चाहिए। एजेंट केवल ट्रिगर टेक्स्ट देखता है, प्रक्रिया का नाम या ID कभी नहीं। ट्रिगर किसी भी प्रक्रिया की तरह ही काम करता है; ट्रिगर लिखना देखें।

प्रक्रिया को उप-प्रक्रिया बनाने के लिए ट्रिगर खाली छोड़ दें, ताकि यह केवल दूसरी प्रक्रिया द्वारा कॉल किए जाने पर चले।

चरण

प्रक्रिया का मुख्य भाग टाइप किए गए चरणों की क्रमबद्ध सूची होता है। चरणों के कई प्रकार हैं, जिन्हें मिलाकर आप कार्य का विवरण देते हैं।

हर चरण हर जगह नहीं आ सकता। If आर्म के अंदर आप दूसरे If या Retry को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं। Tool चरण के विफलता हैंडलर में आप If या दूसरे Tool को छोड़कर कोई भी चरण इस्तेमाल कर सकते हैं।

API चरण रेफरेंस

संरचित प्रक्रिया content, steps ऐरे वाला JSON-एन्कोडेड दस्तावेज़ है। हर चरण एक ऑब्जेक्ट है, जिसकी पहचान उसके type से होती है। ट्रिगर प्रक्रिया का अलग टॉप-लेवल फ़ील्ड है, content का हिस्सा नहीं। API और SDK पेलोड में प्रक्रिया के लिए type: "deterministic" इस्तेमाल होता है।

पूछें

Ask चरण एजेंट को जानकारी मांगने और यूज़र द्वारा उचित जवाब देने तक प्रतीक्षा करने का निर्देश देता है।

• API प्रकार: ask
• instruction: आवश्यक, गैर-खाली स्ट्रिंग।

{
  "type": "ask",
  "instruction": "Ask the user for their order ID."
}

बताएं

Tell चरण एजेंट को अपने शब्दों में एक संदेश बनाने का निर्देश देता है। आगे बढ़ने से पहले यह यूज़र के जवाब की प्रतीक्षा नहीं करता।

• API प्रकार: tell
• instruction: आवश्यक, गैर-खाली स्ट्रिंग।

{
  "type": "tell",
  "instruction": "Explain that the refund normally takes five to ten business days."
}

कहें

Say चरण दिए गए टेक्स्ट को लिखे हुए रूप में ही बोलता है, फिर आगे बढ़ता है। एजेंट द्वारा समर्थित हर अतिरिक्त भाषा के लिए, भाषा कोड के आधार पर सटीक संदेश देने के लिए message_translations दें।

• API प्रकार: say
• message: आवश्यक, गैर-खाली स्ट्रिंग।
• message_translations: भाषा कोड को { "value": "..." } से मैप करने वाला वैकल्पिक ऑब्जेक्ट।

{
  "type": "say",
  "message": "Your refund has been submitted.",
  "message_translations": {
    "es": { "value": "Su reembolso ha sido enviado." }
  }
}

If, else if और else

If चरण में एक या अधिक क्रमबद्ध सशर्त आर्म होते हैं। पहला मेल खाने वाला आर्म चलता है। वैकल्पिक fallback ऐरे Else आर्म है।

• API प्रकार: branch
• branches: आवश्यक, सशर्त आर्म की गैर-खाली सूची।
• fallback: Else चरणों की वैकल्पिक सूची।
• हर आर्म में condition और गैर-खाली steps सूची आवश्यक है।

{
  "type": "branch",
  "branches": [
    {
      "condition": {
        "type": "llm",
        "condition": "The user is on an annual plan."
      },
      "steps": [
        {
          "type": "say",
          "message": "Your annual plan is eligible for a prorated refund."
        }
      ]
    }
  ],
  "fallback": [
    {
      "type": "tell",
      "instruction": "Explain that the account's plan could not be determined."
    }
  ]
}

यह if/else-if/else की तरह काम करता है:

1. शर्तों का मूल्यांकन क्रम से होता है।
2. पहला मेल खाने वाला आर्म चलता है।
3. कोई शर्त मेल न खाने पर fallback चलता है।
4. आर्म पूरा होने के बाद प्रक्रिया मुख्य क्रम में लौट आती है।

ऊपर के उदाहरण में टेक्स्ट शर्त का उपयोग है, जिसका मॉडल प्राकृतिक भाषा में मूल्यांकन करता है। शर्तें डायनामिक वेरिएबल्स पर एक्सप्रेशन भी हो सकती हैं:

{
  "type": "expression",
  "expression": {
    "type": "eq_operator",
    "left": {
      "type": "dynamic_variable",
      "name": "plan_tier"
    },
    "right": {
      "type": "string_literal",
      "value": "annual"
    }
  }
}

एक्सप्रेशन शर्त डायनामिक वेरिएबल्स की जांच करती है, जो टूल के नतीजों से भरे जाते हैं या बातचीत शुरू होने पर सेट होते हैं। यह यूज़र का सबसे हाल का जवाब नहीं पढ़ सकती। यूज़र ने क्या कहा, उसके आधार पर ब्रांच करने के लिए टेक्स्ट शर्त इस्तेमाल करें।

एक If चरण के सभी आर्म में एक ही शर्त प्रकार होना चाहिए: llm या expression।

टूल

Tool चरण किसी खास टूल को कॉल करता है।

• API प्रकार: tool_call
• tool_id: आवश्यक, गैर-खाली टूल ID। टूल एजेंट से जुड़ा होना चाहिए।
• tool_name: आवश्यक टूल नाम, जो टूल से मेल खाता हो।
• instruction: टूल कॉल करने का तरीका बताने वाला वैकल्पिक निर्देश।
• schema_overrides: टूल के पैरामीटर के लिए वैकल्पिक तय वैल्यू।
• on_failure: वैकल्पिक विफलता हैंडलर।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "instruction": "Look up the order using the order ID provided by the user."
}

तय पैरामीटर वैल्यू

जब किसी पैरामीटर की एक खास वैल्यू हमेशा रखनी हो, तो schema_overrides इस्तेमाल करें। मॉडल ओवरराइड किए गए पैरामीटर को न देखता है, न चुनता है। कुंजियां टूल की स्कीमा में पैरामीटर पाथ हैं; हर वैल्यू एक स्रोत बताती है:

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "update_ticket",
  "schema_overrides": {
    "request_body.status": { "source": "constant", "constant_value": "pending" },
    "request_body.ticket_id": { "source": "dynamic_variable", "dynamic_variable": "ticket_id" }
  }
}

विफलता हैंडलिंग

on_failure के बिना, विफल टूल कॉल बातचीत समाप्त कर देती है। इसके बजाय रिकवरी चरण चलाने के लिए on_failure जोड़ें।

• fallback: टूल विफल होने पर चलने वाले चरणों की आवश्यक, गैर-खाली सूची।
• branches: सशर्त विफलता हैंडलिंग के लिए आरक्षित। इसे खाली छोड़ें।

{
  "type": "tool_call",
  "tool_id": "tool_abc123",
  "tool_name": "lookup_order",
  "on_failure": {
    "branches": [],
    "fallback": [
      {
        "type": "tell",
        "instruction": "Explain that the order could not be retrieved and offer to connect the user with support."
      }
    ]
  }
}

विफलता हैंडलर में Ask, Tell, Say, Sub-procedure, System tool और Retry चरण हो सकते हैं। इसमें Tool या If चरण नहीं हो सकते। हैंडलर चलने के बाद, प्रक्रिया Tool चरण के बाद वाले चरण के साथ जारी रहती है।

पुनः प्रयास

Retry चरण, जिसमें वह मौजूद है, उस विफलता हैंडलर को टूल कॉल समेत फिर से चलाता है। हर प्रयास टूल को दोबारा कॉल करता है और, उसके फिर विफल होने पर, हैंडलर के हर चरण को फिर चलाता है। प्रयास खत्म होने पर बातचीत समाप्त हो जाती है।

• API प्रकार: retry
• max_retries: 1 से 3 तक का वैकल्पिक पूर्णांक। डिफ़ॉल्ट 1 है।
• वैल्यू मूल टूल कॉल के बाद के प्रयासों की गिनती करती है।
• Retry केवल on_failure के अंदर मान्य है।
• Retry अपने विफलता हैंडलर का अंतिम चरण होना चाहिए, क्योंकि बाद के चरणों तक पहुंचा नहीं जा सकेगा।

{
  "type": "retry",
  "max_retries": 2
}

उप-प्रक्रिया

Sub-procedure चरण दूसरी संरचित प्रक्रिया चलाता है। उस प्रक्रिया के चरण पूरे होने पर, निष्पादन Sub-procedure चरण के बाद वाले चरण पर लौटता है।

• API प्रकार: sub_procedure
• procedure_id: आवश्यक, गैर-खाली प्रक्रिया ID।
• लक्ष्य उसी एजेंट पर मौजूद होना चाहिए।
• लक्ष्य संरचित प्रक्रिया होना चाहिए।
• कोई प्रक्रिया स्वयं को कॉल नहीं कर सकती।

{
  "type": "sub_procedure",
  "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
}

सिस्टम टूल

System tool चरण एक बिल्ट-इन सिस्टम कार्रवाई करता है।

• API प्रकार: system_tool
• system_tool_name: आवश्यक सिस्टम-टूल नाम।
• फ़िलहाल केवल end_call समर्थित है। बाद में और सिस्टम टूल जोड़े जा सकते हैं।
• end_call टर्मिनल है, इसलिए यह अपनी शामिल सूची, आर्म या विफलता हैंडलर का अंतिम चरण होना चाहिए।

{
  "type": "system_tool",
  "system_tool_name": "end_call"
}

वैलिडेशन नियम

एजेंट को पब्लिश करने या एजेंट ड्राफ़्ट सहेजने पर, इनमें से कोई भी नियम तोड़ने वाली संरचित प्रक्रिया अस्वीकार हो जाती है। त्रुटि अपने पाथ से समस्या वाला चरण बताती है।

• दो If चरण एक के बाद एक नहीं रखे जा सकते।
• If चरण नेस्ट नहीं किए जा सकते।
• एक्सप्रेशन शर्तों वाला If चरण सीधे Ask चरण के बाद नहीं आ सकता।
• एक If चरण की सभी शर्तें एक ही प्रकार की होनी चाहिए: llm या expression।
• Retry केवल on_failure के अंदर हो सकता है और वहीं अंतिम चरण होना चाहिए।
• end_call जिस भी सूची में हो, उसका अंतिम चरण होना चाहिए।
• विफलता हैंडलर के fallback में कम से कम एक चरण होना चाहिए।
• Sub-procedure को उसी एजेंट पर मौजूद संरचित प्रक्रिया की ओर इंगित करना चाहिए, स्वयं की ओर नहीं।
• tool_id एजेंट का टूल होना चाहिए, tool_name मेल खाना चाहिए और schema_overrides टूल की स्कीमा से मेल खाना चाहिए।
• steps सूची, हर instruction और हर message गैर-खाली होना चाहिए।

इनमें से कोई नियम लागू होने पर प्रक्रिया को फिर से व्यवस्थित करने के लिए सर्वोत्तम तरीके देखें।

पूरा API उदाहरण

यह उदाहरण शिपमेंट की स्थिति के आधार पर ऑर्डर रद्द करना संभालता है। यह टूल पैरामीटर तय करता है, विफल टूल कॉल से उबरता है, दूसरी संरचित प्रक्रिया शुरू करता है और फिर कॉल समाप्त करता है।

{
  "steps": [
    {
      "type": "ask",
      "instruction": "Ask the user for their order ID."
    },
    {
      "type": "branch",
      "branches": [
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has already shipped."
          },
          "steps": [
            {
              "type": "tell",
              "instruction": "Explain that shipped orders must be returned before they can be refunded."
            }
          ]
        },
        {
          "condition": {
            "type": "llm",
            "condition": "The user says the order has not shipped."
          },
          "steps": [
            {
              "type": "tool_call",
              "tool_id": "tool_abc123",
              "tool_name": "cancel_order",
              "instruction": "Cancel the order using the order ID provided by the user.",
              "schema_overrides": {
                "request_body.notify_customer": { "source": "constant", "constant_value": true }
              },
              "on_failure": {
                "branches": [],
                "fallback": [
                  {
                    "type": "tell",
                    "instruction": "Apologize that the cancellation did not go through and say you will try once more."
                  },
                  {
                    "type": "retry",
                    "max_retries": 1
                  }
                ]
              }
            }
          ]
        }
      ],
      "fallback": [
        {
          "type": "ask",
          "instruction": "Ask whether the order has already shipped."
        }
      ]
    },
    {
      "type": "sub_procedure",
      "procedure_id": "agtprc_6qbpwdq8n01bxhk44bgjy6f10ck3"
    },
    {
      "type": "say",
      "message": "Thank you for contacting us. Goodbye.",
      "message_translations": {
        "es": { "value": "Gracias por contactarnos. Adiós." }
      }
    },
    {
      "type": "system_tool",
      "system_tool_name": "end_call"
    }
  ]
}

संरचित प्रक्रिया कैसे चलती है

संरचित प्रक्रिया के चरणों को एजेंट द्वारा निष्पादित रूप में बदलना कंपाइलिंग कहलाता है। प्लेटफ़ॉर्म, एजेंट ड्राफ़्ट सहेजे जाने या एजेंट पब्लिश होने पर हर संरचित प्रक्रिया को कंपाइल करता है; लेखक को स्वयं कुछ भी कंपाइल नहीं करना होता।

जब यूज़र का अनुरोध किसी प्रक्रिया के ट्रिगर से मेल खाता है, तो प्लेटफ़ॉर्म उस प्रक्रिया में प्रवेश करता है और उसके चरण क्रम से चलाता है। संरचित प्रक्रिया के अंदर एजेंट हर चरण पर अलग-अलग ध्यान देता है। अंत तक पहुंचने पर प्लेटफ़ॉर्म नियंत्रण बाकी बातचीत को लौटा देता है।

Workflow एज किसी संरचित प्रक्रिया से या उस तक कनेक्ट नहीं हो सकते। संरचित प्रक्रियाओं को श्रृंखला में जोड़ने के लिए Sub-procedure चरण इस्तेमाल करें। प्लेटफ़ॉर्म मेल खाते ट्रिगर से प्रवेश और पूरा होना प्रबंधित करता है, जिसमें प्रक्रिया शुरू होने वाले workflow नोड को नियंत्रण लौटाना भी शामिल है।

नीचे दिए नियम बताते हैं कि रनटाइम पर चरण कैसे काम करते हैं।

संरचित प्रक्रिया प्रबंधित करें

सर्वोत्तम तरीके

हर स्टेप टाइप पहले से अपना व्यवहार लागू करता है, इसलिए आपको शायद ही उसे अलग से लिखने की ज़रूरत पड़ती है। हर स्टेप का उद्देश्य लिखें और बाकी काम स्टेप टाइप पर छोड़ दें। नीचे दिया गया मार्गदर्शन उन मामलों के लिए है जिन्हें सही करना ज़रूरी है।

संरचित प्रक्रिया को टेस्ट करने के लिए, किसी प्रक्रिया को बेहतर बनाना देखें।

स्टेप टाइप चुनना

प्रक्रिया को संरचित करना

टूल्स के साथ काम करना

निर्देश लिखना

प्रक्रियाओं को संयोजित करना

प्रक्रियाओं को संयोजित करने का सामान्य मार्गदर्शन संरचित प्रक्रियाओं पर भी लागू होता है; Free-form प्रक्रियाएं पेज पर प्रक्रियाओं को संयोजित करना देखें।

एक पैटर्न खास तौर पर टाइप्स को मिलाने के लिए है: कोई फ्री-फ़ॉर्म प्रक्रिया संरचित प्रक्रिया का संदर्भ दे सकती है। खुले तौर पर संभाले जाने वाले काम को फ्री-फ़ॉर्म प्रक्रिया में रखें और उन हिस्सों को, जिन्हें हर बार एक ही तरह चलना चाहिए, जैसे पहचान सत्यापन या एस्केलेशन, संरचित प्रक्रिया को सौंपें।

सीमाएं

• If स्टेप्स को नेस्ट नहीं किया जा सकता और दो If स्टेप्स को एक के बाद एक नहीं रखा जा सकता।
• केवल end_call सिस्टम टूल समर्थित है।
• संरचित प्रक्रियाएं नॉलेज बेस दस्तावेज़ों का संदर्भ नहीं दे सकतीं।
• प्रक्रिया पूरी होने पर मौजूदा टर्न खत्म करने का कोई तरीका नहीं है; एजेंट टर्न खुला रखता है और बोलना जारी रख सकता है।
• वर्कफ़्लो एजेज़ किसी संरचित प्रक्रिया से या उससे कनेक्ट नहीं हो सकतीं। संरचित प्रक्रियाओं को जोड़ने के लिए Sub-procedure स्टेप इस्तेमाल करें; एंट्री और पूरा होना प्लेटफ़ॉर्म मैनेज करता है।
• प्रक्रिया शुरू करने से लेटेंसी बढ़ती है: एजेंट उसमें जाने के लिए टूल कॉल करता है और फिर जनरेट किए गए वर्कफ़्लो से गुजरता है।

मॉडल प्रोवाइडर सपोर्ट

संरचित प्रक्रियाएं उप-प्रक्रिया में प्रवेश करते समय और प्रक्रिया पूरी करते समय इंटरनल टूल कॉल को बाध्य करती हैं। प्रमुख OpenAI, Anthropic, Gemini और Grok मॉडल फ़ैमिलीज़ फोर्स्ड टूल चॉइस सपोर्ट करती हैं। अन्य मॉडल या कस्टम प्रोवाइडर इसकी गारंटी नहीं दे सकते, जिससे उप-प्रक्रिया ट्रांज़िशन या प्रक्रिया पूरी होना कम भरोसेमंद हो सकता है। किसी अन्य मॉडल प्रोवाइडर का इस्तेमाल करते समय फोर्स्ड टूल-चॉइस सपोर्ट की पुष्टि करें।

कंटेंट साइज़ सीमा और संरचित प्रक्रियाएं फ्री-फ़ॉर्म प्रक्रियाओं से कैसे अलग हैं, समेत सभी प्रक्रियाओं पर लागू सीमाओं के लिए प्रक्रियाएं देखें।