MCP + RAG: ஏன் நான் சிக்கலான RAG அமைப்புகளை உருவாக்குவதை நிறுத்தினேன்

சிக்கலான RAG அமைப்புகளை உருவாக்குவதில் நான் நான்கு ஆண்டுகள் செலவிட்டேன்.

நான் chunking உத்திகள், embedding மாதிரிகள், vector தரவுத்தளங்கள் மற்றும் rerankers ஆகியவற்றைப் பயன்படுத்தினேன். எனது 1,800 மணிநேர அறிவுத் தளத்திற்காக (knowledge base) ஒரு அமைப்பை உருவாக்கினேன். ஒவ்வொரு முறையும், நான் அதைச் சரியாகச் செய்துவிட்டதாக நினைத்தேன்.

அது ஒருபோதும் சிறப்பாகச் செயல்படவில்லை.

பிறகு நான் Model Context Protocol (MCP) ஆதரவைச் சேர்த்தேன். அது அனைத்தையும் மாற்றியமைத்தது. MCP பெரும்பாலான மக்களுக்குப் பாரம்பரியமான சிக்கலான RAG முறையைத் தேவையில்லாத ஒன்றாக மாற்றிவிடுகிறது.

நான் இத்தகையப் பிரச்சனைகளை எதிர்கொண்டேன்:

  • semantic அல்லது recursive chunking ஆகியவற்றிற்கு இடையே தேர்ந்தெடுப்பது.
  • OpenAI, Cohere, அல்லது Nomic embeddings ஆகியவற்றிற்கு இடையே ஒன்றைத் தேர்ந்தெடுப்பது.
  • Pinecone, Weaviate, அல்லது Chroma ஆகியவற்றிற்கு இடையே முடிவெடுப்பது.
  • top-k retrieval மற்றும் reranking-ஐ நிர்வகிப்பது.

எனது RAG அமைப்பு 2,000 வரிகள் கொண்ட குறியீடாக (code) வளர்ந்தது. அது பார்ப்பதற்குத் திகைப்பூட்டும் வகையில் இருந்தது, ஆனால் தோல்வியடைந்தது. AI ஏற்கனவே புத்திசாலியாக இருந்தபோது, எனது தரவை நான் புத்திசாலியாக மாற்ற முயன்றேன்.

நான் MCP அணுகுமுறைக்கு மாறினேன். வெறும் 150 வரிகள் கொண்ட குறியீட்டில் ஒரு சர்வரை உருவாக்கினேன்.

நான் AI-க்கு இரண்டு கருவிகளை மட்டுமே வழங்கினேன்:

  • search_notes: குறிப்புகளைக் கண்டறிய எளிய உரைப் பொருத்தத்தைப் (text matching) பயன்படுத்துகிறது.
  • get_note_content: ஒரு குறிப்பின் முழு உரையையும் வழங்குகிறது.

எந்த chunk-களும் இல்லை. சிக்கலான embeddings இல்லை. vector தரவுத்தளங்கள் இல்லை.

இந்த எளிய அணுகுமுறை, எனது ஆடம்பரமான RAG அமைப்பை 10 முறைக்கு 9 முறை தோற்கடிக்கிறது. அதற்கான காரணங்கள் இதோ:

  1. AI தர்க்கத்தைக் (logic) கையாள்கிறது. ஒரு முன்கூட்டியே அமைக்கப்பட்ட chunker-ஐ விட, எது பொருத்தமானது என்பதைத் தீர்மானிப்பதில் AI சிறந்தது.
  2. முழுமையான சூழல் (Full context). பாரம்பரிய RAG குறிப்புகளைச் சிறிய துண்டுகளாகப் பிரிக்கிறது. இதனால் பெரும்பாலும் சரியான விடை கிடைக்காமல் போகலாம். MCP மூலம், AI முழு குறிப்பையும் வாசிக்கிறது. அது முழுமையான கருத்தைப் புரிந்துகொள்கிறது.
  3. கணிக்கக்கூடிய தன்மை (Predictability). உரைத் தேடல் (Text search) எளிமையானது. முக்கியச் சொல் (keyword) இருந்தால், அது வேலை செய்யும். நீங்கள் embedding drift மற்றும் dimension பிழைகளைத் தவிர்க்கலாம்.

நீங்கள் பின்வரும் சூழல்களில் பாரம்பரிய RAG-ஐப் பயன்படுத்தலாம்:

  • உங்களிடம் 100,000-க்கும் அதிகமான பெரிய ஆவணங்கள் இருந்தால்.
  • குறைந்த தாமதத்துடன் (low latency) அதிக அளவிலான உற்பத்தியைத் தேவைப்பட்டால்.

ஆனால் தனிப்பட்ட அறிவுத் தளங்கள் (personal knowledge bases), பக்கத் திட்டங்கள் (side projects) அல்லது உள் கருவிகளுக்கு (internal tools), உங்களுக்கு இது தேவையில்லை.

MCP-ன் நன்மைகள்:

  • பராமரிக்க எளிதானது: 2,000 வரிகளுக்குப் பதிலாக 150 வரிகள் மட்டுமே.
  • embedding செலவுகள் இல்லை: மாதிரிகள் மாறும்போது நீங்கள் தரவை மீண்டும் embed செய்ய வேண்டிய அவசியமில்லை.
  • சிறந்த துல்லியம்: AI முழுமையான சூழலைப் பெறுகிறது.
  • பிழைகளைக் கண்டறிவது (debug) எளிது: ஒரு தேடல் ஏன் தோல்வியடைந்தது என்பதை நீங்கள் துல்லியமாகப் பார்க்க முடியும்.

தேவையற்ற சிக்கல்களை (over-engineering) உருவாக்குவதை நிறுத்துங்கள். கடினமான வேலைகளை AI-யிடம் விட்டுவிடுங்கள். உங்கள் தரவை அணுக அனுமதி கொடுங்கள், அதுவே வாசிக்கட்டும்.

Source: https://dev.to/kevinten10/mcp-rag-why-i-stopped-building-complex-rag-systems-after-mcp-changed-everything-4g86

Optional learning community: https://t.me/GyaanSetuAi