ਲੋੜ ਮੁਤਾਬਕ ਬਣਾਏ RAG ਹੱਲਾਂ ਦੀਆਂ ਵਿਹਾਰਕ ਉਦਾਹਰਨਾਂ

ਅੱਜਕੱਲ੍ਹ RAG ਦੀ ਕਈ ਵਾਰ ਬਦਨਾਮੀ ਹੁੰਦੀ ਹੈ. ਜਾਂ ਤਾਂ ਲੋਕ ਹੁਣ ਇਸਨੂੰ ਬਿਲਕੁਲ ਮਾਮੂਲੀ ਸਮਝਦੇ ਹਨ (ਸ਼ੁਰੂ ਕਰਨਾ ਸੌਖਾ ਹੈ, ਪਰ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਲਿਜਾਣਾ ਇੰਨਾ ਸੌਖਾ ਨਹੀਂ), ਜਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ‘ਏਜੰਟ-ਅਧਾਰਿਤ ਸਿਸਟਮ’ ਇਸ ਤੋਂ ਅੱਗੇ ਨਿਕਲ ਗਏ ਹਨ (ਪਰ ਕਈ ਮਾਮਲਿਆਂ ਵਿੱਚ ਥੋੜ੍ਹਾ ਡੂੰਘਾ ਵੇਖਣ 'ਤੇ ਉਹ ਛੇਤੀ ਹੀ RAG ਵਰਗੇ ਦਿਸਣ ਲੱਗਦੇ ਹਨ...).

ਇਹ ਬਲੌਗ ਇੱਕ-ਦੋ ਵਿਹਾਰਕ ਉਦਾਹਰਨਾਂ ਰਾਹੀਂ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸੀਂ ਕੁਝ ਆਮ ਚੁਣੌਤੀਆਂ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ:

• ਰਲਵੇਂ ਟੈਕਸਟ ਅਤੇ ਅੰਕੀ ਡੇਟਾ ਨੂੰ ਸੰਭਾਲਣਾ ਅਤੇ ਇਹ ਸਧਾਰਨ RAG ਨੂੰ ਕਿਉਂ ਨਾਕਾਮ ਕਰਦਾ ਹੈ: ਮੁੱਖ ਸ਼ਬਦ ਆਪਸ ਵਿੱਚ ਟਕਰਾਉਂਦੇ ਹਨ ਅਤੇ ਅੰਕਾਂ ਦਾ ਕੋਈ ਅਰਥਗਤ ਮਤਲਬ ਨਹੀਂ ਹੁੰਦਾ.

• ਪਹਿਲਾਂ ਸਾਰਾਂਸ਼ ਬਣਾਉਣ ਵਾਲੀਆਂ ਐਂਬੈਡਿੰਗਾਂ ਦੀ ਰਚਨਾ ਲਾਭਦਾਇਕ ਕਿਉਂ ਹੈ: ਹਰ ਹਿੱਸੇ ਦਾ ਛੋਟਾ ਵਰਣਨਾਤਮਕ ਸਾਰਾਂਸ਼ ਬਣਾਓ, ਫਿਰ ਉਸੇ ਸਾਰਾਂਸ਼ ਨੂੰ ਐਂਬੈਡ ਕਰਕੇ ਉਸ 'ਤੇ ਪੁੱਛਗਿੱਛ ਕਰੋ.

• ਸੰਦਰਭ-ਅਧਾਰਿਤ ਸਾਰਾਂਸ਼ ਕਿਵੇਂ ਬਣਾਉਣੇ ਹਨ: ਮੂਲ ਦਸਤਾਵੇਜ਼ ਦਾ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ, ਤਾਂ ਜੋ ਇੱਕੋ ਜਿਹੀ ਬਣਤਰ ਵਾਲੇ ਅੰਕੜਿਆਂ ਵਿਚਲਾ ਫ਼ਰਕ ਸਪਸ਼ਟ ਰਹੇ.

• ਕੋਡ ਅਤੇ Pydantic ਮਾਡਲਾਂ 'ਤੇ ਕਦੋਂ ਨਿਰਭਰ ਕਰਨਾ ਹੈ: ਜਿੱਥੇ ਸਮੱਗਰੀ ਦਾ ਹੂ-ਬ-ਹੂ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਕਸਟਮ ਕੋਡ ਅਤੇ/ਜਾਂ Pydantic ਮਾਡਲ ਨੂੰ LLM ਕਾਲਾਂ ਨਾਲ ਜੋੜੋ.

ਬੁਨਿਆਦੀ ਗੱਲਾਂ

ਸਹਾਇਤਾ ਬੌਟਾਂ ਤੋਂ ਲੈ ਕੇ ਅੰਦਰੂਨੀ ਗਿਆਨ ਸਹਾਇਕਾਂ ਤੱਕ, ਕਈ ਚੀਜ਼ਾਂ RAG ਸਿਸਟਮਾਂ ਨਾਲ ਚੱਲਦੀਆਂ ਹਨ.

ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕਰਦੇ ਹੋ:

1. ਆਪਣੇ ਸਰੋਤ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਹਿੱਸੇ ਬਣਾਓ

2. ਹਰ ਹਿੱਸੇ ਨੂੰ ਵੈਕਟਰ ਸਪੇਸ ਵਿੱਚ ਐਂਬੈਡ ਕਰੋ

3. ਪੁੱਛਗਿੱਛ ਵੇਲੇ ਸਿਖਰਲੇ-K ਹਿੱਸੇ ਪ੍ਰਾਪਤ ਕਰੋ

4. ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਜਵਾਬ ਤਿਆਰ ਕਰੋ

LangChain, LlamaIndex ਅਤੇ OpenAI ਦੇ Filestore ਵਰਗੀਆਂ ਪ੍ਰਸਿੱਧ ਟੂਲਕਿੱਟਾਂ ਇਨ੍ਹਾਂ ਕਦਮਾਂ ਨੂੰ ਲਗਭਗ ਮਾਮੂਲੀ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ. ਪਰ ਅਸਲ ਵਰਤੋਂ ਵਾਲੀਆਂ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਅਜਿਹਾ ਡੇਟਾ ਵੀ ਮਿਲੇਗਾ ਜੋ ਸਿਰਫ਼ ਸੰਘਣਾ ਟੈਕਸਟ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਬੁਨਿਆਦੀ RAG ਨੂੰ ਇਸ ਨਾਲ ਮੁਸ਼ਕਲ ਆ ਸਕਦੀ ਹੈ. ਅਗਲੇ ਭਾਗਾਂ ਵਿੱਚ ਅਸੀਂ ਡੇਟਾ ਦੀਆਂ ਚੁਣੌਤੀਆਂ ਦੀਆਂ ਠੋਸ ਉਦਾਹਰਨਾਂ ਦਿਖਾਵਾਂਗੇ ਅਤੇ ਜਿਉਂ-ਜਿਉਂ ਜਟਿਲਤਾ ਵਧੇਗੀ, ਹੱਲ ਨੂੰ ਪੜਾਅਵਾਰ ਤਿਆਰ ਕਰਾਂਗੇ.

1. ਜਦੋਂ ਤੁਹਾਡਾ ਡੇਟਾ ਸਿਰਫ਼ ਟੈਕਸਟ ਨਹੀਂ ਹੁੰਦਾ (ਜੋ ਅਸਲ ਵਿੱਚ ਆਮ ਗੱਲ ਹੈ)

ਗੇਮਿੰਗ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਡੇਟਾ ਦੇ ਇਸ ਹਿੱਸੇ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

1{2 "Attack": {3 "Range": {4 "default": 5,5 "with_Draconic_Ascension": 5.5,6 },7 "Speed": {8 "default": "2 seconds",9 "with_Draconic_Ascension": "2.2 seconds",10 },11 "Damage": {12 "default": 10,13 "with_Draconic_Ascension": 12,14 }15 }16} 

ਐਂਬੈਡਿੰਗਾਂ ਇਸ ਲਈ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੇ ਅਰਥ ਅਤੇ ਵਿਆਕਰਨ ਰਾਹੀਂ ਸ਼ਬਦਾਂ ਵਿਚਲੇ ਸੰਬੰਧ ਸਿੱਖੇ ਹੁੰਦੇ ਹਨ. ਉਪਰੋਕਤ ਡੇਟਾ ਵਿੱਚ ਟੈਕਸਟ ਅਤੇ ਅੰਕ ਰਲੇ ਹੋਏ ਹਨ, ਪਰ ਇਸ ਖ਼ਾਸ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਅੰਕਾਂ ਦਾ ਸ਼ਬਦਾਂ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਹੈ. ਇਸ ਲਈ ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਡੇਟਾ ਦਾ ਇਹ ਹਿੱਸਾ ਕੁਝ ਹੱਦ ਤੱਕ ਵਰਣਨਾਤਮਕ ਸ਼ਬਦਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਬਾਅਦ ਆਉਂਦੇ ਕੁਝ ਬੇਤਰਤੀਬ ਅੰਕਾਂ ਦਾ ਸੁਮੇਲ ਹੈ.

ਜੇ ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇਸ ਕਿਸਮ ਦਾ ਡੇਟਾ ਹੁੰਦਾ, ਤਾਂ ਅਸਲ ਵਿੱਚ ਇਹ ਸਮੱਸਿਆ ਨਾ ਬਣਦੀ, ਕਿਉਂਕਿ ਅਸੀਂ ਕੁਝ ਮੌਜੂਦ ਵਰਣਨਾਤਮਕ ਸ਼ਬਦਾਂ ਦੀਆਂ ਐਂਬੈਡਿੰਗਾਂ ਰਾਹੀਂ ਇਸਨੂੰ ਫਿਰ ਵੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਸੀ (ਜਾਂ ਸਿਰਫ਼ ਟੈਕਸਟ-ਤੋਂ-SQL ਵਰਤ ਸਕਦੇ ਸੀ). ਪਰ ਉਦੋਂ ਕੀ ਹੋਵੇਗਾ ਜੇ ਇਹ ਹਿੱਸਾ ਬਹੁਤ ਸਾਰੇ ਸੰਘਣੇ ਟੈਕਸਟ ਵਾਲੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਦੱਬਿਆ ਹੋਵੇ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਹੀ ਸ਼ਬਦ ਵੀ ਆਉਂਦੇ ਹੋਣ? ਉਦਾਹਰਨ ਲਈ:

1{2"Draconic_Ascension": {3 "description": "Transform into dragon form. Attack range and speed are i4ncreased by 10%, damage is boosted by 20%.",5 "details": {6 "activation_conditions": "Can only be activated when HP is below 50%7or Fury meter is full.",8 "visual_effects": "Wings unfurl, scales shimmer with embers, voice line9s change to echoing growls.",10 "lore": "An ancient bloodline awakens. The bearer of the mark channel11s the soul of the last Flamewing Wyrm, becoming a living storm of fire and fur12y."13 }14 }15}

ਹੁਣ ਕਲਪਨਾ ਕਰੋ ਕਿ ਅਸੀਂ ਇਹ ਲੱਭਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, “ਡ੍ਰੈਕੋਨਿਕ ਅਸੈਂਸ਼ਨ ਨਾਲ ਹਮਲੇ ਦੀ ਰੇਂਜ ਕਿੰਨੀ ਹੈ?” ਬਹੁਤ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਅਸੀਂ ਮਨਚਾਹਾ ਸੰਬੰਧਿਤ ਹਿੱਸਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਾਂਗੇ, ਕਿਉਂਕਿ ਉਹ ਉਹੀ ਮੁੱਖ ਸ਼ਬਦ ਰੱਖਣ ਵਾਲੇ ਹੋਰ ਹਿੱਸਿਆਂ ਦੇ ਰੌਲੇ ਵਿੱਚ ਡੂੰਘਾ ਦੱਬਿਆ ਹੋਇਆ ਹੈ.

ਮੂਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਡੇਟਾ ਦੇ ਇਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਢੁਕਵਾਂ ਫ਼ਰਕ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਭਾਵੇਂ ਉਨ੍ਹਾਂ ਵਿੱਚ ਇੱਕੋ ਵਿਸ਼ੇ ਬਾਰੇ ਵੱਖ-ਵੱਖ ਕਿਸਮ ਦੀ ਜਾਣਕਾਰੀ ਹੈ. ਕੀ ਅਸੀਂ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਇਸਨੂੰ ਹੋਰ ਭਰਪੂਰ ਜਾਂ ਬਿਹਤਰ ਬਣਾ ਸਕਦੇ ਹਾਂ? ਬਿਲਕੁਲ ਬਣਾ ਸਕਦੇ ਹਾਂ:smile:

1. ਆਪਣੇ ਡੇਟਾ ਦਾ ਸਾਰਾਂਸ਼ ਬਣਾ ਕੇ ਉਸਨੂੰ ਹੋਰ ਭਰਪੂਰ ਕਰੋ, ਹਾਂ, ਤੁਸੀਂ ਠੀਕ ਪੜ੍ਹਿਆ ਹੈ

ਹਿੱਸੇ ਨੂੰ ਸਿੱਧਾ ਐਂਬੈਡ ਕਰਨ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਪਹਿਲਾਂ ਡੇਟਾ ਦੇ ਵਿਸ਼ੇ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲਾ ਸਾਰਾਂਸ਼ ਬਣਾ ਸਕਦੇ ਹਾਂ ਅਤੇ ਫਿਰ ਉਸ ਸਾਰਾਂਸ਼ ਨੂੰ ਐਂਬੈਡ ਕਰਕੇ ਉਸੇ ਦੇ ਆਧਾਰ 'ਤੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ. ਜਵਾਬ ਤਿਆਰ ਕਰਨ ਦੇ ਪੜਾਅ ਵਿੱਚ ਅਸੀਂ ਫਿਰ ਵੀ ਸਾਰਾਂਸ਼ ਨਾਲ ਜੁੜਿਆ ਮੂਲ ਡੇਟਾ ਹੀ ਵਰਤਾਂਗੇ.

ਇਸ ਲਈ ਉੱਪਰ ਦਿਖਾਏ ਦੋ ਹਿੱਸਿਆਂ ਵਾਸਤੇ ਅਸੀਂ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਸਾਰਾਂਸ਼ ਬਣਾਵਾਂਗੇ:

1. ਰੇਂਜ, ਗਤੀ ਅਤੇ ਨੁਕਸਾਨ ਦੇ ਹਮਲਾਵਰ ਅੰਕੜੇ (ਮੂਲ ਅਤੇ ਡ੍ਰੈਕੋਨਿਕ ਅਸੈਂਸ਼ਨ ਨਾਲ).

2. ਡ੍ਰੈਕੋਨਿਕ ਅਸੈਂਸ਼ਨ ਦਾ ਵਰਣਨ ਅਤੇ ਵੇਰਵਾ, ਜਿਸ ਵਿੱਚ ਸਰਗਰਮ ਹੋਣ ਦੀਆਂ ਸ਼ਰਤਾਂ, ਦ੍ਰਿਸ਼ ਪ੍ਰਭਾਵ ਅਤੇ ਪਿਛੋਕੜ ਦੀ ਕਹਾਣੀ ਸ਼ਾਮਲ ਹਨ.

ਫਿਰ ਅਸੀਂ ਪੁੱਛਗਿੱਛ ਨੂੰ ਵੀ ਵਧਾਉਂਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹ ਸਾਰਾਂਸ਼ ਨਾਲ “ਮੇਲ ਖਾਵੇ”. ਮਿਸਾਲ ਵਜੋਂ, ਅਸੀਂ “ਡ੍ਰੈਕੋਨਿਕ ਅਸੈਂਸ਼ਨ ਨਾਲ ਹਮਲੇ ਦੀ ਰੇਂਜ ਕਿੰਨੀ ਹੈ?” ਨੂੰ ਬਦਲ ਕੇ “ਡ੍ਰੈਕੋਨਿਕ ਅਸੈਂਸ਼ਨ ਨਾਲ ਹਮਲੇ ਦੀ ਰੇਂਜ ਦੇ ਅੰਕੜੇ ਕੀ ਹਨ?” ਬਣਾ ਦੇਵਾਂਗੇ. ਇਹ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਦੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤੀ ਦੀ ਪੁੱਛਗਿੱਛ ਗੈਰ-ਤਕਨੀਕੀ ਵਰਤੋਂਕਾਰ ~~“ਖੁੱਲ੍ਹੇ ਅੰਦਾਜ਼”~~ ਆਮ ਮਨੁੱਖੀ ਭਾਸ਼ਾ ਵਿੱਚ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਆਖ਼ਰਕਾਰ ਇਹ ਜਾਣਨਾ ਉਨ੍ਹਾਂ ਦੀ ਲੋੜ ਜਾਂ ਚਿੰਤਾ ਨਹੀਂ ਕਿ RAG ਵੱਧ ਤੋਂ ਵੱਧ ਸ਼ੁੱਧਤਾ ਅਤੇ ਰੀਕਾਲ ਲਈ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ.

1. ਚੀਜ਼ਾਂ ਨੂੰ ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ ਨਾ ਲਓ (ਇਹ ਗੱਲ ਆਮ ਤੌਰ 'ਤੇ ਜ਼ਿੰਦਗੀ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ)

ਹੁਣ ਅਗਲਾ ਦ੍ਰਿਸ਼ ਇਹ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਇੱਕੋ ਜਿਹੇ ਦਿਸਣ ਵਾਲੇ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਹਿੱਸਿਆਂ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਿਆ ਜਾਵੇ:

1# Chunk one2{3 "Attack": {4 "Range": {5 "default": 9,6 },7 ...8 }9}10# Chunk two11{12 "Attack": {13 "Range": {14 "default": 6,15 },16 ...17 }18}19# Chunk three20{21 "Attack": {22 "Range": {23 "default": 7,24 },25 ...26 }27}

ਜੇ ਅਸੀਂ ਇਹੀ ਤਰੀਕਾ ਵਰਤਦੇ ਰਹੀਏ, ਤਾਂ ਕਲਪਨਾ ਕਰੋ ਕਿ ਕੋਈ ਪੁੱਛੇ, “ਕਿਰਦਾਰ X ਦੇ ਹਮਲੇ ਦੀ ਰੇਂਜ ਕਿੰਨੀ ਹੈ?” ਹੁਣੇ ਬਣਾਏ ਇਨ੍ਹਾਂ ਸਾਰਾਂਸ਼ਾਂ ਨਾਲ ਅਸੀਂ ਕਿਸਮਤ ਦੇ ਸਹਾਰੇ ਅੰਦਾਜ਼ੇ ਲਗਾ ਰਹੇ ਹੋਵਾਂਗੇ, ਕਿਉਂਕਿ ਇਹ ਵੀ ਬਹੁਤ ਇੱਕੋ ਜਿਹੇ ਦਿਸਣਗੇ. ਤਾਂ ਫਿਰ ਅਸੀਂ ਇਨ੍ਹਾਂ ਵਿੱਚ ਫ਼ਰਕ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹਾਂ?

ਸਿੱਧਾ ਜਵਾਬ ਹੈ: ਸੰਦਰਭ ਦਿਓ. ਅਸੀਂ ਡੇਟਾ ਦੇ ਹਿੱਸੇ ਵਿੱਚ ਉਸਦੇ ਮੂਲ ਦਸਤਾਵੇਜ਼ ਦਾ ਹਵਾਲਾ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹਾਂ, ਜਿਵੇਂ ਇਸ ਮਾਮਲੇ ਵਿੱਚ {”character”: “X”}. ਹੁਣ ਕਿਰਦਾਰ Y ਅਤੇ Z ਲਈ ਵੀ ਉਹੀ ਡੇਟਾ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਸੀਂ ਕਿਰਦਾਰ X ਦਾ ਸਹੀ ਡੇਟਾ ਬਿਲਕੁਲ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਾਂਗੇ.

ਪਰ ਇਸ ਤੋਂ ਬਿਹਤਰ ਅਤੇ ਵਧੇਰੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲਾ ਤਰੀਕਾ ਹਿੱਸੇ ਦਾ ਸੰਦਰਭ-ਅਧਾਰਿਤ ਸਾਰਾਂਸ਼ ਬਣਾਉਣਾ ਹੋਵੇਗਾ. ਭਾਵ, ਸਿਰਫ਼ ਡੇਟਾ ਦੇ ਹਿੱਸੇ ਦਾ ਸਾਰਾਂਸ਼ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਉਸਦਾ ਮੂਲ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਹਿੱਸਾ ਦੋਵੇਂ ਦੇ ਕੇ ਇੱਕ ਸਮੁੱਚਾ ਸੰਦਰਭ-ਅਧਾਰਿਤ ਸਾਰਾਂਸ਼ ਬਣਾ ਸਕਦੇ ਹਾਂ. ਇਸ ਸਾਰਾਂਸ਼ ਵਿੱਚ ਦੱਸਿਆ ਜਾਵੇਗਾ ਕਿ ਇਹ ਹਿੱਸਾ ਮੂਲ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ:

1. ਇਹ ਹਿੱਸਾ ਕਿਰਦਾਰ X ਲਈ ... ਦੇ ਵਿਸਤ੍ਰਿਤ ਅੰਕੜੇ ਦਿੰਦਾ ਹੈ. ਇਹ ਹਿੱਸਾ ਹਮਲੇ ਦੀ ਗਤੀ ਵਿੱਚ X ਦੀ ਤਾਕਤ ਦਿਖਾ ਕੇ ਪੂਰੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ...

2. ਇਹ ਹਿੱਸਾ ਕਿਰਦਾਰ Y ਲਈ ... ਦੇ ਵਿਸਤ੍ਰਿਤ ਅੰਕੜੇ ਦਿੰਦਾ ਹੈ. ਇਹ ਹਿੱਸਾ Y ਦੀ ਖ਼ਾਸ ਸਮਰੱਥਾ ਨਾਲ ਵਧੇ ਹੋਏ ਉਸਦੇ ਅੰਕੜੇ ਦਿਖਾ ਕੇ ਪੂਰੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ...

3. ਇਹ ਹਿੱਸਾ ਕਿਰਦਾਰ Z ਲਈ ... ਦੇ ਵਿਸਤ੍ਰਿਤ ਅੰਕੜੇ ਦਿੰਦਾ ਹੈ. ਇਹ ਹਿੱਸਾ Z ਦੇ ਉਹ ਅੰਕੜੇ ਦਿਖਾ ਕੇ ਪੂਰੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਜੋ ਟੀਮ ਮੁਕਾਬਲਿਆਂ ਵਿੱਚ ਟੈਂਕ ਦੀ ਭੂਮਿਕਾ ਲਈ ਢੁਕਵੇਂ ਹਨ...

ਇਹ ਤਰੀਕਾ (ਜੋ ਕੁਝ ਹੱਦ ਤੱਕ Anthropic ਤੋਂ ਪ੍ਰੇਰਿਤ ਹੈ) ਉੱਪਰ ਦਿੱਤੀ ਉਦਾਹਰਨ ਲਈ ਲੋੜ ਤੋਂ ਵੱਧ ਜਾਪ ਸਕਦਾ ਹੈ. ਪਰ ਇਹ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਲਈ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ “ਸੰਦਰਭ ਤੋਂ ਬਾਹਰ” ਗ਼ਲਤ ਅਰਥ ਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ. ਨਾਲ ਹੀ, ਇਹ ਸਾਰੇ ਹਿੱਸਿਆਂ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਇਕਸਾਰ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੰਜੀਨੀਅਰਿੰਗ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸੁਚੱਜਾ ਰੱਖਦਾ ਹੈ.

1. ਜਦੋਂ ਤੁਹਾਨੂੰ ~~ਹਰ ਚੀਜ਼ ਕਾਬੂ ਵਿੱਚ ਰੱਖਣ ਵਾਲਾ~~ ਸਖ਼ਤ ਅਤੇ ਸਟੀਕ ਹੋਣ ਦੀ ਲੋੜ ਹੋਵੇ

ਆਮ ਤੌਰ 'ਤੇ ਸਾਨੂੰ ਡੇਟਾ ਪੂਰੇ ਰੂਪ ਵਿੱਚ ਮਿਲਦਾ ਹੈ ਅਤੇ ਅਸੀਂ RAG ਸਿਸਟਮ ਲਈ ਉਸਦੇ ਹਿੱਸੇ ਬਣਾਉਂਦੇ ਹਾਂ. ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਅਸੀਂ ਕੁਝ ਵੱਖਰਾ ਦਿਖਾਉਂਦੇ ਹਾਂ: ਅਜਿਹਾ ਡੇਟਾ ਜਿਸਦੇ ਹਿੱਸੇ ਤਾਂ ਬਣੇ ਹੋਏ ਹਨ, ਪਰ ਉਹ ਮਾੜੇ ਹਿੱਸੇ ਹਨ. ਇਹ ਕਿਸੇ ਤਰਕਸੰਗਤ ਹਿੱਸੇ ਵਿੱਚੋਂ ਲਏ ਬੇਤਰਤੀਬ ਭਾਗ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਮੁੜ ਇਕੱਠਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਤਰਕਸੰਗਤ ਹਿੱਸੇ ਤੋਂ ਭਾਵ ਸਮੱਗਰੀ ਦਾ ਅਜਿਹਾ ਹਿੱਸਾ ਹੈ ਜੋ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਇਕੱਠਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਦਸਤਾਵੇਜ਼ ਦਾ ਉਪਭਾਗ ਜਾਂ ਕੋਈ ਇਕਸਾਰ ਪੈਰਾ.

ਇਸ ਡੇਟਾ ਨਾਲ ਸਾਡੀ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਸਾਰੀ ਸਮੱਗਰੀ ਨੂੰ ਇੱਕ LLM ਕਾਲ ਵਿੱਚ ਦੇਣਾ, ਉਸਨੂੰ ਆਪਣੀ ਸਮਝ ਮੁਤਾਬਕ ਸਮੂਹ ਬਣਾਉਣ ਲਈ ਕਹਿਣਾ ਅਤੇ ਫਿਰ ਸਮੂਹਬੱਧ ਸਮੱਗਰੀ ਵਾਪਸ ਲੈਣਾ ਹੈ. LLM ਨੂੰ ਇਸ ਕੰਮ ਵਿੱਚ ਕਾਫ਼ੀ ਵਧੀਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਹੈ ਨਾ? ਜੀ ਹਾਂ ਵੀ ਅਤੇ ਨਹੀਂ ਵੀ.

ਅਸੀਂ ਕਈ ਹੋਰ ਮੌਕਿਆਂ 'ਤੇ ਵੀ ਵੇਖਿਆ ਹੈ ਕਿ ਜਦੋਂ ਪੂਰੀ ਅਤੇ ਹੂ-ਬ-ਹੂ ਸਮੱਗਰੀ ਦੀ ਲੋੜ ਹੋਵੇ, ਖ਼ਾਸ ਕਰਕੇ ਲੰਮੇ ਸੰਦਰਭ ਵਿੱਚ, ਤਾਂ LLM ਸੁਸਤ ਰਵੱਈਆ ਅਪਣਾਉਂਦੇ ਹਨ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ. ਜੋ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਝ ਆਉਂਦਾ ਹੈ. ਪਰ ਇਸ ਖ਼ਾਸ ਵਰਤੋਂ ਲਈ ਇਹ ਕਬੂਲਯੋਗ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਸਮੱਗਰੀ ਸ਼ਬਦ-ਦਰ-ਸ਼ਬਦ ਬਿਲਕੁਲ ਸਹੀ ਚਾਹੀਦੀ ਸੀ: ਨਾ ਕੋਈ ਸਾਰਾਂਸ਼ ਅਤੇ ਨਾ ਹੀ ਮੂਲ ਸਮੱਗਰੀ ਦਾ ਕੋਈ ਹਿੱਸਾ ਛੱਡਣਾ. ਅਸੀਂ ਕੋਈ ਵੀ ਵੇਰਵਾ ਨਹੀਂ ਛੱਡ ਸਕਦੇ.

ਅਤੇ ਬੇਸ਼ੱਕ “ਹਾਂ” ਵਾਲੀ ਗੱਲ ਇਹ ਸੀ ਕਿ ਇਸਨੇ ਟੁੱਟੇ ਹਿੱਸਿਆਂ ਦੇ ਅਰਥ ਅਤੇ ਬਣਤਰ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਕੰਮ ਕੀਤਾ. ਬਸ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਇਹ ਹੂ-ਬ-ਹੂ ਸਮੱਗਰੀ ਵਾਪਸ ਦੇਣ ਤੋਂ ਇਨਕਾਰ ਨਾ ਕਰੇ. ਧੱਤ ਤੇਰੇ ਕੀ:/

ਤਾਂ ਅਸੀਂ LLM ਦੀਆਂ ਖ਼ੂਬੀਆਂ ਨੂੰ ਵਰਤਦੇ ਹੋਏ ਉਨ੍ਹਾਂ ਕੰਮਾਂ ਤੋਂ ਕਿਵੇਂ ਬਚ ਸਕਦੇ ਹਾਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਹ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ? ਅਸੀਂ ਆਪਣੇ ਪੁਰਾਣੇ ਭਰੋਸੇਯੋਗ ਮਿੱਤਰ, ਕੋਡ, ਦੀ ਮਦਦ ਲਈ (ਭਾਵ ਇੱਕ ਕਸਟਮ Python ਫੰਕਸ਼ਨ). ਅਤੇ ਇੱਕ “ਇਸ ਤੋਂ ਸੌਖਾ ਨਹੀਂ ਹੋ ਸਕਦਾ” Pydantic ਮਾਡਲ ਦੀ. ਹੱਲ ਇਹ ਹੈ:

• ਮੌਜੂਦਾ ਤਰਕਸੰਗਤ ਹਿੱਸੇ ਨੂੰ ਕਾਇਮ ਰੱਖਦਿਆਂ ਸਾਰੇ ਭਾਗਾਂ ਉੱਤੇ ਵਾਰੀ-ਵਾਰੀ ਕਾਰਵਾਈ ਕਰੋ.

• ਹਰ ਭਾਗ 'ਤੇ LLM ਨੂੰ ਪੁੱਛੋ: ਕੀ ਇਹ ਭਾਗ ਮੌਜੂਦਾ ਤਰਕਸੰਗਤ ਹਿੱਸੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ? Pydantic ਮਾਡਲ ਅਨੁਸਾਰ ਹਾਂ ਜਾਂ ਨਾਂਹ ਵਿੱਚ ਜਵਾਬ ਦਿਓ.

• ਜੇ ਹਾਂ, ਤਾਂ ਭਾਗ ਨੂੰ ਹਿੱਸੇ ਨਾਲ ਜੋੜੋ. ਜੇ ਨਾਂਹ, ਤਾਂ ਮੌਜੂਦਾ ਤਰਕਸੰਗਤ ਹਿੱਸਾ ਪੂਰਾ ਹੋਣ ਕਰਕੇ ਉਸਨੂੰ ਬਾਹਰ ਭੇਜੋ ਅਤੇ ਇਸ ਭਾਗ ਨਾਲ ਨਵਾਂ ਹਿੱਸਾ ਸ਼ੁਰੂ ਕਰੋ.

ਬੇਸ਼ੱਕ ਅਸੀਂ ਇੱਥੇ ਪੂਰੀ ਸਮੱਗਰੀ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਪਾਸ ਕਰਨ ਨਾਲੋਂ ਕੁਝ ਵੱਧ ਟੋਕਨ ਵਰਤ ਰਹੇ ਹਾਂ. ਪਰ ਇਸ ਖ਼ਾਸ ਵਰਤੋਂ ਵਿੱਚ ਹੂ-ਬ-ਹੂ ਸਮੱਗਰੀ ਬਰਕਰਾਰ ਰੱਖਣਾ ਸਭ ਤੋਂ ਵੱਡੀ ਤਰਜੀਹ ਸੀ, ਇਸ ਲਈ ਇਹ (ਮਾਮੂਲੀ) ਵਾਧੂ ਲਾਗਤ ਬਿਲਕੁਲ ਵਾਜਬ ਸੀ.

ਇਹ ਬਹੁਤ ਸੌਖਾ ਹੱਲ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਅਹਿਮ ਸਿਧਾਂਤ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ: ਜਦੋਂ ਸਖ਼ਤੀ ਅਤੇ ਸਟੀਕਤਾ ਦੀ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਸਾਨੂੰ ਸਿਰਫ਼ LLM 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਕਿਉਂਕਿ ਆਖ਼ਰਕਾਰ ਇਹ ਸੰਭਾਵਨਾ-ਅਧਾਰਿਤ ਹੁੰਦੇ ਹਨ.

ਕਸਟਮ ਕੋਡ ਜਾਂ ਫੰਕਸ਼ਨਾਂ ਅਤੇ Pydantic ਮਾਡਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਨੁਮਾਨਯੋਗ ਅਤੇ ਭਰੋਸੇਯੋਗ ਨਤੀਜੇ ਹਾਸਲ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਨਾਲ ਹੀ LLM ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦਾ ਪੂਰਾ ਲਾਭ ਵੀ ਲਿਆ ਜਾ ਸਕਦਾ ਹੈ.

ਜਨਰੇਟਿਵ AI ਹੱਲ ਬਣਾਉਣਾ ਜਿੰਨਾ AI ਨਾਲ ਜੁੜਿਆ ਮਸਲਾ ਹੈ, ਓਨਾ ਹੀ ਇੰਜੀਨੀਅਰਿੰਗ ਨਾਲ ਜੁੜਿਆ ਮਸਲਾ ਵੀ ਹੈ. ਸਾਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਨ੍ਹਾਂ ਉਦਾਹਰਨਾਂ ਨੇ ਤੁਹਾਨੂੰ ਆਪਣੀਆਂ ਵਿਲੱਖਣ ਚੁਣੌਤੀਆਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ ਹੈ. ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਪਹਿਲ ਦੇਣ ਵਾਲੇ ਜਨਰੇਟਿਵ AI ਹੱਲਾਂ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹਨ ਲਈ, ਰਾਊਟਰ-ਅਧਾਰਿਤ ਏਜੰਟ ਸਿਸਟਮ ਦੀ ਰਚਨਾ ਬਾਰੇ ਸਾਡੀ ਬਲੌਗ ਪੋਸਟ ਵੇਖੋ.