Ask HN: मैं दिसंबर 2023 में अपने खुद के दस्तावेज़ों पर एक कस्टम LLM/ChatGPT कैसे ट्रेन करूँ?

जो developers अपने दस्तावेज़ों पर ChatGPT‑style models “train” करना चाहते हैं, वे increasingly पाते हैं कि full fine‑tuning की अक्सर ज़रूरत नहीं होती या वह cost‑effective नहीं है; इसके बजाय, ज़्यादातर practical solutions retrieval‑augmented generation (RAG) पर निर्भर करते हैं, जहाँ बाहरी data को index करके query time पर prompts में inject किया जाता है। प्रतिभागी LlamaIndex, LangChain, Haystack और कई hosted services (AWS Bedrock, Azure AI Studio, OpenAI Assistants, Notion, PrivateGPT, आदि) की तुलना करते हैं, और ease of use, cost, तथा openness को context‑window limits, chunking strategy, hallucinations, और vector database choices जैसी समस्याओं के खिलाफ तौलते हैं। एक recurring theme यह है कि RAG कई छोटे‑to‑medium corpora और enterprise search/chat use cases के लिए अच्छी तरह काम करता है, जबकि बहुत बड़े या अत्यधिक proprietary datasets को eventually continual pretraining या hybrid RAG + fine‑tuning जैसे more advanced approaches की ज़रूरत पड़ सकती है.

“अपने दस्तावेज़ों पर ट्रेनिंग” का आम तौर पर क्या मतलब होता है

  • कई टिप्पणीकार ज़ोर देते हैं कि जो ज़्यादातर उत्पाद “आपके docs पर ट्रेन” करने का दावा करते हैं, वे असल में RAG (retrieval‑augmented generation) कर रहे होते हैं, न कि असली fine‑tuning या pre‑training।
  • RAG flow: दस्तावेज़ ingest करना → chunk + embed → vector DB में store करना → हर query पर relevant chunks retrieve करना → उन्हें LLM prompt में डालना।
  • कहा जाता है कि raw documents पर true fine‑tuning ज़्यादातर style/patterns सिखाता है, भरोसेमंद factual recall नहीं; अगर fine‑tuning का उपयोग किया जाए तो Q&A style datasets की सिफारिश की जाती है।
  • कुछ लोग तर्क देते हैं कि RAG सही सामान्य तरीका है; एक अल्पसंख्यक इसे “fundamentally flawed” कहते हैं या इसे मुख्यतः छोटे datasets के लिए उपयुक्त मानते हैं।

Cloud और managed solutions

  • AWS Bedrock: knowledge bases (RAG) plus “continuous pre‑training”; इसे शक्तिशाली लेकिन महंगा माना गया, खासकर custom models और OpenSearch के साथ।
  • सुझाए गए विकल्प: OpenSearch की जगह pgvector/RDS का उपयोग; Pinecone एक सस्ता vector store के रूप में।
  • अन्य hosted options जिनका उल्लेख हुआ: Amazon Q, Azure AI Studio + Semantic Kernel, OpenAI Assistants API (built‑in RAG), Notion Q&A, NotebookLM, Office Copilot‑style builders, और विभिन्न SaaS tools।

Open‑source और local stacks

  • लोकप्रिय RAG frameworks: LlamaIndex (काफी सराहा गया), LangChain (bloated/unstable कहकर आलोचना), Haystack, Langroid, txtai, embedchain, Buster.
  • Turnkey/local apps: PrivateGPT, h2oGPT, Gpt4All, Verba, anything‑llm, Khoj, Cheshire Cat, GPT Researcher, secure RAG app layers.
  • कई लोग Ollama, llama.cpp, या इसी तरह के tools के ज़रिए local models चलाते हैं, अक्सर Mistral या Mixtral जैसे models का उपयोग करते हुए।

चर्चा किए गए तकनीकी challenges

  • Chunking strategy और metadata को RAG quality के लिए critical माना गया; naive fixed‑size chunks अक्सर बेहतर प्रदर्शन नहीं करते।
  • Scaling issues: बड़े corpora के साथ, context window में केवल कुछ chunks ही आते हैं; long‑context models मदद करते हैं लेकिन “lost in the middle” concerns रहती हैं।
  • Hybrid retrieval (vector + BM25/lexical) की सिफारिश की जाती है, खासकर acronyms और domain jargon के लिए।
  • Hallucinations अभी भी अनसुलझी हैं; सबसे अच्छे mitigations हैं tight prompts, retrieval constraints, और evaluation/monitoring।
  • Multi‑language RAG multilingual embedding models पर निर्भर करता है; typos/OOV terms को आंशिक रूप से subword tokenization और embedding similarity से संभाला जाता है।

Costs, hardware, और practicality

  • Hosted fine‑tuning और custom models की लागत प्रति माह हज़ारों डॉलर तक हो सकती है, जिसे hobbyists के लिए prohibitive माना गया।
  • Off‑the‑shelf models + RAG + सस्ते vector stores को अधिकांश use cases के लिए व्यावहारिक रास्ता बताया गया है।