मुफ़्त पूरी गाइड
किसी SaaS product के लिए एक AI customer support agent design कीजिए। इसमें intent routing, knowledge retrieval, account-safe tool actions, conversation memory, confidence-आधारित human escalation,...
Interview की लय संक्षिप्त रहती है, ताकि page असली design निर्णयों पर ध्यान लगा सके.
सिर्फ requirements मत बताइए — पूछिए। हर card एक design constraint को उस clarification सवाल से जोड़ता है जो आप architecture बनाने से पहले बोल सकते हैं.
01क्या agent हर चीज़ का जवाब देता है, या पहले triage करता है?
पहले triage: हर incoming message को intent के लिए classify किया जाता है — knowledge से जवाब देने योग्य, account data चाहिए, या तुरंत human के पास जानी चाहिए (गुस्साया customer, legal threat, churn risk)।
02Agent किसी account के साथ असल में क्या कर सकता है?
केवल typed inputs वाले approved tools — status check करना, settings update करना, एक bounded refund जारी करना। जोखिम भरी या अपरिवर्तनीय actions के लिए स्पष्ट confirmation या human ज़रूरी है।
03Human को कब संभालना चाहिए, और उसे क्या मिलता है?
कम confidence पर, बार-बार नाकाम होने पर, या ग्राहक के कहने पर एक इंसान कमान संभाल लेता है। उसे एक handoff packet मिलता है: पूरी बातचीत, retrieve किए गए sources, आज़माए गए actions, और ख़ुद agent की uncertainty। कभी ठंडी शुरुआत नहीं।
04क्या agent पिछले turns याद रखता है — और पिछली conversations?
एक ही बातचीत के भीतर वह हमेशा याद रखता है — बहुत लंबे thread में भी। बातचीतों के बीच वह सिर्फ़ account facts रखता है, पहले की chat content कभी नहीं — retention policy के मुताबिक।
05एक भाषा या अनेक?
Pipeline किसी भी भाषा को संभाल लेती है, पर evaluation नहीं। Golden sets हर locale के लिए अलग बनते हैं, क्योंकि answer quality एक भाषा से दूसरी में नहीं जाती।
06क्या customer किसी भी समय human माँग सकता है?
हमेशा। हर कदम पर 'किसी इंसान से बात करें' बस एक turn दूर होता है। उस रास्ते को छिपाना deflection metrics (उन बातचीतों का हिस्सा जो कभी इंसान तक नहीं पहुँचतीं) को फुला देता है और साथ ही भरोसा तोड़ देता है।
Scope से बाहरVoice channel और real-time speech · Custom foundation models train करना · Sales और marketing conversations (केवल support)
01सबसे बुरा failure mode क्या है — धीमा होना, या गलत होना?
गलत होना: एक गढ़ी हुई policy या एक unauthorized refund किसी भी latency से ज़्यादा महँगा पड़ता है। Grounding, citation और action gating, fluency से ऊपर हैं।
02जवाब देते समय agent कौन-सा data देख सकता है?
सिर्फ़ वही जो यह ग्राहक देख सकता है। Knowledge access हर tenant और हर plan के हिसाब से scope होता है। Internal runbooks और दूसरे tenants का data किसी answer में कभी नहीं झलकना चाहिए।
03जवाब कितने तेज़ महसूस होने चाहिए?
Answers लगभग 2 seconds के भीतर दिखने शुरू हो जाएँ और 30 से काफ़ी नीचे पूरे हों — और यह लगभग 10K conversations/day पर भी बना रहे।
04जब कुछ गलत होता है, क्या हम कारण फिर से बना सकते हैं?
हाँ: हर turn trace होता है — query, retrieved chunks और scores, prompt, inputs/outputs के साथ tool calls, और escalation decision। Failures eval set में replay होती हैं।
05हमें कैसे पता चलेगा कि agent बदतर हो रहा है?
हर model या prompt बदलाव पर quality को reference support बातचीतों के एक तयशुदा set के ख़िलाफ़ जाँचा जाता है। बिना नापे कुछ भी ship नहीं होता। अकेली deflection rate quality नहीं है।
असली interview एक साफ list से कहीं गहरा probe करते हैं. ये scope सवाल उन्हें अलग करते हैं जो problem को कुरेदते हैं बनाम जो रटते हैं.
हर estimate को एक दबाव मानिए जो किसी component को justify करता है: cache, queue, partition, replica, worker pool, या fallback path.
Deflection economics
10K conversations/day (interviewer द्वारा दिया गया), agent लगभग 60% पूरी तरह हल करता है, एक human ticket औसतन ~15 min लेता है10K × 60% = 6,000 resolved/day; 6,000 × ~15 min = 90,000 min ≈ 1,500 agent-hours/day; 8-hour shifts पर ≈ 190 support seats के बराबर काम absorb
Business case resolution QUALITY पर जीता या मरता है — इसीलिए eval suite एक requirement है, tooling नहीं।
प्रति turn context budget
~8K tokens: system + policies (2K) + retrieved chunks (4K) + conversation window (2K)2K + 4K + 2K = प्रति turn 8K tokens — retrieved chunks पूरे budget का आधा हैं, इसलिए उन 4K tokens को ही answer उठाना होगा
Retrieval precision ही असली quality lever है — बड़ा window एक cost बढ़ोतरी है, fix नहीं।
Latency decomposition
p95 targets: retrieval 300 ms + rerank 200 ms + first token 1.5 s≈ पहले streamed token तक 2 s
हर stage को अपना budget और अपनी monitoring मिलती है — "AI slow है" कोई diagnosis नहीं है।
Eval suite cost
500 golden conversations × हर release पर 3 judged variants500 × 3 = प्रति release 1,500 judged runs — parallel में चलाएँ तो यह मिनटों का wall-clock और judge-model tokens के कुछ dollars है
Continuous evaluation एक गलत संभाले गए enterprise ticket से कम खर्चीली है।
Escalation load
10K conversations में से ~40% escalate होती हैं4,000/day humans को handoff packets के साथ routed
Handoff quality तय करती है कि humans agent पर भरोसा करते हैं या नहीं — एक खराब packet उनका काम दोगुना कर देता है।
निर्णय उदाहरण
दिन में दस हज़ार बातचीतें, और agent साठ प्रतिशत को पूरी तरह हल कर देता है। पूरी value इसी पर टिकी है कि वे हल SAHI हों। एक गढ़ी हुई refund policy एक महीने की बचत मिटा देती है।
मैं agent को एक gated pipeline की तरह बनाऊँगा। वह पहले intent classify करता है, ग्राहक की अपनी permissions के साथ retrieve करता है, और सिर्फ़ citations के साथ जवाब देता है। हर side effect typed, allow-listed tools के पीछे जाता है, और risk tiers model के बाहर enforce होते हैं। Confidence हर कदम को gate करती है: threshold से नीचे, ग्राहक को एक इंसान मिलता है साथ में एक handoff packet — बातचीत, sources, आज़माए गए actions, और agent की uncertainty। हर turn traced और replayable है, और नाकामियाँ एक golden eval set को feed करती हैं जिसे rubric और pairwise comparison से आँका जाता है, और इंसान उसे calibrate करते हैं।
जो मैं नहीं करूँगा: model को एक database connection और एक system prompt थमा देना जो कहे "मददगार बनो।" Free-form access ही वह तरीका है जिससे agent गलत ग्राहक को refund कर देता है। मैं quality को अकेली deflection rate से भी नहीं नापूँगा। जो agent गलत जवाबों के साथ आत्मविश्वास से deflect करता है वह पूरे नंबर पाता है और भरोसा तोड़ देता है। और exact-match tests support बातचीतों को नहीं आँक सकते। "क्या इसने सही हल किया" एक preference judgment है — इसीलिए eval set अच्छे AUR बुरे, दोनों reference outputs rubrics के साथ रखता है।
अगर product data residency नियमों के साथ multi-region हो जाए, तो retrieval indexes और conversation logs को हर region के हिसाब से shard करना होगा। तब eval suite में per-locale golden sets जुड़ते हैं, क्योंकि quality भाषाओं के आर-पार portable नहीं है।
पहले एक पूरी तस्वीर, फिर हर path को अपना अलग diagram — write path और read path अलग traffic ढोते हैं और अलग components justify करते हैं.
पूरी तस्वीर
Model जो कुछ भी करता है वह एक gate से गुज़रता है: retrieval permission-scoped है, actions tool gateway से होकर जाती हैं, और low confidence पूरे handoff packet के साथ एक human के पास exit हो जाती है। Traces हर hop record करते हैं।
Path 1
किसी भी generation से पहले intent classification चलती है। Retrieval ग्राहक की permissions को index query में साथ ले जाता है। जवाब अपने sources cite करता है, वरना वह ship नहीं होता।
Path 2
Model प्रस्ताव देता है; gateway निपटारा करता है। Low tiers execute होते हैं, medium tiers customer से confirm कराते हैं, high tiers को human चाहिए — और हर call trace में उतरता है।
optimize करने से पहले contract को inspectable बनाइए: endpoints, entities, ownership, retries, और state.
POST/support/messages
req{ conversation_id?, text }
res200 citations के साथ streamed answer · या { escalated: true, ticket_id }
Customer identity session से आती है — agent की permissions ही customer की permissions हैं, कभी अधिक व्यापक नहीं।
POST/support/{conversation_id}/escalate
res201 { ticket_id } handoff packet संलग्न के साथ
कम confidence, बार-बार failure, या customer के स्पष्ट अनुरोध पर fire होता है — escalation एक feature है, failure नहीं।
POSTinternal: tools.execute(tool, input, risk_tier)
resresult · blocked (confirmation चाहिए) · denied (policy)
Model output से असली side effects तक का एकमात्र path: typed inputs, allow-listed tools, model के बाहर लागू किए गए risk tiers।
Core entities
Conversationconversation_id (PK) · customer_id · channel · state: active/escalated/resolved
Turnturn_id (PK) · conversation_id · role · content · trace_ref
trace_ref पूरी तरह replayable trace से जुड़ता है: retrieval, prompt, tool calls, decisions।
ToolActionaction_id (PK) · conversation_id · tool · input · result · risk_tier · confirmed_by
जोखिम भरे tiers record करते हैं कि किसने confirm किया — agent, customer, या एक human agent।
HandoffPacketconversation_id · summary · retrieved_sources · attempted_actions · uncertainty_notes
Escalation पर human को जो मिलता है — takeover और restart के बीच का फ़र्क।
interview के आखिरी एक-तिहाई के लिए एक lane चुनें. हर lane आपको topic, वह interviewer सवाल जिसका जवाब देना है, और बचने वाला failure mode देती है.
"model $500 refund करना चाहता है" और असल में पैसा हिलने के बीच layered defenses क्या हैं?
फ़ैसला gateway करता है, model नहीं। Refund tool typed inputs लेता है एक hard cap के साथ, और risk tiers model के बाहर tool gateway में रहते हैं। $500 auto-execute line के ऊपर है, तो पैसा तभी हिलता है जब customer confirm करे या कोई human approve करे। एक blocked attempt भी trace में दर्ज होता है।
System prompt को control मानना — policy tool gateway में रहती है, model के बाहर।
दो companies यह product इस्तेमाल करती हैं। एक ऐसे question के लिए retrieval walk कीजिए जिसका best-matching chunk दूसरे tenant का है।
Tenant ID को index query के अंदर रखो। तब दूसरे tenant का chunk कभी retrieval candidate बनता ही नहीं — वह ranking से पहले बाहर हो जाता है, बाद में निकाला नहीं जाता। results को post-filter मत करो। वहाँ एक check चूको और किसी competitor का document prompt में पहुँच जाएगा।
Retrieved chunks को बाद में post-filter करना — permission filter index query के भीतर ही होना चाहिए।
Conversation के बीच confidence गिर जाती है। Human agent ठीक-ठीक क्या देखता है, और customer के flow का क्या होता है?
Human एक handoff packet खोलता है, कोई खाली screen नहीं। उसमें पूरी conversation होती है, ऊपर एक running summary, वे sources जो agent ने retrieve किए, हर action जो उसने आज़माया, और उसका अपना uncertainty note। Customer उसी chat में रहता है और बस देखता है कि एक इंसान जुड़ गया। उसे कभी अपनी बात दोहरानी नहीं पड़ती।
केवल एक transcript के साथ escalate करना — sources, attempted actions, और uncertainty notes ही human को restart से बचाते हैं।
एक prompt बदलाव ship होता है। आप कैसे जानेंगे कि support quality चुपचाप regress नहीं हुई — customers के बताने से पहले?
हर release पर golden conversations का एक तय set फिर से replay करो। एक judge model हर answer को एक rubric के आधार पर score करता है और नए version की तुलना पुराने से करता है, और humans उसे नियमित रूप से re-calibrate करते हैं। Exact-match prose को grade नहीं कर सकता, और deflection rate confident गलत answers को इनाम देता है। Rubric और pairwise judgment मिलकर regression को customers से पहले पकड़ लेते हैं।
Exact-match tests या deflection rate को metric मानना — support answers को rubric और pairwise judgment चाहिए, human-calibrated।
एक customer agent द्वारा पिछले महीने की गई action पर विवाद करता है। Conversation फिर से बनाइए: क्या store है, कितने समय तक, और कौन पढ़ सकता है?
हर turn traced था — query, retrieve किए chunks और उनके scores, prompt, inputs और outputs के साथ tool calls, और escalation decision। तो विवादित action ठीक वैसे ही replay होता है जैसे हुआ था। Logs सिर्फ़ retention window तक ही रहते हैं, PII redacted के साथ। उन्हें पढ़ना खुद एक permissioned, audited action है।
कच्चे conversations को PII सहित हमेशा के लिए store करना — retention और redaction requirements हैं, cleanup नहीं।
AI customer support agent को ज़ोर से समझाइए और अपनी व्याख्या पर AI scoring पाइए.