ಹೆಚ್ಚಿನ RAG ಟ್ಯುಟೋರಿಯಲ್‌ಗಳು ನೋಟ್‌ಬುಕ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ. ಅವು ಕೆಲವು ಸುಸಜ್ಜಿತ PDFಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತವೆ, ಪ್ರತಿ ಸಾವಿರ ಅಕ್ಷರಗಳಿಗೆ ಪಠ್ಯವನ್ನು ವಿಭಜಿಸುತ್ತವೆ, ಆ ತುಣುಕುಗಳನ್ನು ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ಗೆ ಹಾಕುತ್ತವೆ ಮತ್ತು ಅದನ್ನು ಒಂದು ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂದು ಕರೆಯುತ್ತವೆ. ಶುಕ್ರವಾರದ ಮಧ್ಯಾಹ್ನ, ಆ ಡೆಮೊವು ಪರಿಪೂರ್ಣವಾಗಿ ಚಲಿಸುತ್ತದೆ. ಆದರೆ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ಅದೇ ಪೈಪ್‌ಲೈನ್ ಸುಮ್ಮನೆ ಒಂದು ಹೊರೆಯಾಗಿ ಬದಲಾಗುತ್ತದೆ.

ರಿಟ್ರಿವಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿನ ನಿಜವಾದ ಅಡಚಣೆಯು (bottleneck) ಮಾದರಿ ಅಥವಾ ಪ್ರಾಂಪ್ಟ್ ಆಗಿರುವುದಿಲ್ಲ. ಅದು ಇಂಜೆಸ್ಟಿನ್ (ingestion). ಒಂದು RAG ಪೈಪ್‌ಲೈನ್ ಅದಕ್ಕೆ ನೀಡಲಾದ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ರಿಟ್ರೀವ್ ಮಾಡಬಲ್ಲದು, ಮತ್ತು ಆ ಮಾಹಿತಿ ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ (noisy), ಹಳೆಯದಾಗಿದ್ದರೆ (stale) ಅಥವಾ ಅಪೂರ್ಣವಾಗಿದ್ದರೆ, ಮಾದರಿಯು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು ನೀಡುತ್ತದೆ. ಬಾಟ್ ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ (hallucinated) ಮಾಡಿದೆ ಎಂದು ಬಳಕೆದಾರರು ದೂರು ನೀಡಿದಾಗ, ಅದರ ತಪ್ಪೆಲ್ಲವೂ ಯಾರೂ ಸೂಕ್ಷ್ಮವಾಗಿ ಗಮನಿಸದ ಡೇಟಾ ಪೈಪ್‌ಲೈನ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿರುತ್ತದೆ.

ವೈಟ್‌ಬೋರ್ಡ್ ಟ್ರ್ಯಾಪ್ (The Whiteboard Trap)

ಆರ್ಕಿಟೆಕ್ಚರ್ ಡೈಗ್ರಾಮ್‌ಗಳು ಇಂಜೆಸ್ಟಿನ್ ಅನ್ನು "Documents → Vector DB" ಎಂದು ಲೇಬಲ್ ಮಾಡಿದ ಒಂದೇ ಬಾಣದಂತೆ ತೋರಿಸುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಮೂಲប្រព័ន្ធಗಳು (Source systems) ಯಾವುದೇ ಸೂಚನೆ ಇಲ್ಲದೆ ಬದಲಾಗುತ್ತವೆ. HTML ಲೇಔಟ್‌ಗಳು ಮರುರೂಪಗೊಳ್ಳುತ್ತವೆ. URLಗಳು ಸಾಮಾನ್ಯ ಲ್ಯಾಂಡಿಂಗ್ ಪೇಜ್‌ಗಳಿಗೆ ರಿಡೈರೆಕ್ಟ್ ಆಗುತ್ತವೆ. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ಆರಂಭಿಕ HTTP ಪ್ರತಿಕ್ರಿಯೆಯ ನಂತರ ವಿಷಯವನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ. ಇಂಜೆಸ್ಟಿನ್ ಅನ್ನು ಒಂದು ಬಾರಿಯ ಸೆಟಪ್ ಕಾರ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು ಮೊದಲ ತಪ್ಪು. ಇದು ಯಾವುದೇ ETL ಪೈಪ್‌ಲೈನ್‌ನಷ್ಟೇ ಕಠಿಣವಾದ ಮತ್ತು ನಿರಂತರವಾದ ಡೇಟಾ ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಸ್ಯೆಯಾಗಿದೆ.

RAG ವೈಫಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಫೀಡ್ ವೈಫಲ್ಯಗಳಾಗಲು ಕಾರಣವೇನು?

ಇದನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ: ಒಬ್ಬ ಬಳಕೆದಾರರು ನಿಮ್ಮ ಇಂಟರ್ನಲ್ ಅಸಿಸ್ಟೆಂಟ್‌ನನ್ನು ಪ್ರಸ್ತುತ ರಿಫಂಡ್ ಪಾಲಿಸಿಯ ಬಗ್ಗೆ ಕೇಳುತ್ತಾರೆ. ಮಾದರಿಯು ವೆಕ್ಟರ್ ಸ್ಟೋರ್‌ನಿಂದ ಮೇಲಿನ ತುಣುಕನ್ನು (top chunk) ತೆಗೆದುಕೊಂಡು 30 ದಿನಗಳ ಅವಧಿಯನ್ನು ತಿಳಿಸುತ್ತದೆ. ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಪಾಲಿಸಿಯು ಕಳೆದ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ 60 ದಿನಗಳಿಗೆ ಬದಲಾಗಿದೆ. LLM ತಪ್ಪು ಉತ್ತರವನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ. ಅದು ತಪ್ಪಾದ ಇನ್‌ಪುಟ್ ಅನ್ನು ನಂಬಿತು. ರಿಟ್ರಿವಲ್ ಲೇಯರ್ ಹಳೆಯ ಪೇಜ್ ಅನ್ನು ನೀಡಿತು, ಮತ್ತು ಎಂಬೆಡ್ಡಿಂಗ್ (embedding) ಅರ್ಥಪೂರ್ಣವಾಗಿ ಹತ್ತಿರವಿರುವುದರಿಂದ, ಮಾದರಿಯು ಅದನ್ನು ಸತ್ಯ ಎಂದು ಪರಿಗಣಿಸಿತು.

ಈ ಮಾದರಿಯು ನಿರಂತರವಾಗಿ ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ. ತಂಡಗಳು ತಮ್ಮ ಕಾರ್ಪಸ್ (corpus) ನ್ಯಾವಿಗೇಷನ್ ಫುಟರ್‌ಗಳು, ಡೂಪ್ಲಿಕೇಟ್ ಪ್ರೆಸ್ ರಿಲೀಸ್‌ಗಳು ಮತ್ತು ಟೇಬಲ್‌ಗಳನ್ನು ಅರ್ಧಕ್ಕೆ ವಿಭಜಿಸುವ ತುಣುಕುಗಳಿಂದ ತುಂಬಿದ್ದರೂ, ಟೆಂಪರೇಚರ್ (temperature) ಮತ್ತು top-k ಅನ್ನು ಸರಿಪಡಿಸಲು ಗಂಟೆಗಟ್ಟಲೆ ಸಮಯ ವ್ಯಯಿಸುತ್ತಾರೆ. ನೀವು ಜನರೇಷನ್ ಅನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡುವ ಮೊದಲು, ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಏನನ್ನು ತಿಳಿಯಲು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ಆಡಿಟ್ (audit) ಮಾಡಿ.

ಇಂಜೆಸ್ಟಿನ್ ಅನ್ನು ನಾಶಪಡಿಸುವ ಏಳು ಬಲೆಗಳು

1. ಮೊದಲ ರನ್ ಸುಳ್ಳು

ನಿಮ್ಮ ಆರಂಭಿಕ ಕ್ರಾಲ್‌ನಲ್ಲಿ (crawl) ಹಸಿರು ಚೆಕ್‌ಮಾರ್ಕ್ ಕಾಣಿಸಿಕೊಳ್ಳುವುದು ಅತಿ ಕಡಿಮೆ ಅರ್ಥವನ್ನು ನೀಡುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ ಡೇಟಾ ಜೀವಂತವಾಗಿರುತ್ತದೆ. ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಪೇಜ್‌ಗಳು ಮರುರೂಪಗೊಳ್ಳುತ್ತವೆ, ಬ್ಲಾಗ್ ಪರ್ಮಾಲಿಂಕ್‌ಗಳು ಮುರಿದುಹೋಗುತ್ತವೆ ಮತ್ತು ಸೈಟ್‌ಮ್ಯಾಪ್‌ಗಳು ಸುಮ್ಮನೆ ಕೆಲವು ವಿಭಾಗಗಳನ್ನು ಕೈಬಿಡುತ್ತವೆ. ಪೈಪ್‌ಲೈನ್ ಯಾವುದೇ ದೋಷವಿಲ್ಲದೆ ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ನೀವು ಕೇವಲ ಪರಿಶೀಲಿಸಿದರೆ, ನೀವು ಕಣ್ಣು ಮುಚ್ಚಿ ಹಾರಾಡುತ್ತಿದ್ದೀರಿ ಎಂದರ್ಥ. ನೀವು ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕಾಗುತ್ತದೆ. ನಿರೀಕ್ಷಿತ ದಾಖಲೆಗಳು ಇ presence ಇವೆಯೇ, ಅವುಗಳ ರಚನೆಯು ಇನ್ನೂ ಸರಿಯಾಗಿದೆಯೇ ಮತ್ತು ಮೂಲವು ಫಲಿತಾಂಶಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪುಟಗಟ್ಟಲು (paginate) ನಿರ್ಧರಿಸಿದ ಕಾರಣ ಒಟ್ಟು ಪಠ್ಯದ ಪ್ರಮಾಣ ಕುಸಿದೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.

2. ಕ್ರಾಲಿಂಗ್ ಎನ್ನುವುದು ಇಂಜೆಸ್ಟಿನ್ ಅಲ್ಲ

HTML ಅನ್ನು ಪಡೆಯುವುದು ಸುಲಭವಾದ ಭಾಗವಾಗಿದೆ. ಒಂದು ರಾಗ ಕ್ರಾಲ್ (raw crawl) ಎಲ್ಲವನ್ನೂ ಸೆರೆಹಿಡಿಯುತ್ತದೆ: ಕುಕಿ ಬ್ಯಾನರ್‌ಗಳು, "ಸಂಬಂಧಿತ ಲೇಖನಗಳು" ಸೈಡ್‌ಬಾರ್‌ಗಳು, ಜಾಹೀರಾತು ಬ್ಲಾಕ್‌ಗಳು ಮತ್ತು ಫುಟರ್ ಕಾಪಿರೈಟ್ ನೋಟಿಸ್‌ಗಳು. ನೀವು ಆ ರಾಗ HTML ಅನ್ನು ಅಜಾಗರೂಕತೆಯಿಂದ ಚಂಕ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿದರೆ, ಪ್ರತಿಯೊಂದು ಪಠ್ಯದ ತುಣುಕಿನೊಂದಿಗೆ ನ್ಯಾವಿಗೇಷನ್ ಮೆನುವಿನ ಭಾಗಗಳು ಸೇರಿಕೊಳ್ಳುತ್ತವೆ. ಬಳಕೆದಾರರು API ರೇಟ್ ಲಿಮಿಟ್‌ಗಳ ಬಗ್ಗೆ ಕೇಳಿದಾಗ, ರಿಟ್ರೈವರ್ 40 ಪ್ರತಿಶತ ಸೈಡ್‌ಬಾರ್ ಲಿಂಕ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ತುಣುಕನ್ನು ತೋರಿಸಬಹುದು. ಸ್ವಚ್ಛವಾದ ಎಕ್ಸ್‌ಟ್ರಾಕ್ಷನ್ (extraction) ಮುಖ್ಯವಾಗಿದೆ. ನೀವು ಮುಖ್ಯ ವಿಷಯದ ಪ್ರದೇಶವನ್ನು ಗುರುತಿಸಬೇಕು, ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ (boilerplate) ಅನ್ನು ತೆಗೆದುಹಾಕಬೇಕು ಮತ್ತು ಪ್ರತಿ ಪುಟದಲ್ಲಿ ಪುನರಾವರ್ತನೆಯಾಗುವ ಅಂಶಗಳನ್ನು ತೆಗೆದುಹಾಕಬೇಕು. ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಜ್ಞಾನದ ತಳಹದಿಯನ್ನು (knowledge base) ನಿರ್ಮಿಸುತ್ತಿಲ್ಲ, ಬದಲಾಗಿ ವೆಬ್‌ಸೈಟ್‌ನ ಕ್ರೋಮ್ (chrome) ಗಾಗಿ ಸರ್ಚ್ ಇಂಜಿನ್ ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ.

3. ಚಂಕಿಂಗ್ ಅರ್ಥವನ್ನು ಮುರಿಯುತ್ತದೆ

ಬಹುತೇಕ ಎಲ್ಲಾ ಕ್ವಿಕ್‌ಸ್ಟಾರ್ಟ್ ಗೈಡ್‌ಗಳಲ್ಲಿ ಫಿಕ್ಸೆಡ್-ಸೈಜ್ ಚಂಕಿಂಗ್ (Fixed-size chunking) ಡಿಫಾಲ್ಟ್ ಆಗಿದೆ ಮತ್ತು ಇದು ಅಪಾಯಕಾರಿ. ಕೇವಲ ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆಯ ಆಧಾರದ ಮೇಲೆ ದಾಖಲೆಯನ್ನು ವಿಭಜಿಸಿದರೆ, ನೀವು ಟೇಬಲ್‌ಗಳನ್ನು ಮಧ್ಯದಲ್ಲಿ ಕತ್ತರಿಸುತ್ತೀರಿ, ಸಂಖ್ಯೆಯುಳ್ಳ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಹಂತ 4 ಮತ್ತು 5 ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತೀರಿ ಮತ್ತು ಬುಲೆಟ್ ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಅವುಗಳ ಹೆಡಿಂಗ್‌ಗಳಿಂದ ದೂರ ಮಾಡುತ್ತೀರಿ. ಬೆಲೆ ಪಟ್ಟಿಯ (pricing table) ಎರಡನೇ ಅರ್ಧವನ್ನು ಮಾತ್ರ ಹೊಂದಿರುವ ಚಂಕ್ ಅರ್ಥಹೀನವಾಗಿರುತ್ತದೆ. ಸ್ಟ್ರಕ್ಚರ್-ಅವೇರ್ ಚಂಕಿಂಗ್ (Structure-aware chunking) ಮೂಲ ಫಾರ್ಮ್ಯಾಟ್‌ಗೆ ಗೌರವ ನೀಡುತ್ತದೆ. ಹೆಡಿಂಗ್ ಹಿರಾರ್ಕಿ (hierarchy) ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ. ಸಾಧ್ಯವಾದಷ್ಟು ಟೇಬಲ್‌ಗಳನ್ನು ಅಖಂಡವಾಗಿಡಿ. ಒಂದೇ H2 ಅಥವಾ H3 ಅಡಿಯಲ್ಲಿ ಪ್ಯಾರಾಗ್ರಾಫ್ ಗಡಿಗಳಲ್ಲಿ ವಿಭಜಿಸಿ. ಅವು ಸಾಕಷ್ಟು ಚಿಕ್ಕದಾಗಿದ್ದರೆ ಒಂದೇ ಚಂಕ್‌ನಲ್ಲಿ ಪಟ್ಟಿಗಳನ್ನು (lists) ಉಳಿಸಿಕೊಳ್ಳಿ. ಗುರಿ ಸಮಾನ ಗಾತ್ರದ ಬ್ಲಾಕ್‌ಗಳಲ್ಲ, ಬದಲಾಗಿ ಅರ್ಥಪೂರ್ಣ ಘಟಕಗಳಾಗಿರುವುದು.

4. ಫ್ರೆಶ್‌ನೆಸ್ ಸಮಸ್ಯೆ (The Freshness Problem)

ಒಂದು ಇಂಟರ್ನಲ್ ವಿಕಿಯ ಸ್ಟ್ಯಾಟಿಕ್ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಸರಳವಾದ ವಿಧಾನವಾಗಿದೆ. ಲೈವ್ ವೆಬ್‌ನಿಂದ ನಿರಂತರವಾಗಿ ದತ್ತಾಂಶವನ್ನು ಇಂಜೆಸ್ಟ್ ಮಾಡುವುದು ಕಷ್ಟಕರವಾಗಿದೆ. ಒಂದು ಪುಟವನ್ನು ಕೊನೆಯ ಬಾರಿ ಯಾವಾಗ ಸಂಗ್ರಹಿಸಲಾಯಿತು, ಅದು ಅಂದಿನಿಂದ ಬದಲಾಗಿದೆಯೇ ಮತ್ತು ಆ ಮಾಹಿತಿ ಎಷ್ಟು ಕಾಲ ಮಾನ್ಯವಾಗಿರುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿಯಬೇಕಾಗುತ್ತದೆ. ಹಳೆಯ ದತ್ತಾಂಶ (Stale data) ಎಂದರೆ ಯಾವಾಗಲೂ ಕಣ್ಣಿಗೆ ಕಾಣುವ ಹಳೆಯ ದಿನಾಂಕ ಎಂದರ್ಥವಲ್ಲ. ಕೆಲವೊಮ್ಮೆ ಒಂದು ಪುಟವು ತನ್ನ ಪಠ್ಯವನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತದೆ ಆದರೆ ಅದೇ URL ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಂಟೆಂಟ್ ಹ್ಯಾಶಿಂಗ್ (content hashing) ಇಲ್ಲದೆ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅದನ್ನು ಎಂದಿಗೂ ಗಮನಿಸುವುದಿಲ್ಲ. ಮೂಲದ ಅಸ್ಥಿರತೆಯ ಆಧಾರದ ಮೇಲೆ ಸ್ಪಷ್ಟವಾದ ರಿಫ್ರೆಶ್ ನಿಯಮಗಳನ್ನು ರೂಪಿಸಿ. ಹಣಕಾಸಿನ ದತ್ತಾಂಶ ಫೀಡ್‌ಗೆ ಪ್ರತಿ ಗಂಟೆಗೊಮ್ಮೆ ಪರಿಶೀಲನೆ ಬೇಕಾಗಬಹುದು. ಕಂಪನಿಯ 'ಅಬೌಟ್ ಪೇಜ್'ಗೆ ಪ್ರತಿ ಮೂರು ತಿಂಗಳಿಗೊಮ್ಮೆ ಪರಿಶೀಲನೆ ಬೇಕಾಗಬಹುದು. ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳನ್ನು ದಾಖಲಿಸಿ ಮತ್ತು time-to-live ಮಿತಿಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ, ವಿಶೇಷವಾಗಿ ನಿಮ್ಮ ಡೊಮೇನ್ ನಿಯಮಿತ ಅಥವಾ ಸುರಕ್ಷತಾ-ನಿರ್ಣಾಯಕ ಮಾರ್ಗದರ್ಶನವನ್ನು ಒಳಗೊಂಡಿದ್ದರೆ, ಅಲ್ಲಿ ಹಳೆಯ ಸತ್ಯಗಳು ನೈಜ ಹಾನಿಯನ್ನು ಉಂಟುಮಾಡಬಹುದು.

5. ಡೂಪ್ಲಿಕೇಟ್ ಮಾಲಿನ್ಯ (Duplicate Pollution)

ವೆಬ್‌ಸೈಟ್‌ಗಳು ಪುನರಾವರ್ತನೆಗಳಿಂದ ತುಂಬಿರುತ್ತವೆ. ಅದೇ ಉತ್ಪನ್ನದ ವಿವರಣೆಯು ವರ್ಗದ ಪುಟ (category page), ಉತ್ಪನ್ನದ ಪುಟ ಮತ್ತು ಪ್ರಚಾರದ ಲ್ಯಾಂಡಿಂಗ್ ಪುಟದಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅದೇ ಪ್ರೆಸ್ ರಿಲೀಸ್ /news/, /press/, ಮತ್ತು /blog/ ಅಡಿಯಲ್ಲಿ ಇರುತ್ತದೆ. ವೆಕ್ಟರ್ ಸರ್ಚ್ (Vector search) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡ್ಯೂಪ್ಲಿಕೇಟ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಹತ್ತಾರು ಅತೀ ಹೆಚ್ಚು ಹೋಲುವ ಚಂಕ್‌ಗಳು (chunks) ಇದ್ದರೆ, ಅವು ನಿಮ್ಮ top-k ರಿಟ್ರಿೀವಲ್‌ನಲ್ಲಿ ವೈವಿಧ್ಯಮಯ ಮತ್ತು ಪ್ರಸ್ತುತ ಫಲಿತಾಂಶಗಳನ್ನು ತಡೆಯಬಹುದು. ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡುವ ಮೊದಲು ನಿಮಗೆ ಕ್ಯಾನೊನಿಕಲ್ ಟ್ರ್ಯಾಕಿಂಗ್ ಅಥವಾ ಕಂಟೆಂಟ್ ಡ್ಯೂಪ್ಲಿಕೇಶನ್ ಅಗತ್ಯವಿದೆ. ಎರಡು ಚಂಕ್‌ಗಳು ಒಂದೇ ವಿಷಯವನ್ನು ಹೇಳುತ್ತಿದ್ದರೆ, ಅಧಿಕೃತ ಮೂಲವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ ಮತ್ತು ನಕಲುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಿ. ನಿಮ್ಮ ರಿಟ್ರೀವರ್‌ಗೆ ಸೀಮಿತ ಸ್ಲಾಟ್‌ಗಳಿವೆ. ಅವು ವ್ಯರ್ಥವಾಗಲು ಬಿಡಬೇಡಿ.

6. ಕಣ್ಮರೆಯಾದ ಮೆಟಾಡೇಟಾ (Missing Metadata)

ಮೆಟಾಡೇಟಾ ಇಲ್ಲದ ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್ ಎಂಬುದು ಸಂದರ್ಭದ ನೆನಪಿಲ್ಲದ ಕೇವಲ ಒಂದು ದಟ್ಟವಾದ ಪಠ್ಯ ಹುಡುಕಾಟದ ಇಂಜಿನ್ (text search engine) ಇದ್ದಂತೆ. ಸ್ಮಾರ್ಟ್ ರಿಟ್ರಿೀವಲ್ ಎಂಬುದು ಕೇವಲ ರ‌）」 ಎಂಬೆಡ್ಡಿಂಗ್‌ಗಳು ನೀಡಲಾಗದ ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ರ್ಯಾಂಕಿಂಗ್ ಸಿಗ್ನಲ್‌ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಮೂಲ URL, ಸೆರೆಹಿಡಿದ ದಿನಾಂಕ, ದಾಖಲೆಯ ವರ್ಗ ಮತ್ತು ಆವೃತ್ತಿ ಸಂಖ್ಯೆಯನ್ನು ಸಂಗ್ರಹಿಸಿ. ನೀವು API ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಅನ್ನು ಇಂಜೆಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ವರ್ಷನಿಂಗ್ (versioning) ಅತ್ಯಗತ್ಯ. ಇಲ್ಲದಿದ್ದರೆ, ಒಂದು ಕ್ವೆರಿಯು v1 ಮತ್ತು v2 ಸ್ಪೆಸಿಫಿಕೇಶನ್‌ಗಳನ್ನು ಒಂದೇ ಉತ್ತರದಲ್ಲಿ ಬೆರೆಸಿಬಿಡಬಹುದು. ನೀವು HR ನೀತಿಗಳನ್ನು ಇಂಜೆಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ಪ್ರದೇಶ ಅಥವಾ ಇಲಾಖೆಯ ಮೂಲಕ ಟ್ಯಾಗ್ ಮಾಡುವುದು ಮಾಡೆಲ್‌ಗೆ ತಲುಪುವ ಮೊದಲೇ ಫಲಿತಾಂಶಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಮೆಟಾಡೇಟಾ ಪಠ್ಯದ ರಾಶಿಯನ್ನು (text dump) ಒಂದು ಸುಸಜ್ಜಿತ ಜ್ಞಾನ ವ್ಯವಸ್ಥೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.

7. ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅಂತರಗಳು (JavaScript Gaps)

ಆಧುನಿಕ ಸೈಟ್‌ಗಳು ತಮ್ಮ ಪಠ್ಯವನ್ನು ಮೊದಲ HTML ಪೇಲೋಡ್‌ನಲ್ಲಿ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಅವು ಒಂದು ಸ್ಕೆಲೆಟನ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತವೆ ಮತ್ತು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕರೆಗಳ ಮೂಲಕ ಅದನ್ನು ಹೈಡ್ರೇಟ್ (hydrate) ಮಾಡುತ್ತವೆ. ಒಂದು ಸಾಮಾನ್ಯ HTTP ವಿನಂತಿಯು ಲೋಡಿಂಗ್ ಸ್ಪಿನರ್ ಮತ್ತು ಲೇಔಟ್ ಶೆಲ್ ಹೊರತುಪಡಿಸಿ ಏನನ್ನೂ ತೋರಿಸದಿರಬಹುದು. ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಖಾಲಿ ಪುಟಗಳನ್ನು ಅಥವಾ ಭಾಗಶಃ ಫ್ರಾಗ್ಮೆಂಟ್‌ಗಳನ್ನು ಇಂಜೆಸ್ಟ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಏನೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ನಿಮಗೆ ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ. ಹೆಡ್‌ಲೆಸ್ ಬ್ರೌಸರ್ ಬಳಸುವುದು ರೆಂಡರಿಂಗ್ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಆದರೆ ಹೊಸ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ: ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಬಳಕೆ, ನಿಧಾನವಾದ ಥ್ರೂಪುಟ್ ಮತ್ತು ಬಾಟ್ ಡಿಟೆಕ್ಷನ್ ಗೋಡೆಗಳು. ನಿಮ್ಮ ವಹಿವಾಟುಗಳನ್ನು (trade-offs) ಎಚ್ಚರಿಕೆಯಿಂದ ಆರಿಸಿ, ಆದರೆ ಪ್ರತಿ ಮೂಲಕ್ಕೂ ಕೇವಲ curl ಸಮಾನವಾದವು ಸಾಕಾಗುತ್ತದೆ ಎಂದು ನಂಬಬೇಡಿ.

ಒಂದು ಪ್ರಾಯೋಗಿಕ ಇಂಜೆಶ್ಚನ್ ಚೆಕ್‌ಲಿಸ್ಟ್ (A Practical Ingestion Checklist)

ನೀವು RAG ಫೀಡ್ ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ ಅಥವಾ ಪರಿಶೀಲಿಸುತ್ತಿದ್ದರೆ, ಇಲ್ಲಿಂದ ಪ್ರಾರಂಭಿಸಿ:

  • ಮೂಲದ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಪೇಜಿನೇಶನ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ. ಒಂದು ಸೈಟ್‌ಮ್ಯಾಪ್ ಒಂದು ವರ್ಗದಲ್ಲಿನ ಮೊದಲ ಹತ್ತು ಲೇಖನಗಳನ್ನು ಮಾತ್ರ ಪಟ್ಟಿ ಮಾಡಬಹುದು. ಆಳವಾಗಿ ಕ್ರಾಲ್ ಮಾಡಿ ಮತ್ತು ಪೇಜಿನೇಟೆಡ್ ಅಥವಾ ಡೈನಾಮಿಕ್ ಆಗಿ ಲೋಡ್ ಆಗುವ ಕಂಟೆಂಟ್ ಅನ್ನು ನಿಜವಾಗಿಯೂ ಸೆರೆಹಿಡಿಯಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
  • ಚಂಕಿಂಗ್ ಮಾಡುವ ಮೊದಲು ಬಾಯ್ಲರ್ ಪ್ಲೇಟ್ (boilerplate) ಅನ್ನು ತೆಗೆದುಹಾಕಿ. ನ್ಯಾವಿಗೇಷನ್, ಜಾಹೀರಾತುಗಳು, ಫುಟರ್‌ಗಳು ಮತ್ತು ಪುನರಾವರ್ತಿತ ಕಾನೂನು ಡಿಸ್‌ಕ್ಲೈಮರ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ. ಒಂದು ಪದ ಅಥವಾ ವಾಕ್ಯವು ಪ್ರತಿಯೊಂದು ಪುಟದಲ್ಲೂ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದರೆ, ಅದು ಶಬ್ದ (noise) ಅಷ್ಟೇ.
  • ರಚನೆ-ಅರಿವಿರುವ ಚಂಕಿಂಗ್ ಬಳಸಿ (Structure-aware chunking). ಹೆಡಿಂಗ್‌ಗಳು, ಬುಲೆಟ್ ಲಿಸ್ಟ್‌ಗಳು ಮತ್ತು ಟೇಬಲ್‌ಗಳನ್ನು ಗೌರವಿಸಿ. ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆಯ ಬದಲಿಗೆ ಅರ್ಥಪೂರ್ಣ ಮಿತಿಗಳ (semantic boundaries) ಆಧಾರದ ಮೇಲೆ ವಿಭಜಿಸಿ.
  • ಸಮೃದ್ಧ ಮೆಟಾಡೇಟಾವನ್ನು ಲಗತ್ತಿಸಿ. URL, ಸೆರೆಹಿಡಿದ ದಿನಾಂಕ, ಕಂಟೆಂಟ್ ವರ್ಗ ಮತ್ತು ಆವೃತ್ತಿಯನ್ನು ಸೇರಿಸಿ. ನಿಮ್ಮ ರಿಟ್ರಿೀವಲ್ ಕ್ವೆರಿಗಳಲ್ಲಿ ಈ ಕ್ಷೇತ್ರಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವಂತಾಗಲಿ.
  • **ದತ್ತಾಂಶದ ಅಸ್ಥಿರತೆಯ ಆಧಾರದ ಮೇಲೆ ರಿಫ್ರೆಶ್ ಫ್ರೀಕ್ವೆನ್ಸಿಗಳನ್ನು ನಿ

ಕೇವಲ ಪೈಪ್‌ಲೈನ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳ ಮೂಲಕವೇ ಇನ್ಜೆಕ್ಷನ್ ಆರೋಗ್ಯವನ್ನು ಅಳೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಯಶಸ್ವಿ ಕೆಲಸಗಳು ಮತ್ತು ಸ್ವಚ್ಛವಾದ ಲಾಗ್‌ಗಳು ಒಂದು ಸ್ವಚ್ಛವಾದ ಕಾರ್ಪಸ್ ಅನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ. ಡೇಟಾಬೇಸ್ ತೆರೆಯಿರಿ ಮತ್ತು ನಿಮ್ಮ ಬಳಕೆದಾರರು ಪಡೆಯುವ ನಿಜವಾದ ಚಂಕ್‌ಗಳನ್ನು ಓದಿ. ಒಂದು ವೇಳೆ ಪಠ್ಯವು ಕಾಪಿರೈಟ್ ಸೂಚನೆಗಳು, ವಿಭಜಿತವಾದ ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಹಳೆಯದಾದ ನೀತಿ ಪುಟಗಳಿಂದ ತುಂಬಿದ್ದರೆ, ನಿಮ್ಮ ಸಮಸ್ಯೆ LLM ಅಲ್ಲ. ಮೊದಲು ಫೀಡ್ ಅನ್ನು ಸರಿಪಡಿಸಿ. ಉಳಿದೆಲ್ಲವೂ ಕಸದ ಮೇಲೆ ಮಾಡುವ ಟ್ಯೂನಿಂಗ್ ಇದ್ದಂತೆ.