ಕಂಪನಿ ಡೇಟಾದೊಂದಿಗೆ ಮಾತನಾಡುವ ಸಹಾಯಕ ಆರ್ಕಿಟೆಕ್ಚರ್

ಲಾಭಗಳು:

• ಎಂಡ್-ಟು-ಎಂಡ್ ಎಂಟರ್‌ಪ್ರೈಸ್ ಆರ್‌ಎಜಿ ಅಸಿಸ್ಟೆಂಟ್‌ನ ಘಟಕಗಳು ಮತ್ತು ಡೇಟಾ ಹರಿವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು
• ಬಹು-ಮೂಲ ಡೇಟಾವನ್ನು (ವಿಕಿ, ಟಿಕೆಟ್, PDF, ಡೇಟಾಬೇಸ್) ಒಂದೇ ಸಹಾಯಕಕ್ಕೆ ಸಂಯೋಜಿಸುವುದು
• ಸ್ಕೇಲೆಬಿಲಿಟಿ, ಕ್ಯಾಶಿಂಗ್ ಮತ್ತು ಲೇಟೆನ್ಸಿಗಾಗಿ ವಾಸ್ತುಶಿಲ್ಪದ ನಿರ್ಧಾರಗಳನ್ನು ಮಾಡಿ

ಹಿಂದಿನ ಘಟಕಗಳಲ್ಲಿ, ನಾವು ಭಾಗಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಕಲಿತಿದ್ದೇವೆ: ಎಂಬೆಡಿಂಗ್, ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್, ಚಂಕಿಂಗ್, ಮರುಪಡೆಯುವಿಕೆ. ಈಗ ನಾವು ಇವುಗಳನ್ನು ಸಂಯೋಜಿಸೋಣ ಮತ್ತು ನಿಮ್ಮ ಸ್ವಂತ ಕಂಪನಿಯ ಡೇಟಾದೊಂದಿಗೆ ಮಾತನಾಡುವ ಸಹಾಯಕನ ಅಂತ್ಯದಿಂದ ಅಂತ್ಯದ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ನಿರ್ಮಿಸೋಣ. ಉದ್ಯೋಗಿಯು "ನಮ್ಮ ರಜೆ ನೀತಿ ಏನು?" ಎಂದು ಕೇಳುವುದು ಗುರಿಯಾಗಿದೆ. ಜನರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಬಹುದಾದ ವ್ಯವಸ್ಥೆ, ಉತ್ತರಗಳು ನಿಜವಾದ ಆಂತರಿಕ ದಾಖಲೆಗಳು, ಉಲ್ಲೇಖಗಳು ಮತ್ತು ಬಹು ಡೇಟಾ ಮೂಲಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತವೆ. ಈ ಘಟಕವು ಸಂಪೂರ್ಣ ಆರ್ಕಿಟೆಕ್ಚರ್, ಡೇಟಾ ಹರಿವು ಮತ್ತು ಉತ್ಪಾದನಾ ಮಟ್ಟದ ನಿರ್ಧಾರಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.

ಎಂಡ್-ಟು-ಎಂಡ್ ಘಟಕಗಳು

ಕಾರ್ಪೊರೇಟ್ RAG ಸಹಾಯಕ ಎರಡು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಇಂಡೆಕ್ಸಿಂಗ್ ಲೈನ್ (ಆಫ್‌ಲೈನ್) ಡೇಟಾವನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತದೆ; ಪ್ರಶ್ನೆ ಸಾಲು (ಆನ್‌ಲೈನ್) ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಇಂಡೆಕ್ಸಿಂಗ್ ಲೈನ್ ಘಟಕಗಳು:

1. ಕನೆಕ್ಟರ್‌ಗಳು: ಮೂಲಗಳಿಂದ ಡೇಟಾವನ್ನು ಎಳೆಯುವ ಕನೆಕ್ಟರ್‌ಗಳು - ವಿಕಿ, ಟಿಕೆಟ್ ವ್ಯವಸ್ಥೆ, ಫೈಲ್ ಸ್ಟೋರ್, ಡೇಟಾಬೇಸ್, ಇಮೇಲ್.
2. ಸಾಮಾನ್ಯೀಕರಣ: ಪಠ್ಯವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಲು ವಿವಿಧ ಸ್ವರೂಪಗಳನ್ನು (PDF, HTML, DOCX) ಪರಿವರ್ತಿಸುವುದು; ಹೆಡರ್ / ಅಡಿಟಿಪ್ಪಣಿ ಸ್ವಚ್ಛಗೊಳಿಸುವಿಕೆ.
3. ಚಂಕಿಂಗ್ + ಮೆಟಾಡೇಟಾ: ಚಂಕಿಂಗ್ ಮತ್ತು ಟ್ಯಾಗಿಂಗ್ (ಮೂಲ, ದಿನಾಂಕ, ಅಧಿಕಾರ).
4. ಎಂಬೆಡಿಂಗ್ + ಲೋಡಿಂಗ್: ವೆಕ್ಟರ್ ಡೇಟಾಬೇಸ್‌ಗೆ ವೆಕ್ಟರ್‌ಗಳು ಮತ್ತು ಮೆಟಾಡೇಟಾವನ್ನು ಬರೆಯುವುದು.

ಪ್ರಶ್ನೆ ಪೈಪ್ಲೈನ್ ಘಟಕಗಳು:

1. ಪ್ರಶ್ನೆ ಪೂರ್ವ ಸಂಸ್ಕರಣೆ: ಪುನಃ ಬರೆಯುವುದು, ವಿಕೇಂದ್ರೀಕರಣ.
2. ಮರುಪಡೆಯುವಿಕೆ: ಹೈಬ್ರಿಡ್ ಹುಡುಕಾಟ + ಮೆಟಾಡೇಟಾ ಫಿಲ್ಟರ್ + ಮರು-ಶ್ರೇಯಾಂಕ.
3. ಪ್ರಾಂಪ್ಟ್ ರಚನೆ: ಟೆಂಪ್ಲೇಟ್‌ನಲ್ಲಿ ಸಂದರ್ಭ + ಪ್ರಶ್ನೆ + ಸೂಚನೆಗಳನ್ನು ಇರಿಸುವುದು.
4. ಜನರೇಷನ್: ಮಾದರಿ + ಮೂಲಗಳಿಂದ ಆಧಾರವಾಗಿರುವ (ಸಂದರ್ಭೋಚಿತ) ಉತ್ತರ.
5. ಪೋಸ್ಟ್-ಪ್ರೊಸೆಸಿಂಗ್: ಉಲ್ಲೇಖದ ಫಾರ್ಮ್ಯಾಟಿಂಗ್, ಭದ್ರತಾ ಪರಿಶೀಲನೆ, ಲಾಗಿಂಗ್.

ಸಲಹೆ: ಪ್ರಶ್ನೆ ಸಾಲಿನಿಂದ ಇಂಡೆಕ್ಸಿಂಗ್ ಲೈನ್ ಅನ್ನು ಭೌತಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿ. ಇಂಡೆಕ್ಸಿಂಗ್ ನಿಧಾನ ಮತ್ತು ಆವರ್ತಕವಾಗಿದೆ (ರಾತ್ರಿಯ ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆ); ವಿಚಾರಣೆಯ ಸಾಲು ಹಗುರವಾಗಿರಬೇಕು ಮತ್ತು ತಕ್ಷಣವೇ ಇರಬೇಕು. ಬಳಕೆದಾರರು ಕಾಯುತ್ತಿರುವಾಗ ಎರಡು ಸಾಲುಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದು ಭಾರೀ ಪ್ರಕ್ರಿಯೆಗೆ ಒತ್ತಾಯಿಸುತ್ತದೆ.

ಡೇಟಾ ಹರಿವನ್ನು ದೃಶ್ಯೀಕರಿಸುವುದು

[ಇಂಡೆಕ್ಸಿಂಗ್ - ಆಫ್‌ಲೈನ್]ಸಂಪನ್ಮೂಲಗಳು → ಸಾಧಾರಣಗೊಳಿಸಿ → ಚಂಕ್+ಮೆಟಾಡೇಟಾ → ಎಂಬೆಡ್ → ವೆಕ್ಟರ್ ಡಿಬಿ (ವಿಕಿ, ಟಿಕೆಟ್, ಪಿಡಿಎಫ್, ಡಿಬಿ)[QUERY - ಆನ್‌ಲೈನ್]ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆ → ಪೂರ್ವ-ಪ್ರಕ್ರಿಯೆ → ಹಿಂಪಡೆಯುವಿಕೆ (ಹೈಬ್ರಿಡ್+ಫಿಲ್ಟರ್+ಮರುಪಡೆಯುವಿಕೆ) (ಸಂದರ್ಭ+ಪ್ರಶ್ನೆ+ಸೂಚನೆ) → ಮಾದರಿ → ಉತ್ತರ+ಮೂಲ → ಬಳಕೆದಾರ

ಬಹು-ಮೂಲ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸುವುದು

ನಿಜವಾದ ಕಂಪನಿಗಳಲ್ಲಿ, ಉತ್ತರವು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ನಿಲ್ಲುವುದಿಲ್ಲ. "ಗ್ರಾಹಕರಿಗೆ ಮರುಪಾವತಿಯನ್ನು ಹೇಗೆ ನೀಡುವುದು?" ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವನ್ನು ಸಹಾಯ ಲೇಖನದಲ್ಲಿ (ಕಾರ್ಯವಿಧಾನ), ಟಿಕೆಟ್ ಇತಿಹಾಸದಲ್ಲಿ (ನೈಜ ಉದಾಹರಣೆಗಳು) ಮತ್ತು ನೀತಿ PDF (ನಿಯಮಗಳು) ಎರಡರಲ್ಲೂ ಕಾಣಬಹುದು. ಸಹಾಯಕರು ಅವರೆಲ್ಲರನ್ನೂ ಒಂದೇ ಕೊಳದಲ್ಲಿ ಹುಡುಕಬೇಕು.

ನಿರ್ಣಾಯಕ ಅಂಶ: ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಂದೇ ವೆಕ್ಟರ್ ಸ್ಟೋರ್‌ಗೆ ಸಂಯೋಜಿಸುವಾಗ, ಪ್ರತಿ ಚೂರು `ಸೋರ್ಸ್_ಟೂರ್` ಮೆಟಾಡೇಟಾವನ್ನು ಒಯ್ಯಬೇಕು. ಆದ್ದರಿಂದ ನೀವು ಅವೆಲ್ಲವನ್ನೂ ಹುಡುಕಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅವುಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ "ಅಧಿಕೃತ ನೀತಿಗಳನ್ನು ಮಾತ್ರ ತರಲು". ಅಲ್ಲದೆ, ವಿಭಿನ್ನ ಮೂಲಗಳು ವಿಭಿನ್ನ ಮಟ್ಟದ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಹೊಂದಿವೆ: ಅಧಿಕೃತ ನೀತಿ > ಸಹಾಯ ಲೇಖನ > ಉದ್ಯೋಗಿಯ ಟಿಕೆಟ್ ಟಿಪ್ಪಣಿ. ನೀವು ಈ ಆದ್ಯತೆಯನ್ನು ಮರು-ಶ್ರೇಯಾಂಕ ಅಥವಾ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.

ಮೂಲ

ವಿಷಯ ಪ್ರಕಾರ

ನಂಬಿಕೆ

ಆವರ್ತನವನ್ನು ನವೀಕರಿಸಿ

ನೀತಿ PDF

ಅಧಿಕೃತ ನಿಯಮ

ಹೆಚ್ಚು

ಮಾಸಿಕ

ಸಹಾಯ ಲೇಖನ

ಕಾರ್ಯವಿಧಾನ

ಮಧ್ಯಮ-ಎತ್ತರದ

ವಾರಕ್ಕೊಮ್ಮೆ

ಟಿಕೆಟ್ ಇತಿಹಾಸ

ನಿಜವಾದ ಮಾದರಿ

ಮಧ್ಯಮ

ನಿರಂತರ

ವಿಕಿ

ಮಿಶ್ರ/ಪ್ರಸ್ತುತ ಟಿಪ್ಪಣಿ

ವೇರಿಯಬಲ್

ನಿರಂತರ

ಸ್ಕೇಲೆಬಿಲಿಟಿ, ಕ್ಯಾಶ್ ಮತ್ತು ಲೇಟೆನ್ಸಿ

ಉತ್ಪಾದನೆಯಲ್ಲಿ ಮೂರು ಸಮಸ್ಯೆಗಳು ಎದ್ದು ಕಾಣುತ್ತವೆ. ಸುಪ್ತತೆ: ಬಳಕೆದಾರರು 2 ಸೆಕೆಂಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಯುವಾಗ ಅನುಭವವು ಹದಗೆಡುತ್ತದೆ. ಪರಿಹಾರ: ಉತ್ತರವನ್ನು ಸ್ಟ್ರೀಮಿಂಗ್ ರೂಪದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಿ - ಮಾದರಿ ಬರೆಯುವಂತೆ ಅದನ್ನು ಪರದೆಯ ಮೇಲೆ ಸುರಿಯಲಾಗುತ್ತದೆ. ಸಂಗ್ರಹ: ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಪುನರಾವರ್ತಿತ ಸಂದರ್ಭಗಳಿಗಾಗಿ, ಸಂಗ್ರಹವು ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಸ್ಕೇಲ್: ಬಳಕೆದಾರ ಹೆಚ್ಚಾದಂತೆ, ಮರುಪಡೆಯುವಿಕೆ ಮತ್ತು ಮಾದರಿ ಕರೆಗಳನ್ನು ಅಡ್ಡಲಾಗಿ ಅಳೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ವೆಚ್ಚದ ಬದಿಯಲ್ಲಿ ಹೆಬ್ಬೆರಳಿನ ನಿಯಮ: ಅತ್ಯಂತ ದುಬಾರಿ ಹಂತವು ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಮಾದರಿಗೆ ಹೋಗುವ ಟೋಕನ್ಗಳ ಸಂಖ್ಯೆಯಾಗಿದೆ. ಆದ್ದರಿಂದ, ಮರು-ಶ್ರೇಣಿಯ ಮೂಲಕ ಸಂದರ್ಭವನ್ನು 4 ಉತ್ತಮ ಭಾಗಗಳಿಗೆ ಕಡಿಮೆ ಮಾಡುವುದು ಗುಣಮಟ್ಟ ಮತ್ತು ವೆಚ್ಚ ಎರಡನ್ನೂ ಸುಧಾರಿಸುತ್ತದೆ. ಸರಳವಾದ ವರ್ಗೀಕರಣ ಅಥವಾ ರೂಟಿಂಗ್‌ಗಾಗಿ ಸಣ್ಣ/ವೇಗದ ಮಾದರಿಯನ್ನು ಬಳಸುವುದು ಸಾಮಾನ್ಯ ವಿನ್ಯಾಸವಾಗಿದೆ ಮತ್ತು ಅಂತಿಮ ಉತ್ತರಕ್ಕಾಗಿ ಹೆಚ್ಚು ಶಕ್ತಿಶಾಲಿ ಮಾದರಿಯನ್ನು ಬಳಸುವುದು (ಉದಾ. claude-opus-4-8).

ಎಚ್ಚರಿಕೆ: "ಒಮ್ಮೆ ಮಾಡಿ, ಮರೆತುಬಿಡಿ" ಎಂದು ಸೂಚಿಕೆಯನ್ನು ಹೊಂದಿಸಬೇಡಿ. ದಾಖಲೆಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ, ಅಳಿಸಲಾಗಿದೆ, ಸೇರಿಸಲಾಗಿದೆ. ಮರು-ಸೂಚ್ಯಂಕ ತಂತ್ರವನ್ನು ಸ್ಥಾಪಿಸಿ: ಬದಲಾದ ದಾಖಲೆಗಳನ್ನು ಪತ್ತೆ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಮಾತ್ರ ಮರುಸಂಸ್ಕರಿಸಿ. ಹಳೆಯ ಸೂಚ್ಯಂಕವು ಪ್ರಸ್ತುತವಾಗಿ ಕಂಡುಬರುವ ಉತ್ತರವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಆದರೆ ತಪ್ಪಾಗಿದೆ.

ದುರ್ಬಲ ವಾಸ್ತುಶಿಲ್ಪ / ಬಲವಾದ ವಾಸ್ತುಶಿಲ್ಪ

ದುರ್ಬಲ (ಏಕ ಸ್ಕ್ರಿಪ್ಟ್, ಎಲ್ಲವೂ ಮಿಶ್ರಣ):

ಬಳಕೆದಾರರು ಕೇಳಿದಾಗ: ಆ ಕ್ಷಣದಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಓದಿ, ಅವುಗಳನ್ನು ಚೂರುಚೂರು ಮಾಡಿ, ಅವುಗಳನ್ನು ಎಂಬೆಡ್ ಮಾಡಿ, ಅವುಗಳನ್ನು ಹುಡುಕಿ, ಉತ್ತರಿಸಿ. # ಸಮಸ್ಯೆ: ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಎಲ್ಲಾ ಸೂಚಿಕೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ; ಸೆಕೆಂಡುಗಳ ವಿಳಂಬ, # ಮೂಲ ಬೇರ್ಪಡಿಕೆ ಇಲ್ಲ, ಫಿಲ್ಟರ್ ಇಲ್ಲ, ರಿಫ್ರೆಶ್ ಇಲ್ಲ.

ಶಕ್ತಿಯುತ (ಸ್ಪ್ಲಿಟ್ ಪೈಪ್‌ಗಳು + ಮೆಟಾಡೇಟಾ + ಸಂಗ್ರಹ + ಸ್ಟ್ರೀಮಿಂಗ್):

ಇಂಡೆಕ್ಸಿಂಗ್: ಬ್ಯಾಚ್ ರಾತ್ರಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ, ಬದಲಾದ ದಾಖಲೆಗಳನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡುತ್ತದೆ. ಪ್ರಶ್ನೆ: ಹಗುರವಾದ ಸಾಲು — ಪೂರ್ವ-ಸಂಸ್ಕರಣೆ → ಹೈಬ್ರಿಡ್ ಮರುಪಡೆಯುವಿಕೆ+ಫಿಲ್ಟರ್ → ರೀರ್ಯಾಂಕ್ → ಪ್ರಾಂಪ್ಟ್ → ಮಾದರಿ (ಸ್ಟ್ರೀಮಿಂಗ್) → ಉಲ್ಲೇಖ → ಲಾಗ್. ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ಮೂಲವನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ಗೊಂದಲದ ಸಾಲು, ಭಾರೀ ವಿಳಂಬ. ಪ್ರತಿ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ PDF ಗಳನ್ನು ಮರುಸಂಸ್ಕರಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸ್ಟಾರ್ಟ್ಅಪ್ ಬರೆದಿದೆ; ಪ್ರತಿ ಉತ್ತರವು ಸರಾಸರಿ 11 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಇಂಡೆಕ್ಸಿಂಗ್ ಲೈನ್ ಅನ್ನು ಬೇರ್ಪಡಿಸಿದಾಗ ಮತ್ತು ಡೇಟಾವನ್ನು ಹಿಂದೆ ವೆಕ್ಟರ್ ಸ್ಟೋರ್‌ಗೆ ವರ್ಗಾಯಿಸಿದಾಗ, ಪ್ರಶ್ನೆಯ ಸಮಯವು 1.3 ಸೆಕೆಂಡುಗಳಿಗೆ ಕಡಿಮೆಯಾಯಿತು ಮತ್ತು ಸ್ಟ್ರೀಮಿಂಗ್‌ನೊಂದಿಗೆ, "ಮೊದಲ ಪದ" 400 ms ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿತು.

ಪ್ರಕರಣ 2 - ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳು, ತಪ್ಪು ಆದ್ಯತೆ. ಬೆಂಬಲ ಸಹಾಯಕರು ನೀತಿ PDF ಮತ್ತು ಹಳೆಯ ಟಿಕೆಟ್ ಟಿಪ್ಪಣಿಗಳಿಗೆ ಸಮಾನ ತೂಕವನ್ನು ನೀಡಿದರು; ಮಾದರಿಯು ಕೆಲವೊಮ್ಮೆ ಅಧಿಕೃತ ನಿಯಮವಾಗಿ ಎರಡು ವರ್ಷಗಳ ಹಿಂದಿನ ಉದ್ಯೋಗಿಯ ತಪ್ಪಾದ ರೇಟಿಂಗ್ ಅನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. source_tour ಮೆಟಾಡೇಟಾ ಮತ್ತು "ಘರ್ಷಣೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಅಧಿಕೃತ ನೀತಿಯನ್ನು ಪರಿಗಣಿಸಿ" ಸೂಚನೆಯನ್ನು ಪ್ರಾಂಪ್ಟ್‌ಗೆ ಸೇರಿಸಿದಾಗ, ತಪ್ಪು-ಆದ್ಯತೆಯ ದೋಷಗಳನ್ನು 89% ರಷ್ಟು ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ.

ಪ್ರಕರಣ 3 - ಹಳೆಯ ಸೂಚ್ಯಂಕ. HR ಸಹಾಯಕರು 3 ತಿಂಗಳವರೆಗೆ ಅಪ್‌ಡೇಟ್ ಮಾಡದ ಸೂಚ್ಯಂಕದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ; ರಜೆ ನೀತಿ ಬದಲಾಗಿದೆ, ಆದರೆ ಸಹಾಯಕರು ಹಳೆಯ ದಿನಗಳನ್ನು ಹೇಳುತ್ತಿದ್ದರು. ಬದಲಾದ ಫೈಲ್‌ಗಳನ್ನು ಪತ್ತೆ ಮಾಡುವ ದೈನಂದಿನ ರಿಫ್ರೆಶ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದಾಗ, ಪ್ರಸ್ತುತ-ಪ್ರತಿಕ್ರಿಯೆ ದರವು 70% ರಿಂದ 99% ಕ್ಕೆ ಏರಿತು.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• ಮಿಕ್ಸಿಂಗ್ ಇಂಡೆಕ್ಸಿಂಗ್ ಮತ್ತು ಕ್ವೆರಿ ಲೈನ್‌ಗಳು: ಬಳಕೆದಾರರು ಕಾಯುತ್ತಿರುವಾಗ ಭಾರೀ ಸಂಸ್ಕರಣೆ ಮಾಡಲಾಗುತ್ತದೆ; ವಿಳಂಬ ಸ್ಫೋಟಗೊಳ್ಳುತ್ತದೆ.
• ಮೆಟಾಡೇಟಾದಲ್ಲಿ ಮೂಲ ಪ್ರಕಾರವನ್ನು ಹಾಕುತ್ತಿಲ್ಲ: ಯಾವುದೇ ಆದ್ಯತೆ ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್ ಇಲ್ಲ; ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ಮೂಲವು ಅಧಿಕೃತವಾಗಿ ಕಂಡುಬರುತ್ತದೆ.
• ರಿಫ್ರೆಶ್ ತಂತ್ರವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ: ಸೂಚ್ಯಂಕವು ಹಳೆಯದಾಗುತ್ತದೆ; ಪ್ರಸ್ತುತವಾಗಿ ಕಂಡುಬರುವ ತಪ್ಪು ಉತ್ತರಗಳನ್ನು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ.
• ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡಿ: ಬಳಕೆದಾರರು ಖಾಲಿ ಪರದೆಯನ್ನು ನೋಡುತ್ತಾರೆ; ಗ್ರಹಿಸಿದ ವಿಳಂಬವು ಹೆಚ್ಚು ಆಗುತ್ತದೆ.
• ಪ್ರತಿ ಹಂತದಲ್ಲೂ ದೊಡ್ಡ ಮಾದರಿಯನ್ನು ಬಳಸುವುದು: ವೆಚ್ಚವು ಅನಗತ್ಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ; ಸ್ಟೀರಿಂಗ್ ಅನ್ನು ಚಿಕ್ಕ ಮಾದರಿಗೆ ಬಿಡಿ.

ಸಾರಾಂಶದಲ್ಲಿ

• ಕಾರ್ಪೊರೇಟ್ RAG ಸಹಾಯಕ ಎರಡು ಪ್ರತ್ಯೇಕ ಸಾಲುಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಆಫ್‌ಲೈನ್ ಇಂಡೆಕ್ಸಿಂಗ್ ಮತ್ತು ಆನ್‌ಲೈನ್ ಪ್ರಶ್ನೆ; ಅವುಗಳನ್ನು ಭೌತಿಕವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಿ.
• ಇಂಡೆಕ್ಸಿಂಗ್ = ಕನೆಕ್ಟರ್ + ಸಾಮಾನ್ಯೀಕರಣ + ಚಂಕ್/ಮೆಟಾಡೇಟಾ + ಎಂಬೆಡ್/ಅಪ್‌ಲೋಡ್; ಪ್ರಶ್ನೆ = ಪೂರ್ವ-ಪ್ರಕ್ರಿಯೆ + ಮರುಪಡೆಯುವಿಕೆ + ಪ್ರಾಂಪ್ಟ್ + ಜನರೇಟ್ + ನಂತರದ ಪ್ರಕ್ರಿಯೆ.
• ಬಹು-ಮೂಲ ಡೇಟಾವನ್ನು ಒಂದೇ ರೆಪೊಸಿಟರಿಯಾಗಿ ಸಂಯೋಜಿಸಲಾಗಿದೆ, ಆದರೆ source_type ಮೆಟಾಡೇಟಾ ಮತ್ತು ನಂಬಿಕೆಯ ಆದ್ಯತೆಯನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ.
• ಲೇಟೆನ್ಸಿಗಾಗಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ಕ್ಯಾಶ್, ಕಾಂಟೆಕ್ಸ್ಟ್ ಥ್ರೊಟ್ಲಿಂಗ್ ಮತ್ತು ವೆಚ್ಚಕ್ಕೆ ಮಾದರಿ ಆಯ್ಕೆಯು ನಿರ್ಣಾಯಕವಾಗಿದೆ.
• ಮರು-ಸೂಚ್ಯಂಕವಿಲ್ಲದೆ, ಸೂಚ್ಯಂಕವು ಹಳೆಯದಾಗುತ್ತದೆ; ಬದಲಾಯಿಸುವ ದಾಖಲೆಗಳನ್ನು ನಿಯಮಿತವಾಗಿ ಮರುಪ್ರಕ್ರಿಯೆ ಮಾಡಿ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ನಿಮ್ಮ ಸ್ವಂತ ತಂಡಕ್ಕಾಗಿ ಸಹಾಯಕನ ವಾಸ್ತುಶಿಲ್ಪದ ರೇಖಾಚಿತ್ರವನ್ನು ಬರೆಯಿರಿ. (1) ಕನಿಷ್ಠ ಮೂರು ನೈಜ ಡೇಟಾ ಮೂಲಗಳನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕನೆಕ್ಟರ್ ಅಗತ್ಯ, ಅಪ್‌ಡೇಟ್ ಆವರ್ತನ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಮಟ್ಟವನ್ನು ಬರೆಯಿರಿ. (2) ಬಾಕ್ಸ್-ಬಾಣ ರೇಖಾಚಿತ್ರದೊಂದಿಗೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಸೂಚ್ಯಂಕ ಮತ್ತು ಪ್ರಶ್ನೆ ಸಾಲುಗಳನ್ನು ಎಳೆಯಿರಿ. (3) "ಈ ಸಹಾಯಕದಲ್ಲಿ ನಾನು ಸುಪ್ತತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಎಲ್ಲಿ ಕಡಿಮೆ ಮಾಡಬಹುದು?" ಪ್ರಶ್ನೆಗೆ ಕನಿಷ್ಠ ಎರಡು ನಿರ್ದಿಷ್ಟ ನಿರ್ಧಾರಗಳನ್ನು ಬರೆಯಿರಿ. (4) ನಿಮ್ಮ ರಿಫ್ರೆಶ್ ಕಾರ್ಯತಂತ್ರವನ್ನು ಒಂದೇ ವಾಕ್ಯದಲ್ಲಿ ವಿವರಿಸಿ: ಯಾವ ಸಂಪನ್ಮೂಲವನ್ನು ಮರುಇಂಡೆಕ್ಸ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಬಾರಿ?

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು ಇಂಡೆಕ್ಸಿಂಗ್ ಮತ್ತು ಕ್ವೆರಿ ಲೈನ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮತ್ತು ಸರಿಯಾದ ಘಟಕಗಳೊಂದಿಗೆ ಸೆಳೆಯಬಲ್ಲೆ.
• [ ] ನಾನು source_type ಮತ್ತು ಟ್ರಸ್ಟ್ ಆದ್ಯತೆಯೊಂದಿಗೆ ಬಹು-ಮೂಲ ಡೇಟಾವನ್ನು ಸಂಯೋಜಿಸಬಹುದು.
• [ ] ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೆಚ್ಚಕ್ಕಾಗಿ ಮಾದರಿ ಆಯ್ಕೆಗಾಗಿ ನಾನು ಸ್ಟ್ರೀಮಿಂಗ್/ಕ್ಯಾಶ್ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು.
• [ ] ಮರು-ಸೂಚ್ಯಂಕ ತಂತ್ರವು ಏಕೆ ಅತ್ಯಗತ್ಯ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ.
• [ ] ನನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ದುಬಾರಿ ಹಂತವೆಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಮಾದರಿಗೆ ಹೋಗುವ ಟೋಕನ್ ಎಂದು ನಾನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುತ್ತೇನೆ.