LLMಗಳು ಒಮ್ಮೆಗೆ ಸೀಮಿತ ಪ್ರಮಾಣದ ಪಠ್ಯವನ್ನು ಮಾತ್ರ “ನೋಡಬಲ್ಲವು” (ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ). ಸಣ್ಣ ಕೆಲಸಗಳಿಗೆ ಇದು ಸಾಕಾಗುತ್ತದೆ, ಆದರೆ ಜ್ಞಾನಭಂಡಾರವು ಸಾವಿರಾರು ಪುಟಗಳಷ್ಟು ವಿಸ್ತರಿಸಿದಾಗ ವಿಫಲವಾಗುತ್ತದೆ. ಕಾನ್ಟೆಕ್ಸ್ಟ್ ವಿಂಡೋ ಸಾಕಷ್ಟಿದ್ದರೂ, “ಹುಲ್ಲಿನ ಬಣವೆಯಲ್ಲಿ ಸೂಜಿ ಹುಡುಕುವ” ಸಮಸ್ಯೆಯಿಂದ ಕಾರ್ಯಕ್ಷಮತೆ ಕುಸಿಯಬಹುದು.
RAG (‘ಮರುಪಡೆಯುವಿಕೆಯಿಂದ ವರ್ಧಿತ ಉತ್ಪಾದನೆ’) ಬಹಳ ಸಾಮಾನ್ಯ ವಿಧಾನವಾಗಿ ಹೊರಹೊಮ್ಮಿದೆ. ಇದರಲ್ಲಿ ನೀವು ಜ್ಞಾನಭಂಡಾರವನ್ನು (ದಾಖಲೆಗಳು, ವಿಕಿಗಳು, ನೀತಿಗಳು, ಪ್ರತಿಲಿಪಿಗಳು ಇತ್ಯಾದಿ) ನಿರ್ವಹಿಸುತ್ತೀರಿ, ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಗೆ ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ಬಳಸಿ ಶಬ್ದಾರ್ಥ ಹುಡುಕಾಟ ನಡೆಸಿ ಅತ್ಯಂತ ಸಂಬಂಧಿತ ತುಣುಕುಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ ಮತ್ತು ಆ ಭಾಗಗಳನ್ನು ಪ್ರಶ್ನೆಯೊಂದಿಗೆ LLMಗೆ ಒದಗಿಸುತ್ತೀರಿ. ಇದು ಮಾಡೆಲ್ನ ಸಂದರ್ಭವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಸರಿಯಾಗಿ ಮಾಡಿದಾಗ ಉತ್ತರದ ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಿ ಭ್ರಮಾತ್ಮಕ ಉತ್ತರಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.
pgai ಎಂಬುದು ಮುಕ್ತ ಆಕರದ Postgres ವಿಸ್ತರಣೆ (ಮತ್ತು ಪೂರಕ ಪರಿಕರಗಳ ಸಮೂಹ). ವಿಶ್ವಾಸಾರ್ಹ ಮುಕ್ತ ಆಕರದ PostgreSQL ಡೇಟಾಬೇಸ್ ಮೇಲೆ “ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆ ಮರುಪಡೆಯುವಿಕೆ” ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನಿರ್ಮಿಸಲು ಇದು ನೆರವಾಗುತ್ತದೆ.
ಎಂಬೆಡಿಂಗ್ಗಳಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು “ಕೇವಲ ಸಂಗ್ರಹಣೆ” ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು, ಪ್ರಮಾಣಿತ RAG ಕಾರ್ಯವಾಹಿನಿಯ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ಡೇಟಾಬೇಸ್ ಪದರಕ್ಕೆ ತರುವುದೇ ಮುಖ್ಯ ಆಲೋಚನೆ (ಒಳಸೇರಿಸು → ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸು → ಎಂಬೆಡ್ ಮಾಡು → ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ಸಮನ್ವಯದಲ್ಲಿರಿಸು).
ಆರಂಭಿಕ ಅನಿಸಿಕೆಯ ಪ್ರಕಾರ ಇದು ಭರವಸೆಯದಾಗಿದೆ. ಆದರೆ ನಿಮ್ಮ RAG ಕಾರ್ಯವಾಹಿನಿ ಸ್ವಲ್ಪ ಸಂಕೀರ್ಣವಾದರೂ, ವಿಶೇಷವಾಗಿ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವ ವಿಧಾನಗಳಲ್ಲಿ, ಇದು ಸೂಕ್ತವಲ್ಲ. ಆದರೂ ನಾವು ಈ ಯೋಜನೆಯನ್ನು ನಿಕಟವಾಗಿ ಗಮನಿಸುತ್ತೇವೆ.
RAG ನಿರ್ಮಿಸಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ. ವಿವಿಧ RAG ವಿಧಾನಗಳ ವಿವರವಾದ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ RAG ಪರಿಹಾರಗಳ ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳು. ಲೇಖನವನ್ನು ಓದಿ. ಗುಣಮಟ್ಟಕ್ಕೆ ಆದ್ಯತೆ ನೀಡಿದಾಗ ವಿನ್ಯಾಸದ ಆಯ್ಕೆಗಳು ಅಚ್ಚರಿಯಷ್ಟು ಸಂಕೀರ್ಣವಾಗುತ್ತವೆ. ಸಾಮಾನ್ಯ “ಪೂರ್ವನಿಯೋಜಿತ” ವಿಧಾನವು ಹೀಗಿರುತ್ತದೆ:
ದಾಖಲೆಗಳ ಗುಚ್ಛವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ.
ಅವುಗಳನ್ನು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಿ. ಇದನ್ನು ಮಾಡಲು ಹಲವು ವಿಧಾನಗಳಿವೆ (ಉದಾ. ಪ್ಯಾರಾಗಳು, ಶಬ್ದಾರ್ಥದ ಗುಂಪುಗಳು).
ಪ್ರತಿ ಭಾಗವನ್ನೂ ಎಂಬೆಡಿಂಗ್ ಆಗಿ ಪರಿವರ್ತಿಸಿ.
ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ (Pinecone, Milvus ಇತ್ಯಾದಿ) ಅಥವಾ pgvector ಬಳಸಿ Postgresನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ.
ಪ್ರಶ್ನಿಸುವಾಗ ಅತ್ಯಂತ ಹತ್ತಿರದ ಭಾಗಗಳನ್ನು ಹುಡುಕಿ `ಮತ್ತು ಅವುಗಳನ್ನು LLMಗೆ ಕಳುಹಿಸಿ (ಮತ್ತೊಮ್ಮೆ ಹೇಳುವುದಾದರೆ... ಇದನ್ನೂ ಮಾಡಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ).
ಹಲವು ತಂತ್ರಜ್ಞಾನ ಸಂಯೋಜನೆಗಳಲ್ಲಿ (1)–(3)ನೇ ಹಂತಗಳು ಡೇಟಾಬೇಸ್ನ ಹೊರಗೆ, ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅಥವಾ ದತ್ತಾಂಶ ಕಾರ್ಯವಾಹಿನಿಯಲ್ಲಿ ನಡೆಯುತ್ತವೆ. ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮುಖ್ಯವಾಗಿ ಇವುಗಳಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ:
ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು
ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ಹುಡುಕುವುದು
pgai ಒಂದು Postgres ವಿಸ್ತರಣೆ. ಇದು ಮುಕ್ತ ಆಕರದ್ದಾಗಿದ್ದು, Timescale ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ನಡುವಿನ ಗಡಿಯನ್ನು ಮಸುಕಾಗಿಸಲು ಇದು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.
ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೈಯಾರೆ ನಿರ್ವಹಿಸುವ ಅಂಶವಾಗಿ ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ಪರಿಗಣಿಸುವ ಬದಲು, pgai ಅವುಗಳನ್ನು ಡೇಟಾಬೇಸ್ ವೈಶಿಷ್ಟ್ಯವನ್ನಾಗಿಸುತ್ತದೆ:
ಯಾವ ಕೋಷ್ಟಕ ಅಥವಾ ದಾಖಲೆಗಳನ್ನು ಎಂಬೆಡ್ ಮಾಡಬೇಕೆಂದು ನೀವು ನಿರ್ಧರಿಸುತ್ತೀರಿ.
ಎಂಬೆಡಿಂಗ್ ಮಾಡೆಲ್ ಮತ್ತು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವ ತಂತ್ರವನ್ನು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ.
ಮೂಲ ದತ್ತಾಂಶ ಬದಲಾದಂತೆ ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ನವೀಕರಿಸುವುದೂ ಸೇರಿದಂತೆ ಉಳಿದೆಲ್ಲವನ್ನೂ pgai ನಿರ್ವಹಿಸುತ್ತದೆ.
ಇದರ ಭರವಸೆ ಆಕರ್ಷಕವಾಗಿದೆ:
ನಿರ್ವಹಿಸಬೇಕಾದ ವಿಶೇಷ ಸಂಯೋಜಕ ಕೋಡ್ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಆಧಾರವಾಗಿರುವ ಮೂಲ ದಾಖಲೆಗಳು ಬದಲಾದಂತೆ ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ‘ತಾಜಾ’ವಾಗಿರಿಸುವುದು ಸುಲಭವಾಗಬೇಕು.
ಮರುಪ್ರಯತ್ನಗಳು, ಬಳಕೆ ದರದ ಮಿತಿಗಳು, ವಿಫಲ ಕಾರ್ಯಗಳು ಇತ್ಯಾದಿಯನ್ನು Postgres/pgai ನಿರ್ವಹಿಸುತ್ತದೆ.
ಓದುಗರ ಗಮನಕ್ಕೆ: pgai ತನ್ನೊಳಗೆ pgvector ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಇದು ಮತ್ತೊಂದು ಜನಪ್ರಿಯ RAG Postgres ವಿಸ್ತರಣೆ. pgvector, Postgresಗೆ ವೆಕ್ಟರ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಸಾಮ್ಯತೆ ಹುಡುಕಾಟವನ್ನು ಸೇರಿಸುತ್ತದೆ. pgai ಅದರ ಮೇಲೆ ನಿರ್ಮಿತವಾಗಿದ್ದು, ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು, ಎಂಬೆಡ್ ಮಾಡುವುದು ಮತ್ತು ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ನವೀಕೃತವಾಗಿರಿಸುವಂತಹ RAG ಕಾರ್ಯವಾಹಿನಿಯ ಹಂತಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ.
1) ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಸರಳವಾಗಿದೆ.
ಎಲ್ಲವೂ ನಿರೀಕ್ಷೆಯಂತೆ ನಡೆದರೆ ಪ್ರಕ್ರಿಯೆ ಸಾಕಷ್ಟು ಸರಳವಾಗಿದೆ:
Timescale ಡಾಕರ್ ಇಮೇಜ್ಗಳನ್ನು (ಡೇಟಾಬೇಸ್ + ವರ್ಕರ್) ಪಡೆಯಿರಿ.
ನಿಮ್ಮ ಎಂಬೆಡಿಂಗ್ ಪೂರೈಕೆದಾರರ API ಕೀಲಿಯನ್ನು ಒದಗಿಸಿ.
ವೆಕ್ಟರೈಸರ್ ಅನ್ನು ಘೋಷಿಸಲು ಸ್ವಲ್ಪ SQL ಚಲಾಯಿಸಿ (ಮೂಲತಃ: ಯಾವುದನ್ನು ಎಂಬೆಡ್ ಮಾಡಬೇಕು, ಹೇಗೆ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಬೇಕು ಮತ್ತು ಯಾವ ಮಾಡೆಲ್ ಬಳಸಬೇಕು).
ನಂತರ ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆಯಾಗಿ ವೆಕ್ಟರೈಸರ್ ವರ್ಕರ್ ಚಲಿಸುವಂತೆ pgai ವ್ಯವಸ್ಥೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅಸಮಕಾಲಿಕವಾಗಿ ಎಂಬೆಡಿಂಗ್ಗಳನ್ನು ರಚಿಸುತ್ತದೆ (ಉದಾ. ಪ್ರತಿ 5 ನಿಮಿಷಕ್ಕೊಮ್ಮೆ ಅಥವಾ ನಿಮಗೆ ಬೇಕಾದ ಅವಧಿಯಲ್ಲಿ).
2) ಸಂಪೂರ್ಣ ಕಾರ್ಯವಾಹಿನಿಯನ್ನು ಡೇಟಾಬೇಸ್ನ “ಹತ್ತಿರವೇ” ನಡೆಸುವುದು ಅನುಕೂಲಕರವಾಗಿದೆ.
pgai ಕೋಷ್ಟಕಗಳಿಂದ ವಿಷಯವನ್ನು ಒಳಸೇರಿಸಬಹುದು. S3ನಂತಹ ಸ್ಥಳಗಳಿಂದ ದಾಖಲೆಗಳನ್ನು ಲೋಡ್ ಮಾಡಿ, ಅವುಗಳನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ, ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಿ, ಎಂಬೆಡ್ ಮಾಡಬಹುದು. ಇದು PDF, ಮಾರ್ಕ್ಡೌನ್ ಮುಂತಾದ ವಿವಿಧ ಪಠ್ಯ ದಾಖಲೆ ಸ್ವರೂಪಗಳನ್ನೂ ನಿರ್ವಹಿಸಬಲ್ಲದು.
1) ನೀವು ಸಾಕಷ್ಟು ನಿಯಂತ್ರಣ ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ (ಮತ್ತು RAGಗೆ ಕೆಲವೊಮ್ಮೆ ನಿಯಂತ್ರಣ ಅಗತ್ಯ).
ಉತ್ತರದ ಗುಣಮಟ್ಟದ ಆಧಾರದಲ್ಲಿ ಅಳೆಯುವ ಉನ್ನತ ಕಾರ್ಯಕ್ಷಮತೆಯ RAG ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿಯ ವಿಶೇಷ ಕಾರ್ಯವಾಹಿನಿಗಳು ಅಗತ್ಯ:
ಕಸ್ಟಮ್ ಭಾಗ-ವಿಭಜನೆ ನಿಯಮಗಳು (ಶೀರ್ಷಿಕೆ, ಪುಟ, ಮಾತನಾಡುವವರ ಸರದಿ ಇತ್ಯಾದಿಗಳ ಆಧಾರದಲ್ಲಿ)
ಮೆಟಾಡೇಟಾ-ಅರಿವಿನ ಭಾಗ-ವಿಭಜನೆ (ವಿಭಾಗದ ಶೀರ್ಷಿಕೆಗಳು, ಸಮಯಗುರುತುಗಳು, ಲೇಖಕರು, ದಾಖಲೆ ಪ್ರಕಾರವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದು)
ಪ್ರತಿ ದಾಖಲೆ ಪ್ರಕಾರಕ್ಕೂ ವಿಭಿನ್ನ ಎಂಬೆಡಿಂಗ್ ತಂತ್ರಗಳು
ಮೇಲಿನ ಅಂಶಗಳಲ್ಲಿ pgai ಕಡಿಮೆ ನಮ್ಯತೆ ನೀಡುತ್ತದೆ.
ಸದ್ಯಕ್ಕೆ ಎರಡು ಮುಖ್ಯ ಭಾಗ-ವಿಭಜನೆ ತಂತ್ರಗಳಿವೆ: ಅಕ್ಷರ ಪಠ್ಯ ವಿಭಜಕ ಮತ್ತು ಪುನರಾವರ್ತಿತ ಅಕ್ಷರ ಪಠ್ಯ ವಿಭಜಕ. ಜೊತೆಗೆ ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸದಿರುವ ಆಯ್ಕೆಯೂ ಇದೆ. ಕೆಲವು ಬಳಕೆಯ ಸಂದರ್ಭಗಳಿಗೆ ಅದು ಸಾಕಾಗಬಹುದು. ಆದರೆ ಕಾರ್ಯೋತ್ಪಾದನಾ ಪರಿಸರದ ಅನೇಕ RAG ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಹೆಚ್ಚು ಕಸ್ಟಮೈಸೇಶನ್ ಅಗತ್ಯ.
Chonkieಯಂತಹ ಲೈಬ್ರರಿಗಳಲ್ಲಿ ಕಾಣುವ ಹೆಚ್ಚು ಸುಧಾರಿತ ಭಾಗ-ವಿಭಜನೆ ತಂತ್ರಗಳನ್ನು Timescale ಅಳವಡಿಸಬಹುದೇ ಎಂಬುದನ್ನು ನೋಡುವುದು ಅದ್ಭುತವಾಗಿರುತ್ತದೆ. ಅದೇ ರೀತಿ Anthropicನ ಸಂದರ್ಭಾಧಾರಿತ ಮರುಪಡೆಯುವಿಕೆಯಂತಹ ಸುಧಾರಿತ ವಿನ್ಯಾಸಗಳಿಗೂ ಬೆಂಬಲ ನೀಡಬಹುದು.
2) ಪಠ್ಯಕ್ಕೆ ಮೊದಲ ಆದ್ಯತೆ, ಬಹುವಿಧ ಮಾಧ್ಯಮಕ್ಕಲ್ಲ.
ಹಲವು ಆಸಕ್ತಿದಾಯಕ RAG ಸಮಸ್ಯೆಗಳು ಈಗ ಕೇವಲ ಪಠ್ಯಕ್ಕೆ ಸೀಮಿತವಾಗಿಲ್ಲ:
ರೇಖಾಚಿತ್ರಗಳಿರುವ PDFಗಳು
ತೆರೆಚಿತ್ರಗಳು / ಚಿತ್ರಗಳು
ಧ್ವನಿ ಮುದ್ರಣಗಳು
ವೀಡಿಯೊ ತುಣುಕುಗಳು
ಈ ಮೂಲಗಳಿಂದ “ಪಠ್ಯವನ್ನು ಹೊರತೆಗೆಯಲು” ಸಾಧ್ಯವಾದರೂ, ಅದು ನಿಜವಾದ ಬಹುವಿಧ ಮಾಧ್ಯಮ ಎಂಬೆಡಿಂಗ್ ಕಾರ್ಯವಾಹಿನಿಗೆ ಸಮಾನವಲ್ಲ.
ಭವಿಷ್ಯದಲ್ಲಿ pgai ಬಹುವಿಧ ಮಾಧ್ಯಮ ಮಾಡೆಲ್ಗಳಿಗೆ ಮೊದಲಿನಿಂದ ಕೊನೆಯವರೆಗೆ ಬೆಂಬಲ ನೀಡಿದರೆ ಅದು ಆಕರ್ಷಕವಾಗಿರುತ್ತದೆ. ಅಂದರೆ S3ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿರುವ ದೊಡ್ಡ ಚಿತ್ರಗಳು, ಧ್ವನಿ ಮತ್ತು ವೀಡಿಯೊಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹ ಸಮನ್ವಯದೊಂದಿಗೆ ಲೋಡ್ ಮಾಡುವುದು → ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುವುದು → ಎಂಬೆಡ್ ಮಾಡುವುದು. ಆದರೆ ಇಂದು ಇದು ಪಠ್ಯ ಎಂಬೆಡಿಂಗ್ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ.
3) ನಿಮಗೆ ಎಂಬೆಡಿಂಗ್ಗಳು ಮಾತ್ರ ಬೇಕಿದ್ದರೆ, pgai ಅಗತ್ಯವಿಲ್ಲದಿರಬಹುದು.
ನಿಮ್ಮ ಒಳಸೇರಿಸುವಿಕೆ ಕಾರ್ಯವಾಹಿನಿ ಈಗಾಗಲೇ ಕಸ್ಟಮ್ ಆಗಿದ್ದರೆ ಅಥವಾ ಹಾಗಿರಬೇಕಾದರೆ, “ಪಠ್ಯದ ಭಾಗಗಳನ್ನು ಎಂಬೆಡ್ ಮಾಡುವುದು” RAGನ ಅತ್ಯಂತ ಕಷ್ಟದ ಭಾಗವಲ್ಲ. ಅಂತಹ ಸಂದರ್ಭದಲ್ಲಿ pgai ಸಮಸ್ಯೆಯ ಅತ್ಯಂತ ಸುಲಭ ಭಾಗವನ್ನಷ್ಟೇ ಪರಿಹರಿಸುತ್ತದೆ.
ಜೊತೆಗೆ, ನಿಮ್ಮ ಜ್ಞಾನಭಂಡಾರವನ್ನು ಅಪರೂಪಕ್ಕೆ ನವೀಕರಿಸಿದರೆ, ಎಂಬೆಡಿಂಗ್ಗಳ ಸ್ವಯಂಚಾಲಿತ ಸಮನ್ವಯದ ಮೌಲ್ಯ ಅಷ್ಟಾಗಿ ಇರುವುದಿಲ್ಲ.
ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ಗಳ ಮೇಲೆ ಪಠ್ಯದಿಂದ-SQL ಅಂತರಸಂಪರ್ಕವನ್ನು ನಿಯೋಜಿಸುವುದು pgai ಬಳಸುವ ಒಂದು ಉತ್ತಮ ವಿಧಾನವಾಗಿದೆ. pgai ಒದಗಿಸುವ semantic_catalog ಮಾಡ್ಯೂಲ್ ಮೂಲಕ ಇದನ್ನು ಸುಲಭವಾಗಿ ಸಾಧಿಸಬಹುದು. ಈ ರೀತಿ ಸರಳವಾಗಿ ಸಿದ್ಧಪಡಿಸಿ:
Bash
ನಂತರ pgai semantic-catalog create ಬಳಸಿ ನಿಮ್ಮ ದತ್ತಾಂಶ ನಿಘಂಟುಗಳಿಂದ ಮಾಹಿತಿ ಸಂಗ್ರಹಿಸುವಂತೆ ಶಬ್ದಾರ್ಥ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿಸಿ. ಇದು ನಿಮ್ಮ ದತ್ತಾಂಶ ಸಂಗ್ರಹದಿಂದ ಸಂದರ್ಭವನ್ನು ರಚಿಸುತ್ತದೆ. ಅದು ಸರಿಸುಮಾರು ಹೀಗಿರುತ್ತದೆ:
Plain Text
ಈ ಸಂದರ್ಭವು ಈಗ pgaiಗೆ ಹಲವು ರೀತಿಯಲ್ಲಿ ಲಭ್ಯವಿದೆ:
ಶಬ್ದಾರ್ಥ ಹುಡುಕಾಟದ ಮೂಲಕ:
ನಿಮ್ಮ ಸಹಜ ಭಾಷೆಯ ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧಿಸಬಹುದಾದ ಕೋಷ್ಟಕಗಳು, ಕಾರ್ಯಗಳು ಮತ್ತು ಇತರ ವಸ್ತುಗಳನ್ನು ಈ ಪ್ರಶ್ನೆಯು ಹಿಂದಿರುಗಿಸುತ್ತದೆ:
Bash
ಕಚ್ಚಾ ಸಂದರ್ಭವನ್ನು ಪಡೆಯಿರಿ:
ಇದು ನಿಮ್ಮ ಸಹಜ ಭಾಷೆಯ ಪ್ರಶ್ನೆಗೆ ಸಂಬಂಧಿಸಿದ ಕಚ್ಚಾ YAML ಸಂದರ್ಭವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ:
Bash
SQL ರಚಿಸಿ:
ಅಥವಾ ನಿಮ್ಮ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಅಗತ್ಯವಿರುವ ಕಚ್ಚಾ SQL ಅನ್ನು ನೇರವಾಗಿ ರಚಿಸಬಹುದು. ಹಿಂದಿನ ಹಂತದ ಸಂದರ್ಭವನ್ನು LLMಗೆ ಕಳುಹಿಸಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ:
Bash
ನೀವು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾದ RAG ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಈ ಅಗತ್ಯಗಳಿಗಾಗಿ pgai ಪ್ರಯತ್ನಿಸಬಹುದು:
ಪ್ರಮುಖ ದಾಖಲೆ ವ್ಯವಸ್ಥೆಯಾಗಿ Postgres,
ಅತ್ಯಲ್ಪ ಸಂಯೋಜಕ ಕೋಡ್,
ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಮನ್ವಯದಲ್ಲಿರುವ ಎಂಬೆಡಿಂಗ್ಗಳು,
ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ಗಳಿಗೆ ಪಠ್ಯದಿಂದ-SQL ಅನ್ವಯಿಸುವ ತ್ವರಿತ ಮಾರ್ಗ,
ಹೊಸ RAG ಪರಿಕರಗಳು ಮತ್ತು Postgres ವಿಸ್ತರಣೆಗಳನ್ನು ಪ್ರಯೋಗಿಸುವುದು.
ನಿಮ್ಮ RAG ಕಾರ್ಯವಾಹಿನಿಗೆ ಈ ಕೆಳಗಿನವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಅಗತ್ಯವಿದ್ದರೆ, pgai ಬಳಸಲು ಕಾಯುವುದು ಸೂಕ್ತ:
ವ್ಯಾಪಕವಾಗಿ ಕಸ್ಟಮೈಸ್ ಮಾಡಿದ ಒಳಸೇರಿಸುವಿಕೆ ಅಥವಾ ಭಾಗ ಮಾಡುವ ತರ್ಕ
ವಿಭಿನ್ನ ಪಾರ್ಸಿಂಗ್ ಅಗತ್ಯಗಳಿರುವ ಹಲವು ದಾಖಲೆ ಪ್ರಕಾರಗಳು
ಬಹುವಿಧ ಮಾಧ್ಯಮದ ಎಂಬೆಡಿಂಗ್ಗಳು
ಕೊನೆಯದಾಗಿ, pgvector ವ್ಯಾಪಕ ಬಳಕೆ ಕಂಡಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟ. ಆದರೆ pgaiಗೂ ಅಷ್ಟೇ ಆಸಕ್ತಿ ಮತ್ತು ಅದರ ಪರಿಣಾಮವಾಗಿ ಬೆಂಬಲ ಸಿಗುತ್ತದೆಯೇ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಇದು ಬಳಕೆಗೆ ಬಂದು ಕೇವಲ ಸುಮಾರು 18 ತಿಂಗಳಾಗಿವೆ ಎಂಬುದನ್ನೂ ಗಮನಿಸಬೇಕು.
ನಿತ್ಯದ ಕಾರ್ಯಾಚರಣೆಯ ಹೆಚ್ಚಿನ ಕೆಲಸವನ್ನು ಡೇಟಾಬೇಸ್ಗಳೇ ನಿರ್ವಹಿಸಿ, ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಸರಳಗೊಳಿಸಲು ನೆರವಾಗುವ pgai, RAGಗೆ ಆಸಕ್ತಿದಾಯಕ ವಿಧಾನವಾಗಿದೆ.
ಸದ್ಯಕ್ಕೆ ಇದು:
ಸರಳ RAG ಸಂಯೋಜನೆಗಳಿಗೆ ಬಳಸಲು ಯೋಗ್ಯ ಮತ್ತು ನಿಜಕ್ಕೂ ಅನುಕೂಲಕರವಾಗಿದೆ
ಹೆಚ್ಚು ವಿಶೇಷವಾಗಿ ರೂಪಿಸಿದ ಕಾರ್ಯವಾಹಿನಿಗಳಿಗೆ, ಅದರಲ್ಲೂ ಬಹುವಿಧ ಮಾಧ್ಯಮಕ್ಕೆ, ಸಾಕಷ್ಟು ನಮ್ಯವಾಗಿಲ್ಲ
ಇದು ಭರವಸೆ ಮೂಡಿಸಿದೆ. ಇದರ ಪ್ರಗತಿಯನ್ನು ಖಂಡಿತವಾಗಿಯೂ ಗಮನಿಸುತ್ತಿರಬೇಕು.