TypeChat: चैट-आधारित AI प्लेटफ़ॉर्म

 (microsoft.github.io)
3 पॉइंट द्वारा GN⁺ 2023-07-21 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा ऐप्स में natural language input जोड़ते समय सबसे बड़ी कठिनाई उपयोगकर्ता के इरादे को ऐसे स्ट्रक्चर में बदलना है जिस पर software भरोसा कर सके, और TypeChat इस समस्या को TypeScript types के ज़रिए हल करने की कोशिश करने वाली एक लाइब्रेरी है
  • LLM के मुक्त-रूप text responses को parse करना अस्थिर होता है, इसलिए TypeChat responses को JSON में लाने और schema validation जोड़ने का काम करता है, ताकि ऐप उसे प्रोसेस कर सकने वाले डेटा में बदल सके
  • TypeScript types JSON संरचना को बहुत सटीक रूप से व्यक्त कर सकते हैं, और LLM ने training के दौरान इस फ़ॉर्मैट को बहुत देखा है, इसलिए यह response schema के रूप में उपयोग के लिए उपयुक्त है
  • अगर response type से मेल नहीं खाता, तो TypeScript compiler errors को फिर से feedback के रूप में देकर उसे सुधारा जा सकता है, जिससे post-processing या user confirmation से पहले type safety बढ़ाई जा सकती है
  • TypeChat को npm install typechat से install किया जा सकता है, यह MIT लाइसेंस वाला open source प्रोजेक्ट है, और OpenAI API व Azure OpenAI service integration भी देता है

natural language अनुरोधों को ऐप द्वारा प्रोसेस किए जा सकने वाले डेटा में बदलना

  • नवीनतम large language models को chat assistants में जोड़ना आसान है, लेकिन मौजूदा app interfaces में natural language को भरोसेमंद तरीके से integrate करना एक अलग चुनौती है
  • TypeChat का फ़ोकस उपयोगकर्ता अनुरोधों को ऐसे रूप में बदलने पर है जिन्हें ऐप प्रोसेस कर सके, और ऐसे कार्य संभव बनाना है जिन पर developers और users भरोसा कर सकें
  • जारी की गई लाइब्रेरी codebase की type definitions का उपयोग करके structured AI responses प्राप्त करती है और type safety को लक्ष्य बनाती है
  • install निम्न कमांड से किया जा सकता है
npm install typechat

natural language parsing के बजाय JSON और types का उपयोग

  • LLM मूल रूप से अंग्रेज़ी जैसी natural language बातचीत के लिए tuned होते हैं, इसलिए prompt में “bullet list में जवाब दो” जैसे नियम डालने पर भी सामान्य software के लिए उसे स्थिर रूप से parse करना कठिन होता है
  • अगर उससे JSON में जवाब माँगा जाए, तो आम तौर पर ऐसा response मिल सकता है जिसे ऐप अधिक आसानी से संभाल सके
    • उदाहरण में “blueberry muffin” 1 और “grande latte” 1 का अनुरोध items array वाले JSON में बदला जाता है
  • साधारण उदाहरण संरचना का संकेत देने में मदद करते हैं, लेकिन वे AI को क्या लौटाना है, इसे पर्याप्त रूप से परिभाषित नहीं करते और validation का मानदंड भी नहीं देते

response schema के रूप में TypeScript types का उपयोग

  • TypeChat prompt में TypeScript types शामिल करता है, ताकि LLM को यह बताया जा सके कि उसे किस JSON संरचना में response लौटाना है
  • उदाहरण schema का Response type, items: Item[] शामिल करता है, और Item में name, quantity, वैकल्पिक size, notes fields होते हैं
  • TypeScript JSON का सटीक वर्णन करने के लिए उपयुक्त है, और LLM ने type definitions बहुत देखी हैं, इसलिए response format को guide करने में यह उपयोगी है
  • अगर response type से मेल नहीं खाता, तो वैध TypeScript code के रूप में मौजूद type definition के आधार पर TypeScript compiler validation करता है
  • compiler error feedback का उपयोग response को सुधारने के लिए किया जाता है, जिससे type-matching response पाने की प्रक्रिया अधिक मजबूत बनती है

TypeChat का उपयोग और उदाहरण

  • TypeChat का उपयोग data schema तरीके से किया जा सकता है, जो user intent को structured response में बदलता है
  • उदाहरण code उपयोगकर्ता इनपुट वाक्य के sentiment को negative, neutral, positive में से एक के रूप में पहचानने वाला SentimentResponse interface परिभाषित करता है
  • createLanguageModel(process.env) से environment variables आधारित language model बनाया जाता है, फिर schema file पढ़कर createJsonTranslator<SentimentResponse> से translator बनाया जाता है
  • अगर translator.translate(request) सफल होता है, तो response.data.sentiment आउटपुट किया जाता है; असफल होने पर error message दिखाया जाता है
  • data schema के अलावा API schema का उपयोग करके बुनियादी प्रोग्राम भी बनाए जा सकते हैं
  • उपयोग के तरीके docs और examples में देखे जा सकते हैं

open source और model neutrality

  • TypeChat MIT लाइसेंस वाला open source प्रोजेक्ट है और GitHub पर उपलब्ध है
  • सुविधा के लिए यह OpenAI API और Azure OpenAI service के लिए basic integration देता है
  • इसका डिज़ाइन लक्ष्य model neutrality है, और यह ऐसे दृष्टिकोण को अपनाता है जिसे chat completion style API के साथ इस्तेमाल किया जा सके
  • फिलहाल TypeChat उन models पर सबसे अच्छा काम करता है जिन्हें prose और code दोनों पर train किया गया है
  • पैकेज npm पर उपलब्ध है, इसलिए इसे तुरंत आज़माया जा सकता है

संबंधित पढ़ाई

2 टिप्पणियां

 
sungwoo 2023-07-26

हाहा, खबर देखकर पोस्ट करने वाला था, लेकिन AI की रफ्तार का मुकाबला नहीं कर पा रहा हूँ
 
GN⁺ 2023-07-21
Hacker News की राय

  • मुझे ठीक से समझ नहीं आ रहा कि इसमें कौन-सा अतिरिक्त मूल्य है
    LLM को भेजा जाने वाला मुख्य संदेश यहाँ है: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    आखिरकार यह fixed prompt से structured data लौटाने जैसा दिखता है, जिसमें थोड़ी automation और vendor lock-in जोड़ दी गई है। ऐसी LLM libraries में से ज़्यादातर नीचे की API पर चढ़ाई गई कमजोर API जैसी लगती हैं; वही काम करने वाली script आसानी से बनाई जा सकती है, और model व user requirements बदलने पर वह ज़्यादा flexible रहती है
    मसलन prompt बदलना हो या Python classes इस्तेमाल करनी हों, तो ऐसी library और API calls/text templates को user के ऊपर उठा देने वाले तरीके (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...) के बीच काम की मात्रा में बड़ा फर्क है

    • मूल्य यहाँ है: 1) LLM द्वारा लौटाए गए result पर TypeScript type checker चलाना, 2) अगर type errors हों तो उन्हें इकट्ठा करके “correction prompt” बनाना, ताकि type check पास करने की अधिक संभावना वाला output मिले, 3) जब दूसरे step की heuristic fail हो जाए, उसे भी साफ-सुथरे ढंग से handle करना
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      इसी idea पर प्रयोग करने के मेरे अनुभव में, दूसरी heuristic अपेक्षाकृत simple types—यानी गहराई से nested न होने वाले records और arrays, तथा type variables के सीमित उपयोग—में हैरान कर देने वाली तरह से अच्छी तरह काम करती है। LLM को अपेक्षाकृत simple type की value लौटाने के लिए prompt देना भर भी उपयोगी applications बनाने के लिए काफी हो सकता है, और इस library का मूल्य इस बात में है कि यह उस request pattern को खुद implement करने की जरूरत कम करती है और TypeScript codebase के साथ standard integration देती है
    • आजकल दिखने वाली LLM libraries लगभग सभी ऐसी ही हैं। आखिर में बात LLM से किसी काम को किसी खास तरीके से करने का अनुरोध करने तक आ जाती है, और मैंने देखा है कि जटिल conditions में वह instructions कम follow करता है और default behavior पर लौट जाता है
      फिर भी लगता है कि libraries इस्तेमाल करने की दिशा सही है, इसलिए देख रहा हूँ कि कौन-सा approach पर्याप्त mature होगा
    • vendor lock-in कहाँ है, यह समझ नहीं आ रहा। यह एक open source library है, और आपने जिस file को link किया है उसमें ChatGPT और Bard दोनों providers की settings हैं
    • मूल्य unstructured data को structured data में बदलने और यह सुनिश्चित करने में है कि वह schema constraints को satisfy करता है
      उदाहरण के लिए अगर किसी product पर 1000 free-text survey responses हैं, तो आप schema बना सकते हैं और हर एक पर TypeChat चला कर उस free text का dataset पा सकते हैं। बेहद उपयोगी है
    • abstraction जितनी बेहतर होती है, उपयोगी चीज़ें code करना उतना आसान होता जाता है

  • एक बात समझ नहीं आती
    valid response आने की उम्मीद करना, आखिरी step में validator लगाकर गलत response detect करना, और फिर model से मनचाहे grammar में जवाब देने की विनती करने जैसी जटिल प्रक्रिया से क्यों गुजरना पड़ता है, यह समझ नहीं आता
    अगर केवल requested format से match करने वाले tokens sample किए जाएँ, तो valid JSON grammar guarantee की जा सकती है। हर बार सबसे high score token को greedily चुनने के बजाय, requested format के अनुरूप tokens में से सबसे high score वाला चुनना चाहिए
    Microsoft की Guidance पहले से ऐसा करती है: https://github.com/microsoft/guidance
    लेकिन लगता है OpenAI सभी tokens के full scores expose नहीं करता, केवल top score tokens ही दिखाता है। अगर model local पर चलाएँ, तो Guidance इस्तेमाल करना आसान है, JSON हर बार सही रहेगा यह guarantee की जा सकती है, और generation भी तेज़ होती है—यह अजीब है

    • यह brown M&M वाली कहानी[0] जैसी है। अगर model semantically correct data लौटाता है, तो कम-से-कम grammar सही होने की उम्मीद की जा सकती है। अगर वह इतना भी नहीं कर पाता, तो response वैसे भी फेंकना पड़ेगा
      साथ ही, उस तरीके से TypeScript types की पूरी complexity capture करना मुश्किल लगती है
      [0] https://www.snopes.com/fact-check/brown-out/
    • उस तरीके से syntactically correct JSON guarantee किया जा सकता है, लेकिन वह semantically correct है या नहीं, यह अलग सवाल है
      अगर model वास्तव में कोई दूसरा token डालना चाहता है और आप जबरदस्ती { डलवाते हैं, तो उसके बाद generate होने वाले text की quality गिर भी सकती है। पक्का नहीं, बस विचार कर रहा हूँ
    • केवल valid tokens sample करने का तरीका मुझे बहुत promising लगता है
      मैंने open source LLM को JSON parsing के लिए fine-tune किया था, और guided token sampling के बिना भी use case के हिसाब से 70B parameters overkill हो सकते हैं। काफी छोटे models पर भी अच्छे results देखे, और small model fine-tuning को guided token sampling के साथ जोड़ना दिलचस्प होगा
      हालांकि बहुत general-purpose applications के लिए fine-tuning perfect नहीं हो सकती। training dataset में न सोचे गए inputs आएँ तो मुश्किल हो जाती है
    • LLM ज़्यादा complex scenarios handle कर सकता है। उदाहरण के लिए vending machine में पूरा order flow follow किए बिना अगर आप बस order बोल दें, तो “कुछ chocolate bars” जैसी expression को inventory से match करके guess कर सकता है
      बेशक web पर यह समझ में नहीं आता। mouse से कुछ products click करना कहीं आसान है
    • Llama.cpp ने हाल में बताया कि उसने fixed format follow कराने के लिए token selection को constrain करने वाली grammar-based sampling जोड़ी है
      https://github.com/ggerganov/llama.cpp/pull/1773

  • मुझे लगता है कि मैं कुछ सोचता हूँ और Anders Hejlsberg उसे बना देते हैं
    संरचित requests और responses 100% LLM का अगला evolution हैं। लोग पहले ही chatbots से ऊबने लगे हैं, और अगर text parsing और prompt की चिंता किए बिना किसी भी backend को plug in किया जा सके, तो यह कमाल होगा

    • मैं locally चलने वाले LLM में अपने दिए हुए actionable interfaces जोड़ना चाहता हूँ। जैसे “समय देखना”, “calendar देखना”, “user को message भेजना” वगैरह
      TypeChat सही दिशा में लगता है। “इस JSON input को, अगर संभव हो, उपलब्ध actions में से किसी एक से match करो” जैसी एक अतिरिक्त layer की कल्पना की जा सकती है
      मुझे bots, यानी LLMs आदि का actual code layers को जोड़ने वाला एक साफ-सुथरा hybrid future दिखता है। कभी वे collection/tagging का हिस्सा होंगे, और कभी input का जवाब देने का हिस्सा
      कुल मिलाकर यह बहुत दिलचस्प क्षेत्र है, लेकिन सब कुछ इतनी तेजी से बदल रहा है कि मैंने अभी इसमें गहराई से dive नहीं किया है। बहुत से smart लोग इस पर काम कर रहे हैं, इसलिए लगता है कि धूल थोड़ी बैठने का इंतजार करना चाहिए। फिर भी, जिस home interface का मैं सपना देखता था, वह अब बनाने लायक stage पर आ चुका लगता है
    • कल ही मैंने कुछ similar implement किया, लेकिन objects के बजाय function-centric approach पर focus किया
    • backend layer के dynamic mapper के रूप में इस्तेमाल किया जाए तो यह जबरदस्त हो सकता है
      उदाहरण के लिए, Java consumer के आसपास बार-बार बदलने वाले API payloads को follow करके देखिए। banking sector, विशाल JSON payloads और Java backend environment में sanity बनाए रखने के लिए हमने अलग से NodeJS layer बनाई थी
      mapping वह क्षेत्र है जहाँ LLM चमक सकते हैं
    • देखने लायक: https://news.ycombinator.com/item?id=36750083

  • अगर एक hot take दूँ, तो हम धीरे-धीरे AI के toolification phase में प्रवेश कर रहे हैं। लोग समझ रहे हैं कि इसमें actual value creation ज्यादा नहीं है, लेकिन AI में इतना पैसा invest हो चुका है कि funding जारी है। academic papers निकालने के लिए भी यह अच्छा topic है, और LangChain तो लगभग joke जैसा है फिर भी seed में 10 मिलियन डॉलर मिल गए
    DeFi/crypto दो साल पहले इस phase से गुजरा था। कुछ साल तक एक अजीब limbo state चलती रहेगी, फिर लोग धीरे-धीरे समझेंगे कि AI product नहीं, feature है; इसकी applicability सीमित है और यह दुनिया नहीं बचाएगा। सारे edge cases की वजह से self-driving cars नहीं हो पाएंगी, और लोगों को मार सकने के जोखिम के कारण surgery भी नहीं हो पाएगी
    मैं लगातार कहता आया हूँ कि Copilot जैसे सबसे useful AI tools भी ज्यादा से ज्यादा marginally useful हैं। best case में वे Google पर कुछ clicks बचा देते हैं, और agents बिल्कुल भी “intelligent” नहीं हैं। कुछ साल पहले chatbots[1] जैसा ही bubble आया था, और आजकल किसी को परवाह नहीं। “metaverse” बहुत जल्दी खत्म हो गया, लेकिन वही herd mentality काम कर रही थी। कभी “next big thing” होता है, फिर नहीं रहता
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • इस बात से मैं सख्ती से असहमत हूँ कि AI सिर्फ सीमित applicability वाला bubble है
      आपने AI के सबसे कठिन use cases ही चुने हैं, जैसे self-driving cars और surgery। ज्यादातर लोगों के कामों में life-and-death stakes नहीं होते, इसलिए वे automation के लिए बहुत suitable हैं। जहाँ life-and-death jobs में human element बचा रहेगा, वहाँ भी AI agents से augmentation होने की संभावना बहुत है। उदाहरण के लिए surgery इंसान ही करे, फिर भी doctor या nurse के लिए AI के साथ diagnosis करना mandatory हो सकता है
      क्या आप सच में कुछ साल पहले के chatbot bubble की तुलना आज से कर रहे हैं? ChatGPT कुछ ही महीनों में 100 million users तक पहुँच गया, और बहुत सारे लोगों ने सचमुच इसे इस्तेमाल किया। कुछ साल पहले chatbot bubble की कोई खास presence भी नहीं थी
      Copilot वगैरह सिर्फ marginally useful लगते हैं क्योंकि आप अभी उनकी सबसे खराब versions देख रहे हैं। ChatGPT ने मेरी जिंदगी बदल दी है, और अभी यह code execution भी नहीं करता। Code Interpreter करता है, लेकिन मैंने अभी test नहीं किया
      2030 तक शायद इंसान code type नहीं करेंगे, बल्कि machine को prompt देंगे और AI agents को direct करेंगे। तब तक ज्यादातर jobs भी शायद automate हो चुकी होंगी
      AI सिर्फ trend नहीं है; यह हर industry को बदल देगा, और लोगों के सोचने से कहीं ज्यादा तेजी से। metaverse से तुलना करके AI के implications को कम करके आंकने वाला cynicism बेतुका और imagination की कमी दिखाता है। खासकर AI agents की तरफ अभी बहुत काम बाकी है, लेकिन हम शायद लोगों के सोचने से बहुत पहले वहाँ पहुँच जाएंगे, और impact बहुत बड़ा होगा
    • जब भी मैं ChatGPT इस्तेमाल करता हूँ, मुझे लगता है कि मैं वह technology नहीं देख रहा जो बाकी लोग देख रहे हैं। कहा जाता है कि यह हर सवाल का जवाब देता है और कुछ भी सिखा देता है, लेकिन असल में यह मुझे content farm service जैसा लगता है। Copilot भी similar है; अक्सर खराब examples में से कम खराब वाला ढूँढने और bugs fix करने से आसान है कि code खुद ही लिख लिया जाए
      हालांकि AlphaGo को खराब moves “hallucinate” करने वाली स्थिति से दुनिया का सर्वश्रेष्ठ player बनने में ज्यादा समय नहीं लगा। अगर language models में भी ऐसा संभव है, तो GPT-x आज की पूरी debate को उड़ा सकता है
    • “actual value creation नहीं है” वाली बात से मैं सख्ती से असहमत हूँ। मेरे use case में इसका बहुत स्पष्ट counterexample है
      GPT-4 तब बहुत मददगार है जब कोई skilled व्यक्ति ऐसा adjacent काम कर रहा हो जहाँ उसकी skills broadly लागू होती हैं लेकिन domain knowledge कमजोर हो
      मैं 10 साल से code लिख रहा हूँ और हाल ही में पहली बार machine learning सीख रहा हूँ; मैं रोज GPT-4 इस्तेमाल करता हूँ और काफी संतुष्ट हूँ
      बेशक कुछ rough edges कभी-कभी चुभ सकते हैं। मेरे लिए वे manageable हैं और बहुत परेशान नहीं करते। उन्हें ignore या bypass करने की आदत हो गई है, और ऐसे tools इस्तेमाल करने में definitely skill लगती है
      मुझे लगता है कि मिलने वाली value लगातार बढ़ेगी। हमने अभी low-hanging और mid-height fruits भी पूरी तरह नहीं तोड़े हैं
    • DeFi/crypto से मुख्य फर्क यह है कि वहाँ technology चाहे कितनी भी impressive रही हो, लोगों को पहला फायदा पाने के लिए अपने काम करने का तरीका पूरी तरह बदलना पड़ता था
      modern AI, असल में आमतौर पर LLM, लगभग हर economic sector में तुरंत और व्यापक रूप से लागू हो सकता है। इसलिए बहुत से लोग पहले से features बना और release कर रहे हैं। इस technology में जबरदस्त value है। क्या यह दुनिया को पूरी तरह बदल देगा? नहीं, लेकिन नए product categories बनाने और existing products की capabilities के बड़े हिस्से को fundamentally improve करने के लिए यह काफी है
    • मुझे यह काफी reasonable interpretation लगता है। AI के बहुत use cases हैं और कुछ कामों में यह सचमुच अच्छा है, लेकिन यह वह silver bullet नहीं है जिसकी लोग उम्मीद कर रहे हैं

  • Apple, Google, Amazon, Microsoft के voice assistants में से अभी तक किसी ने LLM को अपनी service में integrate क्यों नहीं किया, और OpenAI ने अपना voice assistant क्यों नहीं निकाला, यह समझ नहीं आता
    साथ ही, अगर RSS की तरह websites AI interaction के लिए standard URL expose करें और TypeChat से interface public करें, तो लगता है इस दिशा में काफी आगे बढ़ा जा सकता है

    • OpenAI के अपना assistant बनाने की संभावना ज़्यादा है। Karpathy के “Building a kind of JARVIS @ OреոΑӏ” से तो ऐसा ही लगता है, और Microsoft भी ज़ाहिर तौर पर OpenAI के LLM से Cortana को integrate या reinterpret करने पर काम कर रहा होगा
      हालांकि voice-based LLM से कहीं ज़्यादा value वास्तव में actions perform करने की capability में है। Alexa को उदाहरण मानें, तो smart home control को predictable और debuggable तरीके से handle करने वाला system चाहिए। नहीं तो लोग irritate हो जाते हैं
      मुझे साफ़ तौर पर लगता है कि यह संभव है, लेकिन मौजूदा Alexa या Siri, और कम इस्तेमाल होने वाले Cortana जैसे systems कई सालों से कम powerful models पर बनी rules और software की layers हैं, जो कई hooks और APIs इस्तेमाल करते हैं। इन्हें चलाने के लिए current quality बनाए रखते हुए सुधार करना और साथ ही system के major parts को replace करना पड़ेगा, इसलिए समय लगेगा
      ऊपर से, ये assistants असल में पैसे नहीं कमाते और ज़्यादातर घाटे में रहते हैं। इनकी value उन्हीं big companies के लिए है जो phones, shopping आदि दूसरे तरीकों से पैसे कमा सकती हैं या अपना business push कर सकती हैं, इसलिए startups के लिए incentive कम है
      मैंने पहले Cortana और Alexa दोनों पर काम किया है, और LLM progress के आधार पर शुरू से नया version बनाने के बारे में भी बहुत सोचा था। Technology overall intuitive थी और अब possible हुए new use cases के ideas भी थे, लेकिन कोई workable business model नहीं मिला। इसलिए अब मैं बिल्कुल अलग काम कर रहा हूँ
    • जब पहली बार पता चला कि ChatGPT क्या है, तो मेरा पहला विचार था: “अच्छा, Siri को असल में ऐसा होना चाहिए था”
    • ChatGPT और Bing इस्तेमाल करने के बाद Alexa से बात करना हास्यास्पद लगता है। अच्छी performance वाला hardware खराब software की वजह से सालों से अटका हुआ है, यह देखकर सच में frustration होती है
    • Microsoft Windows 11 में Cortana को replace करने के लिए वही कर रहा है
    • मैं Home Assistant को control करने के लिए इस्तेमाल हो सकने वाली किसी चीज़ का सच में इंतज़ार कर रहा हूँ
      हालांकि इसके लिए cloud-based API इस्तेमाल करना बहुत असुरक्षित लगता है, इसलिए मैं चाहता हूँ कि यह घर के अंदर server पर चले। साथ ही voice recognition और response time इतने तेज़ हों कि waiting जैसा बिल्कुल महसूस न हो
      personal assistant DIY attempts कुछ बार देखे हैं, लेकिन उनमें हमेशा काफी latency रही है, इसलिए अक्सर इस्तेमाल करने पर जल्दी चिढ़ होने लगेगी

  • एक हिस्सा है कि { "name": "grande latte" } जैसा response मिलना आसान है
    लेकिन अगर type Item = { name: string; ... size?: string; } है, तो यह name: "grande latte" से बचने में कैसे मदद करता है, यह मुझे ठीक से समझ नहीं आता
    example response में "size": 16 है और उसे “काफी बढ़िया” कहा गया है, लेकिन वह असल में requested type भी return नहीं करता। शायद example में typo है, और अगर ऐसा है तो idea खुद अच्छा लगता है

    • पकड़ने के लिए धन्यवाद। blog post के पिछले iteration में size गलती से number के रूप में specified किसी दूसरे schema का इस्तेमाल कर रहा था। schema बदल दिया था, लेकिन prompt फिर से run नहीं किया, और अब शायद fix हो गया होगा
    • मुझे लगता है यह example overall काफी weak है। यह सिर्फ typo से बड़ी समस्या है
      शायद शुरुआत में ही name string field चाहिए ही नहीं। { name: “the brown one”, size: “the espresso cup”, … } जैसी values मिलने से आप रोक नहीं सकते, और यह original string को parse करने जितना ही खराब है
      शायद हर field के लिए known values को represent करने वाला बड़ा string union type चाहिए होगा। तब LLM को उन्हीं में match करने के लिए कहा जा सकता है
      लेकिन फिर यह भी सवाल है कि इसे type syntax से क्यों बांधना चाहिए। Zod जैसा approach, जो runtime data से ऐसे union types बना सके, ज़्यादा सही लगता है
      quantity positive integer होनी चाहिए और fraction नहीं होनी चाहिए, जैसे constraints भी चाहिए। बेशक JSON value को बाद में validate किया जा सकता है, लेकिन तब user को दो तरह की errors दिखेंगी। एक वह error जो LLM fluent human tone में देगा, और दूसरी अजीब तरह से technical error जैसे “quantity value बहुत बड़ी है”
      ऐसी चीज़ें explain करने के लिए type syntax गलत जगह लगता है
    • यह बस documentation bug जैसा लगता है। लगता है announcement लिखने के आखिरी चरण में ounces की संख्या से standard sizes पर बदला और output value उसी हिसाब से बदलना भूल गए
      दिए गए code भर से system के पास “grande” को 16 में map करने का कोई तरीका नहीं है, और 16 कहीं और इस्तेमाल होता भी नहीं दिखता
    • अगले paragraph में “type को ignore करने पर क्या होता है” cover किया गया है, इसलिए शायद उसी intention से लिखा गया होगा

  • ऐसा लगता है जैसे type check pass करने वाली कोई चीज़ output होने तक LLM को बार-बार run किया जाता है, और error message के साथ फिर prompt दिया जाता है
    cute idea है और लगता है काम करेगा, लेकिन बड़े models और लंबे input prompts के साथ cost ज़्यादा हो सकती है। शायद यह हर scenario का solution नहीं है

    • कम से कम OpenAI में internally नया function calling feature इस्तेमाल करना बेहतर नहीं होगा?
    • TypeChat कैसे काम करता है, यह ठीक से नहीं पता, लेकिन Guidance [1] भी similar project है और वास्तव में token sampling में integrate करके format enforce कर सकता है
      [1]: https://github.com/microsoft/guidance
    • ज़्यादातर products शायद पहले product-market fit की चिंता करेंगे, और उसके बाद cost कम करने की कोशिश करेंगे
      market structured output मांग रहा है, इसलिए models भी उसी दिशा में improve होंगे—यह भी काफी reasonable assumption है

  • इस हफ़्ते Laravel PHP के लिए इससे बहुत मिलता-जुलता, लेकिन scope में छोटा कुछ बनाकर release किया: https://github.com/adrenallen/ai-agents-laravel
    मेरा मानना है कि engineers को किसी दिए गए LLM के साथ नया “bot” आसानी से spin up कर पाने में सक्षम होना चाहिए। functions को ऐसे रूप में बदलने और response को handle करके फिर parse करने वाला बहुत-सा tedious काम होता है, जिसे ChatGPT समझ सके
    ऐसे system का इस्तेमाल करने पर आप actual PHP code लिखने और कुछ साफ़ comments जोड़ने पर focus कर सकते हैं, और फिर bot उस code को किसी भी काम में सीधे tool की तरह इस्तेमाल कर सकता है
    यह approach code sharing को भी कहीं ज़्यादा आसान बनाता है। कोई function लिखे, तो उसे नए bot में लाकर तुरंत इस्तेमाल किया जा सकता है। “LLM के इस्तेमाल और समझने के लिए transform करने वाली layer” को हटाने वाली बात बढ़िया है, और build speed काफ़ी बढ़ा देती है
    अभी यह perfect नहीं है, लेकिन मुझे लगता है कि एक-दूसरे के code का बेहतर इस्तेमाल करने के लिए अंततः सब कुछ इसी दिशा में जाएगा। आज coding में package managers इस्तेमाल करने के तरीके के बारे में सोचें, तो काश AI-specific tools के लिए भी एक package manager होता। जैसे “weather fetch” library install करके अपने bot में जोड़ दूँ, और अब वह weather fetch कर सके

    • मैं एक similar लेकिन थोड़े broader scope वाले approach पर काम कर रहा हूँ, इसलिए star किया। कुछ ideas वाकई साफ़-सुथरे हैं

  • ज़रा रुकिए, क्या यह TypeScript type definitions के against objects की runtime validation करता है? अगर इसे standalone library या feature के रूप में release किया जा सके, तो TypeScript codebase में API response payload validation वगैरह के लिए यह पूरी तरह game changer हो सकता है

  • यहाँ guidance [0] का इस्तेमाल न होना बहुत हैरान करने वाला है
    यह required fields को पूरा करने के सुझाव दे सकता है, जिससे validation[1] की ज़रूरत कम हो सकती है, और आखिरकार GPU time भी बच सकता है
    निश्चित रूप से कोई वजह होगी, लेकिन मैं सच में जानना चाहूँगा
    वैसे, मैं ठीक ऐसी ही चीज़ बना रहा था, और लगा जैसे Microsoft अचानक आकर मेरा lunch खा गया
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...