Contextual Retrieval तकनीक

 (anthropic.com)
3 पॉइंट द्वारा GN⁺ 2024-09-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कार्यस्थल के knowledge-based AI में इस्तेमाल होने वाला RAG दस्तावेज़ों को छोटे chunks में बाँटते समय company name, समय-संदर्भ जैसे context खो सकता है, जिससे संबंधित जानकारी छूट सकती है
  • Anthropic का Contextual Retrieval हर chunk के आगे पूरे दस्तावेज़ के आधार पर एक छोटा विवरण जोड़ता है, फिर embedding और BM25 index बनाता है ताकि retrieval failure rate कम हो सके
  • प्रयोगों में Contextual Embeddings ने top-20 chunk retrieval failure rate को 5.7% से 3.7% तक, यानी 35% कम किया, और Contextual Embeddings व Contextual BM25 के संयोजन ने इसे 2.9% तक, यानी 49% कम किया
  • reranking जोड़ने पर top-150 candidates को फिर से score किया जाता है और केवल top-20 model तक भेजे जाते हैं, जिससे retrieval failure rate 5.7% से 1.9% तक, यानी 67% घट गया
  • अगर knowledge base 200,000 tokens से कम है, तो पूरा content prompt में डालना भी संभव है, लेकिन बड़े knowledge base में Contextual Retrieval और reranking के संयोजन को use case के अनुसार evaluate करना चाहिए

RAG दस्तावेज़ का context कैसे खो देता है

  • किसी खास काम में AI model को उपयोगी बनने के लिए background knowledge तक पहुँच चाहिए
    • customer support chatbot को उस business का ज्ञान चाहिए
    • legal analysis bot को पुराने case law का ज्ञान चाहिए
  • developers आमतौर पर Retrieval-Augmented Generation(RAG) से model knowledge को बढ़ाते हैं
    • knowledge base से संबंधित जानकारी retrieve की जाती है
    • retrieved जानकारी को user prompt में जोड़कर model response बेहतर किया जाता है
  • पारंपरिक RAG दस्तावेज़ों को chunks में बाँटते समय context हटा देता है, इसलिए वह संबंधित जानकारी खोजने में विफल हो सकता है
  • Contextual Retrieval, RAG के retrieval stage को बेहतर करने का तरीका है, और इसकी दो sub-techniques साथ में इस्तेमाल की जा सकती हैं
    • Contextual Embeddings: context जोड़े गए chunks से embeddings बनती हैं
    • Contextual BM25: context जोड़े गए chunks से BM25 index बनता है
    • यह संयोजन retrieval failures को 49% कम करता है, और reranking के साथ मिलकर इसे 67% तक घटाता है
  • Claude पर Contextual Retrieval deploy करने के लिए एक cookbook उपलब्ध है

छोटे knowledge base में long prompt भी संभव है

  • अगर knowledge base 200,000 tokens से कम, यानी लगभग 500 पन्नों से छोटा है, तो RAG के बिना पूरा knowledge base prompt में डाला जा सकता है
  • Claude का prompt caching इस approach को तेज़ और cost-efficient बनाता है
    • अक्सर इस्तेमाल होने वाले prompts को API calls के बीच cache किया जा सकता है
    • latency को 2x से अधिक कम किया जा सकता है
    • cost को अधिकतम 90% तक घटाया जा सकता है
    • यह कैसे काम करता है, इसे prompt caching cookbook में देखा जा सकता है
  • knowledge base बड़ा होने पर अधिक scalable retrieval method की ज़रूरत होती है, और वहीं Contextual Retrieval काम आता है

सामान्य RAG और BM25 की भूमिका

  • जब बड़ा knowledge base context window में नहीं समाता, तब सामान्य समाधान RAG होता है
  • RAG का preprocessing flow इस प्रकार है
    • document corpus को आमतौर पर कुछ सौ tokens से छोटे text chunks में बाँटा जाता है
    • embedding model chunks को अर्थ-संरक्षित vector embeddings में बदलता है
    • embeddings को vector database में store किया जाता है, जहाँ semantic similarity search संभव होती है
  • runtime पर user query के अर्थ से सबसे मिलते-जुलते chunks vector database से निकाले जाते हैं, और relevant chunks को generative model prompt में जोड़ दिया जाता है
  • embedding models semantic relation को अच्छी तरह पकड़ते हैं, लेकिन exact string match छूट सकता है
  • BM25(Best Matching 25) एक ranking function है जो lexical match का उपयोग करता है, और unique identifiers या technical terms वाली queries में खास तौर पर प्रभावी है
    • BM25, TF-IDF की अवधारणा पर आधारित है
    • TF-IDF यह मापता है कि किसी collection में कोई शब्द किसी document के लिए कितना महत्वपूर्ण है
    • BM25 document length को ध्यान में रखता है और term frequency पर saturation function लागू करता है, ताकि सामान्य शब्द परिणामों पर हावी न हों
  • उदाहरण के लिए, यदि technical support database में "Error code TS-999" खोजा जाए, तो embedding model सामान्य error code documents ढूँढ सकता है, लेकिन सटीक "TS-999" match छूट सकता है
  • BM25 उस string को सीधे खोजकर संबंधित document की पहचान करता है

embeddings और BM25 को साथ इस्तेमाल करने वाला RAG

  • RAG, embeddings और BM25 को जोड़कर अधिक सटीक chunks retrieve कर सकता है
    • knowledge base को छोटे chunks में बाँटा जाता है
    • हर chunk के लिए TF-IDF encoding और semantic embedding बनाई जाती है
    • BM25 exact-match आधारित शीर्ष chunks खोजता है
    • embedding semantic similarity आधारित शीर्ष chunks खोजती है
    • rank fusion तकनीक से परिणामों को मिलाकर duplicates हटाए जाते हैं
    • top K chunks को prompt में डालकर response generate किया जाता है
  • यह तरीका exact term match और व्यापक semantic understanding के बीच संतुलन बनाता है
  • यह single prompt में न समाने वाले विशाल knowledge base तक cost-efficient तरीके से scale हो सकता है
  • लेकिन मौजूदा RAG systems दस्तावेज़ों को chunks में तोड़ते समय context नष्ट करने की सीमा रखते हैं
  • SEC filings पर आधारित knowledge base में "What was the revenue growth for ACME Corp in Q2 2023?" पूछना इसका एक अच्छा उदाहरण है
    • संबंधित chunk में सिर्फ "The company's revenue grew by 3% over the previous quarter." हो सकता है
    • केवल इस chunk से यह स्पष्ट नहीं होता कि किस company और किस समयावधि की बात हो रही है
    • retrieval और usage, दोनों चरणों में सही जानकारी का उपयोग कठिन हो जाता है

Contextual Retrieval कैसे काम करता है

  • Contextual Retrieval हर chunk को embed करने और BM25 index बनाने से पहले उसके आगे chunk-specific contextual description जोड़ता है
    • embedding पर लागू करने पर यह Contextual Embeddings बनता है
    • BM25 index पर लागू करने पर यह Contextual BM25 बनता है
  • SEC filing उदाहरण में मूल chunk इस प्रकार है
The company's revenue grew by 3% over the previous quarter.
  • context जोड़े जाने पर chunk इस तरह बदल जाता है
This chunk is from an SEC filing on ACME corp's performance in Q2 2023; the previous quarter's revenue was $314 million. The company's revenue grew by 3% over the previous quarter.
  • retrieval सुधारने के लिए context के उपयोग पर पहले भी कई तरीके प्रस्तावित किए गए हैं
  • ये तरीके Contextual Retrieval के chunk-by-chunk context जोड़ने वाले तरीके से अलग हैं

Claude से chunk context बनाना

  • हज़ारों या लाखों chunks पर मनुष्यों से manually annotation कराना व्यावहारिक नहीं है
  • Anthropic ने Claude के लिए ऐसा prompt बनाया जो पूरे document context के आधार पर हर chunk के लिए छोटा, chunk-specific context लिखता है
  • Claude 3 Haiku के लिए इस्तेमाल किया गया prompt इस प्रकार है
<document>
{{WHOLE_DOCUMENT}}
</document>
Here is the chunk we want to situate within the whole document
<chunk>
{{CHUNK_CONTENT}}
</chunk>
Please give a short succinct context to situate this chunk within the overall document for the purposes of improving search retrieval of the chunk. Answer only with the succinct context and nothing else.
  • उत्पन्न context text आमतौर पर 50~100 tokens का होता है, और इसे chunk के आगे जोड़कर embedding तथा BM25 index generation में इस्तेमाल किया जाता है
  • prompt caching का उपयोग करने पर हर chunk के लिए reference document फिर से भेजने की ज़रूरत नहीं पड़ती
    • document को एक बार cache में रखा जाता है और पहले से cached content को refer किया जाता है
    • यदि 800-token chunk, 8k-token document, 50-token context instruction, और प्रति chunk 100-token context मानें, तो contextualized chunk generation की one-time cost प्रति 10 लाख document tokens पर $1.02 होती है

प्रयोग की विधि और retrieval performance

  • प्रयोग कई knowledge domains, embedding models, retrieval strategies और evaluation metrics पर किए गए
    • codebase
    • novel
    • ArXiv paper
    • scientific paper
  • हर domain के question-answer examples Appendix II में शामिल हैं
  • graph सभी knowledge domains का average performance दिखाता है, जिसमें शीर्ष embedding configuration Gemini Text 004 और top-20 chunk retrieval का उपयोग किया गया
  • evaluation metric 1 - recall@20 है
    • यह मापता है कि top 20 chunks में relevant document retrieve न हो पाने की दर क्या है
  • कुल परिणामों में evaluate किए गए सभी embedding-source combinations ने contextualization लागू करने पर बेहतर performance दिखाई
  • performance improvement के परिणाम इस प्रकार हैं
    • Contextual Embeddings: top-20 chunk retrieval failure rate 5.7% → 3.7%, यानी 35% कम
    • Contextual Embeddings + Contextual BM25: retrieval failure rate 5.7% → 2.9%, यानी 49% कम

implementation के समय ध्यान रखने योग्य बातें

  • chunk boundaries retrieval performance को प्रभावित कर सकती हैं
    • chunk size
    • chunk boundaries
    • chunk overlap
  • Contextual Retrieval ने test किए गए सभी embedding models में performance सुधारी, लेकिन सुधार की मात्रा model के अनुसार अलग हो सकती है
    • Gemini embeddings और Voyage embeddings विशेष रूप से प्रभावी रहे
  • दिया गया सामान्य prompt अच्छी तरह काम करता है, लेकिन domain या use case के अनुसार custom contextualizer prompt और बेहतर परिणाम दे सकता है
    • उदाहरण: ऐसे key terms की glossary शामिल करना जो knowledge base के अन्य documents में ही define किए गए हों
  • context window में अधिक chunks डालने से relevant जानकारी शामिल होने की संभावना बढ़ती है
    • लेकिन बहुत अधिक जानकारी model को distract कर सकती है, इसलिए इसकी सीमा है
    • 5, 10, 20 chunks देकर देखने पर 20 chunks का performance सबसे अच्छा था
    • वास्तविक use case में experiment करना ज़रूरी है
  • response generation के लिए contextualized chunks भेजना, और यह अलग दिखाना कि कौन-सा हिस्सा context है और कौन-सा मूल chunk, सुधार ला सकता है
  • हमेशा evaluation चलाना चाहिए

reranking से अतिरिक्त सुधार

  • reranking बड़े knowledge base में शुरुआती retrieval से मिले candidate chunks में से सबसे relevant chunks ही model को भेजने की filtering technique है
  • यह चरण model द्वारा process की जाने वाली जानकारी कम करता है, इसलिए response quality, cost और latency पर असर डाल सकता है
  • प्रक्रिया इस प्रकार है
    • initial retrieval से संभावित रूप से relevant शीर्ष chunks लाए जाते हैं
    • प्रयोग में top 150 का उपयोग किया गया
    • शीर्ष N chunks और user query को reranking model को दिया जाता है
    • reranking model हर chunk को relevance और importance score देता है
    • top K chunks चुने जाते हैं
    • प्रयोग में top 20 का उपयोग किया गया
    • चुने गए chunks को model context में डालकर अंतिम परिणाम बनाया जाता है
  • प्रयोग Cohere reranker के साथ किया गया
  • Voyage reranker भी है, लेकिन उसे test करने का समय नहीं था
  • विभिन्न domains में reranking चरण जोड़ने से retrieval और बेहतर optimize होता है
  • Reranked Contextual Embedding + Contextual BM25 ने top-20 chunk retrieval failure rate को 5.7% → 1.9%, यानी 67% कम किया

cost और latency का संतुलन

  • reranking runtime में एक अतिरिक्त चरण जोड़ता है, इसलिए थोड़ा latency बढ़ना स्वाभाविक है
  • भले ही reranking model सभी chunks को parallel score करे, latency और cost पर उसके प्रभाव को ध्यान में रखना चाहिए
  • अधिक chunks rerank करने से performance सुधर सकती है, लेकिन cost और latency भी बढ़ती है
  • कम chunks rerank करने से cost और latency घटती है, लेकिन performance improvement कम हो सकता है
  • सही संतुलन खोजने के लिए खास use case में कई settings के साथ experiment करना चाहिए

संयोजन करने पर परिणाम

  • कई dataset types में embedding model, BM25 के उपयोग, Contextual Retrieval के उपयोग, reranking के उपयोग, और top-K retrieval counts के संयोजनों की तुलना की गई
  • परिणामों का सार इस प्रकार है
    • Embeddings + BM25, केवल embeddings से बेहतर है
    • test की गई embeddings में Voyage और Gemini सबसे अच्छे रहे
    • model को top-20 chunks देना, top-10 या top-5 से अधिक प्रभावी है
    • chunks में context जोड़ने से retrieval accuracy में बड़ा सुधार होता है
    • reranking, reranking न इस्तेमाल करने की तुलना में बेहतर है
    • अधिकतम performance improvement के लिए Voyage या Gemini आधारित Contextual Embeddings, Contextual BM25, reranking चरण, और prompt में 20 chunks जोड़ने का संयोजन किया जा सकता है
  • developers इस approach को Contextual Retrieval cookbook से प्रयोग कर सकते हैं

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

1 टिप्पणियां

 
GN⁺ 2024-09-22
Hacker News की राय

  • सरकारी एजेंसियों के लिए enterprise RAG बना रहा/रही हूं। RAGAS metrics से experimental A/B test करके देखा तो synthetic evaluation questions के आधार पर hybrid search (semantic search + vector) के बाद LLM-based reranking जोड़ने से कोई बड़ा बदलाव नहीं हुआ, और HyDE ने answer quality और search quality को काफ़ी गिरा दिया
    अभी expert questions और असली user questions के साथ RAGAS evaluation और करनी बाकी है
    इसलिए production/enterprise RAG में hybrid search हमेशा अच्छी होती है—यह कोई नई बात नहीं है, लेकिन एक तरीका हमेशा नहीं जीतता। हमारे मामले में vector similarity के साथ दूसरे तरीके के रूप में सिर्फ़ Azure AI Search की semantic search ही काफ़ी थी। दूसरी जगहों पर BM25 या fine-tuned query post-processing small language model बेहतर हो सकता है, इसलिए आखिरकार use case के हिसाब से लगातार test करना होगा
    आगे RAPTOR, SelfRAG, agentic RAG, query improvement (expansion और sub-queries), GraphRAG आज़माने का प्लान है
    अब तक की सीख यह है कि baseline और experiment group रखकर RAGAS जैसे metrics से null hypothesis को खारिज करने की कोशिश करनी चाहिए, और evaluation questions/answers के लिए तीन तरह के data इस्तेमाल करने चाहिए: experts द्वारा लिखे Q&A, logs से मिले real user questions, और source documents से generated synthetic Q&A

    • क्या comments में लिखे acronyms समझा सकते हैं या explanation links दे सकते हैं?
    • HippoRAG को आप कैसे देखते हैं, यह जानने की उत्सुकता है। क्या इसे पहले ही आज़माया है या आगे try करने का plan है?

  • इस तरीके में मुझे सबसे अच्छी बात यह लगती है कि यह prompt caching का अच्छा इस्तेमाल करता है
    cached prompts की लागत आमतौर पर सामान्य cost का लगभग 1/10 होती है, इसलिए हर chunk को पूरे original document के साथ चलाने जैसी तरकीब पहले cost के लिहाज़ से समझ में नहीं आती थी, लेकिन अब संभव हो गई है
    caching से cost कम होने के कारण इस तरह की और भी अच्छी techniques खुलेंगी, ऐसा लगता है
    contextual retrieval memo: https://simonwillison.net/2024/Sep/20/introducing-contextual... और prompt caching memo: https://simonwillison.net/2024/Aug/14/prompt-caching-with-cl...

    • मैं blog follow करता/करती हूं और LLM से जुड़े लगभग सारे posts पढ़ता/पढ़ती हूं। कई LLMs और features explore करने में monthly cost लगभग कितनी आती है, यह जानना चाहूंगा/चाहूंगी
      latest models और features के साथ बने रहने के लिए कितना खर्च करना पड़ता है, इसका अंदाज़ा लगाने में यह useful context होगा
    • embeddings के लिए बहुत कुछ पहले से calculate किया जा सकता है। cache करने की ज़रूरत नहीं, pre-compute कर सकते हैं, और तब ETL में आम तौर पर इस्तेमाल होने वाली कई techniques इसमें आ सकती हैं
      traditional search background से देखें तो RAG को off-the-shelf embedding models और vector search तक सीमित रखना काफी naive strategy जैसा लगता है। vector search अपने आप में उतनी अच्छी नहीं है, और LLM को दिया जाने वाला context बेहतर करने के लिए अतिरिक्त information retrieval strategies चाहिए। यहां जो हो रहा है, असल में वही है
      Microsoft ने पहले Graph RAG paper निकाला था, जिसमें index data से entity extraction द्वारा बनाए गए concept graph के आधार पर RAG और vector search को combine किया गया था। इससे matched chunks में contextually relevant information खींचकर लाई जा सकती है
      मुझे लगता है कि vector search के बिना भी काफी दूर तक जाया जा सकता है। cost भी बहुत सस्ती हो जाती है। बस traditional search engine और well-tuned queries इस्तेमाल करें। बेशक key query tuning है, और यह general-purpose cases में शायद अच्छा fit न हो, लेकिन ज़्यादा specialized cases में काम कर सकता है
    • cost भी एक पहलू है, लेकिन ingestion time का क्या? क्या यह तरीका pipeline में काफ़ी processing time नहीं जोड़ता?

  • संदर्भ जोड़ें तो, यह approach इतनी नई नहीं है। RAG results सुधारने के common तरीकों में से एक है LLM से base chunks को “expand” कराना, ताकि match होने वाला semantic surface area बढ़े
    HyDE[1] से query expansion चलाने पर और सुधार हो सकता है, लेकिन यह हमेशा बेहतर नहीं होता, इसलिए मैं इसे alternate path के रूप में इस्तेमाल करता/करती हूं
    Anthropic ने यहां क्या नया पेश किया है, यह मुझे साफ़ नहीं है। cookbook code देखने पर भी वह सिर्फ़ उस context को बनाने की प्रक्रिया दिखाता है, और “contextual search” के लिए API में वास्तव में कोई बदलाव नहीं है
    जो बदला है, वह एक महीने पहले introduce की गई prompt caching है, जिससे लंबे document को पूरा context के रूप में देकर individual chunks में बेहतर context बहुत सस्ते में जोड़ा जा सकता है। caching developers के लिए public करने लायक शानदार feature है और इसकी value मानता/मानती हूं
    लेकिन इसके अलावा यह एक specific RAG workflow दिखाने वाला cookbook ही लगता है
    जोड़ना चाहूंगा/चाहूंगी कि Cohere मेरे द्वारा इस्तेमाल किए गए APIs में सबसे पसंदीदा में से है। मेरा उनसे कोई संबंध नहीं है, और Cohere RAG API दूसरे providers के मुकाबले बहुत अच्छी थी। ज़ोरदार recommendation
    1: https://arxiv.org/abs/2212.10496

    • innovation शायद इस approach की cost को affordable बनाने के लिए caching इस्तेमाल करने में है। implementation का तरीका यह है कि chunks बनाते समय हर बार LLM से पूरे context से atomic chunk बनाने को कहा जाता है
      data में tens of thousands chunks हों तो यह सब करना पड़ता है, इसलिए cost बहुत आती है। documents cache करने से वह cost घटाई जा सकती है
    • करीब एक महीने पहले Prompt Caching से यह करने की कोशिश की थी, लेकिन देखा कि cached prompt की maximum lifetime 5 minutes है
      मेरी RAG requirements के लिए यह ठीक नहीं बैठता, और शायद ज़्यादातर के लिए भी ऐसा ही होगा। क्योंकि query अगले महीने या 1 साल बाद चल सकती है। वह policy बदली हुई भी नहीं लगती, इसलिए RAG के संबंध में Prompt Caching की बात करना थोड़ा surprising है

  • हम भी कुछ ऐसा ही कर रहे हैं। पहले दस्तावेज़ को h1, h2, h3 शीर्षकों के आधार पर chunks में बांटते हैं, और chunk की शुरुआत में header को context के तौर पर जोड़ देते हैं
    एक काल्पनिक उदाहरण में, अगर मूल chunk था “वयस्कों के लिए सामान्य खुराक 200mg टैबलेट या कैप्सूल 1–2, दिन में 3 बार” तो अब उसके पहले # Fever, ## Treatment, separator line, और फिर वही सामग्री आती है
    यह काफ़ी अच्छे से काम करता लगता है, और दस्तावेज़ index करते समय LLM की भी ज़रूरत नहीं पड़ती

    • मैं हमेशा सोचता था कि LLM कैसे जानता है कि कोई लंबा लेख या audio transcript Alan Watts ने लिखा है या नहीं। इस तरह की metadata annotations Llama जैसे models के training data तैयार करते समय आम रही होंगी
      शायद यही “ChatGPT दिसंबर में धीमा हो गया” वाली बहस की शुरुआत भी हो सकती है। यानी वह “date” metadata ChatGPT को यह बताता होगा कि वह कम मददगार हो
    • मैं 100 से ज़्यादा pages वाले लंबे documents या document bundles पर आधारित question answering पर काम कर रहा हूँ, और मिलता-जुलता approach अपनाया है
      पहले हर page का summary बनाकर title देता हूँ और sub-section list extract करता हूँ। फिर सभी summaries को मिलाकर model से hierarchical index बनाने को कहता हूँ। Model पूरे bundle को tree में व्यवस्थित करता है, और query के समय tree के अंदर का path अतिरिक्त context के तौर पर जोड़ दिया जाता है
    • जिज्ञासा है कि शामिल किए गए headers को किस format में डालना है, इसके लिए आपने अलग-अलग तरीकों से experiment किया है या नहीं। मैं भी कुछ ऐसा ही कर रहा हूँ, इसलिए पूछ रहा हूँ

  • यह technique मुझे ख़ास पसंद नहीं है। दिए गए scenario के आम समस्या होने से सहमत हूँ, लेकिन सुझाया गया solution थोड़ा अटपटा लगता है
    vector embeddings में bag-of-words compression जैसी property होती है, और वे पहले newline text block पर ज़रूरत से ज़्यादा index हो सकती हैं। नतीजतन vector का कोई खास index पहले की तुलना में 0 के काफ़ी करीब आ जाता है। quantization के बाद वह आखिरकार 0 हो सकता है, जिससे dense vector की precision काफ़ी खो सकती है। IDF search कुछ हद तक इसकी भरपाई करता है, लेकिन पर्याप्त नहीं
    अगर embedding को “semantically boost” करके document title, summary, abstract वगैरह के ज़्यादा करीब ले जाया जाए, तो इस “context” prefix का recall benefit मिल सकता है और base vector दूषित भी नहीं होगा। implementation के लिहाज़ से यह weighted sum है। augmentation stage में context window में डालते समय अगर document match हो जाए, तो summary chunk को भी साथ inject किया जा सकता है। निजी तौर पर यह मुझे कहीं ज़्यादा साफ़ solution लगता है
    Trieve API में “semantic boost” का description[1]:
    semantic_boost: chunk के embedding vector को distance phrase की दिशा में move करने के लिए उपयोगी। उदाहरण के लिए, जिस chunk का chunk_html iphone है, उसे distance_phrase के रूप में flagship और distance_factor के रूप में 0.25 इस्तेमाल करके “flagship” term के 25% और करीब धकेला जा सकता है। conceptually, यह chunk_html के innerText vector और distance_phrase vector के बीच Euclidean/L2 distance line खींचता है, और उस line के साथ chunk_html vector को distance_factorL2Distance जितना और करीब या दूर move करता है
    [1]:https://docs.trieve.ai/api-reference/chunk/create-or-upsert-...

    • थोड़ा हटकर सवाल है, लेकिन क्या vector databases models के बीच compatible होते हैं? मेरी समझ में embeddings model-specific होती हैं, इसलिए शायद नहीं
      तो क्या इसका मतलब है कि vector DB एक ही LLM, बल्कि Claude-3.5 Sonnet जैसे एक specific version से बंध जाती है, और उसे 3.5 Haiku या Opus पर भी नहीं ले जा सकते; ChatGPT या Llama पर जाना हो तो re-indexing करनी पड़ेगी?

  • मेरे हिसाब से सबसे उपयोगी technique है linked-list strategy implement करना, जहां chunk के पास उन items के कई pointers होते हैं जो उसे refer करते हैं। यह काम मैं manually करता हूँ, लेकिन किसी specific node को refer करने के तरीकों की variety काफ़ी बढ़ जाती है
    दूसरे तरीके से देखें तो यह comments जैसा है। इस article के नीचे के सभी comments को original post की ओर इशारा करने वाले pointers माना जा सकता है। कुछ comments मूल पोस्ट से semantic distance में करीब होते हैं, और कुछ लेखक की perception की वजह से दूर। लेकिन अगर हर comment को parent_id दे दें, तो original post तक पहुंचने के paths बढ़ जाते हैं
    इस technique का example यहां देखा जा सकता है [1]। end user कौन-सी query करेगा, यह guess करने की कोशिश नहीं करते; बस user को बोलने देते हैं और फिर उसे pointer के रूप में index करते हैं। किसी object को represent करने के options सीमित होते हैं, लेकिन कुछ representations core object के meaning से बहुत, बहुत, बहुत दूर होते हैं
    [1] - https://x.com/yourcommonbase/status/1833262865194557505

  • छोटे datasets में best answer पाने के लिए 200k tokens बस डाल देना चाहिए—यह बात मेरे अनुभव से मेल नहीं खाती
    prompt जितना बड़ा होता है, मैंने अक्सर देखा है कि output की consistency घटती है और instruction following भी खराब होती है। यहां तक कि 25k tokens से काफ़ी कम range में भी ऐसा होता लगता है। जानना चाहूंगा कि क्या दूसरों को भी ऐसा अनुभव होता है, और क्या इससे बचने के कोई well-known तरीके हैं

  • दिलचस्प। मेरी समस्या यह है कि RAG से knowledge chunks नहीं, बल्कि लागू हो सकने वाले rules खोजने हैं। संदर्भ में सिर्फ वही rules inject करने चाहिए जो उस context पर लागू हो सकते हैं
    मैंने अभी प्रयोग नहीं किया है, लेकिन मुझे लगता है कि यह तरीका काम कर सकता है: एक छोटा classifier train किया जाए जो तय करे कि कोई खास rule लागू हो सकता है या नहीं। मुख्य LLM की भूमिका यह तय करना होगी कि मौजूदा context में वह rule सचमुच लागू होता है या नहीं
    उदाहरण के लिए मान लें कि हम LLM के साथ multi-user dungeon game खेल रहे हैं। पहले किसी character ने taxi से जुड़ी कोई खराब हरकत की थी, इसलिए game ने यह rule बनाया: “जब भी वह taxi में बैठने की कोशिश करेगा, उसे बाहर निकाल दिया जाएगा। ‘हमें पता है आप कौन हैं, और जब तक आप taxi company के director से औपचारिक माफी नहीं मांगते, हम आपको customer के रूप में स्वीकार नहीं करेंगे’।” माफी मांगने पर rule हट जाएगा। taxi company का director कोई दूसरा player भी हो सकता है, या वह व्यक्ति हो सकता है जिसने अपने NPC taxi fleet द्वारा enforce किए जाने वाले rule को पहली बार trigger किया हो
    मुझे उत्सुकता है कि active rules की संख्या के आधार पर यह कितना scale करेगा, और traditional RAG को किस हद तक लागू किया जा सकेगा। कोई rule लागू होता है या नहीं, यह तय करना किसी knowledge chunk के relevant होने का निर्णय करने से ज्यादा abstract और कठिन समस्या लगता है
    खास तौर पर इसे और कठिन बनाने वाली मुख्य बात dependency loop है, जो knowledge search में नहीं होती। rule लागू होता है या नहीं, यह पहचानने के लिए पहले उस rule को retrieve करना होगा। इस समस्या को कैसे हल किया जा सकता है?

    • अगर in-game context query में सही ढंग से वर्णित हो, तो RAG में इस्तेमाल होने वाली traditional vector search इस मामले में भी ठीक लगती है
      उदाहरण query LLama 3.1 8B की मदद से लिखी जाए तो इसे पर्याप्त detail में कुछ इस तरह लिखा जा सकता है: dark elf army पास आ रही है, Grimgold Ironfist हताश स्थिति में है, वह पहले dwarf militia का गर्वित सदस्य था लेकिन अब उसकी health 35% है, inventory में एक पुरानी pickaxe, water bucket, बासी bread और 17 gold coins हैं, और Taxi Guild के साथ “problematic past” के बावजूद वह सड़क पर taxi रोकने की कोशिश कर रहा है
      vector store से retrieve होने वाले rule के उदाहरण में character name/attributes और taxi तथा Taxi Guild के उल्लेखों की वजह से vector proximity बनेगी और वह search में आ जाएगा
      rule कुछ ऐसा होगा: “Taxi Guild ने Grimgold पर कठोर penalty लगाई है। जब भी वह taxi रोकने की कोशिश करेगा, उसे तुरंत vehicle से बाहर निकाल दिया जाएगा। Guild के edict में लिखा है: ‘Grimgold Ironfist, बदनाम दाढ़ी वाला dwarf, Golden Horse Cab Company के director Thorgrim Stonebeard से औपचारिक माफी मांगने तक members द्वारा चलाई जाने वाली किसी भी taxi में सवारी नहीं कर सकता। इसका पालन न करने पर हमारी services से स्थायी रूप से ban कर दिया जाएगा’”

  • वे कहते हैं, “अगर knowledge base 200,000 tokens से छोटा है (लगभग 500 pages)”, तो मेरी इच्छा है कि Anthropic बस tokenizer public कर दे। ताकि हमें अनुमान न लगाना पड़े

    • response को token unit में stream किया जाता है, तो क्या reverse engineering संभव नहीं होगी?

  • उस दिन का इंतजार कर रहा हूं जब पूरी AI industry एक चक्कर लगाकर आखिरकार TF-IDF पर वापस आ जाएगी

    • सही, मुझे भी यह थोड़ा funny लगा। elasticsearch जैसे products वैसे भी classic text matching algorithms को default तौर पर support करते होंगे, ऐसा लगता है