सेल्फ-इम्प्रूविंग टेक्स्ट-टू-क्वेरी एजेंट बनाने के लिए सिमेंटिक बेंचमार्क का उपयोग

हमारा टेक्स्ट-टू-क्वेरी एजेंट फ्रंटियर मॉडल पर 45 सेकंड से घटकर GLM 5.3 Flash पर 2 सेकंड का हो गया, उसी सटीकता के साथ और 1/20 लागत पर।

Conversion में हमारा अधिकांश हालिया AI कार्य सामान्य मार्केटिंग इंटेलिजेंस पर केंद्रित रहा है।

मार्केटिंग ऑटोमेशन टीमें सिस्टम में कई तरह के काम करती हैं: खातों पर शोध करना, ऑडियंस बनाना, अभियानों की योजना बनाना, सामग्री लिखना और प्रदर्शन डेटा पर कार्य करना। हम ऐसे एजेंट बना रहे हैं जो उन वर्कफ़्लो में तर्क कर सकें और उन्हीं टूल का उपयोग कर सकें जो एक कुशल मार्केटर उपयोग करेगा।

वे सिस्टम सक्षम, सामान्य-उद्देश्य वाले मॉडल से लाभान्वित होते हैं। काम खुला होता है, और अच्छा निर्णय अक्सर किसी कार्य को जल्दी पूरा करने से अधिक महत्वपूर्ण होता है।

लेकिन हमारे पास छोटी, अधिक केंद्रित AI सुविधाओं का एक बैकलॉग भी था। उनमें से एक था नेचुरल-लैंग्वेज फ़िल्टर: उपयोगकर्ता को सादे अंग्रेज़ी में एक ऑडियंस का वर्णन करने दें और उस विवरण को एक फ़िल्टर में बदल दें जिसे वे Conversion के मौजूदा स्टेटमेंट बिल्डर में निरीक्षण और संपादित कर सकें। (Conversion में, एक फ़िल्टर को स्टेटमेंट कहा जाता है।)

पहली बार में, यह एक सीधा संरचित-निर्माण कार्य लग रहा था। मॉडल को उपलब्ध फ़ील्ड दें, आउटपुट प्रारूप का वर्णन करें, और इसे JSON उत्पन्न करने के लिए कहें। यह उससे कहीं अधिक कठिन निकला।

GLM 5.3 Flash का उपयोग करके 5 सेकंड से भी कम समय में उत्पन्न कंपाउंड स्टेटमेंट।

निम्नलिखित उदाहरण लें:

उन संपर्कों को खोजें जिन्होंने पिछले 30 दिनों में कम से कम एक बार डेमो फ़ॉर्म सबमिट किया है और एक सॉफ़्टवेयर कंपनी में काम करते हैं जिसके पास $50,000 से अधिक मूल्य का एक खुला अवसर है।

इसके लिए सिस्टम को निम्नलिखित की आवश्यकता है:

• उस विशिष्ट फ़ॉर्म को ढूंढना जिसका उपयोगकर्ता "डेमो फ़ॉर्म" से मतलब रखता है
• यह निर्धारित करना कि कौन सा फ़ील्ड किसी कंपनी के उद्योग का प्रतिनिधित्व करता है
• यह जानना कि वह वर्कस्पेस "सॉफ़्टवेयर" का प्रतिनिधित्व कैसे करता है, जिसका अर्थ है अनुमान लगाने के बजाय उस फ़ील्ड में वास्तव में संग्रहीत मानों को देखना
• किसी संपर्क से उसकी कंपनी और फिर उस कंपनी के अवसरों तक जाना
• यह सुनिश्चित करना कि "खुला" और "$50,000 से अधिक" एक ही अवसर पर लागू हों
• एक सापेक्ष घटना विंडो लागू करना

इसे यह सब इतनी जल्दी करने की भी आवश्यकता थी कि यह एक फ़िल्टर इंटरफ़ेस जैसा लगे, न कि एक शोध एजेंट जैसा।

जो एक छोटा प्रॉम्प्ट-इंजीनियरिंग कार्य लग रहा था, वह एक बाधित टेक्स्ट-टू-क्वेरी समस्या बन गया था। इसे हल करने के लिए एक टूल-उपयोग करने वाले एजेंट, एक मध्यवर्ती प्रतिनिधित्व (IR), एक नियतात्मक कंपाइलर और एक सिमैंटिक बेंचमार्क की आवश्यकता थी।

हमने परिणामी बेंचमार्क, स्टेटमेंट बेंच, पर आठ मॉडल चलाए, जिनमें Claude Opus 5, Kimi K3, GLM 5.3 Flash और आज सुबह जारी Gemini 3.8 Flash शामिल हैं। परिणाम नीचे दिए गए हैं।

एजेंट को उपकरण देना

उपरोक्त अनुरोध का उत्तर देने के लिए आवश्यक अधिकांश जानकारी ग्राहक के वातावरण के लिए विशिष्ट है। एक एकल वर्कस्पेस में सैकड़ों लाखों ऐतिहासिक फ़ील्ड मान, उसकी संपत्तियों और वस्तुओं के साथ रह सकते हैं। स्पष्ट कारणों से, हम यह सब एक प्रॉम्प्ट में नहीं डाल सकते थे।

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

इस खोज बुनियादी ढांचे का अधिकांश भाग हमारे हालिया ग्लोबल सर्च कार्य से आया है, जो Conversion में सभी रिकॉर्ड पर टेक्स्ट और सिमैंटिक खोज प्रदान करता है। हम जल्द ही इस पर और अधिक साझा करने की योजना बना रहे हैं!

मूल प्रवाह इस प्रकार दिखता है:

1नेचुरल-लैंग्वेज अनुरोध
2          |
3          v
4   टूल-उपयोग करने वाला एजेंट  <-----------------+
5    /     |      \                               |
6फ़ील्ड  संपत्तियां  संबंध                       | कारणों के साथ अस्वीकृति
7    \     |      /                               |
8          v                                      |
9    बाधित IR                                     |
10          |                                      |
11          v                                      |
12 वैलिडेटर और कंपाइलर ---------------------------+
13          |
14          v
15 उत्पादन स्टेटमेंट

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

एक छोटी भाषा बनाना

टूल के उपयोग ने संदर्भ की समस्या हल कर दी। इसने विलंबता को हल नहीं किया।

प्रारंभिक प्रतिक्रिया से एक सबक: उपयोगकर्ता चैट की तुलना में एक उद्देश्य-निर्मित इंटरफ़ेस में कहीं अधिक कम विलंबता सहन करते हैं।

यह एक व्यापक विरोधाभास की ओर इशारा करता है। हम विलंबता की उम्मीदें इस आधार पर निर्धारित करते हैं कि कोई कार्य हमें कितना कठिन लगता है, न कि सिस्टम के लिए कितना कठिन है। सामग्री लिखना कठिन लगता है क्योंकि हम काम देख सकते हैं। एक फ़िल्टर का वर्णन करना सरल लगता है क्योंकि हमारा दिमाग चुपचाप संदर्भ, संस्थाओं, संबंधों और इरादे को हल करता है। मॉडल के लिए, उन छिपी हुई मान्यताओं का पुनर्निर्माण करना ही कार्य है। उपयोगकर्ता जितना कम काम समझता है, वे सिस्टम को उसे करने के लिए उतना ही कम समय देते हैं।

प्रारंभिक प्रतिक्रिया के आधार पर, हमने दो लक्ष्य निर्धारित किए: सामान्य प्रश्नों के लिए 95 प्रतिशत से अधिक सटीकता और लगभग 5 सेकंड का प्रतिक्रिया समय।

Conversion की एक अभिव्यंजक आंतरिक क्वेरी भाषा है। हमारे शुरुआती परीक्षणों में, सीधे उत्पादन प्रारूप का उपयोग करते हुए, केवल Claude Opus जैसे सबसे बड़े मॉडल ही इसे विश्वसनीय रूप से उत्पन्न कर सकते थे। साधारण स्टेटमेंट में भी लगभग 45 सेकंड लगते थे।

विज़ुअल स्टेटमेंट बिल्डर पूर्ण भाषा के केवल एक उपसमूह को उजागर करता है। हमने उस उपसमूह के लिए एक छोटा, एजेंट-अनुकूल मध्यवर्ती प्रतिनिधित्व बनाया। छोटे मॉडल कम टोकन का उपयोग करके इसे उत्पन्न कर सकते थे, जबकि एक नियतात्मक कंपाइलर पूर्ण उत्पादन प्रारूप को संभालता था।

स्टेटमेंट पर विचार करें:

नौकरी का शीर्षक "निदेशक" शामिल करता है।

मूल उत्पादन स्टेटमेंट इस प्रकार दिखता है:

1{
2  "type": "LOGICAL",
3  "version": 1,
4  "logical": {
5    "operator": "OR",
6    "operands": [
7      {
8        "type": "LOGICAL",
9        "version": 1,
10        "logical": {
11          "operator": "AND",
12          "operands": [
13            {
14              "type": "VARIABLE",
15              "version": 1,
16              "variable": {
17                "variableSchemaId": "550e8400-e29b-41d4-a716-446655440000",
18                "where": {
19                  "type": "LOGICAL",
20                  "version": 1,
21                  "logical": {
22                    "operator": "AND",
23                    "operands": [
24                      {
25                        "type": "LOGICAL",
26                        "version": 1,
27                        "logical": {
28                          "operator": "CONTAINS",
29                          "operands": [
30                            {
31                              "type": "ATTRIBUTE",
32                              "version": 1,
33                              "attribute": {
34                                "name": "value"
35                              }
36                            },
37                            {
38                              "type": "CONSTANT",
39                              "version": 1,
40                              "constant": {
41                                "value": "Director"
42                              }
43                            }
44                          ]
45                        }
46                      }
47                    ]
48                  }
49                }
50              }
51            }
52          ]
53        }
54      }
55    ]
56  }
57}

उसी फ़िल्टर का मॉडल-सामना करने वाला प्रतिनिधित्व है:

1{
2  "field": "550e8400-e29b-41d4-a716-446655440000",
3  "op": "contains",
4  "value": "Director"
5}

IR पहले ही कई पीढ़ियों से गुज़र चुका है, और नवीनतम को छोटे मॉडलों को पहले वाले पर विफल होते देखकर आकार दिया गया था। एक बड़ा सुधार बेहतर समान-रिकॉर्ड सिमैंटिक्स (कुछ जो स्कीमा सत्यापन नहीं पकड़ सकता) पेश करना था:

1{
2  "related": "OPPORTUNITY",
3  "all": [
4    { "field": "<stage uuid>", "op": "equals", "value": "Closed Won" },
5    { "field": "<amount uuid>", "op": "gt", "value": 100000 }
6  ]
7}

मॉडल और कोड के बीच इस विभाजन ने हमें कुछ उपयोगी गुण दिए:

• असमर्थित स्टेटमेंट व्यक्त करना कठिन है
• समान-रिकॉर्ड संबंध सिमैंटिक्स दिखाई देते हैं
• फ़ील्ड और संबंध संदर्भों को मान्य किया जा सकता है
• कंपाइलर का मॉडल से स्वतंत्र रूप से परीक्षण किया जा सकता है
• उत्पन्न स्टेटमेंट मौजूदा UI में संपादन योग्य रहते हैं

IR अंततः मॉडल के काम को कम कर देता है: एजेंट उपयोगकर्ता के इरादे को हल करता है और एक बाधित योजना तैयार करता है; कोड उत्पादन प्रारूप को संभालता है।

एक सिमैंटिक बेंचमार्क बनाना

एक आउटपुट पूरी तरह से मान्य हो सकता है और फिर भी गलत हो सकता है। यह अनुरोध लें:

उन कंपनियों के संपर्क जिनके पास $100,000 से अधिक मूल्य का जीता हुआ अवसर है।

एक संपर्क एक कंपनी से संबंधित होता है, और एक कंपनी के कई अवसर हो सकते हैं। इस फ़िल्टर का मिलान करने का अर्थ है संबंधों (संपर्क से कंपनी, कंपनी से अवसरों) को पार करना और रास्ते में दो शर्तों की जाँच करना: सौदा जीता गया है, और सौदा $100,000 से अधिक मूल्य का है।

कठिनाई यह है कि उन शर्तों को एक ही अवसर के लिए पूरा होना चाहिए। यदि उन्हें स्वतंत्र रूप से जाँचा जाता है, तो $20,000 के जीते हुए सौदे और $150,000 के खुले सौदे वाली एक कंपनी दोनों को संतुष्ट करती है: एक शर्त प्रत्येक से मेल खाती है। स्कीमा सत्यापन इसे कभी नहीं पकड़ेगा।

एक बार इस तरह के कुछ उदाहरण पास हो जाने के बाद, प्रॉम्प्ट को संपादित करने से उनमें प्रतिगमन का जोखिम था। हमें अर्थ की जाँच करने का एक तरीका चाहिए था, न कि केवल वैधता की, और हर बार जब कुछ बदलता था तो उसकी जाँच करने का।

हमने स्टेटमेंट बेंच को उत्पाद के व्यवहारों के आसपास बनाया, जो हमारे ग्राहकों द्वारा पहले बनाए गए गुमनाम ऑडियंस पैटर्न से लिया गया था। सूट में अब पंद्रह श्रेणियों में 100 मामले हैं जैसे सादे फ़ील्ड शर्तें, घटनाएँ, सापेक्ष और कैलेंडर समय विंडो, संबंध और कंपाउंड क्वेरी।

प्रत्येक मामला एक यथार्थवादी वर्कस्पेस सैंडबॉक्स के विरुद्ध चलता है। एजेंट को वही डेटा और उपकरण प्राप्त होते हैं जो उसे उत्पादन में मिलते हैं।

मूल्यांकनकर्ता कई परतों की जाँच करता है:

1. क्या एजेंट ने कोई स्टेटमेंट लौटाया?
2. क्या IR उसकी स्कीमा को संतुष्ट करता है?
3. क्या संदर्भित फ़ील्ड और संबंध मौजूद हैं?
4. क्या स्टेटमेंट संकलित हो सकता है और उत्पादन सत्यापन पास कर सकता है?
5. क्या यह अनुरोधित अर्थ का प्रतिनिधित्व करता है?
6. इसमें कितने मॉडल चरणों, टूल कॉल, टोकन और अस्वीकृत सबमिशन की आवश्यकता थी?

पाँचवाँ सबसे दिलचस्प है क्योंकि वैधता सिमैंटिक समानता की गारंटी नहीं देती है।

सिमैंटिक जाँच संकलित स्टेटमेंट को पढ़ती हैं, जैसे "एक अवसर की स्थिति जो चरण और राशि दोनों को वहन करती है," "एक ईमेल घटना जिसका प्रकार क्लिक है, खुला नहीं," या "एक वेबिनार शर्त न कि कस्टम-अभियान वाली।"

एक मूल्यांकन-संचालित अनुकूलन लूप चलाना

बेंचमार्क ने बदल दिया कि हम सुविधा पर कैसे काम करना जारी रख सकते हैं। एक कोडिंग एजेंट को "प्रॉम्प्ट में सुधार करें" या "एक नया IR लागू करें" कहने के बजाय, हम इसे सुधार की एक निष्पादन योग्य परिभाषा दे सकते थे।

लूप इस प्रकार दिखता था:

1. बेंचमार्क चलाएँ
2. विफलताओं को उनके अंतर्निहित कारण से समूहित करें
3. एजेंट के टूल प्रक्षेपवक्र और प्रस्तुत IR का निरीक्षण करें
4. प्रॉम्प्ट, टूल, वैलिडेटर या कंपाइलर बदलें
5. पूरा बेंचमार्क फिर से चलाएँ
6. परिवर्तन को तभी रखें जब वह प्रतिगमन पेश किए बिना सिस्टम में सुधार करता है

कोडिंग एजेंट मॉडल की तुलना करने, IR के साथ प्रयोग करने, टूल विवरण में सुधार करने और स्वायत्त रूप से प्रॉम्प्ट को परिष्कृत करने के लिए बेंचमार्क का उपयोग कर सकते थे। प्रत्येक परिवर्तन के बाद पूरा सूट चलाने ने हमें व्यक्तिगत विफलताओं पर ओवरफिटिंग से भी रोका, और हमने इसकी पुष्टि करने के लिए आगे 50 मामलों को अलग रखा।

कुछ परिवर्तनों ने परिणामों में सबसे अधिक सुधार किया:

• पथ, प्रकार और संरचना को कंपाइलर में ले जाएँ। हमारे पहले IR ने मॉडल को सभी संबंधों को स्पष्ट रूप से लिखने के लिए कहा: संपर्क से कंपनी, कंपनी से अवसर। फ़ील्ड का मेटाडेटा पहले से ही उस पथ को दर्शाता है, इसलिए कंपाइलर अब इसका अनुमान लगाता है। हमने तिथियों, प्रकार कास्टिंग, निषेध प्लेसमेंट और समूह नेस्टिंग के लिए भी ऐसा ही किया। नियमों को कंपाइलर में ले जाने से IR सरल हो गया और स्कीमा विफलताएँ कम हो गईं।
• स्पष्टीकरण और सुधारों के साथ अस्वीकार करें। प्रत्येक स्कीमा और कंपाइलर अस्वीकृति कहती है कि इसके बजाय क्या लिखना है (जब उपलब्ध हो): "इस फ़ील्ड पर gt को नकारा नहीं जा सकता; lte का उपयोग करें", "अभियान_सूची से आईडी कॉपी करें"। छोटे मॉडल एक या दो पुनर्प्रयास में अभिसरण करते हैं, और उत्पादन मॉडल को प्रति सौ अनुरोधों पर कुछ पर अस्वीकार कर दिया जाता है।
• छोटे मॉडलों के लिए प्रॉम्प्ट को संरचित करें। प्रॉम्प्ट को पुनर्गठित करने से सटीकता नहीं बदली, लेकिन इसने पुनर्प्रयासों की संख्या को आधा कर दिया, जिससे सीधे विलंबता में सुधार हुआ। यह Anthropic के प्रॉम्प्टिंग सर्वोत्तम अभ्यास से प्रेरित था।
• गद्य पर उदाहरणों का उपयोग करें। हमारे प्रारूप संदर्भ में दो अतिरिक्त उदाहरणों ने चूक के एक वर्ग को हल किया जो स्पष्टीकरण के पैराग्राफ ने नहीं किया था, जिससे अस्वीकृत सबमिशन लगभग आधे हो गए।
• पूरा संदर्भ दें या कुछ न दें। मॉडल किसी उपकरण को कॉल करने से पहले संदर्भ में जो कुछ है उसके लिए पहुँचते हैं। जब संदर्भ में फ़ील्ड का आंशिक या अलेबल सेट शामिल था, तो मॉडल खोज करने के बजाय निकटतम का उपयोग करता था, जिससे सिमैंटिक रूप से गलत स्टेटमेंट तैयार होते थे। टूल कॉल के पक्ष में आंशिक संदर्भ को कम करके, हमने बिल्ड दरों में वृद्धि की और इनपुट टोकन को पाँचवें हिस्से तक कम कर दिया।

अंतिम उत्पादन कॉन्फ़िगरेशन, GLM 5.3 Flash, ने सभी 100 बेंचमार्क मामलों को 2.3 सेकंड की माध्य विलंबता और 7.1 सेकंड के 95वें प्रतिशतक के साथ पूरा किया। और, 100 में से 97 सिमैंटिक रूप से सही थे। मूल उत्पादन-प्रारूप दृष्टिकोण की तुलना में, सरल फ़िल्टर लगभग 45 सेकंड से बढ़कर 1/20 लागत पर एक सेकंड से थोड़ा अधिक हो गए थे।

स्टेटमेंट बेंच पर मॉडलों की तुलना करना

बेंचमार्क ने हमें वास्तविक कार्य पर मॉडलों की तुलना करने का एक तरीका भी दिया।

2 सितंबर, 2026 को, हमने आठ मॉडलों पर समान 100 मामले चलाए। प्रत्येक मॉडल को समान प्रॉम्प्ट, टूल, IR, कंपाइलर और 30-सेकंड अनुरोध टाइमआउट प्राप्त हुआ।

प्रदाता रूटिंग, प्रॉम्प्ट कैशिंग और अस्थायी अनुमान लोड सभी विलंबता को प्रभावित करते हैं।

मॉडल

मान्य बिल्ड

सिमैंटिक रूप से सही

P50 विलंबता

P95 विलंबता

कैश रीड

टूल कॉल

अस्वीकृत सबमिशन

प्रति 1,000 अनुरोध अनुमानित लागत

Claude Opus 5

100/100 (100%)

100/100 (100%)

3.16s

8.53s

91.1%

162

0

$27.51

GLM 5.2

100/100 (100%)

100/100 (100%)

4.38s

13.02s

93.5%

201

5

$14.94

Kimi K3

100/100 (100%)

100/100 (100%)

5.17s

11.84s

34.3%

157

0

$48.51

GLM 5.3 Flash

100/100 (100%)

97/100 (97%)

2.34s

7.07s

92.8%

163

2

$1.33

DeepSeek V4 Pro

96/100 (96%)

96/96 (100%)

5.53s

24.31s

47.8%

172

1

$12.00

Gemini 3.7 Flash

77/100 (77%)

77/77 (100%)

15.14s

30.01s

26.5%

228

1

$18.24

Gemini 3.8 Flash

76/100 (76%)

76/76 (100%)

14.29s

30.01s

35.4%

266

1

$27.44

DeepSeek V4 Flash

56/100 (56%)

55/56 (98%)

6.79s

30.00s

41.5%

100

1

$0.56

अनुमानित लागत प्रति 1,000 प्रयासित अनुरोध हैं जो 2 सितंबर, 2026 को प्रत्येक प्रदाता की सूचीबद्ध गैर-प्रचार दर पर देखे गए इनपुट, कैश्ड-इनपुट और आउटपुट टोकन का उपयोग करते हैं। कैश्ड इनपुट प्रकाशित कैश-रीड दर पर बिल किया जाता है जहाँ प्रदाता एक प्रकाशित करता है, और अन्यथा पूर्ण इनपुट दर पर।

चित्र 1. लागत के विरुद्ध शुद्धता। GLM 5.3 Flash Claude Opus 5 की लागत के लगभग बीसवें हिस्से पर 97 प्रतिशत तक पहुँचता है।

चित्र 2. विलंबता वितरण, माध्यिका और 95वाँ प्रतिशतक, P95 द्वारा क्रमबद्ध।

कुछ निष्कर्ष सामने आए।

न तो मॉडल आकार और न ही मूल्य ने विलंबता की भविष्यवाणी की। सबसे तेज़ मॉडल सबसे छोटा और सबसे सस्ता था। दूसरा सबसे तेज़ सबसे बड़ा और सबसे महंगा था।

विफलता गलत उत्तरों से धीमे उत्तरों की ओर बढ़ गई है। आठ में से छह मॉडल हर उस स्टेटमेंट पर सिमैंटिक रूप से सही थे जिसे उन्होंने पूरा किया; उनके बीच अंतर लगभग पूरी तरह से इस बात में है कि टाइमआउट के अंदर कितने अनुरोध पूरे हुए। IR और प्रॉम्प्ट के शुरुआती पुनरावृत्तियों में, अधिकांश छोटे मॉडल बिल्ड चरण में <50% सिमैंटिक सटीकता के साथ बेंचमार्क में विफल रहे।

रीज़निंग टोकन टूल कॉल से अधिक भारी हैं। Gemini 3.8 Flash ने अपने 192,000 आउटपुट टोकन में से 180,000 रीज़निंग पर खर्च किए और 266 टूल कॉल किए; Claude Opus 5 ने रीज़निंग पर 813 टोकन खर्च किए, 162 कॉल किए, और हर मामले को पूरा किया। हमारे ग्लोबल सर्च प्रयासों ने प्रत्येक टूल लुकअप को मिलीसेकंड रेंज में कम कर दिया, इसलिए शेष लागत उनके बीच मॉडल की बारी है।

निष्कर्ष

मॉडल अस्पष्टता को हल करने में अच्छे हैं, कोड सटीकता लागू करने में अच्छा है, और हमारी अधिकांश प्रारंभिक विफलताएँ मॉडल से दोनों करने के लिए कहने से आईं। इस एजेंट को बनाना यह तय करने का काम था कि दोनों में से प्रत्येक भाग का मालिक कौन होना चाहिए। हम उम्मीद करते हैं कि टेक्स्ट-टू-SQL और अधिकांश अन्य नेचुरल-लैंग्वेज इंटरफ़ेस के लिए भी यही सच है।

यदि आप इनमें से किसी भी समस्या में रुचि रखते हैं, तो संपर्क करें! हम भर्ती कर रहे हैं।