ਸਹਾਇਕ ਆਰਕੀਟੈਕਚਰ ਜੋ ਕੰਪਨੀ ਦੇ ਡੇਟਾ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ

ਲਾਭ:

• ਇੱਕ ਐਂਡ-ਟੂ-ਐਂਡ ਐਂਟਰਪ੍ਰਾਈਜ਼ RAG ਸਹਾਇਕ ਦੇ ਕੰਪੋਨੈਂਟਸ ਅਤੇ ਡੇਟਾ ਪ੍ਰਵਾਹ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ
• ਮਲਟੀ-ਸੋਰਸ ਡੇਟਾ (ਵਿਕੀ, ਟਿਕਟ, ਪੀਡੀਐਫ, ਡੇਟਾਬੇਸ) ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਸਹਾਇਕ ਵਿੱਚ ਜੋੜਨਾ
• ਸਕੇਲੇਬਿਲਟੀ, ਕੈਚਿੰਗ ਅਤੇ ਲੇਟੈਂਸੀ ਲਈ ਆਰਕੀਟੈਕਚਰਲ ਫੈਸਲੇ ਲਓ

ਪਿਛਲੀਆਂ ਇਕਾਈਆਂ ਵਿੱਚ, ਅਸੀਂ ਭਾਗਾਂ ਨੂੰ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਸਿੱਖਿਆ: ਏਮਬੈਡਿੰਗ, ਵੈਕਟਰ ਡੇਟਾਬੇਸ, ਚੰਕਿੰਗ, ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ। ਆਉ ਹੁਣ ਇਹਨਾਂ ਨੂੰ ਜੋੜੀਏ ਅਤੇ ਇੱਕ ਸਹਾਇਕ ਦਾ ਅੰਤ ਤੋਂ ਅੰਤ ਤੱਕ ਆਰਕੀਟੈਕਚਰ ਬਣਾਈਏ ਜੋ ਤੁਹਾਡੀ ਆਪਣੀ ਕੰਪਨੀ ਦੇ ਡੇਟਾ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ। ਟੀਚਾ ਇੱਕ ਕਰਮਚਾਰੀ ਨੂੰ ਪੁੱਛਣਾ ਹੈ, "ਸਾਡੀ ਛੁੱਟੀ ਨੀਤੀ ਕੀ ਹੈ?" ਇੱਕ ਸਿਸਟਮ ਜਿੱਥੇ ਲੋਕ ਸਵਾਲ ਪੁੱਛ ਸਕਦੇ ਹਨ, ਜਵਾਬ ਅਸਲ ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼ਾਂ, ਹਵਾਲਿਆਂ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਈ ਡੇਟਾ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ। ਇਹ ਯੂਨਿਟ ਪੂਰੇ ਢਾਂਚੇ, ਡੇਟਾ ਪ੍ਰਵਾਹ ਅਤੇ ਉਤਪਾਦਨ ਪੱਧਰ ਦੇ ਫੈਸਲਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੀ ਹੈ।

ਐਂਡ-ਟੂ-ਐਂਡ ਕੰਪੋਨੈਂਟਸ

ਇੱਕ ਕਾਰਪੋਰੇਟ RAG ਸਹਾਇਕ ਵਿੱਚ ਦੋ ਵੱਖਰੀਆਂ ਲਾਈਨਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇੰਡੈਕਸਿੰਗ ਲਾਈਨ (ਆਫਲਾਈਨ) ਡਾਟਾ ਤਿਆਰ ਕਰਦੀ ਹੈ; ਪੁੱਛਗਿੱਛ ਲਾਈਨ (ਆਨਲਾਈਨ) ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।

ਇੰਡੈਕਸਿੰਗ ਲਾਈਨ ਕੰਪੋਨੈਂਟ:

1. ਕਨੈਕਟਰ: ਕਨੈਕਟਰ ਜੋ ਸਰੋਤਾਂ ਤੋਂ ਡੇਟਾ ਖਿੱਚਦੇ ਹਨ — ਵਿਕੀ, ਟਿਕਟ ਸਿਸਟਮ, ਫਾਈਲ ਸਟੋਰ, ਡੇਟਾਬੇਸ, ਈਮੇਲ।
2. ਸਧਾਰਨਕਰਨ: ਵੱਖ-ਵੱਖ ਫਾਰਮੈਟਾਂ (PDF, HTML, DOCX) ਨੂੰ ਸਾਫ਼ ਟੈਕਸਟ ਵਿੱਚ ਬਦਲਣਾ; ਸਿਰਲੇਖ/ਪਦਲੇਖ ਦੀ ਸਫਾਈ.
3. ਚੰਕਿੰਗ + ਮੈਟਾਡੇਟਾ: ਚੰਕਿੰਗ ਅਤੇ ਟੈਗਿੰਗ (ਸਰੋਤ, ਮਿਤੀ, ਅਧਿਕਾਰ)।
4. ਏਮਬੈਡਿੰਗ + ਲੋਡਿੰਗ: ਵੈਕਟਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਵੈਕਟਰ ਅਤੇ ਮੈਟਾਡੇਟਾ ਲਿਖਣਾ।

ਕਿਊਰੀ ਪਾਈਪਲਾਈਨ ਭਾਗ:

1. ਪੁੱਛਗਿੱਛ ਪ੍ਰੀਪ੍ਰੋਸੈਸਿੰਗ: ਮੁੜ ਲਿਖਣਾ, ਵਿਕੇਂਦਰੀਕਰਨ।
2. ਮੁੜ ਪ੍ਰਾਪਤੀ: ਹਾਈਬ੍ਰਿਡ ਖੋਜ + ਮੈਟਾਡੇਟਾ ਫਿਲਟਰ + ਰੀ-ਰੈਂਕਿੰਗ।
3. ਤੁਰੰਤ ਰਚਨਾ: ਟੈਂਪਲੇਟ ਵਿੱਚ ਸੰਦਰਭ + ਪ੍ਰਸ਼ਨ + ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਰੱਖਣਾ।
4. ਜਨਰੇਸ਼ਨ: ਮਾਡਲ + ਸਰੋਤਾਂ ਤੋਂ ਆਧਾਰਿਤ (ਪ੍ਰਸੰਗਿਕ) ਜਵਾਬ।
5. ਪੋਸਟ-ਪ੍ਰੋਸੈਸਿੰਗ: ਹਵਾਲਾ ਫਾਰਮੈਟਿੰਗ, ਸੁਰੱਖਿਆ ਜਾਂਚ, ਲੌਗਿੰਗ।

ਸੁਝਾਅ: ਇੰਡੈਕਸਿੰਗ ਲਾਈਨ ਨੂੰ ਪੁੱਛਗਿੱਛ ਲਾਈਨ ਤੋਂ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕਰੋ। ਇੰਡੈਕਸਿੰਗ ਹੌਲੀ ਅਤੇ ਆਵਰਤੀ ਹੁੰਦੀ ਹੈ (ਰਾਤ ਵਿੱਚ ਬੈਚਾਂ ਵਿੱਚ ਚੱਲਦੀ ਹੈ); ਪੁੱਛਗਿੱਛ ਦੀ ਲਾਈਨ ਹਲਕੀ ਅਤੇ ਤੁਰੰਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦੋਂ ਉਪਭੋਗਤਾ ਉਡੀਕ ਕਰਦਾ ਹੈ ਤਾਂ ਦੋ ਲਾਈਨਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਭਾਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਡਾਟਾ ਪ੍ਰਵਾਹ ਨੂੰ ਵਿਜ਼ੂਅਲ ਕਰਨਾ

[ਇੰਡੈਕਸਿੰਗ - ਔਫਲਾਈਨ]ਸਰੋਤ → ਆਮ ਬਣਾਓ → ਚੰਕ+ਮੈਟਾਡਾਟਾ → ਏਮਬੇਡ → ਵੈਕਟਰ DB (ਵਿਕੀ, ਟਿਕਟ, PDF, DB)[QUERY - ਔਨਲਾਈਨ]ਉਪਭੋਗਤਾ ਸਵਾਲ → ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ → ਮੁੜ ਪ੍ਰਾਪਤੀ (ਹਾਈਬ੍ਰਿਡ+ਫਿਲਟਰ+ਰੀਰੈਂਕ) → ਪ੍ਰੋਂਪਟ (ਪ੍ਰਸੰਗ+ਸਵਾਲ+ਇੰਸਟ੍ਰਕਸ਼ਨ → ਵਰਤੋ

ਮਲਟੀ-ਸਰੋਤ ਡੇਟਾ ਨੂੰ ਜੋੜਨਾ

ਅਸਲ ਕੰਪਨੀਆਂ ਵਿੱਚ, ਜਵਾਬ ਇੱਕ ਥਾਂ ਤੇ ਨਹੀਂ ਰੁਕਦਾ. "ਕਿਸੇ ਗਾਹਕ ਨੂੰ ਰਿਫੰਡ ਕਿਵੇਂ ਜਾਰੀ ਕਰਨਾ ਹੈ?" ਸਵਾਲ ਦਾ ਜਵਾਬ ਮਦਦ ਲੇਖ (ਪ੍ਰਕਿਰਿਆ), ਟਿਕਟ ਇਤਿਹਾਸ (ਅਸਲ ਉਦਾਹਰਨਾਂ) ਅਤੇ ਨੀਤੀ PDF (ਨਿਯਮਾਂ) ਦੋਵਾਂ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਸਹਾਇਕ ਨੂੰ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਇੱਕ ਪੂਲ ਵਿੱਚ ਖੋਜਣਾ ਚਾਹੀਦਾ ਹੈ।

ਨਾਜ਼ੁਕ ਬਿੰਦੂ: ਇੱਕ ਸਿੰਗਲ ਵੈਕਟਰ ਸਟੋਰ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਜੋੜਦੇ ਸਮੇਂ, ਹਰੇਕ ਸ਼ਾਰਡ ਵਿੱਚ `ਸਰੋਤ_ਟੂਰ` ਮੈਟਾਡੇਟਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ ਤੁਸੀਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨੂੰ ਖੋਜ ਸਕਦੇ ਹੋ ਅਤੇ ਜੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਫਿਲਟਰ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ "ਸਿਰਫ ਅਧਿਕਾਰਤ ਨੀਤੀਆਂ ਲਿਆਓ"। ਨਾਲ ਹੀ, ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਵਿੱਚ ਭਰੋਸੇਯੋਗਤਾ ਦੇ ਵੱਖ-ਵੱਖ ਪੱਧਰ ਹੁੰਦੇ ਹਨ: ਅਧਿਕਾਰਤ ਨੀਤੀ > ਮਦਦ ਲੇਖ > ਇੱਕ ਕਰਮਚਾਰੀ ਦਾ ਟਿਕਟ ਨੋਟ। ਤੁਸੀਂ ਇਸ ਤਰਜੀਹ ਨੂੰ ਮੁੜ-ਰੈਂਕਿੰਗ ਜਾਂ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸਰੋਤ

ਸਮੱਗਰੀ ਦੀ ਕਿਸਮ

ਭਰੋਸਾ

ਅੱਪਡੇਟ ਬਾਰੰਬਾਰਤਾ

ਨੀਤੀ PDF

ਅਧਿਕਾਰਤ ਨਿਯਮ

ਉੱਚ

ਮਹੀਨਾਵਾਰ

ਮਦਦ ਲੇਖ

ਵਿਧੀ

ਮੱਧਮ-ਉੱਚਾ

ਹਫਤਾਵਾਰੀ

ਟਿਕਟ ਇਤਿਹਾਸ

ਅਸਲੀ ਨਮੂਨਾ

ਮੱਧਮ

ਨਿਰੰਤਰ

ਵਿਕੀ

ਮਿਕਸਡ/ਮੌਜੂਦਾ ਨੋਟ

ਵੇਰੀਏਬਲ

ਨਿਰੰਤਰ

ਸਕੇਲੇਬਿਲਟੀ, ਕੈਸ਼ ਅਤੇ ਲੇਟੈਂਸੀ

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

ਲਾਗਤ ਦੇ ਪੱਖ 'ਤੇ ਅੰਗੂਠੇ ਦਾ ਨਿਯਮ: ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਕਦਮ ਆਮ ਤੌਰ 'ਤੇ ਵੱਡੇ ਮਾਡਲ 'ਤੇ ਜਾਣ ਵਾਲੇ ਟੋਕਨਾਂ ਦੀ ਗਿਣਤੀ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ, ਮੁੜ-ਰੈਂਕਿੰਗ ਦੁਆਰਾ ਸੰਦਰਭ ਨੂੰ 4 ਚੰਗੇ ਭਾਗਾਂ ਵਿੱਚ ਘਟਾਉਣ ਨਾਲ ਗੁਣਵੱਤਾ ਅਤੇ ਲਾਗਤ ਦੋਵਾਂ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਆਮ ਡਿਜ਼ਾਇਨ ਸਧਾਰਨ ਵਰਗੀਕਰਨ ਜਾਂ ਰੂਟਿੰਗ ਲਈ ਇੱਕ ਛੋਟੇ/ਤੇਜ਼ ਮਾਡਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ, ਅਤੇ ਅੰਤਮ ਜਵਾਬ ਲਈ ਇੱਕ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਮਾਡਲ (ਜਿਵੇਂ ਕਿ ਕਲਾਉਡ-ਓਪਸ-4-8)।

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

ਕਮਜ਼ੋਰ ਆਰਕੀਟੈਕਚਰ / ਮਜ਼ਬੂਤ ਆਰਕੀਟੈਕਚਰ

ਕਮਜ਼ੋਰ (ਇਕ ਸਕ੍ਰਿਪਟ, ਸਭ ਕੁਝ ਮਿਲਾਇਆ ਗਿਆ):

ਜਦੋਂ ਉਪਭੋਗਤਾ ਪੁੱਛਦਾ ਹੈ: ਉਸ ਸਮੇਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹੋ, ਉਹਨਾਂ ਨੂੰ ਕੱਟੋ, ਉਹਨਾਂ ਨੂੰ ਜੋੜੋ, ਉਹਨਾਂ ਦੀ ਖੋਜ ਕਰੋ, ਉਹਨਾਂ ਦਾ ਜਵਾਬ ਦਿਓ। # ਸਮੱਸਿਆ: ਹਰ ਸਵਾਲ ਲਈ ਸਾਰੇ ਇੰਡੈਕਸਿੰਗ ਦੁਹਰਾਈ ਜਾਂਦੀ ਹੈ; ਦੇਰੀ ਦੇ ਸਕਿੰਟ, # ਕੋਈ ਸਰੋਤ ਵੱਖਰਾ ਨਹੀਂ, ਕੋਈ ਫਿਲਟਰ ਨਹੀਂ, ਕੋਈ ਤਾਜ਼ਗੀ ਨਹੀਂ।

ਸ਼ਕਤੀਸ਼ਾਲੀ (ਸਪਲਿਟ ਪਾਈਪਾਂ + ਮੈਟਾਡੇਟਾ + ਕੈਸ਼ + ਸਟ੍ਰੀਮਿੰਗ):

ਇੰਡੈਕਸਿੰਗ: ਬੈਚ ਰਾਤ ਨੂੰ ਚੱਲਦਾ ਹੈ, ਬਦਲੇ ਹੋਏ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ। ਪੁੱਛਗਿੱਛ: ਲਾਈਟਵੇਟ ਲਾਈਨ — ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸਿੰਗ → ਹਾਈਬ੍ਰਿਡ ਰੀਟ੍ਰੀਵਲ+ਫਿਲਟਰ → ਰੀਰੈਂਕ → ਪ੍ਰੋਂਪਟ → ਮਾਡਲ (ਸਟ੍ਰੀਮਿੰਗ) → ਹਵਾਲਾ → ਲੌਗ। ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ ਅਤੇ ਸਰੋਤ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ

ਕੇਸ 1 - ਉਲਝਣ ਵਾਲੀ ਲਾਈਨ, ਭਾਰੀ ਦੇਰੀ। ਇੱਕ ਸਟਾਰਟਅਪ ਨੇ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖੀ ਹੈ ਜੋ ਹਰੇਕ ਸਵਾਲ ਦੇ ਨਾਲ ਪੀਡੀਐਫ ਨੂੰ ਮੁੜ ਪ੍ਰਕਿਰਿਆ ਕਰਦੀ ਹੈ; ਹਰੇਕ ਜਵਾਬ ਨੇ ਔਸਤਨ 11 ਸਕਿੰਟ ਲਏ। ਜਦੋਂ ਇੰਡੈਕਸਿੰਗ ਲਾਈਨ ਨੂੰ ਵੱਖ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਡੇਟਾ ਪਹਿਲਾਂ ਵੈਕਟਰ ਸਟੋਰ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਪੁੱਛਗਿੱਛ ਦਾ ਸਮਾਂ 1.3 ਸਕਿੰਟ ਤੱਕ ਘਟ ਗਿਆ ਅਤੇ ਸਟ੍ਰੀਮਿੰਗ ਦੇ ਨਾਲ, "ਪਹਿਲਾ ਸ਼ਬਦ" 400 ms ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ।

ਕੇਸ 2 - ਬਹੁਤ ਸਾਰੇ ਸਰੋਤ, ਗਲਤ ਤਰਜੀਹ। ਇੱਕ ਸਹਾਇਕ ਸਹਾਇਕ ਨੇ ਪਾਲਿਸੀ PDF ਅਤੇ ਪੁਰਾਣੇ ਟਿਕਟ ਨੋਟਾਂ ਨੂੰ ਬਰਾਬਰ ਭਾਰ ਦਿੱਤਾ; ਮਾਡਲ ਨੇ ਕਈ ਵਾਰ ਸਰਕਾਰੀ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ ਦੋ ਸਾਲ ਪਹਿਲਾਂ ਤੋਂ ਕਿਸੇ ਕਰਮਚਾਰੀ ਦੀ ਗਲਤ ਰੇਟਿੰਗ ਪੇਸ਼ ਕੀਤੀ ਸੀ। ਜਦੋਂ ਸਰੋਤ_ਟੂਰ ਮੈਟਾਡੇਟਾ ਅਤੇ "ਵਿਰੋਧ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਅਧਿਕਾਰਤ ਨੀਤੀ 'ਤੇ ਵਿਚਾਰ ਕਰੋ" ਹਿਦਾਇਤ ਨੂੰ ਪ੍ਰੋਂਪਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਗਲਤ-ਪ੍ਰਾਥਮਿਕਤਾ ਦੀਆਂ ਤਰੁੱਟੀਆਂ 89% ਤੱਕ ਘਟਾਈਆਂ ਗਈਆਂ ਸਨ।

ਕੇਸ 3 - ਪੁਰਾਣਾ ਸੂਚਕਾਂਕ। ਇੱਕ HR ਸਹਾਇਕ ਇੱਕ ਸੂਚਕਾਂਕ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ ਜੋ 3 ਮਹੀਨਿਆਂ ਲਈ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ; ਛੁੱਟੀ ਦੀ ਨੀਤੀ ਬਦਲ ਗਈ ਹੈ, ਪਰ ਸਹਾਇਕ ਪੁਰਾਣੇ ਦਿਨਾਂ ਦੀ ਗੱਲ ਕਹਿ ਰਿਹਾ ਸੀ। ਜਦੋਂ ਰੋਜ਼ਾਨਾ ਰਿਫ੍ਰੈਸ਼ ਸਥਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਬਦਲੀਆਂ ਗਈਆਂ ਫਾਈਲਾਂ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ, ਮੌਜੂਦਾ-ਜਵਾਬ ਦੀ ਦਰ 70% ਤੋਂ 99% ਤੱਕ ਵਧ ਗਈ ਹੈ।

ਆਮ ਗਲਤੀਆਂ

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

ਸੰਖੇਪ ਵਿੱਚ

• ਕਾਰਪੋਰੇਟ RAG ਸਹਾਇਕ ਵਿੱਚ ਦੋ ਵੱਖਰੀਆਂ ਲਾਈਨਾਂ ਹੁੰਦੀਆਂ ਹਨ: ਔਫਲਾਈਨ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਔਨਲਾਈਨ ਪੁੱਛਗਿੱਛ; ਉਹਨਾਂ ਨੂੰ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਵੱਖ ਕਰੋ।
• ਇੰਡੈਕਸਿੰਗ = ਕਨੈਕਟਰ + ਸਧਾਰਣ + ਚੰਕ/ਮੈਟਾਡੇਟਾ + ਏਮਬੇਡ/ਅੱਪਲੋਡ; ਪੁੱਛਗਿੱਛ = ਪ੍ਰੀ-ਪ੍ਰਕਿਰਿਆ + ਮੁੜ ਪ੍ਰਾਪਤੀ + ਪ੍ਰੋਂਪਟ + ਉਤਪੰਨ + ਪੋਸਟ-ਪ੍ਰਕਿਰਿਆ।
• ਮਲਟੀ-ਸਰੋਤ ਡੇਟਾ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ source_type ਮੈਟਾਡੇਟਾ ਅਤੇ ਟਰੱਸਟ ਤਰਜੀਹ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ।
• ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਲੇਟੈਂਸੀ ਲਈ ਕੈਸ਼, ਸੰਦਰਭ ਥ੍ਰੋਟਲਿੰਗ ਅਤੇ ਲਾਗਤ ਲਈ ਮਾਡਲ ਦੀ ਚੋਣ ਮਹੱਤਵਪੂਰਨ ਹਨ।
• ਰੀ-ਇੰਡੈਕਸਿੰਗ ਤੋਂ ਬਿਨਾਂ, ਸੂਚਕਾਂਕ ਬੇਕਾਰ ਹੋ ਜਾਂਦਾ ਹੈ; ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਬਦਲਣ ਵਾਲੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਮੁੜ ਪ੍ਰਕਿਰਿਆ ਕਰੋ।

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ

ਆਪਣੀ ਟੀਮ ਲਈ ਇੱਕ ਸਹਾਇਕ ਦਾ ਇੱਕ ਆਰਕੀਟੈਕਚਰਲ ਚਿੱਤਰ ਬਣਾਓ। (1) ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਅਸਲ ਡਾਟਾ ਸਰੋਤਾਂ ਦੀ ਪਛਾਣ ਕਰੋ ਅਤੇ ਹਰੇਕ ਲਈ ਕਨੈਕਟਰ ਦੀ ਲੋੜ, ਅੱਪਡੇਟ ਬਾਰੰਬਾਰਤਾ, ਅਤੇ ਭਰੋਸੇ ਦਾ ਪੱਧਰ ਲਿਖੋ। (2) ਇੱਕ ਬਾਕਸ-ਤੀਰ ਚਿੱਤਰ ਨਾਲ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਪੁੱਛਗਿੱਛ ਲਾਈਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਖਿੱਚੋ। (3) "ਮੈਂ ਇਸ ਸਹਾਇਕ ਵਿੱਚ ਲੇਟੈਂਸੀ ਅਤੇ ਲਾਗਤ ਨੂੰ ਕਿੱਥੇ ਘਟਾਵਾਂ?" ਸਵਾਲ ਦੇ ਘੱਟੋ-ਘੱਟ ਦੋ ਠੋਸ ਫੈਸਲੇ ਲਿਖੋ। (4) ਇੱਕ ਵਾਕ ਵਿੱਚ ਆਪਣੀ ਰਿਫਰੈਸ਼ ਰਣਨੀਤੀ ਦਾ ਵਰਣਨ ਕਰੋ: ਕਿਹੜਾ ਸਰੋਤ ਦੁਬਾਰਾ ਸੂਚੀਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਕਿੰਨੀ ਵਾਰ?

ਚੈੱਕਲਿਸਟ

• [ ] ਮੈਂ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਪੁੱਛਗਿੱਛ ਲਾਈਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਅਤੇ ਸਹੀ ਭਾਗਾਂ ਨਾਲ ਖਿੱਚ ਸਕਦਾ ਹਾਂ।
• [ ] ਮੈਂ source_type ਅਤੇ ਭਰੋਸਾ ਤਰਜੀਹ ਨਾਲ ਮਲਟੀ-ਸਰੋਤ ਡੇਟਾ ਨੂੰ ਜੋੜ ਸਕਦਾ ਹਾਂ।
• [ ] ਮੈਂ ਲਾਗਤ ਲਈ ਲੇਟੈਂਸੀ ਅਤੇ ਮਾਡਲ ਦੀ ਚੋਣ ਲਈ ਸਟ੍ਰੀਮਿੰਗ/ਕੈਸ਼ ਫੈਸਲੇ ਲੈ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।
• [ ] ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਮੁੜ-ਇੰਡੈਕਸਿੰਗ ਰਣਨੀਤੀ ਕਿਉਂ ਜ਼ਰੂਰੀ ਹੈ।
• [ ] ਮੈਂ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹਾਂ ਕਿ ਮੇਰੇ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਕਦਮ ਆਮ ਤੌਰ 'ਤੇ ਟੋਕਨ ਹੁੰਦਾ ਹੈ ਜੋ ਵੱਡੇ ਮਾਡਲ ਨੂੰ ਜਾਂਦਾ ਹੈ।