ಹೆಚ್ಚಿನ ಕಂಪನಿ ಚಾಟ್‌ಬಾಟ್‌ಗಳು ಏಕೆ ಉತ್ತರಗಳನ್ನು ಕಲ್ಪಿಸುತ್ತವೆ — ಮೂಲಗಳನ್ನು ತೋರಿಸುವ ಒಂದನ್ನು ನಾವು ಹೇಗೆ ನಿರ್ಮಿಸಿದೆವು

ಪ್ರತಿ ಕಂಪನಿಗೂ ಒಂದೇ ಸಮಸ್ಯೆ. ಉತ್ತರಗಳು ಇವೆ — ಯಾವುದೋ ರಜೆ ನೀತಿಯಲ್ಲಿ, ವಾರಂಟಿ PDFನಲ್ಲಿ, 2023ರ ಯಾವುದೋ SOPಯಲ್ಲಿ — ಆದರೆ ಯಾರಿಗೂ ಸಿಗುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಜನರು ಸಹೋದ್ಯೋಗಿಯನ್ನು ಕೇಳುತ್ತಾರೆ, ಊಹಿಸುತ್ತಾರೆ ಅಥವಾ ಟಿಕೆಟ್ ತೆರೆಯುತ್ತಾರೆ. ಚಾಟ್‌ಬಾಟ್ ಸ್ಪಷ್ಟ ಪರಿಹಾರದಂತೆ ಕಾಣುತ್ತದೆ. ಹೆಚ್ಚಿನವು ಒಂದು ಕಾರಣಕ್ಕೆ ನಿರಾಸೆಗೊಳಿಸುತ್ತವೆ: ತಿಳಿಯದಿದ್ದಾಗಲೂ ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತವೆ, ಮತ್ತು ಉತ್ತರ ಎಲ್ಲಿಂದ ಬಂತು ಎಂದು ಯಾರೂ ಪರಿಶೀಲಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಪರ್ಯಾಯ ಹೇಗಿರುತ್ತದೆ ಎಂದು ತೋರಿಸಲು ನಾವು AIVCJ Knowledge ನಿರ್ಮಿಸಿದೆವು. ಇಂದೇ ತೆರೆಯಬಹುದಾದ ಲೈವ್ ಡೆಮೊ ಇದು: ಒಂದು ಮಾದರಿ ಗ್ರಂಥಾಲಯ ಆರಿಸಿ, ನಿಜವಾದ ಪ್ರಶ್ನೆ ಕೇಳಿ, ಮತ್ತು ಉತ್ತರದ ಪ್ರತಿ ವಾಕ್ಯವೂ ಅದು ಬಂದ ನಿಖರ ಭಾಗವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಸಮಸ್ಯೆ: ನಿರರ್ಗಳವಾಗಿ ಮಾತನಾಡುವುದು ಸರಿಯಾಗಿ ಮಾತನಾಡುವುದಲ್ಲ

ಒಂಟಿ ಭಾಷಾ ಮಾಡೆಲ್ ನೆನಪಿನಿಂದ ಉತ್ತರಿಸುತ್ತದೆ. ನಿಮ್ಮ ರಜೆ ಮುಂದುವರಿಕೆ ನಿಯಮದ ಬಗ್ಗೆ ಕೇಳಿದರೆ, ಸಾವಿರಾರು ಇತರ ಕಂಪನಿಗಳ ನೀತಿಗಳಿಂದ ನಂಬಲರ್ಹವಾದದ್ದನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಸರಳ ಹುಡುಕಾಟ (RAG) ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಸರಳ ಆವೃತ್ತಿಗಳು ಊಹಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ:

• ಹಲವು ಭಾಗಗಳ ಪ್ರಶ್ನೆಗಳು. “ಎರಡು ತಿಂಗಳ ಹಿಂದೆ Financeಗೆ ಸೇರಿದೆ — ವಾರಕ್ಕೆ ಎರಡು ದಿನ ಮನೆಯಿಂದ ಕೆಲಸ ಮಾಡಬಹುದೇ?” — ಇದಕ್ಕೆ ಹೈಬ್ರಿಡ್ ನೀತಿ ಮತ್ತು ಪ್ರೊಬೇಷನ್ ನಿಯಮ ಎರಡೂ ಬೇಕು. ಒಂದೇ ಹುಡುಕಾಟ ಎರಡನ್ನೂ ಅಪರೂಪವಾಗಿ ಕಂಡುಹಿಡಿಯುತ್ತದೆ.
• ಕೋಷ್ಟಕಗಳು ಮತ್ತು ಶೀರ್ಷಿಕೆಗಳು ಬೇರ್ಪಡುತ್ತವೆ. ದಾಖಲೆಯನ್ನು ಪ್ರತಿ 900 ಅಕ್ಷರಕ್ಕೆ ಕತ್ತರಿಸಿದರೆ, ಭತ್ಯೆ ಕೋಷ್ಟಕ ಅದು ಯಾವುದರ ಬಗ್ಗೆ ಎಂದು ಹೇಳುವ ಶೀರ್ಷಿಕೆಯಿಂದ ಬೇರ್ಪಡುತ್ತದೆ.
• ಪ್ರಾಮಾಣಿಕ “ಗೊತ್ತಿಲ್ಲ” ಇಲ್ಲ. ಸರಿಯಾದ ಭಾಗ ಸಿಗದಿದ್ದಾಗ ಮಾಡೆಲ್ ಖಾಲಿಯನ್ನು ತಾನೇ ತುಂಬುತ್ತದೆ.
• ಪರಿಶೀಲಿಸುವ ದಾರಿಯಿಲ್ಲ. ಉಲ್ಲೇಖಗಳಿಲ್ಲದೆ ತಪ್ಪು ಉತ್ತರ ಸರಿಯಾದ ಉತ್ತರದಂತೆಯೇ ಕಾಣುತ್ತದೆ.

AIVCJ Knowledge ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

1. ರಚನೆಯನ್ನು ಅರಿತ ಸೇರ್ಪಡೆ. ದಾಖಲೆಗಳು (PDF, DOCX, TXT) ಅವುಗಳದೇ ರಚನೆಯ ಪ್ರಕಾರ ವಿಭಜನೆಯಾಗುತ್ತವೆ: ಶೀರ್ಷಿಕೆಗಳು ತಮ್ಮ ವಿಷಯದೊಂದಿಗೆ ಇರುತ್ತವೆ, ಕೋಷ್ಟಕಗಳು ಸಂಪೂರ್ಣವಾಗಿರುತ್ತವೆ, ಪ್ರತಿ ಭಾಗವೂ ತನ್ನ ದಾಖಲೆ ಮತ್ತು ವಿಭಾಗವನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಆ ಸಂದರ್ಭ ಭಾಗದೊಂದಿಗೆ ಎಂಬೆಡ್ ಆಗುವುದರಿಂದ, ಕೋಷ್ಟಕದ ಒಂದು ಸಾಲಿಗೂ ತಾನು ಪ್ರಯಾಣ ನೀತಿಯ ಭತ್ಯೆ ವಿಭಾಗಕ್ಕೆ ಸೇರಿದ್ದು ಎಂದು “ಗೊತ್ತಿರುತ್ತದೆ”.
2. ಪ್ರಶ್ನೆ ಯೋಜನೆ. ಒಂದು ಚಿಕ್ಕ, ವೇಗದ ಮಾಡೆಲ್ ಪ್ರತಿ ಪ್ರಶ್ನೆಯನ್ನು ಅದಕ್ಕೆ ಬೇಕಾದ ಬೇರೆ ಬೇರೆ ಸಂಗತಿಗಳಾಗಿ ವಿಭಜಿಸುತ್ತದೆ — ನೌಕರರ ಗ್ರೇಡ್, ನಗರದ ಶ್ರೇಣಿ, ಭತ್ಯೆ ಕೋಷ್ಟಕ — ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಹುಡುಕಾಟವಾಗುತ್ತದೆ.
3. ಹೈಬ್ರಿಡ್ ಹುಡುಕಾಟ. ಪ್ರತಿ ಹುಡುಕಾಟ PostgreSQL ಒಳಗೆ ಎರಡು ರೀತಿಯಲ್ಲಿ ನಡೆಯುತ್ತದೆ: ಅರ್ಥದ ಮೂಲಕ (pgvector ಎಂಬೆಡಿಂಗ್) ಮತ್ತು ನಿಖರ ಪದಗಳ ಮೂಲಕ (ಪೂರ್ಣ-ಪಠ್ಯ ಹುಡುಕಾಟ). ಫಲಿತಾಂಶಗಳನ್ನು reciprocal-rank fusion ಮೂಲಕ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರಶ್ನೆಯ ಪ್ರತಿ ಭಾಗಕ್ಕೂ ಒಂದು ಸ್ಥಾನ ಖಾತರಿ.
4. ಮೂಲಗಳಿಂದ ಮಾತ್ರ ಉತ್ತರ. Claude ಹುಡುಕಿದ ಭಾಗಗಳಿಂದ ಮಾತ್ರ ಉತ್ತರ ಬರೆಯುತ್ತದೆ, ಪ್ರತಿ ಹೇಳಿಕೆಗೂ [1], [2]… ಎಂದು ಉಲ್ಲೇಖಿಸುತ್ತಾ. ದಾಖಲೆಗಳಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ.
5. ಆಧಾರ ಪರಿಶೀಲನೆ. ಎರಡನೇ ಹಂತ ಸಿದ್ಧ ಉತ್ತರವನ್ನು ಅದರ ಮೂಲಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ ಸಂಪೂರ್ಣ ಆಧಾರಿತ, ಭಾಗಶಃ ಆಧಾರಿತ ಅಥವಾ ದಾಖಲೆಗಳಲ್ಲಿಲ್ಲ ಎಂದು ಗುರುತಿಸುತ್ತದೆ — ಬಳಕೆದಾರರಿಗೆ ಕಾಣುತ್ತದೆ.

ಡೆಮೊದಲ್ಲಿ ನೀವು ನೋಡುವುದು

• ಕ್ಲಿಕ್ ಮಾಡಬಹುದಾದ ಉಲ್ಲೇಖಗಳು — ಮೂಲ ಪುಟ ತೆರೆದು ನಿಖರ ಭಾಗವನ್ನು ಹೈಲೈಟ್ ಮಾಡುತ್ತವೆ.
• “ಈ ಉತ್ತರ ಏಕೆ?” — ಹುಡುಕಿದ ಪ್ರತಿ ಭಾಗ ಅದರ ಅರ್ಥ, ಕೀವರ್ಡ್ ಮತ್ತು ಫ್ಯೂಷನ್ ಅಂಕಗಳೊಂದಿಗೆ; ಯಾವುವು ಉಲ್ಲೇಖಗೊಂಡವು, ಆಧಾರ ತೀರ್ಪು, ತೆಗೆದುಕೊಂಡ ಸಮಯ ಮತ್ತು ಬಳಸಿದ ಟೋಕನ್‌ಗಳು.
• ನಿಮ್ಮದೇ ದಾಖಲೆ. PDF ಅಥವಾ Word ಫೈಲ್ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ (ನಿಮಗೆ ಮಾತ್ರ, ಪ್ರತಿ ರಾತ್ರಿ ಅಳಿಸಲಾಗುತ್ತದೆ) ಮತ್ತು ಕೆಲವೇ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಅದರ ಬಗ್ಗೆ ಪ್ರಶ್ನೆ ಕೇಳಿ.
• ಒಂದು ಗುಣಮಟ್ಟ ಪುಟ — ಪ್ರಶ್ನೆ ಪ್ರಶ್ನೆಯಾಗಿ ಪೂರ್ಣ ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶಗಳೊಂದಿಗೆ.

ಊಹೆಯಲ್ಲ, ಅಳತೆ — ಮಿತಿಗಳ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕವಾಗಿ

ಪ್ರತಿ ಮಾದರಿ ಗ್ರಂಥಾಲಯಕ್ಕೂ ಎರಡು ಪರೀಕ್ಷಾ ಸೆಟ್‌ಗಳಿವೆ, ಮತ್ತು ಪ್ರತಿ ಉತ್ತರವನ್ನೂ ಮೂಲಗಳಿಗೆ ನಿಷ್ಠೆ ಮತ್ತು ಪ್ರಶ್ನೆಗೆ ಪ್ರಸ್ತುತತೆಯ ಮೇಲೆ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.

• ಗೋಲ್ಡನ್ ಸೆಟ್ (45 ಪ್ರಶ್ನೆಗಳು). ದಾಖಲೆಗಳ ಜೊತೆಗೇ ಬರೆದದ್ದು; ಹಲವು ದಾಖಲೆಗಳ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ದಾಖಲೆಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಉತ್ತರಿಸದ ಪ್ರಶ್ನೆಗಳೂ ಇವೆ. ಟ್ಯೂನಿಂಗ್‌ನಲ್ಲಿ ಇದನ್ನು ಬಳಸಿದೆವು, ಹಾಗಾಗಿ ಇದು ನಮ್ಮನ್ನು ಹೆಚ್ಚಾಗಿ ತೋರಿಸುತ್ತದೆ. ನಮ್ಮ ಮೊದಲ ಆವೃತ್ತಿ — ನಿಗದಿತ ಗಾತ್ರದ ತುಂಡುಗಳು ಮತ್ತು ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಒಂದು ಹುಡುಕಾಟ — 45ರಲ್ಲಿ 40, 91–93% ನಿಷ್ಠೆ; ಎಲ್ಲ ತಪ್ಪುಗಳೂ ಹಲವು ಭಾಗಗಳ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ. ರಚನೆ ಆಧಾರಿತ ತುಂಡುಗಳು, ಸಂದರ್ಭ ಎಂಬೆಡಿಂಗ್ ಮತ್ತು ಪ್ರಶ್ನೆ ಯೋಜನೆ ಅದನ್ನು ರನ್‌ಗಳಲ್ಲಿ 45ರಲ್ಲಿ 42–45, 98–100% ನಿಷ್ಠೆಗೆ ಏರಿಸಿದವು.
• ಬ್ಲೈಂಡ್ ಸೆಟ್ (20 ಪ್ರಶ್ನೆಗಳು). ನಂತರ ಇನ್ನೊಬ್ಬ ಲೇಖಕರು ಜನರು ನಿಜವಾಗಿ ಟೈಪ್ ಮಾಡುವಂತೆ ಬರೆದದ್ದು — ಹಿಂಗ್ಲಿಷ್, ಅಕ್ಷರ ತಪ್ಪುಗಳು, ಅಸ್ಪಷ್ಟ ಪದಗಳು, ಎರಡು ದಾಖಲೆಗಳು ಬೇಕಾದ ಪ್ರಶ್ನೆಗಳು — ಟ್ಯೂನಿಂಗ್‌ಗೆ ಎಂದೂ ಬಳಸಿಲ್ಲ: ರನ್‌ಗಳಲ್ಲಿ 20ರಲ್ಲಿ 19–20, 95–96% ನಿಷ್ಠೆ. ಒಂದು ರನ್‌ನ ತಪ್ಪು ಕಲಿಯುವಂಥದ್ದು: ಕಂಪನಿಯ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅನ್ನು ಕ್ಯಾಬ್‌ನಲ್ಲಿ ಮರೆತರೆ ಏನು ಮಾಡಬೇಕು ಎಂದು (ಹಿಂಗ್ಲಿಷ್‌ನಲ್ಲಿ) ಕೇಳಿದಾಗ, 24×7 IT Security ಲೈನ್ ಬದಲು ಸಾಮಾನ್ಯ IT ಹೆಲ್ಪ್‌ಡೆಸ್ಕ್ ಹೇಳಿತು ಮತ್ತು ಪೊಲೀಸ್ ದೂರು ಹಂತವನ್ನು ಬಿಟ್ಟಿತು — ಬ್ಲೈಂಡ್ ಸೆಟ್ ಹಿಡಿಯಲೆಂದೇ ಇರುವ ಅಂತರ ಇದು.

ಮರೆಮಾಡುವುದಕ್ಕಿಂತ ಹೇಳುವುದೇ ಮೇಲು ಎನಿಸುವ ಎರಡು ಎಚ್ಚರಿಕೆಗಳು: ಮೌಲ್ಯಮಾಪನವನ್ನು ಒಂದು AI ನಿರ್ಣಾಯಕ (Claude) ಉಲ್ಲೇಖ ಉತ್ತರಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ ಮಾಡುತ್ತದೆ — ಸಹಾಯಕದ ಅದೇ ಮಾಡೆಲ್ ಕುಟುಂಬ — ಫಲಿತಾಂಶಗಳನ್ನು ಮನುಷ್ಯರು ಪರಿಶೀಲಿಸಿಲ್ಲ; ಮತ್ತು ನಮ್ಮ ಮಾದರಿ ದಾಖಲೆಗಳು ಹೆಚ್ಚಿನ ನಿಜವಾದ ಕಂಪನಿ ಫೈಲ್‌ಗಳಿಗಿಂತ ಸ್ವಚ್ಛವಾಗಿವೆ. ಸಂಖ್ಯೆಗಳನ್ನು ಸೂಚಕವಾಗಿ ನೋಡಿ. ಪ್ರತಿ ಪ್ರಶ್ನೆ, ಉತ್ತರ ಮತ್ತು ಅಂಕ ಗುಣಮಟ್ಟ ಪುಟದಲ್ಲಿ ಸಾರ್ವಜನಿಕವಾಗಿದೆ.

ಅಷ್ಟೇ ಮುಖ್ಯ: ದಾಖಲೆಗಳಲ್ಲಿ ಇಲ್ಲದ ಪ್ರಶ್ನೆಗಳಿಗೆ ಪ್ರಾಮಾಣಿಕ “ಇದು ದಾಖಲೆಗಳಲ್ಲಿ ನನಗೆ ಸಿಗಲಿಲ್ಲ” ಸಿಗುತ್ತದೆ — ಕಲ್ಪನೆಯಲ್ಲ.

ಇದೇ ಶಿಸ್ತನ್ನು ನಾವು ಕ್ಲೈಂಟ್ ಯೋಜನೆಗಳಿಗೆ ತರುತ್ತೇವೆ: ಮೊದಲ ದಿನದಿಂದಲೇ ನಿಜವಾದ ಪ್ರಶ್ನೆಗಳ ಪರೀಕ್ಷಾ ಸೆಟ್, prompt, ಮಾಡೆಲ್ ಅಥವಾ ದಾಖಲೆ ಬದಲಾದಾಗಲೆಲ್ಲಾ ಮತ್ತೆ ನಡೆಸಲಾಗುತ್ತದೆ — ಗುಣಮಟ್ಟ ಒಂದು ಭಾವನೆಯಲ್ಲ, ಗಮನಿಸಬಹುದಾದ ಸಂಖ್ಯೆಯಾಗಲಿ ಎಂದು.

ನಿಮ್ಮ ದತ್ತಾಂಶದಲ್ಲಿ ನಡೆಸುವುದು

ಡೆಮೊ ನಾವು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅಳವಡಿಸುವ ಅದೇ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ: Next.js, pgvector ಸಹಿತ PostgreSQL ಮತ್ತು Claude — ನೀವು ಆರಿಸುವ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ, ಸೂಕ್ಷ್ಮ ದಾಖಲೆಗಳಿಗೆ ನಿಮ್ಮದೇ ಸರ್ವರ್‌ಗಳೂ ಸೇರಿದಂತೆ. ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಹೆಚ್ಚು ಬಳಕೆಯ ಕಾರ್ಯಪ್ರವಾಹ (HR ಪ್ರಶ್ನೆಗಳು, ಉತ್ಪನ್ನ ಬೆಂಬಲ ಅಥವಾ ಆಂತರಿಕ SOPಗಳು), ಐವತ್ತು ನಿಜವಾದ ಪ್ರಶ್ನೆಗಳು ಮತ್ತು ತಿಂಗಳುಗಳಲ್ಲ ವಾರಗಳಲ್ಲಿ ಅಳೆದ ಪೈಲಟ್‌ನೊಂದಿಗೆ ಆರಂಭವಾಗುತ್ತದೆ. ಬೆಳೆದಂತೆ ಕನೆಕ್ಟರ್‌ಗಳು (Google Drive, SharePoint, Notion), ದಾಖಲೆ ಮಟ್ಟದ ಅನುಮತಿಗಳು ಮತ್ತು WhatsApp ಚಾನೆಲ್ ಸೇರಿಸಿ.

AIVCJ Knowledge ಲೈವ್ ಆಗಿ ಪ್ರಯತ್ನಿಸಿ →