LLM ਚੈਟ ਅਨੁਭਵ ਵਾਲਾ AI ਐਪ ਕਿਵੇਂ ਬਣਾਉਣਾ

ਉਪਯੋਗ ਮਾਮਲੇ ਅਤੇ ਸਫਲਤਾ ਮੈਟਰਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਕੋਈ ਮਾਡਲ ਚੁਣਣ ਜਾਂ ਚੈਟਬੋਟ UI ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਪੱਸ਼ਟ ਕਰੋ ਕਿ ਚੈਟ ਅਨੁਭਵ ਦਾ ਮਕਸਦ ਕੀ ਹੈ। “LLM ਚੈਟ ਜੋੜੋ” ਕੋਈ ਉਪਯੋਗ ਮਾਮਲਾ ਨਹੀਂ—ਉਪਭੋਗਤਾ ਚੈਟ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਉਹ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹਨ: ਉੱਤਰ, ਮੁਕੰਮਲ ਕੀਤੀਆਂ ਕਾਰਵਾਈਆਂ ਅਤੇ ਘੱਟ ਵਾਰ-ਵਾਰ ਦੀ ਗੱਲਬਾਤ।

ਉਪਭੋਗਤਾ ਸਮੱਸਿਆ ਸਪੱਸ਼ਟ ਕਰੋ

ਉਪਭੋਗਤਾ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਇੱਕ ਵਾਕ ਵਿੱਚ ਸਮੱਸਿਆ ਲਿਖੋ। ਉਦਾਹਰਣ ਵਜੋਂ: ਮੈਂ ਆਪਣੀ ਰਿਟਰਨ ਪਾਲਿਸੀ ਬਾਰੇ ਤੇਜ਼, ਸਹੀ ਜਵਾਬ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ ਬਿਨਾਂ ਪੰਜ tabs ਖੋਲ੍ਹੇ, ਜਾਂ ਮੈਂ ਇੱਕ ਸਹੀ ਵੇਰਵੇ ਨਾਲ ਸਮਰਥਨ ਟਿਕਟ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਵਿੱਚ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ/ਚਾਹੁੰਦੀ ਹਾਂ।

ਇੱਕ ਚੈਕ: ਜੇ ਤੁਸੀਂ ਵਾਕ ਵਿੱਚੋਂ “ਚੈਟ” ਸ਼ਬਦ ਹਟਾ ਦਿਓ ਅਤੇ ਵਾਕ ਅਜੇ ਵੀ ਸਮਝ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਉਪਭੋਗਤਾ ਲੋੜ ਵਰਨਣ ਕਰ ਰਹੇ ਹੋ।

3–5 ਮੁੱਖ ਟਾਸਕ ਚੁਣੋ (ਅਤੇ ਬਾਕੀ ਨੂੰ ਅਜੇ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰੋ)

ਪਹਿਲੀ ਵਰਜਨ ਨੂੰ ਕੇਂਦਰਿਤ ਰੱਖੋ। ਉਹਨਾਂ ਕੁਝ ਹੀ ਟਾਸਕਾਂ ਦੀ ਚੋਣ ਕਰੋ ਜੋ ਤੁਹਾਡਾ ਅਸਿਸਟੈਂਟ end-to-end ਸੰਭਾਲੇ, ਉਦਾਹਰਣ ਵਜੋਂ:

• ਆਪਣੀ ਅਧਿਕਾਰਿਕ ਡੌਕਯੂਮੈਂਟੇਸ਼ਨ 'ਤੇ ਆਧਾਰਿਤ FAQs ਦੇ ਜਵਾਬ ਦਿਓ
• ਯੂਜ਼ਰ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਿੰਖੇਪ ਦਿਓ ਅਤੇ ਸਮਰਥਨ ਜਵਾਬ ਦਾ ਡਰਾਫਟ ਤਿਆਰ ਕਰੋ
• ਸਿਸਟਮ ਵਿੱਚ ਆਈਟਮ ਬਣਾਓ ਜਾਂ ਅੱਪਡੇਟ ਕਰੋ (ਟਿਕਟ, ਆਰਡਰ, CRM ਰਿਕਾਰਡ)
• ਕੁਝ ਵਰਕਫ਼ਲੋ ਦੁਆਰਾ ਯੂਜ਼ਰ ਨੂੰ ਗਾਈਡ ਕਰੋ (ਰਿਫੰਡ, ਓਨਬੋਰਡਿੰਗ, ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ)

ਹਰ ਟਾਸਕ ਲਈ ਇੱਕ ਸਪੱਸ਼ਟ “ਮੁਕੰਮਲ” ਹਾਲਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਅਸਿਸਟੈਂਟ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕੇਗਾ, ਤਾਂ ਉਹ ਇੱਕ ਡੈਮੋ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਵੇਗਾ ਨਾ ਕਿ ਇੱਕ AI ਐਪ।

ਮਾਪਯੋਗ ਸਫਲਤਾ ਮੈਟਰਿਕਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਵੇਂ ਜਾਣੋਂਗੇ ਕਿ ਅਸਿਸਟੈਂਟ ਵਰਕ ਕਰ ਰਿਹਾ ਹੈ। ਕਾਰੋਬਾਰੀ ਅਤੇ ਗੁਣਵੱਤਾ ਮੈਟਰਿਕਸ ਮਿਸ਼ਰਿਤ ਕਰੋ:

• ਬਚਾਇਆ ਸਮਾਂ: ਟਾਸਕ ਪੂਰਾ ਕਰਨ ਲਈ ਔਸਤ ਸਮਾਂ ਬਨਾਮ ਬੇਸਲਾਈਨ
• ਰੈਜ਼ੋਲੂਸ਼ਨ ਰੇਟ: % ਗੱਲਬਾਤਾਂ ਜਿਹੜੀਆਂ ਯੂਜ਼ਰ ਲਕੜੀ ਨੂੰ ਹਾਸਲ ਕਰਨ ਨਾਲ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ
• ਇਸਕੇਲੇਸ਼ਨ ਰੇਟ: ਕਿੰਨੀ ਵਾਰੀ ਯੂਜ਼ਰਾਂ ਨੂੰ ਫਿਰ ਵੀ ਇਨਸਾਨੀ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ
• CSAT ਜਾਂ ਥੰਬਜ਼ ਉੱਪ/ਡਾਊਨ: ਮੁੱਖ ਇੰਟਰੈਕਸ਼ਨਾਂ ਦੇ ਬਾਅਦ ਸਾਦਾ ਉਪਭੋਗਤਾ ਫੀਡਬੈਕ
• ਕੁਆਲਟੀ ਸਪੌਟ ਚੈਕਸ: ਨਮੂਨੇ ਤੌਰ 'ਤੇ ਚਾਰਚਾਂ ਦੀ ਸਮੀਖਿਆ ਇੱਕ ਰਬਰਿਕ ਦੇ ਖਿਲਾਫ਼

ਹਰ ਮੈਟਰਿਕ ਲਈ ਸ਼ੁਰੂਆਤੀ ਟਾਰਗੇਟ ਚੁਣੋ। ਭੀੜੇ ਟਾਰਗੇਟ ਵੀ ਪ੍ਰੋਡਕਟ ਫੈਸਲੇ ਆਸਾਨ ਕਰ ਦਿੰਦੇ ਹਨ।

ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਸੀਮਾਵਾਂ ਲਿਖੋ (ਤਾਂ ਜੋ ਬਾਅਦ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਨਾ ਕਰਨਾ ਪਵੇ)

ਉਹ ਬਾਊਂਡਰੀ ਲਿਖੋ ਜੋ ਹੋਰ ਸਭ ਚੀਜ਼ਾਂ ਨੂੰ ਰੂਪ ਦੇਣਗੀਆਂ:

• ਲੇਟੈਂਸੀ: ਕੀ ответа ਦਾ ਸਮਾਂ ਤੁਹਾਡੇ ਉਤਪਾਦ ਵਿੱਚ ਕਬੂਲਯੋਗ ਲੱਗੇਗਾ
• ਬਜਟ: ਇਕ ਗੱਲਬਾਤ ਜਾਂ ਪ੍ਰਤੀ ਸਚਿਵ ਉਪਭੋਗਤਾ ਦੀ ਲਾਗਤ
• ਪ੍ਰਾਈਵੇਸੀ ਅਤੇ ਅਨੁਕੂਲਤਾ: ਮਾਡਲ ਕਿਸ ਡਾਟਾ ਨੂੰ ਦੇਖ ਸਕਦਾ/ਸਕਦੀ, ਸਟੋਰ ਕਰ ਸਕਦਾ/ਸਕਦੀ, ਜਾਂ ਲੌਗ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹੈ
• ਸਹਾਇਤ ਕੀਤੀਆਂ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਟੋਨ: ਤੁਹਾਡੇ ਦਰਸ਼ਕ ਲਈ “ਚੰਗਾ” ਕਿਵੇਂ ਸੁਣਦਾ ਹੈ

ਇੱਕ ਸਾਫ਼ ਉਪਯੋਗ ਮਾਮਲੇ, ਛੋਟੀ ਟਾਸਕ ਲਿਸਟ, ਮਾਪਯੋਗ ਮੈਟਰਿਕਸ ਅਤੇ ਸਪੱਸ਼ਟ ਸੀਮਾਵਾਂ ਨਾਲ, ਬਾਕੀ LLM ਚੈਟ ਨਿਰਮਾਣ ਪ੍ਰਯੋਗਿਕ ਟਰੇਡ-ਆਫ਼ ਬਣ ਜਾਂਦੇ ਹਨ—ਅੰਦਾਜ਼ੇ ਨਹੀਂ।

ਆਪਣਾ LLM ਚੁਣੋ: Hosted API ਜਾਂ Self-Hosted

ਥੀਕ ਮਾਡਲ ਚੁਣਨਾ ਹਾਈਪ ਬਾਰੇ ਨਹੀਂ, ਫਿੱਟ ਬਾਰੇ ਹੈ: ਗੁਣਵੱਤਾ, ਰਫ਼ਤਾਰ, ਲਾਗਤ ਅਤੇ ਚਲਾਉਣੀ ਕੋਸ਼ਿਸ਼। ਤੁਹਾਡੀ ਚੋਣ UX ਤੋਂ ਲੈ ਕੇ ਜਾਰੀ ਰੱਖ-ਰਖਾਅ ਤੱਕ ਸਭ ਕੁਝ ਪ੍ਰਭਾਵਤ ਕਰੇਗੀ।

Hosted APIs (ਮੈਨੇਜਡ ਮਾਡਲ)

Hosted ਪ੍ਰੋਵਾਈਡਰ ਤੁਹਾਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਇੰਟਿਗਰੇਟ ਕਰਨ ਦਿੰਦੇ ਹਨ: ਤੁਸੀਂ ਟੈਕਸਟ ਭੇਜਦੇ ਹੋ, ਟੈਕਸਟ ਲੈਕੇ ਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਕੇਲਿੰਗ, ਅਪਡੇਟ ਅਤੇ ਹਾਰਡਵੇਅਰ ਸੰਭਾਲਦੇ ਹਨ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ AI ਐਪ ਵਿਕਾਸ ਲਈ ਬਹਿਤਰੀਨ ਸ਼ੁਰੂਆਤ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਪਣੇ LLM ਚੈਟ ਅਨੁਭਵ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਆਜ਼ਮਾਈਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪੂਰਾ ਇੰਫਰਾਸਟਰੱਕਚਰ ਟੀਮ ਬਣਾਏ।

ਟਰੇਡ-ਆਫ਼: ਸਕੇਲ 'ਤੇ ਪ੍ਰਾਈਸਿੰਗ ਵੱਧ ਹੋ ਸਕਦੀ ਹੈ, ਡਾਟਾ ਰਿਹਾਇਸ਼ੀ ਵਿਕਲਪ ਸੀਮਿਤ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਤੀਜੇ ਧਿਰ ਦੀ ਅਪটাইਮ ਅਤੇ ਨੀਤੀ ਉੱਤੇ ਨਿਰਭਰ ਰਹੋਗੇ।

Self-hosted / open models

ਖੁੱਲ੍ਹੇ ਮਾਡਲ ਨੂੰ ਖੁਦ ਚਲਾਉਣ ਨਾਲ ਡਾਟਾ ਹੈਂਡਲਿੰਗ, ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਉੱਚ ਵੋਲਿਊਮ 'ਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਘੱਟ ਮਾਰਜਿਨਲ ਲਾਗਤ 'ਤੇ ਵੱਧ ਨਿਯੰਤਰਣ ਮਿਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ on-prem ਡੀਪਲੋਇਮੈਂਟ ਜਾਂ ਸਖਤ ਗਵਰਨੈਂਸ ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਇਹ ਫायदੇਮੰਦ ਹੈ।

ਟਰੇਡ-ਆਫ਼: ਤੁਸੀਂ ਸਾਰਾ ਕੰਮ ਖੁਦ ਦੇਖਦੇ ਹੋ—ਮਾਡਲ ਸਰਵਿੰਗ, GPU ਕੈਪਾਸਿਟੀ ਯੋਜਨਾ, ਮਾਨੀਟਰਿੰਗ, ਅਪਗਰੇਡ ਅਤੇ ਇੰਸੀਡੈਂਟ ਰਿਸਪਾਂਸ। ਲੇਟੈਂਸੀ ਚੰਗੀ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਦੇ ਨੇੜੇ ਡਿਪਲੋਏ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਡੀ ਸਟੈਕ ਠੀਕ ਨਾ ਹੋਵੇ ਤਾਂ ਖਰਾਬ ਹੋ ਸਕਦੀ ਹੈ।

ਸੰਦੇਸ਼-ਵਿੰਡੋ: ਇਹਨੂੰ ਅਸਲ ਗੱਲਬਾਤਾਂ ਦੇ ਅਨੁਸਾਰ ਮੇਲ ਖਾਵੇ

ਕੰਟੈਕਸਟ ਜ਼ਿਆਦਾ ਨਾ ਖਰੀਦੋ। ਆਮ ਸੁਨੇਹੇ ਦੀ ਲੰਬਾਈ ਅਤੇ ਤੁਸੀਂ ਕਿੰਨੀ ਹਿਸਟਰੀ ਜਾਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸਮੱਗਰੀ ਸ਼ਾਮਲ ਕਰੋਗੇ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ। ਲੰਬਾ ਕੰਟੈਕਸਟ ਵਿੰਡੋ ਲਗਾਤਾਰਤਾ ਸੁਧਾਰ ਸਕਦਾ ਹੈ, ਪਰ ਅਕਸਰ ਇਹ ਲਾਗਤ ਅਤੇ ਲੇਟੈਂਸੀ ਵਧਾਉਂਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਚੈਟ ਫਲੋਜ਼ ਲਈ, ਛੋਟੀ ਵਿੰਡੋ ਅਤੇ ਵਧੀਆ retrieval RAG ਖ਼ਾਸ ਤੁਹਾਡੇ ਲਈ ਵੱਧ ਕੁਸ਼ਲ ਹੋਵੇਗੀ।

ਲਾਗਤ, ਲੇਟੈਂਸੀ ਅਤੇ ਗੁਣਵੱਤਾ ਵਿੱਚ ਸੰਤੁਲਨ

ਇੱਕ ਚੈਟਬੋਟ UI ਲਈ, ਲੇਟੈਂਸੀ ਇੱਕ ਫੀਚਰ ਹੈ: ਯੂਜ਼ਰ ਦੇਖਦੇ ਹੀ ਦੇਰੀ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਜਟਿਲ ਬੇਨਤੀਆਂ ਲਈ ਉੱਚ-ਗੁਣਵੱਤਾ ਮਾਡਲ ਤੇਜ਼-ਸਸਤਾ ਮਾਡਲ ਨਾਲ ਮਿਲਾਓ (ਸੰਖੇਪ, ਰੀਰਾਈਟਿੰਗ, ਕਲਾਸੀਫਿਕੇਸ਼ਨ ਲਈ)।

ਦਿਨ ਇੱਕ ਤੋਂ ਫਾਲਬੈਕ ਮਾਡਲ ਯੋਜਨਾ ਬਣਾਓ

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

ਸਧਾਰਨ, ਸਕੇਲ ਕਰਨਯੋਗ ਆਰਕੀਟੈਕਚਰ ਡਿਜ਼ਾਈਨ ਕਰੋ

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

ਸਿਸਟਮ ਨੂੰ ਤਿੰਨ ਸਾਫ਼ ਲੇਅਰਾਂ ਵਿੱਚ ਵੰਡੋ

1) Chat UI (ਕਲਾਇੰਟ ਲੇਅਰ)

ਫਰੰਟ ਐਂਡ ਨੂੰ ਇੰਟਰੈਕਸ਼ਨ ਪੈਟਰਨਾਂ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖੋ: ਸਟ੍ਰੀਮਿੰਗ ਜਵਾਬ, ਸੁਨੇਹੇ ਰੀਟ੍ਰਾਈ, ਅਤੇ ਸਾਈਟੇਸ਼ਨ ਜਾਂ ਟੂਲ ਨਤੀਜੇ ਦਿਖਾਉਣਾ। ਮਾਡਲ ਲੌਜਿਕ ਇੱਥੇ ਨਾ ਰੱਖੋ ਤਾਂ ਜੇ UI ਬਦਲਣਾ ਹੋਵੇ ਤਾਂ ਆਸਾਨੀ ਨਾਲ ਕਰ ਸਕੋ।

2) AI ਸਰਵਿਸ (API ਲੇਅਰ)

UI ਲਈ ਇੱਕ ਸਮਰਪਿਤ ਬੈਕਐਂਡ ਸਰਵਿਸ ਬਣਾਓ ਜੋ /chat, /messages, ਅਤੇ /feedback ਲਈ ਕਾਲ ਸਹੀਤ ਹੈ। ਇਹ ਸਰਵਿਸ ਪ੍ਰਮਾਣਿਕਤਾ, ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਰਿਕਵੈਸਟ ਸ਼ੇਪਿੰਗ (ਸਿਸਟਮ ਪ੍ਰਾਂਪਟ, ਫਾਰਮੈਟਿੰਗ ਨਿਯਮ) ਸੰਭਾਲੇ। ਇਸਨੂੰ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਅਤੇ ਕਿਸੇ ਵੀ ਮਾਡਲ ਵਿਚਕਾਰ ਇੱਕ ਸਥਿਰ ਕਾਂਟ੍ਰੈਕਟ ਵਜੋਂ ਮੰਨੋ।

3) Orchestration ਲੇਅਰ (AI ਸਰਵਿਸ ਦੇ ਅੰਦਰ ਜਾਂ ਵੱਖਰੀ ਸਰਵਿਸ ਵਜੋਂ)

ਇਥੇ “ਇੰਟੈਲਿਜੈਂਸ” ਸੰਭਾਲਯੋਗ ਬਣਦੀ ਹੈ: ਟੂਲ/ਫੰਕਸ਼ਨ ਕਾਲਿੰਗ, retrieval (RAG), ਨੀਤੀ ਚੈਕ ਅਤੇ ਆਉਟਪੁਟ ਵੈਲੀਡੇਸ਼ਨ। ਓਰਕੈਸਟ੍ਰੇਸ਼ਨ ਮੋਡੀਊਲਰ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਖੋਜ, ਟਿਕਟ ਬਣਾਉਣਾ, CRM ਅੱਪਡੇਟ ਵਰਗੀਆਂ ਯੋਗਤਾਵਾਂ ਜੋੜ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਪ੍ਰਾਂਪਟ ਟੈਕਸਟ ਨੂੰ ਗੂਥੇ।

ਜੇ ਤੁਸੀਂ UI + ਬੈਕਐਂਡ + ਡਿਪਲੋਇਮੈਂਟ ਤੇਜ਼ੀ ਨਾਲ ਬਣਾ ਕੇ ਪ੍ਰਾਂਪਟਸ, ਟੂਲ ਅਤੇ RAG 'ਤੇ ਇਟਰੈਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ vibe-coding ਪਲੈਟਫਾਰਮ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—ਫਿਰ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰੋ।

ਸਹੀ ਚੀਜ਼ਾਂ ਸਟੋਰ ਕਰੋ (ਸਿਰਫ ਸੁਨੇਹੇ ਨਹੀਂ)

ਗੱਲਬਾਤਾਂ ਸਟੋਰ ਕਰੋ, ਪਰ ਨਾਲ ਹੀ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ (ਪਸੰਦ, ਪਰਮਿਸ਼ਨ) ਅਤੇ ਇਵੈਂਟਸ (ਟੂਲ ਕਾਲ, RAG ਕਵੈਰੀਜ਼, ਮਾਡਲ ਵਰਤਿਆ, ਲੇਟੈਂਸੀ) ਵੀ ਰੱਖੋ। ਇਵੈਂਟ ਡਾਟਾ ਡਿਬਗਿੰਗ ਅਤੇ ਮੁਲਾਂਕਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ।

ਪਹਿਲੇ ਦਿਨ ਤੋਂ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ ਬਣਾਓ

ਸੰਰਚਿਤ ਪੇਲੋਡ ਮੈਟਾਡੇਟਾ ਲੌਗ ਕਰੋ (ਨਾਹ ਕਿ ਸੰਵੇਦਨਸ਼ੀਲ ਰੌ ਟੈਕਸਟ), ਮੈਟ੍ਰਿਕਸ ਕੈਪਚਰ ਕਰੋ (ਲੇਟੈਂਸੀ, ਟੋਕਨ ਉਪਯੋਗ, ਟੂਲ ਐਰਰ ਰੇਟ) ਅਤੇ UI → API → ਟੂਲਾਂ 'ਤੇ ਟਰੇਸਿੰਗ ਸ਼ਾਮਲ ਕਰੋ। ਜਦ ਕੁਝ ਟੁੱਟੇ ਤਾਂ ਤੁਹਾਨੂੰ ਉੱਤਰ ਚਾਹੀਦਾ ਹੈ: ਕਿਸ ਕਦਮ ਨੇ ਫੇਲ ਕੀਤਾ, ਕਿਹੜੇ ਯੂਜ਼ਰ ਲਈ, ਅਤੇ ਕਿਉਂ—ਬਿਨਾਂ ਅਨੁਮਾਨ ਲਗਾਏ।

ਪ੍ਰਾਂਪਟ ਅਤੇ ਆਉਟਪੁਟ ਮਿਆਰ ਬਣਾਓ

ਤੁਹਾਡਾ ਚੈਟ ਅਨੁਭਵ ਸਿਰਫ਼ 'ਸਮਾਰਟ' ਮਹਿਸੂਸ ਨਹੀਂ ਹੋਵੇਗਾ ਜਦੋਂ ਇਹ ਲਗਾਤਾਰ ਨਾ ਹੋਵੇ। ਪ੍ਰਾਂਪਟ ਅਤੇ ਆਉਟਪੁਟ ਮਿਆਰ ਉਹ ਕੰਟ੍ਰੈਕਟ ਹਨ ਜੋ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਟ ਅਤੇ ਮਾਡਲ ਦਰਮਿਆਨ ਹੁੰਦੇ ਹਨ: ਇਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਵੇਂ ਗੱਲ ਕਰੇ, ਅਤੇ ਆਉਟਪੁਟ ਕਿਸ ਰੂਪ ਵਿੱਚ ਹੋਵੇ ਤਾਂ ਤੁਹਾਡੀ ਐਪ ਉਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਵਰਤ ਸਕੇ।

ਸਪੱਸ਼ਟ ਸਿਸਟਮ ਨਿਰਦੇਸ਼ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਇੱਕ ਸਿਸਟਮ ਸੁਨੇਹਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਅਸਿਸਟੈਂਟ ਦੀ ਭੂਮਿਕਾ, ਸਕੋਪ ਅਤੇ ਟੋਨ ਸੈੱਟ ਕਰਦਾ ਹੈ। ਸਪੱਸ਼ਟ ਰੱਖੋ:

• ਭੂਮਿਕਾ: ਤੁਸੀਂ ਕਿਸ ਲਈ ਸਹਾਇਕ ਹੋ
• ਸਕੋਪ: ਕਿਸ ਵਿਸ਼ਿਆਂ 'ਤੇ ਜਵਾਬ ਦੇਣਾ ਹੈ ਅਤੇ ਕੌਣ ਤੋਂ ਇਨਕਾਰ ਕਰਨਾ ਹੈ
• ਟੋਨ: ਦੋਸਤਾਨਾ, ਸੰਖੇਪ, ਅਨੁਮਾਨ ਨਾ ਲਗਾਓ; ਜਰੂਰਤ ਹੋਵੇ ਤਾਂ ਸਪਸ਼ਟੀकरण ਦੀ ਮੰਗ ਕਰੋ

ਸਭ ਕੁਝ ਸਿਸਟਮ ਸੁਨੇਹੇ ਵਿੱਚ ਭਰਨਾ ਟਾਲੋ। ਸਥਿਰ ਨੀਤੀਆਂ ਅਤੇ ਵਰਤਾਰਾ ਉੱਥੇ ਰੱਖੋ; ਬਦਲਣ ਵਾਲਾ ਸਮੱਗਰੀ (ਯੂਜ਼ਰ ਡਾਟਾ ਜਾਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਕੰਟੈਕਸਟ) ਦੂਜੇ ਥਾਂ ਰੱਖੋ।

ਐਪ ਕਾਰਵਾਈਆਂ ਲਈ ਸੰਰਚਿਤ ਆਉਟਪੁਟ ਪ੍ਰਾਫ਼ਰ ਕਰੋ

ਜਦੋਂ UI ਨੂੰ ਨਤੀਜੇ ਰੇਂਡਰ ਕਰਨੇ ਹੋਣ (ਕਾਰਡ, ਟੇਬਲ, ਸਥਿਤੀ ਲੇਬਲ), ਤਾਂ ਪ੍ਰਾਕ੍ਰਿਤਿਕ ਭਾਸ਼ਾ ਇਕੱਲੀ ਹੋ ਕੇ ਕਈ ਵਾਰੀ ਨਾਜ਼ੁਕ ਹੁੰਦੀ ਹੈ। ਸੰਰਚਿਤ ਆਉਟਪੁਟ ਵਰਤੋਂ—ਆਦਰਸ਼ ਤੌਰ 'ਤੇ JSON ਸਕੀਮਾ—ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ deterministic ਤਰੀਕੇ ਨਾਲ ਆਉਟਪੁਟ ਪਾਰਸ ਕਰ ਸਕੇ।

ਉਦਾਹਰਣ: ਇੱਕ ਟਾਰਗੇਟ ਸਕੀਮਾ ਜਿਵੇਂ { answer: string, next_steps: string[], citations: { title: string, url: string }[] } ਰੱਖੋ। ਪਹਿਲਾਂ ਕੜਾਈ ਨਾਲ ਵੈਲਿਡੇਟ ਨਾ ਵੀ ਕਰੋ, ਪਰ ਇੱਕ ਲਕੜੀ ਟਾਰਗੇਟ ਸਕੀਮਾ ਰਹਿਣ ਨਾਲ ਅਚਾਨਕ ਚੀਜ਼ਾਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ।

ਗਾਰਡਰੇਲਜ਼ ਸ਼ਾਮਲ ਕਰੋ: ਇਨਕਾਰ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਵਿਹਾਰ

ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਅਸਿਸਟੈਂਟ ਨੂੰ ਇਨਕਾਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹਨ, ਜਿਹੜੀਆਂ ਨੂੰ ਪੁਸ਼ਟੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਜਿਹੜੀਆਂ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ—ਇਹਨਾਂ ਲਈ ਸਪਸ਼ਟ ਨਿਯਮ ਲਿਖੋ। ਸੇਫ਼ ਡਿਫਾਲਟ ਸ਼ਾਮਲ ਕਰੋ:

• ਜੇ ਮੁੱਖ ਜਾਣਕਾਰੀ ਘੱਟ ਹੈ ਤਾਂ ਸਪਸ਼ਟੀਕਾਰਕ ਪ੍ਰਸ਼ਨ ਪੁੱਛੋ
• ਜੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਜਾਂ ਮਨ੍ਹਾਂ ਕੀਤੇ ਬੇਨਤੀਆਂ ਆਉਂਦੀਆਂ ਹਨ ਤਾਂ ਇਨਕਾਰ ਕਰੋ ਅਤੇ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਦਿਓ
• ਜੇ ਅਣਨਿਸ਼ਚਿਤ ਹੈ ਤਾਂ ਏਸ ਦੀ ਜਾਣਕਾਰੀ ਦਿਓ ਅਤੇ ਤਸਦੀਕ ਕਰਨ ਦਾ ਤਰੀਕਾ ਸੁਝਾਓ

ਸਲਾਟਾਂ ਵਾਲਾ ਪ੍ਰਾਂਪਟ ਟੇਮਪਲੇਟ ਬਣਾਓ

ਇੱਕ ਦੁਹਰਾਓਗੋਗ ਟੇਮਪਲੇਟ ਵਰਤੋਂ ਤਾਂ ਜੋ ਹਰ ਰਿਕਵੈਸਟ ਇੱਕੋ ਢਾਂਚੇ ਵਿੱਚ ਹੋਵੇ:

• System: ਨਿਰਦੇਸ਼ ਅਤੇ ਨੀਤੀਆਂ
• User: ਯੂਜ਼ਰ ਦਾ ਸੁਨੇਹਾ
• Context: ਸਬੰਧਤ ਤੱਥ (ਸਿਰਫ਼ ਜਰੂਰੀ)
• Tools: ਉਪਲਬਧ ਕਾਰਵਾਈਆਂ + ਸੀਮਾਵਾਂ

ਇਹ ਵੰਡ ਪ੍ਰਾਂਪਟਸ ਨੂੰ ਡੀਬੱਗ, ਮੁਲਾਂਕਣ ਅਤੇ ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੀ ਹੈ ਬਿਨਾਂ ਕੁਝ ਟੁੱਟੇ।

ਅਸਲ ਕਾਰਵਾਈਆਂ ਲਈ ਟੂਲ ਅਤੇ ਫੰਕਸ਼ਨ ਕਾਲਿੰਗ ਜੋੜੋ

ਚੈਟ ਅਨੁਭਵ ਅਸਲ ਵਿੱਚ ਫਾਇਦੇਮੰਦ ਤਾਂ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਹ ਕਾਰਵਾਈਆਂ ਕਰ ਸਕੇ: ਟਿਕਟ ਬਣਾਉਣਾ, ਆਰਡਰ ਲੱਭਣਾ, ਮੀਟਿੰਗ ਨਿਰਧਾਰਿਤ ਕਰਨੀ, ਜਾਂ ਈਮੇਲ ਡਰਾਫਟ ਕਰਨੀ। ਮੁੱਖ ਗੱਲ: ਮਾਡਲ ਨੂੰ ਕਾਰਵਾਈਆਂ ਸੁਝਾਉਣ ਦਿਓ, ਪਰ ਜੋ ਅਸਲ ਰਨ ਹੋਵੇ ਉਹ ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਹੋਵੇ।

AI ਨੂੰ ਕਿਹੜੀਆਂ ਕਾਰਵਾਈਆਂ ਟ੍ਰਿਗਰ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ, ਨਿਰਧਾਰਿਤ ਕਰੋ

ਪਹਿਲਾਂ ਇੱਕ ਤੰਗ, ਸਪਸ਼ਟ ਕਾਰਵਾਈਆਂ ਦੀ ਸੂਚੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਆਗਿਆਤਿਆ ਜਾ ਸਕਦੀਆਂ ਹਨ, ਉਦਾਹਰਣ:

• ਅੰਦਰੂਨੀ ਨੋਲੇਜ਼ ਖੋਜਨਾ (readonly)
• ਖਾਤਾ ਜਾਂ ਆਰਡਰ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕਰਨਾ (readonly, scoped)
• ਸਪੋਰਟ ਟਿਕਟ ਜਾਂ CRM ਨੋਟ ਬਣਾਉਣਾ
• ਸਮਿੱਟ ਲਈ ਡਰਾਫਟ ਤਿਆਰ ਕਰਨਾ (ਈਮੇਲ, ਐਲਾਨ, ਚੈਕਲਿਸਟ)
• ਘਟਨਾ ਨਿਰਧਾਰਿਤ ਕਰਨਾ/ਪੁਨਰਨਾਂਧਿਤ ਕਰਨਾ (ਸੀਮਾਵਾਂ ਨਾਲ)
• ਰਿਫੰਡ/ਕ੍ਰੈਡਿਟ ਬੇਨਤੀ ਸ਼ੁਰੂ ਕਰਨਾ (ਕਦੇ ਵੀ ਆਟੋ-ਅਪ੍ਰੂਵ ਨਾ ਕਰੋ)

ਜੇ ਕੋਈ ਕਾਰਵਾਈ ਪੈਸੇ, ਐਕਸੈਸ ਜਾਂ ਡਾਟਾ ਵਿਖਾਈ ਵਿੱਚ ਬਦਲਾਅ ਕਰਦੀ ਹੈ, ਤਾਂ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਉਸਨੂੰ “ਖਤਰਨਾਕ” ਮੰਨੋ।

ਭਰੋਸੇਯੋਗ ਆਪਰੇਸ਼ਨਾਂ ਲਈ ਫੰਕਸ਼ਨ ਕਾਲਿੰਗ ਵਰਤੋ

ਮਾਡਲ ਨੂੰ “API ਰਿਕਵੈਸਟ ਲਿਖੋ” ਪੁੱਛਣ ਦੀ ਥਾਂ, ਛੋਟੀ ਟੂਲ ਸੈੱਟ ਜਿਵੇਂ get_order_status(order_id) ਜਾਂ create_ticket(subject, details) ਪ੍ਰਦਾਨ ਕਰੋ। ਮਾਡਲ ਟੂਲ ਦਿੱਸਦਾ ਹੈ ਅਤੇ ਸੰਰਚਿਤ arguments ਭੇਜਦਾ ਹੈ; ਤੁਹਾਡਾ ਸਰਵਰ ਉਸਨੂੰ ਚਲਾਉਂਦਾ ਅਤੇ ਨਤੀਜੇ ਵਾਪਸ ਕਰਦਾ ਹੈ ਤਾਂ ਗੱਲਬਾਤ ਜਾਰੀ ਰਹੇ।

ਇਸ ਨਾਲ ਗਲਤੀਆਂ ਘੱਟ ਹੁੰਦੀਆਂ ਹਨ, ਵਿਹਾਰ ਪੇਸ਼ਗੋਈਯੋਗ ਬਣਦਾ ਹੈ, ਅਤੇ ਕੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਦਾ ਆਡੀਟ ਲੌਗ ਬਣਦਾ ਹੈ।

ਸਰਵਰ 'ਤੇ ਵੈਰੀਫਾਈ ਅਤੇ ਅਧਿਕਾਰ ਲਗਾਓ

ਟੂਲ arguments 'ਤੇ ਕਦੇ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਹਰ ਕਾਲ 'ਤੇ:

• ਇਨਪੁੱਟ ਵੇਰੀਫਾਈ ਕਰੋ (ਟਾਈਪ, ਫਾਰਮੈਟ, ਜਰੂਰੀ ਫੀਲਡ, ਰੇਂਜ)
• ਪਰਮਿਸ਼ਨਾਂ ਲਾਗੂ ਕਰੋ (ਕੌਣ ਕੀ ਦੇਖ ਸਕਦਾ/ਕਰੇ, ਕਿਸ کسਟਮਰ/ਟੈਨੈਂਟ ਲਈ)
• ਰੇਟ ਲਿਮਿਟ ਅਤੇ idempotency ਲਗਾਓ (ਡੁਪਲਿਕੇਟ ਕਾਰਵਾਈਆਂ ਤੋਂ ਬਚਣ ਲਈ)

ਮਾਡਲ ਸਲਾਹ ਦੇਵੇ; ਤੁਹਾਡਾ ਬੈਕਐਂਡ ਪਰਖੇ।

ਖਤਰਨਾਕ ਕਾਰਵਾਈਆਂ ਲਈ ਪੁਸ਼ਟੀ ਜੋੜੋ

ਕਿਸੇ ਵੀ ਅਪਰਿਵਰਤਨਯੋਗ ਜਾਂ ਉੱਚ-ਪ੍ਰਭਾਵ ਵਾਲੇ ਕਦਮ ਲਈ, ਇੱਕ ਮਨੁੱਖ-ਮਿੱਤਰ ਪੁਸ਼ਟੀ ਦਿਖਾਓ: ਛੋਟਾ ਸਾਰ, ਕੀ ਹੋਵੇਗਾ, ਕਿਹੜਾ ਡਾਟਾ ਪ੍ਰਭਾਵਿਤ ਹੋਵੇਗਾ, ਅਤੇ ਸਪਸ਼ਟ “Confirm / Cancel” ਚੋਣ। ਉਦਾਹਰਣ: “ਮੈਂ Order #1842 ਲਈ $50 ਕਰੈਡਿਟ ਦੀ ਬੇਨਤੀ ਕਰਨ ਵਾਲਾ ਹਾਂ। ਪੁਸ਼ਟੀ ਕਰੋ?”

ਆਪਣੇ ਡਾਟਾ ਨੂੰ retrieval (RAG) ਨਾਲ ਜੋੜੋ

ਜੇ ਤੁਹਾਡੇ ਚੈਟ ਅਨੁਭਵ ਨੂੰ ਤੁਹਾਡੇ ਉਤਪਾਦ, ਨੀਤੀਆਂ ਜਾਂ ਗਾਹਕ ਇਤਿਹਾਸ ਬਾਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣੇ ਹੋਣ, ਤਾਂ ਸਾਰਾ ਗਿਆਨ ਪ੍ਰਾਂਪਟਸ ਵਿੱਚ ਨਹੀਂ ਭਾਰੋ ਜਾਂ ਮਾਡਲ ਦੀ ਆਮ ਟਰੇਨਿੰਗ 'ਤੇ ਨਿਰਭਰ ਨਾ ਰਹੋ। Retrieval-Augmented Generation (RAG) ਤੁਹਾਡੇ ਐਪ ਨੂੰ ਆRuntime 'ਤੇ ਸਭ ਤੋਂ ਪ੍ਰਸੰਗਿਕ ਸੁੱਟੀਆਂ ਖੋਜਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ LLM ਉਹਨਾਂ ਸੰਦਰਭਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਕੀ retrieve ਕਰਨਾ ਹੈ ਅਤੇ ਕੀ hardcode, ਫੈਸਲਾ ਕਰੋ

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਵੰਡ:

• Hardcode: ਸਥਿਰ ਨਿਯਮ ਅਤੇ ਵਰਤਾਰਾ: ਟੋਨ, ਇਨਕਾਰ ਨਿਯਮ, ਫਾਰਮੈਟਿੰਗ, ਅਤੇ “ਹਮੇਸ਼ਾਂ ਸੱਚ” ਤੱਥ (ਜਿਵੇਂ ਸਪੋਰਟ ਘੰਟੇ)
• Retrieve: ਉਹ ਸਮੱਗਰੀ ਜੋ ਬਦਲਦੀ ਰਹਿੰਦੀ ਹੈ ਜਾਂ ਬਹੁਤ ਵੱਡੀ ਹੈ: ਹੈਲਪ ਡੌਕਸ, ਇੰਟਰਨਲ ਵਿਕੀ, ਰਿਲੀਜ਼ ਨੋਟ, ਪ੍ਰਾਈਸਿੰਗ ਟੇਬਲਾਂ, ਕੰਟ੍ਰੈਕਟ, ਅਤੇ FAQs

ਇਸ ਨਾਲ ਪ੍ਰਾਂਪਟ ਸਧਾਰਨ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਅਸਿਸਟੈਂਟ ਗ਼ਲਤ ਭਰੋਸਾ ਨਾਲ ਜ਼ਿਆਦਾ ਨਹੀਂ ਬੋਲਦਾ।

ਉੱਚ-ਗੁਣਵੱਤਾ retrieval ਲਈ ਡੌਕਸ ਤਿਆਰ ਕਰੋ

RAG ਦੀ ਗੁਣਵੱਤਾ preprocessing 'ਤੇ ਬਹੁਤ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:

• ਸਾਫ਼ ਟੈਕਸਟ: ਨੈਵੀਗੇਸ਼ਨ, ਕੁਕੀ ਬੈਨਰ, ਦੁਹਰਾਏ ਫੁੱਟਰ ਅਤੇ ਖਰਾਬ OCR ਹਟਾਓ
• ਚੰਕੀੰਗ: ਸਮੱਗਰੀ ਨੂੰ ਛੋਟੇ, ਸਮਝਦਾਰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ (ਅਕਸਰ ਕੁਝ ਪੈਰਾਗ੍ਰਾਫ)। ਬਹੁਤੇ ਵੱਡੇ ਚੰਕ ਪ੍ਰਸੰਗਿਕਤਾ ਘਟਾਉਂਦੇ ਹਨ; ਬਹੁਤ ਛੋਟੇ ਚੰਕ ਸੰਦਰਭ ਘੱਟ ਕਰ ਦਿੰਦਿਆਂ ਹਨ
• ਮੈਟਾਡੇਟਾ: ਸਰੋਤ ਰਾਹ, ਉਤਪਾਦ ਖੇਤਰ, ਵਰਜਨ/ਤਾਰੀਖ, ਦਰਸ਼ਕ ਅਤੇ ਪਹੁੰਚ ਪੱਧਰ ਜਿਵੇਂ ਫੀਲਡ ਸਟੋਰ ਕਰੋ। ਮੈਟਾਡੇਟਾ ਫਿਲਟਰਿੰਗ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ (ਉਦਾਹਰਨ: “ਕੇਵਲ v2 ਡੌਕਸ ਲਿਆਉ”)

ਐਮਬੈਡਿੰਗ ਅਤੇ ਵੈਕਟਰ ਸਟੋਰ ਚੁਣੋ

ਹਰ ਚੰਕ ਲਈ ਐਮਬੈਡਿੰਗ ਬਣਾਕੇ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਵੈਕਟਰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰੋ। ਆਪਣੀਆਂ ਭਾਸ਼ਾਂ ਅਤੇ ਡੋਮੇਨ ਦੇ ਮੁਤਾਬਕ ਐਮਬੈਡਿੰਗ ਮਾਡਲ ਚੁਣੋ। ਫਿਰ ਇੱਕ ਸਟੋਰੇਜ ਪਹੁੰਚ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਸਕੇਲ ਅਤੇ ਸੀਮਾਵਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋ:

• ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਵੈਕਟਰ ਸਟੋਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
• ਜੇ ਸਖਤ ਡਾਟਾ ਕੰਟਰੋਲ ਜਾਂ ਕਸਟਮ ਪ੍ਰਦਰਸ਼ਨ ਲੋੜੀਂਦਾ ਹੋਵੇ ਤਾਂ Self-hosted 'ਤੇ ਜਾਓ

ਯੂਜ਼ਰਾਂ ਲਈ ਭਰੋਸੇਯੋਗ citations ਡਿਜ਼ਾਈਨ ਕਰੋ

RAG ਜਵਾਬ ਉਸ ਵੇਲੇ ਜ਼ਿਆਦਾ ਭਰੋਸੇਯੋਗ ਹੁੰਦੇ ਹਨ ਜਦ ਯੂਜ਼ਰ ਉਹਨਾਂ ਨੂੰ ਪਰਖ ਸਕਣ। ਜਵਾਬ ਦੇ ਨਾਲ citaions ਵਾਪਸ ਕਰੋ: ਦਸਤਾਵੇਜ਼ ਦਾ ਸਿਰਲੇਖ ਅਤੇ ਛੋਟਾ ਨਖਰਾ ਦਿਖਾਓ, ਅਤੇ ਸਰੋਤ ਨੂੰ /docs/refunds ਵਰਗੇ ਸਾਪੇਛੇ ਰਾਹ ਦਿਖਾਓ। ਜੇ ਤੁਸੀਂ ਲਿੰਕ ਨਹੀਂ ਦੇ ਸਕਦੇ (private docs), ਤਾਂ ਇੱਕ ਸਪੱਸ਼ਟ ਸਰੋਤ ਲੇਬਲ ਦਿਖਾਓ (“Policy: Refunds v3, updated 2025-09-01”).

ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਹੋਵੇ ਤਾਂ, RAG ਤੁਹਾਡੇ LLM ਚੈਟ ਨੂੰ ਨਿਆਜ਼ਮੰਦ, ਅਜੋਕਾ ਅਤੇ ਆਡੀਟ ਕਰਨ ਯੋਗ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਗੱਲਬਾਤੀ ਯਾਦਦਾਸ਼ਤ ਅਤੇ ਨਿੱਜੀਕਰਨ

ਮੈਮੋਰੀ ਚੈਟ ਨੂੰ ਇੱਕ ਲੰਬੀ ਰਿਸ਼ਤੇਦਾਰਾਈ ਮਹਿਸੂਸ ਕਰਾਉਂਦੀ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਵਾਰ ਦੀ Q&A। ਇਹ ਇੱਕ ਆਸਾਨ ਜਗ੍ਹਾ ਹੈ ਜਿਥੇ ਤੁਸੀਂ ਅਚਾਨਕ ਲਾਗਤ ਵਧਾ ਸਕਦੇ ਹੋ ਜਾਂ ਗਲਤ ਡਾਟਾ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ। ਸਧਾਰਨ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਹ ਰਣਨੀਤੀ ਚੁਣੋ ਜੋ ਤੁਹਾਡੇ ਕੇਸ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੋ।

ਮੈਮੋਰੀ ਸ਼੍ਰੈਣੀ ਨਿਰਧਾਰਿਤ ਕਰੋ

ਅਕਸਰ ਐਪ ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਚ ਫਿੱਟ ਹੁੰਦੇ ਹਨ:

• ਕੋਈ ਮੈਮੋਰੀ ਨਹੀਂ: ਹਰ ਸੁਨੇਹਾ ਅਲੱਗ ਰਿਹਾ ਜਾਂਦਾ ਹੈ। ਸੰਵੇਦਨਸ਼ੀਲ ਵਿਸ਼ਿਆਂ ਜਾਂ ਇੱਕ-ਵਾਰੀ ਟਾਸਕ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ
• ਛੋਟੀ-ਅਵਧੀ ਮੈਮੋਰੀ (ਸੈਸ਼ਨ): ਐਕਟਿਵ ਚੈਟ ਦੌਰਾਨ ਹਾਲੀਆ ਟਰਨ ਰੱਖੋ (ਜਾਂ ਸੰਖੇਪ)। ਅਸਿਸਟੈਂਟ ਅਤੇ ਸਪੋਰਟ ਫਲੋਜ਼ ਲਈ ਵਧੀਆ ਡਿਫਾਲਟ
• ਲੰਬੀ-ਅਵਧੀ ਪ੍ਰੋਫਾਈਲ: ਸਥਿਰ ਪਸੰਦਾਂ ਰੱਖੋ (ਟੋਨ, ਟਾਈਮਜ਼ੋਨ, ਪ੍ਰੋਡਕਟ ਪਲੈਨ, “ਮੈਨੂੰ Alex ਕਹੋ”)। ਵਿਅਕਤੀਗਤਕਰਨ ਲਈ ਲਾਭਦਾਇਕ ਪਰ ਇਸਨੂੰ ਤੇਜ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ

ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ: ਛੋਟੀ-ਅਵਧੀ ਸੰਖੇਪ + वैकल्पिक ਲੰਬੀ-ਅਵਧੀ ਪ੍ਰੋਫਾਈਲ: ਮਾਡਲ ਸੰਦਰਭ-ਜਾਣੂ ਰਹਿੰਦਾ ਹੈ ਬਿਨਾਂ ਪੂਰੇ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਘੁੰਮਣ ਦੇ।

ਸਿਰਫ਼ ਜਰੂਰੀ ਚੀਜ਼ ਸਟੋਰ ਕਰੋ (ਅਤੇ ਡਿਫਾਲਟ ਤੌਰ 'ਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਤੋਂ ਬਚੋ)

ਪ੍ਰਸਥਾਪਿਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਪਿਛੇ ਰੱਖਦੇ ਹੋ। ਕਦੇ ਵੀ ਰੀਂ ਟ੍ਰਾਂਸਕ੍ਰਿਪਟਾਂ ਸੇਵ ਨਾ ਕਰੋ “ਕਿਉਂਕਿ ਸ਼ਾਇਦ ਲੋੜ ਪਏਗੀ।” ਸੰਰਚਿਤ ਫੀਲਡ ਪ੍ਰੈਫਰ ਕਰੋ (ਜਿਵੇਂ ਪ੍ਰਿਫਰਡ ਭਾਸ਼ਾ) ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ, ਸਿਹਤ ਜਾਣਕਾਰੀ, ਭੁਗਤਾਨ ਡੇਟਾ ਜਾਂ ਉਹ ਕੁਛ ਜੋ ਤੁਸੀਂ ਨਿਆਂਸਪੂਰਵਕ ਨਹੀਂ ਜਸਟਿਫਾਈ ਕਰ ਸਕਦੇ ਪਾਸੇ ਰੱਖੋ।

ਜੇ ਤੁਸੀਂ ਮੈਮੋਰੀ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਆਪਰੇਸ਼ਨਲ ਲੌਗ ਤੋਂ ਵੱਖ ਕਰੋ ਅਤੇ ਰਿਟੇਨਸ਼ਨ ਨਿਯਮ ਲਗਾਓ।

ਟੋਕਨ ਲਾਗਤ ਕੱਟਣ ਲਈ ਪੁਰਾਣੀਆਂ ਟਰਨਾਂ ਨੰੂ ਸੰਖੇਪ ਕਰੋ

ਜਿਵੇਂ-ਜਿਵੇਂ ਗੱਲਬਾਤ ਵਧਦੀ ਹੈ, ਟੋਕਨ ਉਪਯੋਗ (ਅਤੇ ਲੇਟੈਂਸੀ) ਵਧਦਾ ਹੈ। ਪੁਰਾਣੀਆਂ ਸੁਨੇਹਿਆਂ ਨੂੰ ਕੁਝ ਸੰਗ੍ਰਹਿਤ ਨੋਟ ਵਿੱਚ ਸੰਖੇਪ ਕਰੋ, ਜਿਵੇਂ:

• ਯੂਜ਼ਰ ਲਕੜੀ
• ਕੀ ਫੈਸਲੇ ਕੀਤੇ ਗਏ
• ਸੀਮਾਵਾਂ ਅਤੇ ਪਸੰਦਾਂ
• ਖੁਲ੍ਹੇ ਪ੍ਰਸ਼ਨ

ਫਿਰ ਸਿਰਫ ਹਾਲੀਆ ਕੁਝ ਟਰਨਾਂ ਅਤੇ ਸੰਖੇਪ ਰੱਖੋ।

ਯੂਜ਼ਰਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਦਿਓ

UI ਵਿੱਚ ਸਾਫ਼ ਨਿਯੰਤਰ ਸ਼ਾਮਲ ਕਰੋ:

• Clear chat (ਸੈਸ਼ਨ ਮੈਮੋਰੀ ਖਤਮ ਕਰਦਾ ਹੈ)
• Delete history (ਸੰਭਾਲੇ ਡਾਟਾ ਹਟਾਉਂਦਾ ਹੈ)
• Export data (ਭਰੋਸਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਮਦਦ ਕਰਦਾ ਹੈ)

ਇਹ ਛੋਟੀ ਫੀਚਰਸ ਸੁਰੱਖਿਆ, ਕਨਪਲਾਇੰਸ ਅਤੇ ਯੂਜ਼ਰ ਭਰੋਸੇ ਨੂੰ ਬਹੁਤ ਬਹਤਰ ਬਨਾਉਂਦੇ ਹਨ।

ਚੈਟ UI ਅਤੇ ਇੰਟਰੈਕਸ਼ਨ ਪੈਟਰਨ ਬਣਾਓ

ਚੰਗਾ LLM ਚੈਟ ਅਨੁਭਵ ਮੁੱਖ ਤੌਰ 'ਤੇ UX ਹੈ। ਜੇ ਇੰਟਰਫੇਸ ਅਸਪਸ਼ਟ ਜਾਂ ਧੀਮਾ ਹੈ, ਤਾਂ ਯੂਜ਼ਰ ਜਵਾਬਾਂ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ—ਭਾਵੇਂ ਮਾਡਲ ਸਹੀ ਕਹਿੰਦਾ ਹੋਵੇ।

ਕੋਰ ਚੈਟ UI: ਬੁਨਿਆਦੀ ਗੱਲਾਂ ਸਪਸ਼ਟ ਰੱਖੋ

ਸਧਾਰਨ ਲੇਆਉਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਇੱਕ ਸਪਸ਼ਟ ਇਨਪੁਟ ਬਾਕਸ, ਸਪਸ਼ਟ ਸੈਂਡ ਬਟਨ, ਅਤੇ ਸੁਨੇਹੇ ਜੋ ਆਸਾਨੀ ਨਾਲ ਸਕੈਨ ਕੀਤੇ ਜਾ ਸਕਣ।

ਸੁਨੇਹਾ ਹਾਲਤ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਹਰ ਵੇਲੇ ਜਾਣ ਸਕਣ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ:

• Sending… (ਮੇਸੇਜ ਰਾਹ 'ਤੇ ਹੈ)
• Streaming… (ਅਸਿਸਟੈਂਟ ਟਾਈਪ ਕਰ ਰਿਹਾ/ਰਿਹੀ ਹੈ)
• Done (ਅੰਤਿਮ ਜਵਾਬ)
• Failed (ਰੀਟ੍ਰਾਈ ਦੀ ਲੋੜ)

ਲੰਬੀਆਂ ਗੱਲਬਾਤਾਂ ਲਈ ਟਾਈਮਸਟੈਂਪ (ਘੱਟੋ-ਘੱਟ ਪ੍ਰਤੀ ਸੁਨੇਹਾ ਗਰੁੱਪ) ਅਤੇ ਸੁਕੜੇ ਵਿਭਾਜਕ ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਯੂਜ਼ਰਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸ ਆ ਕੇ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਸਟ੍ਰੀਮਿੰਗ ਜਵਾਬ: ਯੂਜ਼ਰ ਤੇਜ਼ੀ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ

ਕੁੱਲ ਜਨਰੇਸ਼ਨ ਸਮਾਂ ਇੱਕੋ ਹੀ ਹੋਵੇ, ਫਿਰ ਵੀ ਸਟ੍ਰੀਮਿੰਗ ਟੋਕਨ ਐਪ ਨੂੰ ਤੇਜ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। ਤੁਰੰਤ ਟਾਈਪਿੰਗ ਨਿਰਦੇਸ਼ ਦਿਖਾਓ, ਫਿਰ ਜਿਵੇਂ-ਜਿਵੇਂ ਆਉਂਦਾ ਹੈ ਸੀਮਾ ਦੀ ਟੋਕਨ ਸਟ੍ਰੀਮ ਕਰੋ। “Stop generating” ਵੀ ਸਮਰਥਿਤ ਕਰੋ ਤਾਂ ਯੂਜ਼ਰ ਕੰਟਰੋਲ ਮਹਿਸੂਸ ਕਰ ਸਕੇ—ਖਾਸ ਕਰਕੇ ਜਦ ਜਵਾਬ ਠੀਕ ਰਸਤੇ ਤੋਂ ਭਟਕ ਜਾਵੇ।

ਮਦਦਗਾਰ ਪੈਟਰਨ: ਲੋਕਾਂ ਨੂੰ ਗਾਈਡ ਕਰੋ ਬਿਨਾਂ ਰਾਹ ਵਿੱਚ ਆਏ

ਕਈ ਯੂਜ਼ਰ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਕੀ ਪੁੱਛਣਾ ਹੈ। ਕੁਝ ਹਲਕੇ-ਫੁਲਕੇ ਸਹਾਇਕ ਤੁਹਾਡੇ ਸੈਸ਼ਨ ਸਫਲਤਾ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਨ:

• ਇਨਪੁਟ ਹੇਠਾਂ ਸੁਝਾਏ ਗਏ ਪ੍ਰਾਂਪਟ (ਉਦਾਹਰਣ: “ਇਸ ਦਾ ਸੰਖੇਪ ਕਰੋ”, “ਇੱਕ ਜਵਾਬ ਡਰਾਫਟ ਕਰੋ”, “ਐਕਸ਼ਨਆਈਟਮ ਲੱਭੋ”)
• ਸੁਨੇਹਿਆਂ 'ਤੇ ਬ੍ਰਾ੍ਹਣ-ਕ੍ਰਿਤ-ਕਾਰਵਾਈਆਂ (ਕਾਪੀ, ਰੀਜਨਰੇਟ, ਛੋਟਾ ਕਰੋ, ਵਿਸਥਾਰ)
• ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਫਾਈਲ ਅੱਪਲੋਡ—ਅਪਲੋਡ ਪ੍ਰਗਤਿ ਦਿਖਾਓ ਅਤੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਫਾਈਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ (ਫ਼ਾਈਲ ਨਾਮ, ਸਾਈਜ਼, ਪੰਨੇ)

ਐਰਰ ਹੈਂਡਲਿੰਗ: ਨਰਮ, ਦਹਿਸ਼ਤਜਨਕ ਨਹੀਂ

ਫੇਲਿਊਰ ਦੀ ਯੋਜਨਾ ਪਹਿਲੋਂ ਤੋਂ ਬਣਾਓ: ਨੈੱਟਵਰਕ ਡ੍ਰਾਪ, ਰੇਟ ਲਿਮਿਟ ਅਤੇ ਟੂਲ ਐਰਰ ਆਉਂਦੇ ਹਨ।

ਦੋਸਤਾਨਾ, ਖਾਸ ਸੁਨੇਹੇ ਦਿਖਾਓ (“ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਗਿਆ। ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ?”), ਇੱਕ-ਕਲਿੱਕ ਰੀਟ੍ਰਾਈ ਦਿਓ, ਅਤੇ ਯੂਜ਼ਰ ਦਾ ਡਰਾਫਟ ਰੱਖੋ। ਲੰਬੇ ਬੇਨਤੀਆਂ ਲਈ ਸਪਸ਼ਟ ਟਾਈਮਆਉਟ ਸੈੱਟ ਕਰੋ, ਫਿਰ “ਤੁ повторਿ ਕਰੋ” ਰਾਜ ਵਿੱਚ ਵਿਕਲਪ ਦਿਓ: ਰੀਟ੍ਰਾਈ, ਪ੍ਰਾਂਪਟ ਸੋਧੋ, ਜਾਂ ਨਵੀਂ ਥ੍ਰੈਡ ਸ਼ੁਰੂ ਕਰੋ।

ਸੁਰੱਖਿਆ, ਸੁਰੱਖਿਆ ਅਤੇ ਨੀਤੀ ਨਿਯੰਤਰਣ

ਜੇ ਤੁਹਾਡੀ ਐਪ ਚੈਟ ਕਰ ਸਕਦੀ ਹੈ ਤਾਂ ਇਸਨੂੰ ਠੱਗਿਆ ਵੀ ਜਾ ਸਕਦਾ ਹੈ, ਦਬਾਇਆ ਵੀ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਗਲਤ ਵਰਤਿਆ ਵੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਅਤੇ ਸੁਰੱਖਿਆ ਨੂੰ ਪ੍ਰੋਡਕਟ ਦੀ ਲੋੜ ਸਮਝੋ, “ਚੰਗੀ ਹੋਵੇ” ਨਹੀਂ। ਮਕਸਦ ਸਧਾਰਨ: ਨੁਕਸਾਨਦੇਹ ਆਉਟਪੁੱਟ ਰੋਕੋ, ਯੂਜ਼ਰ ਅਤੇ ਕੰਪਨੀ ਡਾਟਾ ਦੀ ਰੱਖਿਆ ਕਰੋ, ਅਤੇ ਗਲਤ ਵਰਤੋਂ ਹੇਠ ਸਿਸਟਮ ਨੂੰ ਸਥਿਰ ਰੱਖੋ।

ਖਤਰਨਾਕ ਬੇਨਤੀਆਂ ਲਈ ਨੀਤੀ ਚੈਕਸ

ਪ੍ਰਿਥਕ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਐਪ ਕੀ ਇਨਕਾਰ ਕਰੇਗੀ, ਕੀ ਸੀਮਤ ਜਵਾਬ ਦੇਵੇਗੀ, ਅਤੇ ਕੀ ਹਥਿਆੜਾ-ਸੰਪਰਕ (ਹੈਂਡਆਫ) ਦੀ ਲੋੜ ਹੈ। ਆਮ ਸ਼੍ਰੇਣੀਆਂ: ਸਵੈ-ਨੁਕਸਾਨ, ਚਿਕਿਤਸਾ/ਕਾਨੂੰਨੀ/ਵਿੱਤੀ ਸਲਾ, ਨਫ਼ਰਤ/ਹੈਰਾਸਮੈਂਟ, ਯौन ਸਮੱਗਰੀ (ਖਾਸ ਕਰਕੇ ਨਾਬਾਲਗਾਂ ਨਾਲ ਸੰਬੰਧਿਤ), ਅਤੇ ਮਾਲਵੇਅਰ ਬਣਾਉਣ ਜਾਂ ਸੁਰੱਖਿਆ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਬੇਨਤੀ।

ਜਨਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ (ਅਤੇ ਕਈ ਵਾਰੀ ਬਾਅਦ) ਇੱਕ ਲਾਈਟਵੇਟ ਮੋਡਰੇਸ਼ਨ ਕਦਮ ਲਗਾਓ। ਸੰਵੇਦਨਸ਼ੀਲ ਵਿਸ਼ਿਆਂ ਲਈ, ਇੱਕ ਸੇਫ਼ ਜਵਾਬ ਮੋਡ 'ਤੇ ਜਾਉ: ਉੱਚ-ਸਤਰ ਜਾਣਕਾਰੀ ਦਿਓ, ਪੇਸ਼ੇਵਰ ਸਹਾਇਤਾ ਦੀ ਸਿਫਾਰਸ਼ ਕਰੋ, ਅਤੇ ਵਿਸਥਾਰਵੱਧ ਹਦਾਇਤਾਂ ਤੋਂ ਬਚੋ।

ਪ੍ਰਾਂਪਟ ਇੰਜੈਕਸ਼ਨ ਅਤੇ ਡਾਟਾ ਲੀਕਏਜ ਘਟਾਓ

ਮੰਨੋ ਕਿ ਪ੍ਰਾਪਤ ਕੀਤੇ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਯੂਜ਼ਰ ਸੁਨੇਹੇ ਮਾਲੀਸ਼ੀਅਸ ਹੁੰਦੇ ਹੋ ਸਕਦੇ ਹਨ। ਸਾਫ਼ ਵੰਡ ਰੱਖੋ:

• System instructions (ਤੁਹਾਡੇ ਗੈਰ-ਨੈਗੋਸ਼ੀਏਬਲ ਨਿਯਮ)
• Tool output / retrieved content (ਅਣ-ਭਰੋਸੇਯੋਗ ਸਬੂਤ ਵਜੋਂ)
• User requests

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

ਦੁਰਵਿਹਾਰ ਰੋਕਥਾਮ: auth, ਸੀਮਾਵਾਂ ਅਤੇ ਮਾਨੀਟਰਿੰਗ

ਜੋ ਵੀ ਨਿੱਜੀ ਡਾਟਾ ਜਾਂ ਭੁਗਤਾਨ ਸਰੋਤ ਨੂੰ ਛੂਹਦਾ ਹੈ ਉਸ ਲਈ ਪ੍ਰਮਾਣਿਕਤਾ ਲਾਜ਼ਮੀ ਕਰੋ। ਪ੍ਰਤੀ ਯੂਜ਼ਰ/IP ਰੇਟ ਲਿਮਿਟ, ਸਕ੍ਰੈਪਿੰਗ ਲਈ ਐਨੋਮਲੀ ਡਿਟੈਕਸ਼ਨ, ਅਤੇ ਟੂਲ ਕਾਲਾਂ 'ਤੇ ਸਖਤ ਕੈਪਸ਼ ਲਗਾਓ ਤਾਂ ਕਿ ਲੰਬਾ ਦੌਰਾਨ ਖਰਚਾ ਨਾਹ ਵਧੇ।

ਯੂਜ਼ਰ ਰਿਪੋਰਟਿੰਗ ਅਤੇ ਮਨੁੱਖੀ ਐਸਕੇਲੇਸ਼ਨ

ਚੈਟ UI ਵਿੱਚ ਇੱਕ ਦਿਸਣ ਵਾਲਾ “Report answer” ਬਟਨ ਸ਼ਾਮਲ ਕਰੋ। ਰਿਪੋਰਟਾਂ ਨੂੰ ਇੱਕ ਰਿਵਿュー ਕਿਊ ਵਿੱਚ ਰੂਟ ਕਰੋ, ਗੱਲਬਾਤ ਸੰਦਰਭ (PII ਘੱਟ ਕੀਤਾ ਹੋਇਆ) ਜੁੜੋ, ਅਤੇ ਉੱਚ-ਖਤਰੇ ਕੇਸ ਜਾਂ ਵਾਰ-ਵਾਰ ਨੀਤੀ ਉਲੰਘਣ ਲਈ ਮਨੁੱਖੀ ਆਪਰੇਸ਼ਨ ਨੂੰ ਐਸਕੇਲੇਟ ਕਰੋ।

ਰਿਲੀਜ਼ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਅਤੇ ਮੁਲਾਂਕਣ ਕਰੋ

ਆਪਣੀ LLM ਚੈਟ ਅਨੁਭਵ ਨੂੰ ਅੱਖਾਂ ਨਾਲ ਦੇਖ ਕੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਾ। ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਮੁਲਾਂਕਣ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ ਗੁਣਵੱਤਾ ਗੇਟ ਵਜੋਂ ਸTreat ਕਰੋ: “ਚੰਗਾ” ਕੀ ਹੈ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਨਿੱਤ ਤੇ ਮਾਪੋ, ਅਤੇ ਰਿਲੀਜ਼ਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ ਰੁਝਾਨਾਂ 'ਤੇ ਲਾਕ ਕਰੋ।

ਇੱਕ ਹਕੀਕਤੀ ਟੈਸਟ ਸੈਟ ਬਣਾਓ

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

ਸਪੱਸ਼ਟ ਸਿਗਨਲ ਨਾਲ ਗੁਣਵੱਤਾ ਮਾਪੋ

ਕੁਝ ਮੁੱਖ ਮੈਟਰਿਕਸ ਟ੍ਰੈਕ ਕਰੋ ਜੋ ਯੂਜ਼ਰ ਭਰੋਸੇ ਨਾਲ ਜੁੜਦੇ ਹਨ:

• ਸਹੀਤਾ: ਸਹੀ ਤੌਰ 'ਤੇ ਸਥਿਤੀ ਲਈ ਜਵਾਬ ਦਿੰਦਾ ਹੈ?
• ਗਰਾਊਂਡਡਨੈਸ: ਦਾਵੇ ਕਿਸ ਹੱਦ ਤੱਕ retrieval ਡਾਟਾ ਨਾਲ ਸਹਾਇਤ ਹਨ, ਜਾਂ ਅਨੁਮਾਨ ਹਨ?
• ਇਨਕਾਰ ਸਹੀਤਾ: ਜਦ ਬੇਨਤੀ ਇਨਕਾਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕੀ ਉਹ ਸਪਸ਼ਟ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਇਨਕਾਰ ਕਰਦਾ ਹੈ?

ਇੱਕ ਸਧਾਰਨ ਰਿਵਿਯੂਅਰ ਰਬਰਿਕ (1–5 ਸਕੋਰ + ਛੋਟੀ ਵਜ੍ਹਾ) ਅਣਆਧਿਕਤ ਫੀਡਬੈਕ ਨਾਲੋਂ ਬਿਹਤਰ ਕੰਮ ਕਰੇਗਾ।

ਟੂਲ ਕਾਲਾਂ ਦਾ end-to-end ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਰੋ

ਜੇ ਤੁਹਾਡਾ ਬੋਟ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ, ਤਾਂ ਟੂਲ ਕਾਲਾਂ ਨੂੰ API endpoints ਵਾਂਗਾਂ ਹੀ ਧਿਆਨ ਨਾਲ ਟੈਸਟ ਕਰੋ:

• ਉੱਚਾਰਨ ਕਰੋ ਕਿ ਠੀਕ ਪੈਰਾਮੀਟਰ ਭੇਜੇ ਜਾਂਦੇ ਹਨ (ਟਾਈਪ, ਜ਼ਰੂਰੀ ਫੀਲਡ, ਇਕਾਈਆਂ)
• ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਅਧੂਰੇ ਫੇਲਿਯਰਸ ਦੀ ਪ੍ਰੈਕਟਿਸ ਕਰੋ
• idempotency ਲਾਗੂ ਕਰੋ ਤਾਂ ਜੋ ਦੁਹਰਾਏ ਗਏ ਕਾਲ ਆਰਡਰ, ਟਿਕਟ ਜਾਂ ਸੁਨੇਹੇ ਨਾਂ ਦੁਹਰਾਉਂ

ਟੂਲ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ ਨੂੰ ਲੌਗ ਕਰੋ ਤਾਂ ਕਿ ਬਾਅਦ ਵਿੱਚ ਆਡੀਟ ਕੀਤਾ ਜਾ ਸਕੇ।

ਨਿਯੰਤਰਿਤ ਪ੍ਰਯੋਗ ਚਲਾਓ

ਪ੍ਰਾਂਪਟ ਅਤੇ UI ਬਦਲਾਅ ਲਈ A/B ਟੈਸਟ ਵਰਤੋਂ। ਪਹਿਲਾਂ ਫਿਕਸਡ ਟੈਸਟ ਸੈਟ 'ਤੇ ਵੈਰੀਅੰਟਸ ਦੀ তুলਨਾ ਕਰੋ, ਫਿਰ ਲਗਭਗ ਸੁਰੱਖਿਅਤ ਹੋਣ 'ਤੇ ਛੋਟੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਲਾਇਸ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਨਤੀਜੇ ਕਾਰੋਬਾਰੀ ਮੈਟਰਿਕਸ ਨਾਲ ਜੋੜੋ (ਟਾਸਕ ਕੰਪਲੀਸ਼ਨ, ਸਮਾਂ-ਬਚਤ, ਇਸਕੇਲੇਸ਼ਨ ਰੇਟ), ਸਿਰਫ਼ “ਸੁਣਨ ਵਿੱਚ ਬੇਹਤਰ” ਨਾਲ ਨਹੀਂ।

ਲਾਗਤ, ਲੇਟੈਂਸੀ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਪ੍ਰਬੰਧਨ ਕਰੋ

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

ਖ਼ਰਚ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਓ ਅਤੇ ਨਿਯੰਤਰ ਕਰੋ

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

ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਟਰਿਕ ਮਹਿੰਗੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪਹਿਲਾਂ ਕੈਪ ਕਰਨਾ ਹੈ:

• ਮੈਕਸ ਕੰਟੈਕਸਟ ਸਾਈਜ਼ (ਹਮੇਸ਼ਾਂ ਪੂਰੀ ਗੱਲਬਾਤ ਨਾ ਭੇਜੋ)
• ਮੈਕਸ ਜਵਾਬ ਲੰਬਾਈ (ਯੂਜ਼ਰਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸੰਖੇਪ ਜਵਾਬ ਪਸੰਦ ਹੁੰਦੇ ਹਨ)
• ਪ੍ਰਤੀ ਟਰਨ ਮੈਕਸ ਟੂਲ ਕਾਲ (ਲੂਪ ਅਤੇ ਟੂਲ ਸਪੈਮ ਤੋਂ ਬਚੋ)

ਗੁਣਵੱਤਾ ਬਿਨਾਂ ਖਰਚ ਵਧਾਏ ਲੇਟੈਂਸੀ ਘਟਾਓ

ਜ਼ਿਆਦਾਤਰ ਲੇਟੈਂਸੀ (1) ਮਾਡਲ ਸਮਾਂ ਅਤੇ (2) ਟੂਲ/ਡੇਟਾ ਸੋਰਸ ਉੱਤੇ ਰੁਕਣਾ ਕਾਰਨ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਦੋਹਾਂ ਕੱਟ ਸਕਦੇ ਹੋ:

• ਆਮ ਪ੍ਰਸ਼ਨਾਂ ਲਈ ਕੈਸ਼ਿੰਗ ਲਗਾਓ (ਉਦਾਹਰਣ: “ਪ੍ਰਾਈਸਿੰਗ”, “ਪਾਸਵਰਡ ਰੀਸੈਟ”) ਅਤੇ ਦੁਹਰਾਈ ਵਾਲੇ retrieval ਨਤੀਜਿਆਂ ਨੂੰ ਕੈਸ਼ ਕਰੋ। ਕੈਸ਼ normalization ਯੂਜ਼ਰ ਇਰਾਦੇ + ਸੰਬੰਧਤ ਸੈਗਮੈਂਟ 'ਤੇ ਕੀ ਹੋਵੇ, ਨਾ ਕਿ ਕੱਚੇ ਟੈਕਸਟ 'ਤੇ।
• ਜੋ ਕੁੱਝ ਇਕੱਠੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਉਹ ਪੈਰਾਲਲ ਚਲਾਓ: retrieval ਅਤੇ ਲਾਈਟਵੇਟ ਚੈੱਕ ਇੱਕ ਨਾਲ ਚਲਾਓ, ਫਿਰ ਆਖਰੀ ਜਵਾਬ ਜੋੜੋ।
• ਪ੍ਰਾਂਪਟ ਨੂੰ ਲੀਨ ਰੱਖੋ। ਵਾਧੂ ਨਿਰਦੇਸ਼ ਅਤੇ ਲੰਬੀ ਹਿਸਟਰੀ ਟੋਕਨ ਅਤੇ ਜਵਾਬੀ ਸਮਾਂ ਵਧਾਉਂਦੀ ਹੈ।

ਮਾਡਲ ਰਾਉਟਿੰਗ ਵਰਤੋਂ

ਹਰ ਸੁਨੇਹੇ ਨੂੰ ਤੁਹਾਡੇ ਸਭ ਤੋਂ ਵੱਡੇ ਮਾਡਲ ਦੀ ਲੋੜ ਨਹੀਂ। ਰਾਉਟਿੰਗ ਨਿਯਮ (ਜਾਂ ਇੱਕ ਛੋਟਾ ਕਲਾਸੀਫਾਇਰ) ਵਰਤੋ ਤਾਂ ਕਿ ਆਮ, ਸਧਾਰਨ ਟਾਸਕ (FAQs, ਫਾਰਮੇਟਿੰਗ, ਸਧਾਰਣ ਨਿਕਾਸ) ਇੱਕ ਛੋਟੇ, ਸਸਤੇ ਮਾਡਲ ਤੇ ਜਾਣ ਅਤੇ ਜਟਿਲ ਤਰਕ-ਸੰਬੰਧੀ ਕਾਰਜ ਵੱਡੇ ਮਾਡਲ ਤੇ ਚਲੇਣ। ਇਸ ਨਾਲ ਆਮ ਤੌਰ 'ਤੇ ਲਾਗਤ ਅਤੇ ਰਫ਼ਤਾਰ ਦੋਹਾਂ ਵਿੱਚ ਸੁਧਾਰ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਅਸਲ ਸਰਵਿਸ ਵਾਂਗ ਭਰੋਸੇਯੋਗਤਾ ਇੰਜੀਨੀਅਰ ਕਰੋ

LLMs ਅਤੇ ਟੂਲ ਕਾਲਾਂ ਕਦੇ-ਕਦੇ ਫੇਲ ਹੋਣਗੇ। ਇਸ ਲਈ ਯੋਜਨਾ ਬਣਾਓ:

• ਟੂਲ ਰਿਕਵੈਸਟਾਂ ਲਈ ਟਾਈਮਆਉਟ ਅਤੇ ਬੈਕਆਫ ਰੀਟ੍ਰਾਈਜ਼
• ਫਾਲਬੈਕ (ਵਿਕਲਪ ਮਾਡਲ, ਸਧਾਰਣ ਜਵਾਬ, ਜਾਂ “ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕਰੋ” UX)
• ਜਦ ਕੋਈ ਨਿਰਭਰਤਾ ਅਸਥਿਰ ਹੋਵੇ ਤਾਂ ਸਿਰਕਿਟ ਬ੍ਰੇਕਰ
• ਸਪਸ਼ਟ ਅੰਸ਼ਿਕ ਫੇਲਿਯਰ ਜਵਾਬ (“ਮੈਂ ਤੁਹਾਡਾ ਕੈਲੰਡਰ ਨਹੀਂ ਪਹੁੰਚ ਸਕਿਆ—ਕੀ ਮੈਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਾਂ?”)

ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ, ਯੂਜ਼ਰ ਤੇਜ਼, ਸਥਿਰ ਅਸਿਸਟੈਂਟ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ—ਅਤੇ ਤੁਹਾਨੂੰ ਪੇਮਾਨਾ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕੋ।

ਤਾਇਨਾਤ ਕਰੋ, ਮਾਨੀਟਰ ਕਰੋ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਧਾਰ ਕਰੋ

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

ਜੋ ਯੂਜ਼ਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ (ਅਤੇ ਜੋ ਟੁੱਟਦਾ ਹੈ) ਉਸ ਨੂੰ ਮਾਨੀਟਰ ਕਰੋ

ਟੈਕਨੀਕੀ ਸਿਗਨਲਾਂ ਨੂੰ ਯੂਜ਼ਰ ਅਨੁਭਵ ਨਾਲ ਜੋੜਣ ਵਾਲੀ ਮਾਨੀਟਰਿੰਗ ਸੈੱਟ ਕਰੋ। ਘੱਟੋ-ਘੱਟ p50/p95 ਲੇਟੈਂਸੀ, ਐਰਰ ਰੇਟ ਅਤੇ ਵੱਖ-ਵੱਖ ਫੇਲਿਯਰ ਸ਼੍ਰੇਣੀਆਂ ਟ੍ਰੈਕ ਕਰੋ—ਮਾਡਲ ਟਾਈਮਆਉਟ, ਟੂਲ/ਫੰਕਸ਼ਨ-ਕਾਲ ਫੇਲਿਯਰ, retrieval ਮਿਸ ਅਤੇ UI ਡਿਲਿਵਰੀ ਸਮੱਸਿਆਵਾਂ।

ਇੱਕ ਲਾਭਦਾਇਕ ਪੈਟਰਨ: ਪ੍ਰਤੀ ਸੁਨੇਹਾ ਇੱਕ ਸੰਰਚਿਤ ਇਵੈਂਟ ਜਾਰੀ ਕਰੋ ਜਿਸ ਵਿੱਚ ਮਾਡਲ ਨਾਮ/ਵਰਜ਼ਨ, ਟੋਕਨ ਗਿਣਤੀ, ਟੂਲ ਕਾਲ (ਨਾਮ + ਸਥਿਤੀ), retrieval ਅੰਕੜੇ (ਦਸਤavez ਰਿਟਰਨ, ਸਕੋਰ), ਅਤੇ ਯੂਜ਼ਰ-ਦਿੱਖੀ ਨਤੀਜਾ (ਸਫਲ/ਤਿਆਗ/ਇਸਕੇਲੇਸ਼ਨ) ਵਰਗੇ ਫੀਲਡ ਹੋਣ।

ਪ੍ਰਾਂਪਟ ਅਤੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਲੌਗ ਕਰੋ

ਤੁਹਾਨੂੰ ਡੀਬੱਗ ਅਤੇ ਸੁਧਾਰ ਲਈ ਉਦਾਹਰਣਾਂ ਚਾਹੀਦੀਆਂ ਹੋਣਗੀਆਂ—ਪਰ ਉਨ੍ਹਾਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਨਾਲ ਸਟੋਰ ਕਰੋ। ਪ੍ਰਾਂਪਟਸ ਅਤੇ ਮਾਡਲ ਆਉਟਪੁੱਟ ਨੂੰ ਆਟੋਮੈਟਿਕ ਰੈਡੈਕਸ਼ਨ ਨਾਲ ਲੌਗ ਕਰੋ (ਈਮੇਲ, ਫ਼ੋਨ ਨੰਬਰ, ਪਤੇ, ਭੁਗਤਾਨ ਵੇਰਵੇ, ਐਕਸੈਸ ਟੋਕਨ)। ਰੌ ਟੈਕਸਟ ਐਕਸੈਸ ਸੀਮਤ, ਸਮੇਂ-ਬਾਉਂਡ ਅਤੇ ਆਡੀਟ ਕੀਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੇ ਤੁਸੀਂ ਮੁਲਾਂਕਣ ਲਈ ਗੱਲਬਾਤ ਨੂੰ ਰੀਪਲੇ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ sanitized ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ ਅਤੇ ਕਿਸੇ ਵੀ ਸੰਵੇਦਨਸ਼ੀਲ ਸਮੱਗਰੀ ਲਈ ਇੱਕ ਅਲੱਗ ਐਂਕ੍ਰਿਪਟ ਕੀਤਾ ਬਲਾਬ ਸਟੋਰ ਕਰੋ, ਤਾਂ ਜੋ ਜ਼ਿਆਦਾਤਰ ਵਰਕਫ਼ਲੋਜ਼ ਕਦੇ ਰੌ ਟੈਕਸਟ ਨੂੰ ਨਾਂ ਛੂਹਣ।

ਘੁਟਿਆ ਫ਼ੀਡਬੈਕ ਲੂਪ ਬਣਾਓ

UI ਵਿੱਚ ਇੱਕ ਨਰਮ ਫੀਡਬੈਕ ਕੰਟਰੋਲ (ਥੰਬਜ਼ ਉੱਪ/ਡਾਊਨ + ਵਿਕਲਪਨ ਟਿੱਪਣੀ) ਸ਼ਾਮਲ ਕਰੋ। ਨੈਗੇਟਿਵ ਫੀਡਬੈਕ ਨੂੰ ਇੱਕ ਰਿਵਿਯੂ ਕਿਊ ਵਿੱਚ ਭੇਜੋ ਜਿਸ ਵਿੱਚ:

• sanitized ਟ੍ਰਾਂਸਕ੍ਰਿਪਟ
• retrieved passages (ਜੇ RAG ਵਰਤਿਆ)
• ਟੂਲ ਕਾਲ ਟਰੇਸ ਅਤੇ ਐਰਰ

ਫਿਰ ਉੱਤੇ ਕਾਰਵਾਈ ਕਰੋ: ਪ੍ਰਾਂਪਟ ਨਿਰਦੇਸ਼ਾਂ ਨੂੰ ਠੀਕ ਕਰੋ, ਅਭਾਵਿੱਤ ਗਿਆਨ ਨੂੰ retrieval ਸਾਰਥਕ ਸੋর্স ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਨਿਸ਼ਾਨਦਾਰ ਟੈਸਟ ਬਣਾਓ ਤਾਂ ਜੋ ਉਹੀ ਮੁੱਦਾ ਚੁੱਕਿਆ ਨਾ ਜਾ ਸਕੇ।

ਬਦਲਾਅ ਸੰਚਾਰ ਕਰੋ: ਰੋਡਮੈਪ ਅਤੇ ਉਮੀਦਾਂ

LLM ਵਿਵਹਾਰ ਵਿਕਸਤ ਹੁੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਸਪਸ਼ਟ ਰੋਡਮੈਪ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਜਾਣ ਸਕਣ ਕਿ ਅੱਗੇ ਕੀ ਸੁਧਾਰ ਹੋਣੇ ਹਨ (ਸਹੀਤਾ, ਸਮਰਥਿਤ ਕਾਰਵਾਈਆਂ, ਭਾਸ਼ਾਵਾਂ, ਇੰਟੀਗ੍ਰੇਸ਼ਨ)। ਜੇ ਫੀਚਰ ਯੋਜਨਾ ਅਨੁਸਾਰ ਵੱਖ-ਵੱਖ ਹਨ—ਜਿਵੇਂ ਵੱਧ ਰੇਟ ਲਿਮਿਟ, ਲੰਮੀ ਹਿਸਟਰੀ, ਜਾਂ ਪ੍ਰੀਮੀਅਮ ਮਾਡਲ—ਉਨ੍ਹਾਂ ਨੂੰ /pricing 'ਤੇ ਦਰਸਾਓ ਅਤੇ ਉਤਪਾਦ UI ਵਿੱਚ ਸੁਪਸ਼ਟ ਰੱਖੋ।

ਜੇ ਤੁਹਾਡਾ ਲਕੜੀ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਨਾ ਹੈ ਪਰ ਬਾਅਦ ਵਿੱਚ ਪੂਰੀ ਕਸਟਮ ਸਟੈਕ ਵੱਲ “ਗ੍ਰੈਜੂਏਟ” ਕਰਨ ਦੀ ਚੋਣ ਰੱਖਣੀ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ Koder.ai 'ਤੇ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਵਰਜਨ ਬਣਾਓ (ਸਰੋਤ ਕੋਡ ਐਕਸਪੋਰਟ ਅਤੇ ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ), ਫਿਰ ਵਰਤੋਂ ਵਧਣ 'ਤੇ ਆਪਣੇ ਮੁਲਾਂਕਣ, ਸੁਰੱਖਿਆ ਅਤੇ ਓਬਜ਼ਰਵੇਬਿਲਿਟੀ ਅਭਿਆਸਾਂ ਨਾਲ ਹਾਰਡਨ ਕਰੋ।