LLM enrichment के साथ, बिल टोकन का होता है। Entity Enricher को इस तरह बनाया गया है कि सटीकता से समझौता किए बिना यथासंभव कम बिल किए जाने वाले टोकन भेजे जाएँ — इसका नेतृत्व prompt caching करता है, और इसे schema scoping, स्मार्ट gating, तथा कम बर्बाद retries का समर्थन मिलता है। इसमें से अधिकांश स्वतः होता है; यहाँ किसी अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत नहीं है।
हर संवर्धन कॉल इनपुट टोकन (आपका प्रॉम्प्ट, स्कीमा, और कोई भी संलग्न दस्तावेज़), आउटपुट टोकन (स्ट्रक्चर्ड परिणाम), और — यदि सक्षम हो तो — वेब-सर्च क्वेरीज़ के लिए भुगतान करता है। सबसे बड़ा, सबसे दोहराया जाने वाला हिस्सा आमतौर पर इनपुट होता है: वही सिस्टम निर्देश, स्कीमा विवरण, और स्रोत दस्तावेज़ हर कॉल पर दोबारा भेजे जाते हैं। उस साझा इनपुट को कैश करना सबसे बड़ा लीवर है, इसलिए यह सबसे पहले आता है।
प्रॉम्प्ट + स्कीमा + अटैचमेंट। बड़ा और कॉल्स में अत्यधिक दोहराव वाला — कैशिंग और स्कोपिंग के लिए प्रमुख लक्ष्य।
स्ट्रक्चर्ड परिणाम। हर मॉडल से केवल उन्हीं फ़ील्ड्स के लिए पूछकर इसे सुव्यवस्थित रखा जाता है जो वास्तव में उसके अधिकार में हैं।
सिमेंटिक ID चालू होने पर एक छोटी, अलग मद: जो भी पहचान मुफ़्त टेक्स्ट-तुलना चरणों में तय नहीं होती, उस पर एक एम्बेडिंग खर्च होती है। किसी भी अन्य उपयोग की तरह मापी और बिल की जाती है।
विफल रीट्राई, रेट-लिमिट थ्रैशिंग, और गलत एंटिटी को एनरिच करना। इनके लिए भुगतान करने के बजाय पहले ही समाप्त कर दिया गया।
जब कोई बहु-विशेषज्ञता संवर्धन चलता है, तो यह एक ही एंटिटी के लिए कई LLM कॉल करता है — प्रति विशेषज्ञता क्षेत्र एक। उनमें से हर कॉल एक ही ओपनिंग कॉन्टेक्स्ट साझा करती है: सामान्य सिस्टम निर्देश और आपके द्वारा अटैच किए गए कोई भी इनलाइन-टेक्स्ट दस्तावेज़। Entity Enricher उस साझा प्रीफ़िक्स को कॉल्स के बीच बाइट-दर-बाइट समान रखता है और इसे कैश करने योग्य के रूप में चिह्नित करता है, ताकि प्रोवाइडर इसे एक बार संग्रहीत करे और हर अगली कॉल पर सामान्य इनपुट कीमत के लगभग दसवें हिस्से पर फिर से पढ़े।
N कॉलों में से हर एक पूरी साझा संदर्भ को पूरे इनपुट मूल्य पर दोबारा भेजती है। पाँच expertises का मतलब है उस बड़े साझा ब्लॉक के लिए पाँच बार भुगतान करना।
साझा ब्लॉक कैश में एक बार लिखा जाता है, फिर अन्य चार कॉल पर इनपुट कीमत के ~10% पर वापस पढ़ा जाता है। हर अतिरिक्त एक्सपर्टीज़, भाषा और संलग्न दस्तावेज़ के साथ बचत बढ़ती जाती है।
प्रोवाइडर कैश केवल उस पहले अनुरोध के बाद पढ़े जा सकते हैं जो उन्हें लिखता है और पूरा हो जाता है। यदि सभी expertise domain कॉल एक साथ चलें, तो किसी को भी वार्म कैश नहीं मिलेगा और हर एक अनावश्यक रूप से अपनी खुद की प्रति लिखेगा। इसलिए जब कैशिंग लागू होती है, तो पहली कॉल अकेले चलती है, कैश को प्रसारित होने के लिए एक संक्षिप्त क्षण दिया जाता है, और तभी शेष कॉल समानांतर रूप से शुरू की जाती हैं — ताकि हर एक इसे फिर से लिखने की कीमत चुकाने के बजाय वार्म कैश पढ़े।
Anthropic मॉडल साझा निर्देशों को स्पष्ट रूप से cache करते हैं; संलग्न PDF और चित्र यथास्थान cache होते हैं; और स्वचालित prefix caching वाले provider (OpenAI, xAI, DeepSeek और अन्य) उसी byte-समान prefix से लाभान्वित होते हैं। Caching का लाभ ठीक तभी सबसे अधिक होता है जब इनपुट बड़ा हो — कई expertise, कई भाषाएँ, या संलग्न दस्तावेज़।
लागत अकाउंटिंग कैश-अवेयर है: कैश किए गए इनपुट टोकन को मॉडल की कैश-रीड दर (इनपुट दर का एक अंश) पर बिल किया जाता है, और केवल वास्तव में नए टोकन को पूरी कीमत पर बिल किया जाता है। यह बचत सीधे आपके लागत एनालिटिक्स में दिखती है, केवल सिद्धांत में नहीं।
साझा प्रीफ़िक्स को कैश करने के अलावा, Entity Enricher हर कॉल के उस हिस्से को छोटा करता है जो साझा नहीं होता।
हर expertise कॉल को schema का केवल वही हिस्सा मिलता है जिसके लिए वह ज़िम्मेदार है, पूरा schema नहीं।
एक वित्तीय विशेषज्ञ नियामक field कभी नहीं देखता। कम field का अर्थ है कम token अंदर और बाहर — और response को merge करने से पहले उसके हिस्से तक छाँट दिया जाता है।
जब दस्तावेज़ अटैच किए जाते हैं और आपने किसी सख्त संरचित-आउटपुट मोड को नहीं चुना है, तो फ़ील्ड सूची केवल पठनीय प्रॉम्प्ट में रहती है — वायर पर कोई स्कीमा दोहराया नहीं जाता।
यह स्कीमा टोकन को पूरी तरह हटा देता है और साझा प्रीफ़िक्स को समान रखता है (ताकि यह बेहतर कैश हो)। रिप्लाई को अभी भी क्लाइंट-साइड पर वैलिडेट किया जाता है, जिसमें ड्रिफ़्ट होने पर स्वचालित सेल्फ-करेक्शन होता है।
वैकल्पिक प्री-फ्लाइट क्लासिफिकेशन किसी महंगी मल्टी-मॉडल एनरिचमेंट के शुरू होने से पहले एक अकेला, सस्ता, तेज़ मॉडल चलाकर यह जाँचता है कि कोई एंटिटी वास्तव में आपके स्कीमा से मेल खाती है या नहीं। कोई असंगति — जैसे किसी चंद्रमा को “Planet” स्कीमा में भेज देना — कई प्रीमियम मॉडलों पर पूरी एनरिचमेंट खर्च करने के बजाय एक सेंट के छोटे से हिस्से में पकड़ ली जाती है।
यह नॉन-ब्लॉकिंग है (यदि जाँच विफल होती है, तो enrichment फिर भी आगे बढ़ता है) और रद्द किया जा सकता है, इसलिए जिन models को आपने छोड़ने का निर्णय लिया है उनके लिए आप कभी भुगतान शुरू नहीं करते।
एक असफल validation दौर एक पूर्ण-मूल्य वाला LLM call है जिससे दिखाने को कुछ नहीं मिलता। दो तंत्र retry को दुर्लभ और उत्पादक रखते हैं।
सामान्य LLM आउटपुट विसंगतियाँ — index-आधारित ऑब्जेक्ट जो arrays होने चाहिए, स्ट्रिंग 'null', भटके हुए escaped quotes — validation चलने से पहले ठीक कर दी जाती हैं।
कई संभावित validation विफलताएँ चुपचाप ठीक कर दी जाती हैं, इसलिए वे कभी भी किसी सशुल्क पुनः प्रयास को ट्रिगर ही नहीं करतीं।
जब वास्तव में रिट्राई की आवश्यकता होती है, तो सटीक वैलिडेशन त्रुटि मॉडल को वापस भेजी जाती है ताकि वह उस विशिष्ट समस्या को ठीक कर सके।
स्पष्ट, विशिष्ट फ़ीडबैक अगले प्रयास के सफल होने की संभावना बढ़ाता है, बजाय इसके कि अस्पष्ट मार्गदर्शन पर प्रयास बर्बाद हों।
छोटे स्कीमा के लिए सिंगल-पास सबसे सस्ता है; मल्टी-एक्सपर्टीज़ बड़े स्कीमा के लिए बनाया गया है, जहाँ कैशिंग और प्रति-एक्सपर्टीज़ स्कोपिंग अतिरिक्त कॉल की कीमत से कहीं ज़्यादा भरपाई कर देते हैं। प्रत्येक का उपयोग कब करें, इसके लिए Strategies देखें।
सबसे महँगा मॉडल शायद ही कभी सही डिफ़ॉल्ट होता है, और सबसे सस्ता शायद ही हर जगह पर्याप्त होता है। एक बार अंदाज़ा लगाकर उसी के साथ चलते रहने के बजाय, अपने स्कीमा पर मॉडलों का बेंचमार्क करें और चयन को स्वतः तय होने दें — फिर Settings → Organization → Defaults में संतुलन को लागत की ओर झुका दें, और हर वह रन जिसमें मॉडल निर्दिष्ट नहीं है, चुपचाप उसी वरीयता का पालन करेगा। देखें Benchmarks।
प्रति की — प्रति प्रोवाइडर नहीं — सीमित समवर्तीता जॉब्स को एक ही की पर टूट पड़ने और रेट-लिमिट एरर तक पहुँचने से रोकती है, जिनके रीट्राई बर्बाद टोकन और बीते समय, दोनों में महँगे पड़ते हैं। नियंत्रित, स्थिर समवर्तीता 429 से जूझने की तुलना में सस्ती है।
हर संवर्धन अपनी वास्तविक टोकन गिनती — कैश्ड रीड सहित — और उससे बनी लागत रिकॉर्ड करता है। Cost Dashboard इसे टाइम-सीरीज़ चार्ट और प्रति-मॉडल विवरण में बदल देता है, ताकि आप ठीक-ठीक देख सकें कि खर्च कहाँ जाता है और पुष्टि कर सकें कि कैशिंग और स्कोपिंग अपना काम कर रहे हैं। आप जो मूल्य देखते हैं वही मूल्य आपसे लिया जाता है; प्रोवाइडर की कच्ची लागत और कोई भी प्लेटफ़ॉर्म मार्कअप पारदर्शी रखे जाते हैं।