𝗜 𝗦𝗽𝗲𝗻𝘁 $𝟱𝟬𝟬 𝗼𝗻 𝗥𝗔𝗚 𝗜𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 𝗕𝗲𝗳𝗼𝗿𝗲 𝗠𝗮𝗸𝗶𝗻𝗴 𝟳 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀
ਮੈਂ ਪ੍ਰਾਈਵੇਟ ਡੌਕਯੂਮੈਂਟ ਸਰਚ ਲਈ ਇੱਕ RAG ਪਾਈਪਲਾਈਨ ਬਣਾਈ। ਇਸ 'ਤੇ ਮੇਰਾ $500 ਦਾ ਕੰਪਿਊਟਿੰਗ ਖਰਚਾ ਅਤੇ ਡੀਬੱਗਿੰਗ ਦੇ ਕਈ ਹਫ਼ਤੇ ਲੱਗੇ। ਨਤੀਜੇ ਮਾੜੇ ਸਨ। ਯੂਜ਼ਰਸ ਨੂੰ ਗੈਰ-ਸੰਬੰਧਿਤ ਜਵਾਬ ਮਿਲ ਰਹੇ ਸਨ ਅਤੇ ਕੁਐਰੀਆਂ (queries) ਬਹੁਤ ਹੌਲੀ ਸਨ।
ਮੈਂ ਪਾਈਪਲਾਈਨ ਦਾ ਆਡਿਟ ਕੀਤਾ ਅਤੇ 7 ਆਮ ਗਲਤੀਆਂ ਲੱਭੀਆਂ। ਇਨ੍ਹਾਂ ਨੂੰ ਸੁਧਾਰਨ ਨਾਲ ਸਭ ਕੁਝ ਬਦਲ ਗਿਆ।
- ਫਿਕਸਡ ਟੋਕਨ ਚੰਕਿੰਗ (Fixed Token Chunking) ਮੈਂ ਡੌਕਯੂਮੈਂਟਸ ਨੂੰ ਫਿਕਸਡ ਟੋਕਨ ਕਾਊਂਟਸ ਰਾਹੀਂ ਵੰਡਿਆ ਸੀ। ਇਸ ਨਾਲ ਕੰਟੈਕਸਟ (context) ਖਰਾਬ ਹੋ ਗਿਆ। ਇੱਕ ਵਾਕ ਅੱਧ ਵਿਚਕਾਰ ਹੀ ਟੁੱਟ ਜਾਂਦਾ ਸੀ। LLM ਨੂੰ ਟੁਕੜਿਆਂ ਵਿੱਚ ਡਾਟਾ ਮਿਲਦਾ ਸੀ ਅਤੇ ਉਹ ਮਾੜੇ ਜਵਾਬ ਦਿੰਦਾ ਸੀ।
- ਸੁਧਾਰ: Parent-document retrieval ਦੇ ਨਾਲ semantic chunking ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਪੈਰਾਗ੍ਰਾਫ ਜਾਂ ਹੈਡਰਸ ਵਰਗੀਆਂ ਕੁਦਰਤੀ ਸੀਮਾਵਾਂ ਰਾਹੀਂ ਵੰਡੋ।
- ਸਰਚ ਲਈ ਛੋਟੇ child chunks ਬਣਾਓ।
- ਜਦੋਂ ਕੋਈ ਮੈਚ ਮਿਲਦਾ ਹੈ, ਤਾਂ LLM ਨੂੰ ਪੂਰਾ parent document ਵਾਪਸ ਕਰੋ।
- ਚੰਕਸ ਦੇ ਵਿਚਕਾਰ 10-20% overlap ਰੱਖੋ।
- ਡਿਫੌਲਟ ਸਰਚ ਵੇਟਸ (Default Search Weights) ਮੈਂ vector ਅਤੇ keyword ਸਰਚ ਲਈ 50/50 ਸਪਲਿਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ। ਤਕਨੀਕੀ ਡੌਕਯੂਮੈਂਟਸ ਲਈ, ਸਹੀ keywords ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
- ਸੁਧਾਰ: ਡਾਇਨਾਮਿਕ ਵੇਟਸ (dynamic weights) ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਤੱਥਾਂ ਵਾਲੀਆਂ ਕੁਐਰੀਆਂ (Factual queries): 35% vector, 65% keyword।
- ਸੈਮੈਂਟਿਕ ਕੁਐਰੀਆਂ (Semantic queries): 75% vector, 25% keyword।
- HNSW ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਆਪਟੀਮਾਈਜ਼ ਕਰਨਾ (Over-optimizing HNSW Parameters) ਮੈਂ ef_construction ਨੂੰ ਮੈਕਸੀਮਮ ਵੈਲਯੂ 'ਤੇ ਸੈੱਟ ਕਰ ਦਿੱਤਾ ਸੀ। ਇੱਕ ਵੱਡੇ ਇੰਡੈਕਸ 'ਤੇ, ਇਸ ਨਾਲ ਮੇਰਾ ਸਰਵਰ ਕ੍ਰੈਸ਼ ਹੋ ਗਿਆ ਅਤੇ ਮੇਰੀ ਸਾਰੀ RAM ਵਰਤੀ ਗਈ।
- ਸੁਧਾਰ: ਉਚਿਤ HNSW ਸੈਟਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- M ਨੂੰ 8 ਅਤੇ 32 ਦੇ ਵਿਚਕਾਰ ਰੱਖੋ।
- ef_construction ਨੂੰ 200 'ਤੇ ਸੈੱਟ ਕਰੋ।
- ef_search ਨੂੰ 50 'ਤੇ ਸੈੱਟ ਕਰੋ।
- ਗਲਤ Embedding ਮਾਡਲ (Wrong Embedding Models) ਮੈਂ ਵੈੱਬ ਟੈਕਸਟ 'ਤੇ ਟ੍ਰੇਨ ਕੀਤੇ ਗਏ ਇੱਕ ਜਨਰਲ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਸੀ। ਇਹ ਮੇਰੇ ਤਕਨੀਕੀ ਇੰਜੀਨੀਅਰਿੰਗ ਡੌਕਯੂਮੈਂਟਸ ਨੂੰ ਨਹੀਂ ਸਮਝ ਸਕਿਆ।
- ਸੁਧਾਰ: ਤਕਨੀਕੀ ਜਾਂ ਕੋਡ ਕੰਟੈਂਟ ਲਈ fine-tuned ਮਾਡਲ 'ਤੇ ਸਵਿਚ ਕਰੋ।
- ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਦਾ ਮੇਲ ਨਾ ਹੋਣਾ (Natural Language Mismatch) ਯੂਜ਼ਰਸ "ਮੇਰਾ build ਕਿਉਂ ਹੌਲੀ ਹੈ" ਵਰਗੇ ਸਵਾਲ ਪੁੱਛਦੇ ਹਨ। ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ "CI pipeline optimization" ਵਰਗੇ ਸ਼ਬਦਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚ ਕੋਈ ਮੇਲ ਨਹੀਂ ਸੀ।
- ਸੁਧਾਰ: ਇੱਕ LLM query rewrite ਸਟੈਪ ਜੋੜੋ।
- ਸਰਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯੂਜ਼ਰ ਦੀ ਕੁਐਰੀ ਨੂੰ ਤਕਨੀਕੀ ਸ਼ਬਦਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖੋ।
- ਵਾਧੂ ਕੰਟੈਕਸਟ (Redundant Context) ਟੌਪ 10 ਚੰਕਸ ਨੂੰ ਰਿਟ੍ਰੀਵ ਕਰਨ ਦਾ ਮਤਲਬ ਅਕਸਰ ਇੱਕੋ ਪੈਰਾਗ੍ਰਾਫ ਨੂੰ ਤਿੰਨ ਵਾਰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੁੰਦਾ ਸੀ। ਇਸ ਨਾਲ ਹਲੂਸੀਨੇਸ਼ਨ (hallucinations) ਹੋ ਰਹੇ ਸਨ।
- ਸੁਧਾਰ: ਨਤੀਜਿਆਂ ਵਿੱਚ ਵਿਭਿੰਨਤਾ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ Maximal Marginal Relevance (MMR) ਦੀ ਵਰਤੋਂ ਕਰੋ।
- ਸਿਰਫ਼ End-to-End ਇਵੈਲੂਏਸ਼ਨ (End-to-End Evaluation Only) ਮੈਂ ਸਿਰਫ਼ ਅੰਤਿਮ ਜਵਾਬ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਮੈਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਸਮੱਸਿਆ ਰਿਟ੍ਰੀਵਲ (retrieval) ਵਿੱਚ ਸੀ ਜਾਂ LLM ਵਿੱਚ।
- ਸੁਧਾਰ: ਰਿਟ੍ਰੀਵਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਇਵੈਲੂਏਟ ਕਰੋ।
- Hit rate ਅਤੇ Mean Reciprocal Rank (MRR) ਨੂੰ ਟ੍ਰੈਕ ਕਰੋ।
- 100 query-document ਜੋੜਾਂ ਦਾ ਇੱਕ ਟੈਸਟ ਸੈੱਟ ਬਣਾਓ।
ਸੁਧਾਰਾਂ ਤੋਂ ਬਾਅਦ ਦੇ ਨਤੀਜੇ: • ਜਵਾਬ ਦੀ ਪ੍ਰਸੰਗਿਕਤਾ (Answer relevance): 45% ਤੋਂ 85% • ਕੁਐਰੀ ਲੇਟੈਂਸੀ (Query latency): 3.2s ਤੋਂ 1.8s • ਮਹੀਨਾਵਾਰ ਖਰਚਾ: $180 ਤੋਂ $95
ਪਹਿਲਾਂ chunking ਨੂੰ ਠੀਕ ਕਰੋ। ਫਿਰ weights ਨੂੰ। ਫਿਰ embedding quality ਨੂੰ।
ਤੁਹਾਡਾ ਸਭ ਤੋਂ ਵੱਡਾ RAG ਸਿਰਦਰਦ ਕੀ ਹੈ? ਮੈਨੂੰ ਕਮੈਂਟਸ ਵਿੱਚ ਦੱਸੋ।
ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi