ਵੱਡੇ ਪੱਧਰ 'ਤੇ Production RAG: ਰੋਜ਼ਾਨਾ 10,000+ ਲਿਸਟਿੰਗਾਂ ਤੋਂ ਸਿੱਖੇ ਗਏ ਸਬਕ
ਮੈਂ ਇੱਕ ਜੌਬ ਬੋਰਡ ਲਈ RAG ਪਾਈਪਲਾਈਨ ਬਣਾਈ। ਇਹ staging ਵਿੱਚ ਤਾਂ ਚੱਲ ਰਹੀ ਸੀ ਪਰ ਅਸਲ ਲੋਡ (real load) ਦੇ ਹੇਠਾਂ ਸੰਘਰਸ਼ ਕਰ ਰਹੀ ਸੀ। ਰੋਜ਼ਾਨਾ ਹਜ਼ਾਰਾਂ ਲਿਸਟਿੰਗਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਵਧੀਆ vector store ਹੀ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਿਸਟਮ ਕਿੱਥੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।
ਇੱਥੇ chunking, embeddings, ਲਾਗਤ (costs), ਅਤੇ observability ਬਾਰੇ ਮੇਰੇ ਸਬਕ ਹਨ।
1. ਆਪਣੀ chunking strategy ਦਾ ਅੰਦਾਜ਼ਾ ਨਾ ਲਗਾਓ
ਜ਼ਿਆਦਾਤਰ ਟਿਊਟੋਰਿਅਲ chunking ਨੂੰ ਇੱਕ ਸਧਾਰਨ ਸੈਟਿੰਗ ਵਜੋਂ ਮੰਨਦੇ ਹਨ। Production ਵਿੱਚ, ਤੁਹਾਡੀ strategy ਸਹੀ ਮੁਲਾਂਕਣ (accuracy) ਅਤੇ ਲਾਗਤ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
ਮੈਂ ਜੌਬ ਲਿਸਟਿੰਗਾਂ ਲਈ ਤਿੰਨ ਤਰੀਕਿਆਂ ਦੀ ਜਾਂਚ ਕੀਤੀ:
- Fixed-size chunks: ਇਹ ਫੇਲ੍ਹ ਹੋ ਗਏ। ਉਹਨਾਂ ਨੇ "requirements" ਅਤੇ "benefits" ਵਰਗੇ ਸੈਕਸ਼ਨਾਂ ਨੂੰ ਬੇਤਰਤੀਬੇ (random) ਬਿੰਦੂਆਂ 'ਤੇ ਵੰਡ ਦਿੱਤਾ। ਇਸ ਨਾਲ noisy retrieval ਹੁੰਦਾ ਹੈ।
- Semantic chunking: ਇਹ ਬਿਹਤਰ ਸੀ ਪਰ ਅਸਥਿਰ (inconsistent) ਸੀ। ਕੁਝ chunks ਬਹੁਤ ਲੰਬੇ ਸਨ ਅਤੇ ਕੁਝ ਬਹੁਤ ਛੋਟੇ।
- Recursive character splitting with overlap: ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਰਿਹਾ। ਮੈਂ newlines ਅਤੇ ਵਾਕਾਂ (sentences) ਦੇ ਆਧਾਰ 'ਤੇ ਵੰਡਿਆ। ਮੈਂ 50 token overlap ਦੇ ਨਾਲ 400 token size ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਦੋ chunks ਵਿੱਚ ਫੈਲੇ ਵਾਕ ਜੁੜੇ ਰਹਿਣ।
Pro tip: Chunking ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੇ ਡੇਟਾ ਨੂੰ normalize ਕਰੋ। Greenhouse ਜਾਂ Lever ਵਰਗੇ ਵੱਖ-ਵੱਖ ਸਰੋਤ ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟ ਦਿੰਦੇ ਹਨ। ਪਹਿਲਾਂ ਟੈਕਸਟ ਨੂੰ ਸਾਫ਼ (clean) ਕਰੋ ਤਾਂ ਜੋ ਤੁਹਾਡਾ chunker ਇੱਕ ਇਕਸਾਰ (consistent) ਢਾਂਚਾ ਦੇਖ ਸਕੇ।
2. Embeddings: ਲਾਗਤ (Cost) ਬਨਾਮ ਸਹੀ ਮੁਲਾਂਕਣ (Accuracy)
ਮੈਂ OpenAI text-embedding-3-small ਦੇ ਵਿਰੁੱਧ Ollama ਰਾਹੀਂ Llama 3.1 ਦੀ ਜਾਂਚ ਕੀਤੀ। ਲੋਕਲ ਮਾਡਲ ਮੁਫ਼ਤ ਸੀ ਪਰ "equity compensation" ਵਰਗੇ ਖਾਸ ਖੇਤਰ (domain-specific) ਦੇ ਸ਼ਬਦਾਂ ਨਾਲ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਸੀ। ਇਸ ਨੇ noisy ਨਤੀਜੇ ਦਿੱਤੇ। OpenAI ਦੀ ਲਾਗਤ ਜ਼ਿਆਦਾ ਸੀ ਪਰ ਇਸ ਨੇ ਸਹੀ ਮੈਚ ਪ੍ਰਦਾਨ ਕੀਤੇ। ਮੈਂ OpenAI ਨੂੰ ਚੁਣਿਆ ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ LLM calls ਵਿੱਚ ਗਲਤ retrieval ਦੀ ਲਾਗਤ ਜ਼ਿਆਦਾ ਹੁੰਦੀ ਹੈ।
ਸਮਾਂ ਬਚਾਉਣ ਲਈ, ਮੈਂ ਆਪਣੀਆਂ requests ਨੂੰ batch ਕਰਦਾ ਹਾਂ। ਮੈਂ ਇੱਕ ਵਾਰ ਵਿੱਚ 100 chunks ਤੱਕ ਭੇਜਦਾ ਹਾਂ। ਇਹ latency ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਤੇਜ਼ ਰੱਖਦਾ ਹੈ।
3. Vector Store ਦਾ ਸਮਝੌਤਾ (Trade-off)
ਮੈਂ prototyping ਲਈ Pinecone ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਤੇਜ਼ ਹੈ। ਹਾਲਾਂਕਿ, ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲਾਗਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧ ਗਈ।
ਮੈਂ PostgreSQL ਦੇ ਅੰਦਰ pgvector 'ਤੇ ਸਵਿਚ ਕਰ ਲਿਆ।
- ਇਸ ਨੂੰ ਸੈੱਟ ਕਰਨ ਵਿੱਚ ਜ਼ਿਆਦਾ ਮਿਹਨਤ ਲੱਗੀ।
- ਇਸ ਨੇ ਬਹੁਤ ਸਾਰੇ ਪੈਸੇ ਬਚਾਏ।
- ਇਸ ਨੇ transactional consistency ਪ੍ਰਦਾਨ ਕੀਤੀ। ਕਿਉਂਕਿ embeddings ਉਹੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਹਨ ਜਿੱਥੇ ਜੌਬ ਡੇਟਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਹੀ ਸੱਚ ਦਾ ਸਰੋਤ (source of truth) ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਸਿਸਟਮਾਂ ਨੂੰ sync ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
4. LLM ਲਾਗਤਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ
ਹਰ ਲਿਸਟਿੰਗ ਨੂੰ GPT-4o ਨਾਲ score ਕਰਨਾ ਮਹਿੰਗਾ ਹੈ। ਮੈਂ ਲਾਗਤ ਘਟਾਉਣ ਲਈ ਤਿੰਨ ਤਰੀਕੇ ਵਰਤੇ:
- OpenAI Batch API: ਮੈਂ scoring ਦੇ ਕੰਮ ਰਾਤੋ-ਰਾਤ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹਾਂ। ਇਹ ਵੱਡੀ ਛੋਟ ਪ੍ਰਦ