ਇੱਕ ਭਰੋਸੇਮੰਦ ਜਵਾਬ ਨਾ ਮਿਲਣ ਨਾਲੋਂ ਵੀ ਕਿਉਂ ਮਾੜਾ ਹੋ ਸਕਦਾ ਹੈ

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

ਅਸਲ ਪਾਲਿਸੀ $50 ਕਹਿੰਦੀ ਹੈ। ਬੋਟ ਨੇ ਇਹ ਜਵਾਬ ਖੁਦ ਬਣਾਇਆ ਸੀ। ਇਸਨੇ ਤੁਹਾਡੀਆਂ ਫਾਈਲਾਂ ਕਦੇ ਖੋਲ੍ਹੀਆਂ ਹੀ ਨਹੀਂ ਸਨ। ਇਸਨੇ ਸਿਰਫ਼ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ, ਜੋ ਕਿ ਸਾਲਾਂ ਪਹਿਲਾਂ ਆਪਣੇ ਟ੍ਰੇਨਿੰਗ ਡੇਟਾ ਵਿੱਚ ਦੱਬੇ ਹੋਏ ਪੈਟਰਨਾਂ 'ਤੇ ਅਧਾਰਤ ਸੀ। ਨਿੱਜੀ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਵਿਰੁੱਧ raw large language models ਚਲਾਉਣ ਦੀ ਇਹ ਕੌੜੀ ਸੱਚਾਈ ਹੈ। ਉਹਨਾਂ ਕੋਲ ਤੁਹਾਡੇ ਅੰਦਰੂਨੀ ਗਿਆਨ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ। ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਤੱਥ ਉਹਨਾਂ ਦੇ training weights ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉਹ ਅਣਜਾਣਤਾ ਮੰਨਣ ਦੀ ਬਜਾਏ ਗੜਬੜ ਜਵਾਬ ਬਣਾਉਣ ਲੱਗ ਜਾਂਦੇ ਹਨ। ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ, ਇਹ ਮਜ਼ਾਕੀਆ ਨਹੀਂ ਰਹਿੰਦਾ ਅਤੇ ਇੱਕ liability ਬਣ ਜਾਂਦਾ ਹੈ।

Retrieval-Augmented Generation, ਜਾਂ RAG, ਬਿਲਕੁਲ ਇਸੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਮਾਡਲ ਨੂੰ ਸਭ ਕੁਝ ਯਾਦ ਰੱਖਣ ਲਈ ਕਹਿਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਸਨੂੰ ਚੀਜ਼ਾਂ ਲੱਭਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹੋ।

ਅੰਦਾਜ਼ੇ ਤੋਂ ਪੜ੍ਹਨ ਤੱਕ

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

RAG ਉਸ ਸਾਥੀ ਨੂੰ ਇੱਕ ਫਾਈਲਿੰਗ ਕੈਬਨਿਟ ਤੱਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਸਵਾਲ ਨੂੰ ਅੰਨ੍ਹੇਵਾਹ ਮਾਡਲ ਵੱਲ ਨਹੀਂ ਸੁੱਟਦਾ। ਇਹ ਪਹਿਲਾਂ ਸਬੰਧਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਲੱਭਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ prompt ਵਿੱਚ context ਵਜੋਂ ਪਾਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਹੀ ਮਾਡਲ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਜਵਾਬ ਦੇਣ ਲਈ ਕਹਿੰਦਾ ਹੈ। ਮਾਡਲ ਤੱਥਾਂ ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਤੱਥਾਂ ਨੂੰ ਸਮਝਣ ਵੱਲ ਵਧਦਾ ਹੈ ਜੋ ਸ਼ਾਬਦਿਕ ਰੂਪ ਵਿੱਚ ਉਸਦੇ ਸਾਹਮਣੇ ਹੁੰਦੇ ਹਨ।

ਇਹ ਪ੍ਰਕਿਰਿਆ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੀ ਹੋਈ ਹੈ: offline ਤਿਆਰੀ ਅਤੇ online ਜਵਾਬ।

ਪੜਾਅ 1: ਤਿਆਰੀ ਦਾ ਪੜਾਅ (Offline)

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

Document loaders ਤੁਹਾਡੀ ਸ਼ੁਰੂਆਤ ਹਨ। ਇਹ ਕਨੈਕਟਰ PDFs, Notion workspaces, SharePoint folders, ਵੈੱਬ ਪੇਜਾਂ ਅਤੇ ਅੰਦਰੂਨੀ wikis ਤੋਂ raw ਟੈਕਸਟ ਕੱਢਦੇ ਹਨ। ਇੱਥੇ ਹੀ ਅਸਲੀ ਚੁਣੌਤੀ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਇੱਕ loader ਇੱਕ Word ਦਸਤਾਵੇਜ਼ ਤੋਂ ਸਾਫ਼ ਟੈਕਸਟ ਕੱਢ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਸਕੈਨ ਕੀਤੇ PDF 'ਤੇ ਫਸ ਸਕਦਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਤਸਵੀਰ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ embedded text layer ਨਹੀਂ ਹੈ। Loader ਇੱਕ ਖਾਲੀ string ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਕੁਝ ਵੀ ਸਟੋਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਤੁਹਾਡੇ ਯੂਜ਼ਰ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ "ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ" ਵਾਲਾ ਜਵਾਬ ਮਿਲਦਾ ਹੈ। ਹਮੇਸ਼ਾ ਜਾਂਚ ਕਰੋ ਕਿ ਤੁਹਾਡੇ loaders ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕੱਢਿਆ ਹੈ। ਪਾਈਪਲਾਈਨ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹਰੇਕ ਸਰੋਤ ਤੋਂ ਕੁਝ ਦਸਤਾਵੇਜ਼ਾਂ 'ਤੇ spot checks ਕਰੋ।

ਅਗਲਾ ਕਦਮ text splitting ਹੈ, ਜਿਸਨੂੰ chunking ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਅੱਸੀ ਪੰਨਿਆਂ ਦੀ ਸੁਰੱਖਿਆ ਪਾਲਿਸੀ ਨੂੰ ਇੱਕੋ ਵਾਰ prompt ਵਿੱਚ ਨਹੀਂ ਪਾ ਸਕਦੇ; ਤੁਸੀਂ context ਦੀਆਂ ਸੀਮਾਵਾਂ ਨੂੰ ਪਾਰ ਕਰ ਜਾਵੋਗੇ ਅਤੇ ਜਾਣਕਾਰੀ ਨੂੰ noise ਵਿੱਚ ਦਬਾ ਦਿਓਗੇ। ਇਸਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ chunks ਵਿੱਚ ਕੱਟਦੇ ਹੋ। ਇਸ ਵਿੱਚ ਮੁੱਖ ਗੱਲ ਸਹੀ ਆਕਾਰ ਚੁਣਨਾ ਹੈ। ਬਹੁਤ ਛੋਟੇ chunks, ਜਿਵੇਂ ਕਿ ਇਕੱਲੇ ਵਾਕ, ਅਕਸਰ ਮਹੱਤਵਪੂਰਨ context ਨੂੰ ਗੁਆ ਦਿੰਦੇ ਹਨ। ਇੱਕ chunk ਜੋ ਪੜ੍ਹਦਾ ਹੈ "ਸਾਰੇ अनुरोधਾਂ ਨੂੰ ਮੈਨੇਜਰ ਦੁਆਰਾ ਮਨਜ਼ੂਰੀ ਦਿੱਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ", ਇਹ ਦੱਸਣਾ ਭੁੱਲ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਨਿਯਮ ਸਿਰਫ਼ ਅੰਤਰਰਾਸ਼ਟਰੀ ਯਾਤਰਾ ਲਈ ਲਾ

ਜਦੋਂ ਕੋਈ ਯੂਜ਼ਰ ਅੰਤ ਵਿੱਚ ਪੁੱਛਦਾ ਹੈ, "ਕਲਾਇੰਟ ਡਿਨਰਾਂ ਲਈ ਸਾਡੀ ਟ੍ਰੈਵਲ ਰੀਇੰਬਰਸਮੈਂਟ ਨੀਤੀ ਕੀ ਹੈ?", ਤਾਂ ਲਾਈਵ ਪਾਈਪਲਾਈਨ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦੀ ਹੈ।

ਉਹ