GPT के 50 करोड़ tokens प्रोसेस करने के बाद मिली सीख

 (kenkantzer.com)
4 पॉइंट द्वारा GN⁺ 2024-04-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Truss ने पिछले 6 महीनों में LLM-केंद्रित features चलाते हुए OpenAI models से 50 करोड़ से ज़्यादा tokens प्रोसेस किए, और B2B text summarization, analysis और extraction में असल में सामने आई सीमाओं को संक्षेप में रखा
  • Prompts में जितनी ज़्यादा detailed instructions डाली गईं, वे उतने stable नहीं रहे; जिन common-sense बातों को GPT पहले से जानता है, उनके लिए छोटी और कम specific instructions ने कई बार बेहतर परिणाम दिए
  • Langchain, JSON mode, function calling, assistants के बिना भी chat API और एक JSON extraction function से कई features चलाए गए; core code बस 40 lines के function और error handling/auto-truncation जितना था
  • GPT “न मिले तो empty value लौटाओ” जैसी null hypothesis handling और लंबे outputs में कमजोर रहा; GPT-4 की 128k input window से अलग, output करीब 4k स्तर पर ही रहा
  • RAG और vector DB Truss के सीमित text extraction कामों के लिए ठीक नहीं बैठे; पूरा context देकर analysis/summarization/extraction भरोसेमंद है, लेकिन input खाली हो या relevant जानकारी न हो तो समस्याएं बढ़ जाती हैं

उपयोग का दायरा और आधार

  • Truss ने पिछले 6 महीनों में कुछ LLM-केंद्रित features लॉन्च किए, और usage अनुमानतः 50 करोड़ tokens से थोड़ा अधिक रहा
  • इस्तेमाल किए गए models OpenAI परिवार के हैं, और token usage GPT-4 85%, GPT-3.5 15% है
  • data केवल text है; gpt-4-vision, Sora, Whisper जैसे non-text features शामिल नहीं हैं
  • product context B2B है, और मुख्य काम summarization, analysis, extraction हैं
  • 50 करोड़ tokens लगभग 7.5 लाख pages text के बराबर हैं

Prompts कम specific होने पर बेहतर हो सकते हैं

  • GPT जिन सामान्य knowledge वाली बातों को पहले से जानता है, उनके लिए exact list और instructions जरूरत से ज़्यादा डालने पर results खराब हो सकते थे
  • एक pipeline को text block को classify करना था कि वह अमेरिका के 50 states में से किससे या federal government से संबंधित है
    • शुरुआती prompt में locality_id field के लिए 50 states और federal की ID list JSON format में डालकर चुनने को कहा गया
    • यह तरीका करीब 98% से ज़्यादा काम करता था, लेकिन failures इतने थे कि और जांच करनी पड़ी
  • एक दूसरे field name को explicitly नहीं मांगा गया था, फिर भी वह सही state का पूरा नाम reliably लौटाता था
    • बाद में name में आए string को search करके state खोजने का तरीका अपनाया गया, और यह अच्छी तरह काम करने लगा
  • बेहतर approach यह थी कि “तुम 50 states जानते हो, इसलिए संबंधित state का पूरा नाम या Federal लौटाओ” जैसे common sense पर छोड़ने वाले prompt का इस्तेमाल किया जाए
  • कुछ अतिरिक्त observations भी थीं
    • failures Maryland, Maine, Massachusetts, Michigan जैसे M से शुरू होने वाले states में ज़्यादा दिखे
    • ID को list से चुनवाते समय, हर state को अलग line में रखने वाला readable JSON comma-separated list से कम confusing था

API और abstraction को simple रखा गया

  • इस case में Langchain premature abstraction जैसा था, और लाखों tokens और 3–4 अलग-अलग production features के बाद भी openai_service file में सिर्फ 40-line function बचा
  • वास्तव में इस्तेमाल की गई API सिर्फ chat थी
    • हमेशा JSON extract किया गया
    • JSON mode, function calling, assistants की जरूरत नहीं पड़ी
    • system prompt भी इस्तेमाल नहीं किया गया
    • जब gpt-4-turbo लॉन्च हुआ, तो codebase में सिर्फ एक string बदली गई
  • function का बड़ा हिस्सा OpenAI API की 500 errors या socket termination जैसी errors handle करने में लगा
    • ये errors सुधरी हैं, और OpenAI के load को देखते हुए यह हैरान करने वाला नहीं माना गया
  • context length limit को अपनी auto-truncation से handle किया गया
    • अगर string length model_context_size * 3 से बड़ी हो, तो उसे काट दिया जाता है
    • जब periods या numbers बहुत ज़्यादा हों, तो token ratio 3 characters per token से छोटा हो सकता है और failure हो सकता है
    • context_length_exceeded आने पर model_context_size * 3 / 1.3 के हिसाब से फिर काटकर retry किया गया

Streaming UX को कम आंकना मुश्किल है

  • streaming API से latency घटाकर user को variable speed से type होते characters दिखाने का तरीका शुरू में मजाक जैसा लगा
  • असल users ने variable-speed “typing” indicator को बहुत positive तरीके से लिया
  • यह experience AI में mouse/cursor UX वाले पल जैसा लगा

Empty results और लंबे outputs कमजोरी हैं

  • “न मिले तो empty output लौटाओ” सबसे ज्यादा error-prone prompt phrases में से एक था
    • इसका मतलब सचमुच कुछ भी output न करना नहीं, बल्कि {value: ""} जैसी empty value representation लौटाना था
    • समस्या output constraint failure से ज्यादा null hypothesis तय करने की कठिनाई जैसी थी
  • जब GPT को empty value लौटानी चाहिए थी, तब वह hallucination चुन लेता था; उलटा, confidence कम होने पर empty value बहुत ज्यादा बार लौटा देता था
  • जब एक bug के कारण text block empty हो सकता था, hallucination बहुत ज्यादा हुआ
    • उदाहरण के तौर पर Sunshine Bakery, Golden Grain Bakery, Bliss Bakery जैसे नकली bakery names आए
    • समाधान यह था कि text न हो तो prompt भेजा ही न जाए
  • GPT-4 input के लिए 128k token window रख सकता है, लेकिन output window अब भी करीब 4k स्तर पर है
    • “context window” phrase input और output को confuse कर देता है
  • JSON object list लौटाने को कहने पर, objects simple हों तब भी 10 से ज़्यादा निकालना मुश्किल था
    • 15 मांगने पर अनुमानतः सिर्फ करीब 15% success मिला
    • 10 के आसपास रुकने पर भी output सिर्फ 700–800 tokens के करीब था
  • एक-एक करके request करने और previous results को फिर input में डालने से output limit को bypass किया जा सकता है, लेकिन यह GPT के साथ telephone game खेलने जैसा हो जाता है और Langchain जैसे tools से निपटना पड़ता है

RAG और vector DB इस use case के लिए ठीक नहीं बैठे

  • Truss के case में vector DB और RAG/embeddings ज्यादातर बेकार रहे
  • vector DB और RAG search के लिए, वह भी Google/Bing जैसी real search के लिए, ज्यादा उपयुक्त लगते हैं
  • मुख्य समस्या relevance criteria है
    • relevance का कोई clear cutoff नहीं होता
    • Cohere के rerank जैसे solutions या अपने heuristics हो सकते हैं, लेकिन वे stable नहीं होते
    • irrelevant results से search results contaminate हो सकते हैं, या बहुत conservative होने पर important results छूट सकते हैं
  • vectors को normal data से अलग specialized/proprietary DB में store करना भी बड़ा नुकसान है
    • Google/Bing scale न हो तो context loss tradeoff को justify नहीं कर पाता
  • business apps में search करते समय users अक्सर domain experts होते हैं
    • माना गया कि वे ऐसी semantic search पसंद नहीं करते जो उनके सीधे input के अलावा meaning guess करके results लौटाए
  • ज्यादातर search cases में LLM को normal completion prompt की तरह इस्तेमाल करके user query को faceted search, complex query, या SQL में बदलना बेहतर हो सकता है
    • यह RAG नहीं है

पर्याप्त context होने पर hallucination काफी घटती है

  • Truss के ज्यादातर use cases “text block दो और उसमें से कुछ extract करो” वाले हैं
  • text में mentioned company names मांगने पर GPT आमतौर पर arbitrary company नहीं लौटाता
    • हालांकि text में company न हो तो null hypothesis वाली समस्या फिर सामने आती है
  • code में भी GPT दिए गए code block को rewrite करते समय variables गढ़ने या बीच में arbitrary typos डालने जैसे hallucination ज्यादा नहीं करता
    • लेकिन कुछ बनाने को कहा जाए तो वह standard library function के अस्तित्व को गढ़ सकता है
    • यह भी “मुझे नहीं पता” न कह पाने की समस्या के करीब माना गया
  • पूरा context देकर analysis, summarization, extraction करवाने वाले tasks में यह काफी reliable था
  • structure कुछ ऐसा है कि अच्छा data डालो तो अच्छे GPT token responses मिलते हैं

आगे की संभावनाओं पर आकलन

  • माना गया कि मौजूदा transformer, internet data, और अरबों dollar scale infrastructure access भर से AGI तक नहीं पहुंचा जा सकता
  • GPT-4 marketing नहीं, बल्कि 100% useful technology है, और अभी internet के शुरुआती दौर जैसा चरण है
    • यह सबको नौकरी से निकाल देने वाली technology नहीं है
    • इसका बड़ा असर यह है कि ML/AI की entry barrier कम हुई, जो पहले सिर्फ Google जैसी companies के लिए accessible थी
  • Claude, Gemini आदि पर strict A/B tests नहीं किए गए
    • रोजमर्रा की coding में test करने पर intent को intuit करने वाली subtle चीजों में वे GPT-4 के करीब नहीं लगे
  • LLM/AI trend की हर चीज follow करना जरूरी नहीं माना गया
    • The Bitter Lesson के हिसाब से अगर general model performance improvements specialized improvements से ज्यादा important हैं, तो बस GPT-5 launch पर ध्यान देना काफी है—ऐसा आकलन है
    • Sora जैसे अलग क्षेत्रों को छोड़ दें तो OpenAI की intermediate releases ज्यादातर noise जैसी लगती हैं
  • GPT-5 सब कुछ बदलने के बजाय incremental improvement होने की ज्यादा संभावना है
    • GPT-3 से GPT-3.5 तक जाते समय training intensity 2x करने पर performance 2.2x बेहतर होने वाली superlinear improvement की उम्मीद थी
    • वास्तव में यह logarithmic improvement जैसा दिखता है, और incremental improvement के लिए token speed और per-token cost exponentially बढ़ती दिखती है
  • मौजूदा task set में GPT-4 sweet spot हो सकता है
    • GPT-3.5 की तुलना में GPT-4 के लिए 20x cost देने की इच्छा थी, लेकिन GPT-4 से GPT-5 पर जाने के लिए per token 20x देना शायद नहीं चाहेंगे
    • GPT-5 इसे तोड़ भी सकता है, या iPhone 4 से iPhone 5 पर जाने जैसा ही हो सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-04-14
Hacker News की राय

  • मेरी टीम हर महीने 5 अरब+ tokens प्रोसेस कर रही है और यह संख्या लगातार बढ़ रही है; हमने कुछ बातें सीखी हैं
    पहली, बहुत ज़्यादा premature abstraction हो रहा है। Langchain जैसे tools किसी दिन उपयोगी हो सकते हैं, लेकिन आखिर में prompt बस एक API call ही है, और LLM call को कुछ खास मानने के बजाय उसे unstable API call की तरह standard code से handle करना ज़्यादा आसान है
    दूसरी, hallucination निश्चित रूप से बड़ी समस्या है। Summarization tests में काफी मजबूत दिखती है, लेकिन reasoning सच में कठिन है, और user input लेकर अगला action LLM से तय करवाने वाले action models में context समझना और उससे “मुझे पक्का नहीं पता” कहलवाना खास तौर पर मुश्किल है। फिर भी, यह कर पाना अपने आप में खेल बदलने वाला है
    तीसरी, मैं लेखक की तुलना में थोड़ा ज़्यादा “game-changing” वाली तरफ हूं, लेकिन मुझे नहीं लगता कि दुनिया खत्म हो जाएगी। कुछ jobs पर बड़ा असर पड़ेगा, और कुछ कठिन साल आ सकते हैं जब bots platforms पर public opinion manipulate करेंगे। कुल मिलाकर यह internet जैसी breakthrough चीज़ से ज़्यादा capability amplifier लगता है
    निजी तौर पर यह मुझे 2000s के DevOps बदलाव जैसा लगता है। अब deployment में मदद करने के लिए बड़ी dedicated team की जरूरत नहीं होती; कुछ experts hire किए जाते हैं और ज्यादातर ready-made solutions खरीदे जाते हैं। उसी तरह कुछ machine learning tasks अब मेरे जैसे web developer भी आसानी से implement कर सकते हैं

    • आधुनिक development flow में LLM से क्या उम्मीद रखनी चाहिए, यह समझाते समय ऐसी analogy उपयोगी है। क्योंकि यह दिखाती है कि यह silver bullet नहीं, बल्कि trade-off है
      DevOps के evolution में भी trade-offs थे। उदाहरण के लिए, “बस AWS RDS इस्तेमाल कर लो” के सीधे परिणामस्वरूप database management जैसी core capabilities गायब हो गईं, और cloud billing costs भी बहुत बढ़ गए। खासकर उन startups के operating costs भी बढ़े जिनके data scale या regional complexity बहुत ज्यादा नहीं थे, और मुझे लगता है यह trend GitLab के बड़े outage जैसी घटनाओं तक भी ले गया
    • “मुझे पक्का नहीं पता” कहलवाना language model के अपने function जैसा है। Output तक पहुंचते-पहुंचते calculation में मौजूद uncertainty prediction के अंदर गायब हो जाती है
      अगर किसी से सिक्के का head/tail बताने को कहा जाए और वह “heads” जवाब दे, तो जवाब देने से पहले वह Pr[heads] = .5 जैसी uncertainty बता सकता है, लेकिन वास्तविक prediction और coin toss के result में वह uncertainty गायब हो जाती है। LLM में भी token की final prediction में calculation के दौरान की uncertainty गायब हो जाती है, इसलिए जब तक prediction खुद uncertainty की अभिव्यक्ति न हो, “मैं समझ नहीं पाया” जैसा output शायद ही निकलेगा। हालांकि वजह यह है कि वह शुरू से समझता नहीं, बल्कि predict करता है
    • मैंने DevOps analogy के बारे में पहले कभी नहीं सोचा था, लेकिन यह काफी सही बैठती लगी, इसलिए अभी इसी idea पर एक post लिखा: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      मूल रूप से, मुझे लगता है हम GPT को AI operations में PaaS/Heroku/Render जैसे equivalent के रूप में इस्तेमाल कर रहे हैं
    • “internet जैसी breakthrough चीज़ से ज़्यादा capability amplifier” वाली बात से सहमत हूं। Customers भी बड़े models की cost के मुकाबले output में price shock महसूस कर रहे हैं। समय के साथ costs नीचे आएंगी
    • Summarization मजबूत है लेकिन reasoning कठिन है—इस बात से सहमत हूं। analogy मांगने का तरीका दिलचस्प और हैरानी की बात है कि उपयोगी था

  • “हम हमेशा JSON extract करते हैं। JSON mode की जरूरत नहीं” वाला हिस्सा मुझे curious लगा। मेरे case में यह काफी अच्छा चला
    “Lesson 4: GPT null hypothesis बनाने में सचमुच कमजोर है” वाली बात से मैं पूरी तरह सहमत हूं। कल ही text modification rules prompt test करते हुए मैंने अंत में लिखा था, “अगर कोई भी rule text पर लागू नहीं होता, तो original text बिना बदलाव लौटाएं”
    क्या आप जानते हैं, जिस text पर एक भी rule लागू नहीं होता था, उस पर ChatGPT ने क्या जवाब दिया? बिल्कुल यह string: “The original text without any changes”

    • ऐसी कहानियां होती हैं जिनमें एक सनकी जिन्न wish की wording को अक्षरशः interpret करके cursed wish पूरी कर देता है; अभी हमारे पास वही है। Image generation models को लंबे समय से prompt कर रहे लोगों को इसका कुछ अंदाजा है, लेकिन LLM के कारण आए लोगों के लिए यह काफी चौंकाने वाला हो सकता है
      पहले tarot cards के लिए एक शानदार garden में wine पीती तीन महिलाओं की image बनाते समय, prompt के अंत में “lush vegetation” डाल दिया था; उसमें lush के double meaning की वजह से elegant माहौल लाल नाक वाली party college girls जैसा हो गया था
    • मैंने इसे इस अर्थ में पढ़ा कि “हमारा तरीका अच्छा काम करता है, इसलिए JSON mode इस्तेमाल करने की जरूरत नहीं।” हमारी company में भी यही स्थिति है। 1 साल से production में है और बदलने की जरूरत नहीं पड़ी। हमारा prompt GPT-3.5 से हमेशा JSON output दिलाने में काफी effective है
    • Cake decoration fail sites देखें तो इंसान भी ऐसी गलतियां हर समय करते हैं

  • बेहतर prompts लिखें तो सस्ता model इस्तेमाल कर सकते हैं
    “अगर कुछ नहीं मिले तो कुछ भी return न करें” LLM को escape route देने का level 0 तरीका है। बेहतर है कि उसे ज़्यादा नरम exit दिया जाए। उदाहरण के लिए, “अगर definitive statement देने के लिए पर्याप्त जानकारी नहीं है, तो स्पष्ट रूप से बताएं कि आप ऐसा कर रहे हैं, और hypothesis का आधार व logical foundation लिखते हुए hypothesis बना सकते हैं” जैसा लिखें, और अंत में उससे अपने answer को evaluate करवाएं

    • Prompts को abstract तरीके से develop नहीं करना चाहिए। Prompt का लक्ष्य model की internal representations को activate करके task को सबसे अच्छी तरह perform करवाना है
      अगर कोई automated method नहीं है, तो अलग-अलग inputs पर model responses को बार-बार test करके समझना होगा कि वह request को कैसे interpret करता है, कहां fail होता है, और उन gaps को भरना होगा। यहां तक कि यह भी verify करना होगा कि model को nothing का मतलब पता है या नहीं

  • LLM क्षेत्र की शीर्ष 3 सेवाओं की सदस्यता लेकर मैं अक्सर एक ही prompt डालकर देखता हूँ, और GPT-4 के पक्ष में नतीजा बहुत एकतरफा है। GPT-4 को आए 1 साल हो चुका है और इस बीच कई updates हुए हैं, यह मानकर भी यह हैरान करने वाला है
    कम से कम मेरे usage pattern में hallucination भी कम ही होता है। दूसरी तरफ Claude code लिखते समय ऐसे plausible API काफी आसानी से गढ़ देता है जो मौजूद ही नहीं होते। GPT-4 जब जानता है कि वह सही है, तो ज्यादा अड़ा रहता है और कम हामी भरता है। ये फर्क metrics में लगभग पकड़ में नहीं आते, इसलिए खुद इस्तेमाल करके ही दिखते हैं

    • मेरे मामले में Claude 3 Opus GPT-4 से बेहतर था। खासकर यह explanations बेहतर देता है, और उससे भी अहम, ज्यादा thorough तरीके से देता है
      Coding tasks में भी मैं इससे code लिखवाने के बजाय किसी topic या code की explanation मांगता हूँ, और यह कहीं ज्यादा nuanced जवाब देने की ओर झुकता है। लंबा text देकर बातचीत करने पर लगता है कि Claude Opus content को ज्यादा गहराई से समझता है; GPT-4 दिए गए text को summarize करने तक रहता है, जबकि Claude बेहतर ढंग से expand करके reasoning करता है
    • जिज्ञासा है कि तुलना Claude Opus से की गई थी, या किसी lower variant से। Opus मुझे English copy generation के लिए सचमुच पसंद है
    • GPT-4 खराब shape वाले, कम information वाले या बिखरे structure वाले prompts को बेहतर handle करता है। अगर बड़े prompt को समझदारी से structure न किया जाए, तो Claude confuse हो सकता है कि उससे मांगा क्या जा रहा है
      हालांकि well-structured prompts में Claude Opus GPT-4 से बेहतर output देने की ओर झुकता है। Claude ज्यादा flexible और लंबे answers देता है, जबकि ChatGPT/GPT-4 हमेशा अपने खास छोटे और “typical” जवाबों जैसा सुनाई देता है
    • मेरा अनुभव उल्टा रहा। मैं कई services subscribe करके वही सवाल copy-paste करता हूँ, और software development से जुड़े सवालों में Claude Opus इतना आगे है कि अब सोच रहा हूँ शायद GPT-4 इस्तेमाल करने की जरूरत ही न पड़े
      मांगे गए code examples में GPT-4 का बनाया code अक्सर compile तक नहीं होता था, और Claude में ऐसा लगभग कभी नहीं हुआ
    • मैं भी तीनों services subscribe करके इसी तरह compare करता हूँ। खासकर हर नए version के आने पर
      आजकल मेरा litmus test है: “Austin से 200 miles के अंदर 10 अनोखे bars बताओ”। यह सबके लिए बेहद मुश्किल है; GPT-4 कुछ हद तक करीब था, लेकिन Claude ने बस गढ़ दिया और Gemini पूरी तरह टूट गया

  • GPT बहुत शानदार है, लेकिन लेख के दो paragraphs की interpretation से मैं strongly agree नहीं करता
    यह summary दी जा सकती है कि “GPT, तुम 50 states को स्पष्ट रूप से जानते हो, इसलिए जिस state पर यह लागू होता है उसका पूरा नाम दो, या अगर यह US government से संबंधित है तो Federal जवाब दो” जैसी approach बेहतर थी
    लेकिन जब बात ज्यादा अस्पष्ट कही गई तो GPT की quality और generalization बेहतर होना उच्च-स्तरीय delegation/thinking का typical marker है—यह interpretation मुझे ज्यादा खिंची हुई लगती है। Natural language GPT के लिए सबसे probable output है, क्योंकि यह training text जैसी होती है। इस case में developer बस उस दिशा में ज्यादा झुका जहाँ GPT अच्छा है; उसने GPT से ज्यादा काम नहीं करवाया
    ऐसे कई simple tasks हैं जिनमें GPT fail हो जाता है। अक्षर बदलना, जानबूझकर typos डालना जैसे काम GPT के लिए बहुत मुश्किल हैं। ID mapping जैसी चीजें भी वैसी ही हैं, खासकर जब mapping training में देखी गई mapping से काफी अलग हो। उदाहरण के लिए non-ISO country codes जैसे मिलते-जुलते तीन-अक्षर codes
    दिलचस्प बात यह है कि GPT mapping को “समझता” है। मेरे हिसाब से वही बल्कि high-dimensional pattern matching का असली संकेत है

    • या फिर यह बस mapping को memorize कर रहा हो सकता है। मतलब यह नहीं कि हूबहू reproduce करता है, बल्कि उसके पास पहले देखी गई mapping जैसी vectors हैं

  • ‘null’ समस्या पर tip: LLM tokens output करने के लिए बनाए गए हैं, tokens output न करने के लिए नहीं
    इसलिए “कुछ भी return मत करो” कहने के बजाय, जब result न हो तो “XYZ का default value return करो” कहें, और फिर state name search की तरह result में उस default value, जैसे XYZ, को text search कर लें
    साथ ही system prompt बहुत उपयोगी हो सकते हैं। मूल रूप से यह LLM को X role-play कराने का मौका है। अच्छा होगा अगर system prompt को सीधे pass करने दिया जाए, फिर भी यह न होने से तो बेहतर है

  • GPT का 10 से ज्यादा JSON objects की list सही से return न कर पाना prompt problem है। मैंने इसे सही order में 200 तक reliably return करवाया है
    तरीका यह है कि list बिल्कुल इस्तेमाल न करें, और output में "item1": {...} जैसे JSON keys इस्तेमाल करें। जब किसी input के लिए 0~n outputs हो सकते हों, तो value के रूप में list इस्तेमाल की जा सकती है

    • उसे बता रहा हूँ कि user ऐसी culture से आता है जहाँ incomplete list में answer देना rude और insulting माना जाता है
    • अगर आप थोड़ा और विस्तार से समझा सकें तो अच्छा होगा। मैं अभी इसी समस्या से जूझ रहा हूँ
      GPT-4 को defined structure वाली existing items की list देकर schema conversion जैसे तरीके से JSON में बदलवाऊँ तो यह पूरे दिन अच्छे से करता है। लेकिन अगर किसी भी तरह की inference चाहिए और इसे essentially अपनी list बनानी हो, तो यह सिर्फ बहुत limited subset देता है
      दूसरे LLMs में भी similar problem है। आप कैसे approach करते हैं, यह जानने में बहुत रुचि है

  • “text block से company names extract करो” जैसे tasks को दो stages में बांट सकते हैं
    पहले पूछें, “क्या इस text block में कोई company mention हुई है?” अगर नहीं, तो null result मिल गया। अगर हाँ, तो पूछें, “इस text block में मौजूद company names list करो”

  • मैं personal writing app में OpenAI models इस्तेमाल कर रहा हूँ और यह लेख सच में accurate है। “prompt जितना कम, उतना बेहतर” वाले Lesson 1 से जुड़ी एक चीज मैंने सीखी है
    Notes के लिए intelligent search feature बनाते समय मैं चाहता था कि ChatGPT structured JSON data return करे। उदाहरण के लिए, “पिछले 2 सालों में Haskell mention करने वाले और draft के रूप में marked मेरे सभी notes दो” पूछकर ChatGPT से तय करवाना चाहता था कि क्या return करना है। यह सिर्फ कभी-कभी काम करता था
    इसके बजाय data को SQLite database में डालकर, ChatGPT को schema भेजा और desired results return करने वाली query लिखवाई, तो यह काफी बेहतर चला

    • यह LLM की तुलना में database और अच्छे search filters के लिए ज्यादा उपयुक्त लगता है
    • जिज्ञासा है कि आपने response_format=json_object try किया है या नहीं
      Structured responses पाने के लिए function calling ज्यादा fit थी, लेकिन सिर्फ JSON body लेने की तुलना में उसमें constraints ज्यादा हैं

  • बहुत precise instructions देने पर accuracy घटने का example, ऐसे systems कैसे काम करते हैं इस बारे में मेरी crude understanding के हिसाब से, समझ में आता है
    पूरी states list डालने का मतलब है कि हर state के vectors को किसी हद तक activate कर देना। अगर सिर्फ “state” कहें और pass किए गए text में कोई explicit state हो, तो जिस चीज़ को खोजना है उससे जुड़े कम vectors activate होते हैं। इसलिए softmax करते समय सही state चुने जाने की संभावना ज्यादा हो जाती है
    इसी संदर्भ में /n और comma comparison भी शायद tokenization difference की वजह से होने की संभावना ज्यादा है