ਕੀ Postgres ਤੁਹਾਡੀ RAG ਪ੍ਰਕਿਰਿਆ ਸੰਭਾਲ ਸਕਦਾ ਹੈ?

• LLM ਇੱਕ ਵਾਰ ਵਿੱਚ ਸੀਮਤ ਲਿਖਤ ਹੀ “ਦੇਖ” ਸਕਦੇ ਹਨ, ਜਿਸਨੂੰ ਸੰਦਰਭ ਸੀਮਾ ਕਹਿੰਦੇ ਹਨ. ਇਹ ਛੋਟੇ ਕੰਮਾਂ ਲਈ ਠੀਕ ਹੈ, ਪਰ ਜਦੋਂ ਗਿਆਨ-ਭੰਡਾਰ ਹਜ਼ਾਰਾਂ ਪੰਨਿਆਂ ਵਿੱਚ ਫੈਲਿਆ ਹੋਵੇ ਤਾਂ ਇਹ ਕਾਰਗਰ ਨਹੀਂ ਰਹਿੰਦਾ. ਸੰਦਰਭ ਸੀਮਾ ਕਾਫ਼ੀ ਹੋਣ ਦੇ ਬਾਵਜੂਦ, “ਪਰਾਲੀ ਦੇ ਢੇਰ ਵਿੱਚ ਸੂਈ” ਵਾਲੀ ਸਮੱਸਿਆ ਕਾਰਨ ਕਾਰਗੁਜ਼ਾਰੀ ਘਟ ਸਕਦੀ ਹੈ.

• RAG, ਭਾਵ “ਪ੍ਰਾਪਤੀ-ਸੰਵਰਧਿਤ ਉਤਪਾਦਨ”, ਇੱਕ ਬਹੁਤ ਆਮ ਢਾਂਚਾ ਬਣ ਗਿਆ ਹੈ. ਇਸ ਵਿੱਚ ਤੁਸੀਂ ਗਿਆਨ-ਭੰਡਾਰ, ਜਿਵੇਂ ਦਸਤਾਵੇਜ਼, ਵਿਕੀ, ਨੀਤੀਆਂ ਅਤੇ ਪ੍ਰਤੀਲਿਪੀਆਂ, ਸੰਭਾਲਦੇ ਹੋ; ਵਰਤੋਂਕਾਰ ਦੀ ਪੁੱਛਗਿੱਛ ਉੱਤੇ ਅਰਥ-ਆਧਾਰਿਤ ਖੋਜ ਚਲਾ ਕੇ ਐਂਬੈਡਿੰਗਾਂ ਰਾਹੀਂ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਅੰਸ਼ ਲੱਭਦੇ ਹੋ; ਫਿਰ ਉਹ ਹਿੱਸੇ ਸਵਾਲ ਦੇ ਨਾਲ LLM ਨੂੰ ਦਿੰਦੇ ਹੋ. ਇਸ ਨਾਲ ਮਾਡਲ ਦਾ ਸੰਦਰਭ ਸੀਮਤ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਸਹੀ ਢੰਗ ਨਾਲ ਕਰਨ ਉੱਤੇ ਜਵਾਬਾਂ ਦੀ ਗੁਣਵੱਤਾ ਸੁਧਰ ਸਕਦੀ ਹੈ ਤੇ ਮਨਘੜਤ ਜਾਣਕਾਰੀ ਘਟ ਸਕਦੀ ਹੈ.

• pgai ਇੱਕ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਵਾਲਾ Postgres ਵਿਸਥਾਰ ਅਤੇ ਸਹਾਇਕ ਸੰਦਾਂ ਦਾ ਸਮੂਹ ਹੈ, ਜੋ ਭਰੋਸੇਯੋਗ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਵਾਲੇ PostgreSQL ਡਾਟਾਬੇਸ ਉੱਤੇ “AI ਪ੍ਰਾਪਤੀ” ਕਾਰਜ-ਪ੍ਰਵਾਹ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ.

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

• ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਭਾਵ ਮੁਤਾਬਕ ਇਹ ਉਮੀਦਜਨਕ ਹੈ, ਪਰ RAG ਪ੍ਰਕਿਰਿਆ ਥੋੜ੍ਹੀ ਜਿਹੀ ਵੀ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਵੇ, ਖ਼ਾਸ ਕਰਕੇ ਹਿੱਸੇ ਬਣਾਉਣ ਦੇ ਤਰੀਕਿਆਂ ਕਰਕੇ, ਤਾਂ ਇਹ ਢੁਕਵੀਂ ਨਹੀਂ ਰਹਿੰਦੀ. ਫਿਰ ਵੀ ਅਸੀਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਉੱਤੇ ਨੇੜਿਓਂ ਨਜ਼ਰ ਰੱਖਾਂਗੇ.

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

1. ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਲਓ.

2. ਉਨ੍ਹਾਂ ਨੂੰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡੋ. ਇਹ ਕਰਨ ਦੇ ਕਈ ਤਰੀਕੇ ਹਨ, ਜਿਵੇਂ ਪੈਰਿਆਂ ਜਾਂ ਅਰਥ-ਆਧਾਰਿਤ ਸਮੂਹਾਂ ਮੁਤਾਬਕ ਵੰਡਣਾ.

3. ਹਰੇਕ ਹਿੱਸੇ ਨੂੰ ਐਂਬੈਡਿੰਗ ਵਿੱਚ ਬਦਲੋ.

4. ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ ਵੈਕਟਰ ਡਾਟਾਬੇਸ, ਜਿਵੇਂ Pinecone ਜਾਂ Milvus, ਵਿੱਚ ਜਾਂ pgvector ਦੀ ਵਰਤੋਂ ਕਰਕੇ Postgres ਵਿੱਚ ਸਟੋਰ ਕਰੋ.

5. ਪੁੱਛਗਿੱਛ ਵੇਲੇ ਸਭ ਤੋਂ ਨੇੜਲੇ ਹਿੱਸੇ ਲੱਭੋ `ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ LLM ਨੂੰ ਦਿਓ. ਮੁੜ ਦੱਸ ਦੇਈਏ ਕਿ ਇਹ ਕਰਨ ਦੇ ਵੀ ਕਈ ਤਰੀਕੇ ਹਨ.

ਕਈ ਤਕਨੀਕੀ ਢਾਂਚਿਆਂ ਵਿੱਚ ਕਦਮ (1)–(3) ਡਾਟਾਬੇਸ ਤੋਂ ਬਾਹਰ, ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਜਾਂ ਡਾਟਾ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹੁੰਦੇ ਹਨ ਅਤੇ ਡਾਟਾਬੇਸ ਮੁੱਖ ਤੌਰ ’ਤੇ ਇਨ੍ਹਾਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ:

• ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ

• ਐਂਬੈਡਿੰਗਾਂ ਵਿੱਚ ਖੋਜ ਕਰਨਾ

pgai ਇੱਕ ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਵਾਲਾ Postgres ਵਿਸਥਾਰ ਹੈ, ਜਿਸਨੂੰ Timescale ਨੇ ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ. ਇਹ ਉਸ ਹੱਦ ਨੂੰ ਧੁੰਦਲਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ.

ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ ਐਪ ਵੱਲੋਂ ਹੱਥੀਂ ਸੰਭਾਲੀ ਜਾਣ ਵਾਲੀ ਚੀਜ਼ ਮੰਨਣ ਦੀ ਥਾਂ pgai ਉਨ੍ਹਾਂ ਨੂੰ ਡਾਟਾਬੇਸ ਦੀ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਬਣਾ ਦਿੰਦਾ ਹੈ:

• ਤੁਸੀਂ ਤੈਅ ਕਰਦੇ ਹੋ ਕਿ ਕਿਹੜੀ ਸਾਰਣੀ ਜਾਂ ਕਿਹੜੇ ਦਸਤਾਵੇਜ਼ ਐਂਬੈਡ ਕਰਨੇ ਹਨ.

• ਤੁਸੀਂ ਐਂਬੈਡਿੰਗ ਮਾਡਲ ਅਤੇ ਹਿੱਸੇ ਬਣਾਉਣ ਦੀ ਰਣਨੀਤੀ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ.

• ਬਾਕੀ ਕੰਮ pgai ਸੰਭਾਲਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਸਰੋਤ ਡਾਟਾ ਬਦਲਣ ਉੱਤੇ ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ ਅੱਪ-ਟੂ-ਡੇਟ ਰੱਖਣਾ ਵੀ ਸ਼ਾਮਲ ਹੈ.

ਇਸ ਦੇ ਵਾਅਦੇ ਆਕਰਸ਼ਕ ਹਨ:

• ਸੰਭਾਲਣ ਲਈ ਘੱਟ ਵਿਸ਼ੇਸ਼ ਜੋੜਨ ਵਾਲਾ ਕੋਡ.

• ਮੂਲ ਸਰੋਤ ਦਸਤਾਵੇਜ਼ ਬਦਲਣ ਉੱਤੇ ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ “ਤਾਜ਼ਾ” ਰੱਖਣਾ ਸੌਖਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.

• Postgres ਅਤੇ pgai ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ, ਦਰ ਸੀਮਾਵਾਂ, ਅਸਫਲ ਕੰਮ ਆਦਿ ਸੰਭਾਲਦੇ ਹਨ.

ਪਾਠਕ ਲਈ ਨੋਟ: pgai ਵਿੱਚ pgvector, ਇੱਕ ਹੋਰ ਬਹੁਤ ਪ੍ਰਸਿੱਧ RAG Postgres ਵਿਸਥਾਰ, ਵੀ ਸ਼ਾਮਲ ਹੈ. pgvector Postgres ਵਿੱਚ ਵੈਕਟਰ ਸਟੋਰੇਜ ਅਤੇ ਸਮਾਨਤਾ ਖੋਜ ਜੋੜਦਾ ਹੈ, ਜਦਕਿ pgai ਇਸ ਦੇ ਆਧਾਰ ਉੱਤੇ ਹਿੱਸੇ ਬਣਾਉਣ, ਐਂਬੈਡ ਕਰਨ ਅਤੇ ਐਂਬੈਡਿੰਗਾਂ ਨੂੰ ਅੱਪ-ਟੂ-ਡੇਟ ਰੱਖਣ ਵਰਗੇ RAG ਕਦਮਾਂ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰਦਾ ਹੈ.

1) ਇਸਨੂੰ ਚਾਲੂ ਕਰਨਾ ਸੌਖਾ ਹੈ.

ਆਮ ਹਾਲਾਤ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਾਫ਼ੀ ਸੌਖੀ ਹੈ:

• Timescale ਦੇ Docker ਚਿੱਤਰ ਪ੍ਰਾਪਤ ਕਰੋ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਡਾਟਾਬੇਸ ਅਤੇ ਵਰਕਰ ਸ਼ਾਮਲ ਹਨ.

• ਆਪਣੇ ਐਂਬੈਡਿੰਗ ਪ੍ਰਦਾਤਾ ਦੀ API ਕੁੰਜੀ ਦਿਓ.

• ਵੈਕਟਰਾਈਜ਼ਰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਥੋੜ੍ਹਾ ਜਿਹਾ SQL ਚਲਾਓ: ਕੀ ਐਂਬੈਡ ਕਰਨਾ ਹੈ, ਉਸਦੇ ਹਿੱਸੇ ਕਿਵੇਂ ਬਣਾਉਣੇ ਹਨ ਅਤੇ ਕਿਹੜਾ ਮਾਡਲ ਵਰਤਣਾ ਹੈ.

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

2) ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਡਾਟਾਬੇਸ ਦੇ “ਨੇੜੇ” ਚਲਾਉਣਾ ਵਧੀਆ ਹੈ.

pgai ਸਾਰਣੀਆਂ ਤੋਂ ਸਮੱਗਰੀ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ S3 ਵਰਗੀਆਂ ਥਾਵਾਂ ਤੋਂ ਦਸਤਾਵੇਜ਼ ਲੋਡ ਕਰਕੇ ਉਨ੍ਹਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ, ਹਿੱਸੇ ਅਤੇ ਐਂਬੈਡਿੰਗਾਂ ਵੀ ਬਣਾ ਸਕਦਾ ਹੈ. ਇਹ PDF, Markdown ਆਦਿ ਵਰਗੇ ਵੱਖ-ਵੱਖ ਲਿਖਤੀ ਦਸਤਾਵੇਜ਼ ਸਰੂਪ ਵੀ ਸੰਭਾਲ ਸਕਦਾ ਹੈ.

1) ਤੁਹਾਡਾ ਕਾਫ਼ੀ ਨਿਯੰਤਰਣ ਘਟ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ RAG ਨੂੰ ਕਈ ਵਾਰ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ.

ਜਵਾਬਾਂ ਦੀ ਗੁਣਵੱਤਾ ਮੁਤਾਬਕ ਉੱਚ-ਕਾਰਗੁਜ਼ਾਰੀ ਵਾਲੇ RAG ਸਿਸਟਮਾਂ ਨੂੰ ਅਕਸਰ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਵੇਂ:

• ਅਨੁਕੂਲਿਤ ਹਿੱਸਾ-ਵੰਡ ਨਿਯਮ, ਜਿਵੇਂ ਸਿਰਲੇਖਾਂ, ਪੰਨਿਆਂ ਜਾਂ ਬੁਲਾਰਿਆਂ ਦੀ ਵਾਰੀ ਮੁਤਾਬਕ

• ਮੈਟਾਡਾਟਾ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਵਾਲੀ ਹਿੱਸਾ-ਵੰਡ, ਜਿਸ ਵਿੱਚ ਭਾਗਾਂ ਦੇ ਸਿਰਲੇਖ, ਸਮਾਂ-ਚਿੰਨ੍ਹ, ਲੇਖਕ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਿਸਮ ਕਾਇਮ ਰੱਖੇ ਜਾਣ

• ਹਰੇਕ ਦਸਤਾਵੇਜ਼ ਕਿਸਮ ਲਈ ਵੱਖਰੀ ਐਂਬੈਡਿੰਗ ਰਣਨੀਤੀ

ਉਪਰੋਕਤ ਮਾਮਲਿਆਂ ਵਿੱਚ pgai ਘੱਟ ਲਚਕ ਦਿੰਦਾ ਹੈ.

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

ਜੇ Timescale, Chonkie ਵਰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਮਿਲਦੀਆਂ ਕੁਝ ਹੋਰ ਉੱਨਤ ਹਿੱਸਾ-ਵੰਡ ਰਣਨੀਤੀਆਂ ਸ਼ਾਮਲ ਕਰ ਸਕੇ ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ Anthropic ਦੀ ਸੰਦਰਭੀ ਪ੍ਰਾਪਤੀ ਵਰਗੇ ਉੱਨਤ ਡਿਜ਼ਾਈਨਾਂ ਦਾ ਸਮਰਥਨ ਦੇਵੇ, ਤਾਂ ਇਹ ਸ਼ਾਨਦਾਰ ਹੋਵੇਗਾ.

2) ਪਹਿਲਾਂ ਲਿਖਤ, ਬਹੁ-ਮਾਧਿਅਮ ਨਹੀਂ.

RAG ਦੀਆਂ ਕਈ ਦਿਲਚਸਪ ਸਮੱਸਿਆਵਾਂ ਹੁਣ ਸਿਰਫ਼ ਲਿਖਤ ਤੱਕ ਸੀਮਤ ਨਹੀਂ ਰਹੀਆਂ:

• ਚਿੱਤਰਾਂ ਵਾਲੀਆਂ PDF ਫ਼ਾਈਲਾਂ

• ਸਕ੍ਰੀਨਸ਼ਾਟ ਜਾਂ ਤਸਵੀਰਾਂ

• ਧੁਨੀ ਰਿਕਾਰਡਿੰਗਾਂ

• ਵੀਡੀਓ ਅੰਸ਼

ਭਾਵੇਂ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਸਰੋਤਾਂ ਵਿੱਚੋਂ “ਲਿਖਤ ਕੱਢ” ਸਕਦੇ ਹੋ, ਪਰ ਇਹ ਅਸਲ ਬਹੁ-ਮਾਧਿਅਮ ਐਂਬੈਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ.

ਜੇ pgai ਆਖ਼ਰਕਾਰ ਬਹੁ-ਮਾਧਿਅਮ ਮਾਡਲਾਂ ਲਈ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸਮਰਥਨ ਦੇਵੇ, ਅਰਥਾਤ S3 ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ, ਧੁਨੀ ਜਾਂ ਵੀਡੀਓ ਨੂੰ ਮਜ਼ਬੂਤ ਸਮਕਾਲੀਕਰਨ ਨਾਲ ਲੋਡ → ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡ → ਐਂਬੈਡ ਕਰੇ, ਤਾਂ ਇਹ ਬਹੁਤ ਆਕਰਸ਼ਕ ਹੋਵੇਗਾ. ਪਰ ਅੱਜ ਇਹ ਲਿਖਤ ਐਂਬੈਡਿੰਗ ਕਾਰਜ-ਪ੍ਰਵਾਹ ਹੈ.

3) ਜੇ ਤੁਹਾਨੂੰ ਸਿਰਫ਼ ਐਂਬੈਡਿੰਗਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਤਾਂ ਸ਼ਾਇਦ pgai ਦੀ ਲੋੜ ਨਹੀਂ.

ਜੇ ਤੁਹਾਡੀ ਡਾਟਾ-ਪ੍ਰਾਪਤੀ ਪ੍ਰਕਿਰਿਆ ਪਹਿਲਾਂ ਹੀ ਅਨੁਕੂਲਿਤ ਹੈ ਜਾਂ ਅਜਿਹੀ ਹੋਣੀ ਲਾਜ਼ਮੀ ਹੈ, ਤਾਂ “ਲਿਖਤ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਐਂਬੈਡ ਕਰਨਾ” RAG ਦਾ ਸਭ ਤੋਂ ਔਖਾ ਭਾਗ ਨਹੀਂ ਹੈ. ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ pgai ਸਮੱਸਿਆ ਦਾ ਸਭ ਤੋਂ ਸੌਖਾ ਭਾਗ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇ ਤੁਹਾਡਾ ਗਿਆਨ-ਭੰਡਾਰ ਕਦੇ-ਕਦਾਈਂ ਹੀ ਅੱਪਡੇਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਐਂਬੈਡਿੰਗਾਂ ਦੇ ਸਵੈਚਾਲਿਤ ਸਮਕਾਲੀਕਰਨ ਦਾ ਮੁੱਲ ਵੀ ਘੱਟ ਹੁੰਦਾ ਹੈ.

pgai ਦੀ ਇੱਕ ਖ਼ਾਸ ਤੌਰ ’ਤੇ ਚੰਗੀ ਵਰਤੋਂ ਆਪਣੇ ਡਾਟਾਬੇਸਾਂ ਉੱਤੇ ਲਿਖਤ-ਤੋਂ-SQL ਅੰਤਰਫਲਕ ਤੈਨਾਤ ਕਰਨਾ ਹੋਵੇਗੀ. pgai ਵੱਲੋਂ ਦਿੱਤੇ semantic_catalog ਮੋਡੀਊਲ ਨਾਲ ਇਹ ਕਾਫ਼ੀ ਸੌਖੇ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਬਸ ਇਸ ਤਰ੍ਹਾਂ ਸੈੱਟਅੱਪ ਕਰੋ:

1OPENAI_API_KEY="your-OpenAPI-key-goes-here"2TARGET_DB="postgres://user:password@host:port/database"3CATALOG_DB="postgres://user:password@host:port/database"

ਫਿਰ pgai semantic-catalog create ਨਾਲ ਅਰਥ-ਸੂਚੀ ਨੂੰ ਤੁਹਾਡੀਆਂ ਡਾਟਾ ਡਿਕਸ਼ਨਰੀਆਂ ਵਿੱਚੋਂ ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਦਿਓ. ਇਹ ਤੁਹਾਡੇ ਡਾਟਾ-ਭੰਡਾਰ ਤੋਂ ਅਜਿਹਾ ਸੰਦਰਭ ਬਣਾਉਂਦਾ ਹੈ:

1---2schema: postgres_air3name: aircraft4type: table5description: Lists aircraft models with performance characteristics and unique codes.6columns:7- name: model8  description: Commercial name of the aircraft model.9- name: range10  description: Maximum flight range in kilometers.11- name: class12  description: Airframe class category or configuration indicator.13- name: velocity14  description: Cruising speed of the aircraft.15- name: code16  description: Three-character aircraft code serving as the primary key.17...

ਇਹ ਸੰਦਰਭ ਹੁਣ pgai ਲਈ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਉਪਲਬਧ ਹੈ:

ਅਰਥ-ਆਧਾਰਿਤ ਖੋਜ ਰਾਹੀਂ:

ਇਹ ਪੁੱਛਗਿੱਛ ਉਹ ਸਾਰਣੀਆਂ, ਫੰਕਸ਼ਨ ਅਤੇ ਹੋਰ ਇਕਾਈਆਂ ਵਾਪਸ ਕਰੇਗੀ ਜੋ ਤੁਹਾਡੀ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਵਾਲੀ ਪੁੱਛਗਿੱਛ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋ ਸਕਦੀਆਂ ਹਨ:

1pgai semantic-catalog search -p "Your natural language question goes here!"

ਕੱਚਾ ਸੰਦਰਭ ਪ੍ਰਾਪਤ ਕਰੋ:

ਇਹ ਤੁਹਾਡੀ ਕੁਦਰਤੀ ਭਾਸ਼ਾ ਵਾਲੀ ਪੁੱਛਗਿੱਛ ਨਾਲ ਸੰਬੰਧਿਤ ਕੱਚਾ YAML ਸੰਦਰਭ ਦਿਖਾਏਗਾ:

1pgai semantic-catalog search -p "Your natural language question goes here!" --render

SQL ਬਣਾਓ:

ਜਾਂ ਤੁਸੀਂ ਆਪਣੀ ਪੁੱਛਗਿੱਛ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਲੋੜੀਂਦਾ ਕੱਚਾ SQL ਸਿੱਧਾ ਬਣਾ ਸਕਦੇ ਹੋ. ਪਿਛਲੇ ਕਦਮ ਦਾ ਸੰਦਰਭ ਇੱਕ LLM ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

1pgai semantic-catalog generate-sql -p "Your natural language question goes here!"

ਜੇ ਤੁਸੀਂ ਮੁਕਾਬਲਤਨ ਸੌਖਾ RAG ਸਿਸਟਮ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਹੇਠ ਲਿਖੀਆਂ ਲੋੜਾਂ ਲਈ pgai ਅਜ਼ਮਾਉਣ ਯੋਗ ਹੈ:

• ਤੁਹਾਡੇ ਅਧਿਕਾਰਤ ਰਿਕਾਰਡ ਸਿਸਟਮ ਵਜੋਂ Postgres,

• ਘੱਟ ਤੋਂ ਘੱਟ ਜੋੜਨ ਵਾਲਾ ਕੋਡ,

• ਆਪਣੇ ਆਪ ਸਮਕਾਲੀ ਰਹਿਣ ਵਾਲੀਆਂ ਐਂਬੈਡਿੰਗਾਂ,

• ਆਪਣੇ ਡਾਟਾਬੇਸਾਂ ਉੱਤੇ ਲਿਖਤ-ਤੋਂ-SQL ਲਾਗੂ ਕਰਨ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ,

• ਨਵੇਂ RAG ਸੰਦਾਂ ਅਤੇ Postgres ਵਿਸਥਾਰਾਂ ਨਾਲ ਤਜਰਬੇ ਕਰਨਾ.

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

• ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਨੁਕੂਲਿਤ ਡਾਟਾ-ਪ੍ਰਾਪਤੀ ਜਾਂ ਹਿੱਸੇ ਬਣਾਉਣ ਦਾ ਤਰਕ

• ਵੱਖ-ਵੱਖ ਵਿਸ਼ਲੇਸ਼ਣ ਲੋੜਾਂ ਵਾਲੇ ਕਈ ਕਿਸਮਾਂ ਦੇ ਦਸਤਾਵੇਜ਼

• ਬਹੁ-ਮਾਧਿਅਮ ਐਂਬੈਡਿੰਗਾਂ

ਅੰਤ ਵਿੱਚ, ਇਹ ਸਪਸ਼ਟ ਹੈ ਕਿ pgvector ਨੂੰ ਵੱਡੇ ਪੱਧਰ ਉੱਤੇ ਅਪਣਾਇਆ ਗਿਆ ਹੈ, ਪਰ ਇਹ ਸਪਸ਼ਟ ਨਹੀਂ ਕਿ pgai ਨੂੰ ਵੀ ਉੱਨੀ ਹੀ ਦਿਲਚਸਪੀ ਅਤੇ ਇਸ ਕਰਕੇ ਉੱਨਾ ਹੀ ਸਮਰਥਨ ਮਿਲੇਗਾ. ਹਾਲਾਂਕਿ ਇਸਨੂੰ ਆਏ ਅਜੇ ਲਗਭਗ 18 ਮਹੀਨੇ ਹੀ ਹੋਏ ਹਨ.

pgai RAG ਲਈ ਇੱਕ ਦਿਲਚਸਪ ਪਹੁੰਚ ਹੈ, ਜੋ ਰੋਜ਼ਮਰ੍ਹਾ ਦੇ ਸੰਚਾਲਕੀ ਕੰਮ ਦਾ ਵਧੇਰੇ ਹਿੱਸਾ ਡਾਟਾਬੇਸਾਂ ਨੂੰ ਸੌਂਪਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਸੌਖਾ ਰਹੇ.

ਫ਼ਿਲਹਾਲ ਇਹ:

• ਸੌਖੀਆਂ RAG ਬਣਤਰਾਂ ਲਈ ਵਰਤੋਂਯੋਗ ਅਤੇ ਸੱਚਮੁੱਚ ਸੁਖਦ ਹੈ

• ਵਧੇਰੇ ਵਿਸ਼ੇਸ਼ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਖ਼ਾਸ ਕਰਕੇ ਬਹੁ-ਮਾਧਿਅਮ ਪ੍ਰਕਿਰਿਆਵਾਂ, ਲਈ ਕਾਫ਼ੀ ਲਚਕਦਾਰ ਨਹੀਂ ਹੈ

ਇਹ ਉਮੀਦਜਨਕ ਹੈ ਅਤੇ ਇਸਦੀ ਤਰੱਕੀ ਉੱਤੇ ਨਜ਼ਰ ਰੱਖਣੀ ਯਕੀਨੀ ਤੌਰ ’ਤੇ ਲਾਭਦਾਇਕ ਹੋਵੇਗੀ.