ಒಂದು ಆಕರ್ಷಕ AI ಡೆಮೊ ಮತ್ತು ಮಧ್ಯರಾತ್ರಿ 2 ಗಂಟೆಗೆ ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ಸುಗಮವಾಗಿ ನಡೆಯುವ ಪ್ರೊಡಕ್ಷನ್ ಸಿಸ್ಟಮ್ ನಡುವಿನ ಅಂತರವು ಬಹಳ ದೊಡ್ಡದಿದೆ. ಇಂತಹ ಡೆಮೊಗಳನ್ನು ನಿರ್ಮಿಸುವ ಹೆಚ್ಚಿನ ಜನರಿಗೂ ಇದು ತಿಳಿದಿದೆ. ಆದರೆ ಅವರು ನಿಮಗೆ ನೀಲನಕ್ಷೆಯನ್ನು (blueprint) ಮಾರಾಟ ಮಾಡುವಾಗ ಯಾವಾಗಲೂ ಈ ಸತ್ಯವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ನೀವು ತಪ್ಪು ಫೌಂಡೇಶನ್ ಮಾಡೆಲ್ ಅನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದಕ್ಕಾಗಿ ನಿಮ್ಮ ಪೈಪ್‌ಲೈನ್ ವಿಫಲವಾಗುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಡಿಸೈನ್ ಒಂದು ಪ್ರೊಟೊಟೈಪ್ ಅನ್ನು ಉತ್ಪನ್ನದಂತೆ (product) ಪರಿಗಣಿಸಿದಾಗ ಅದು ವಿಫಲವಾಗುತ್ತದೆ.

ಪ್ರಸ್ತುತ, ಪ್ರತಿಯೊಂದನ್ನೂ ಏಜೆಂಟ್ (agent) ಎಂದು ಕರೆಯಲಾಗುತ್ತಿದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ಥಿತಿ ಎದುರಾಗುವವರೆಗೆ ಲೂಪ್ ಆಗುವ ಸ್ಕ್ರಿಪ್ಟ್ ಕೂಡ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಏಜೆಂಟ್ ಆಗಿ ಬದಲಾಗಿದೆ. ಕೊನೆಯ ಮೂರು ಸಂದೇಶಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುವ ಚಾಟ್‌ಬಾಟ್ ಕೂಡ ಏಜೆಂಟ್ ಆಗಿದೆ. ಇಂತಹ ಅಸ್ಪಷ್ಟ ಪದಬಳಕೆಯು ಎಂಜಿನಿಯರಿಂಗ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ನಿಜವಾದ ಹಾನಿಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಒಂದು ಸರಳ cron job ಮೂಲಕ ನಿರ್ವಹಿಸಬಹುದಾದ ಐದು ಹಂತಗಳ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ತಂಡಗಳು ಭಾರೀ ಏಜೆಂಟ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳನ್ನು ಬಳಸಲು ಮುಂದಾಗುತ್ತವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅವರು ನಿಜವಾದ ಸಂಕೀರ್ಣತೆಯ ಮೇಲೆ ಹೂಡಿಕೆ ಮಾಡುವುದನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತಾರೆ, ಏಕೆಂದರೆ ಈ ಲೇಬಲ್‌ನಿಂದಾಗಿ ಲಾರ್ಜ್ ಲ್ಯಾಂಗ್ವೇಜ್ ಮಾಡೆಲ್ ಎಲ್ಲಾ ಎಡ್ಜ್ ಕೇಸ್‌ಗಳನ್ನು (edge cases) ಮಾಂತ್ರಿಕವಾಗಿ ಸರಿಪಡಿಸುತ್ತದೆ ಎಂಬ ಭ್ರಮೆ ಮೂಡುತ್ತದೆ. ಆದರೆ ಅದು ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ.

ಏಜೆಂಟ್ ಅಂದರೆ ನಿಜವಾಗಿ ಏನು

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

ನೀವು ನಿರ್ಮಿಸುತ್ತಿರುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಣಯಿಸಲು ಈ ಮೂರು ನಿಯಮಗಳನ್ನು ಬಳಸಿ:

  • ಒಂದು ವೇಳೆ ಮನುಷ್ಯ ಪ್ರತಿಯೊಂದು ಹಂತವನ್ನೂ ಹೇಳಬೇಕಾದಲ್ಲಿ, ಅದು ಕೇವಲ ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಆಗಿದೆ. ಇಲ್ಲಿ ನೀವು ಚಾಲನೆ ನೀಡುತ್ತಿದ್ದೀರಿ. ಸಿಸ್ಟಮ್ ಕೇವಲ ಅತ್ಯಂತ ವಿನಯಶೀಲವಾದ ಸ್ಟೀರಿಂಗ್ ವೀಲ್ ಇದ್ದಂತೆ.
  • ಒಂದು ವೇಳೆ ಟೂಲ್ ಕಾಲ್ ವಿಫಲವಾದರೂ ಅದು ಅದನ್ನು ಸರಿಪಡಿಸಿಕೊಳ್ಳಬಲ್ಲದಾದರೆ, ನೀವು ಸರಿಯಾದ ಹಾದಿಯಲ್ಲಿದ್ದೀರಿ ಎಂದರ್ಥ. ಸರ್ಚ್ API ಟೈಮ್ ಔಟ್ ಆಗುವುದು ಅಥವಾ 500 ಎರರ್ ನೀಡುವುದು ಕೆಲಸವನ್ನು ನಿಲ್ಲಿಸಬಾರದು. ಸಿಸ್ಟಮ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕು (retry), ಸ್ವಲ್ಪ ವಿರಾಮ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಪರ್ಯಾಯ ಮೂಲಕ್ಕೆ ಬದಲಾಗಬೇಕು ಅಥವಾ ಸಹಾಯಕ್ಕಾಗಿ ಕೇಳಬೇಕು.
  • ಒಂದು ಗುರಿಯನ್ನು ಉಪ-ಕಾರ್ಯಗಳಾಗಿ (subtasks) ವಿಂಗಡಿಸಿ ಅವುಗಳನ್ನು ಹಂಚಿಕೆ ಮಾಡಿದರೆ, ಅದು ನಿಜವಾದ ಏಜೆಂಟ್. ಅದಕ್ಕೆ "Q3 ಕಾಂಪ್ಲೈಯನ್ಸ್ ವರದಿಯನ್ನು ಸಿದ್ಧಪಡಿಸು" ಎಂಬಂತಹ ಕಮಾಂಡ್ ನೀಡಿ; ಅದು ಡೇಟಾ ಮೂಲಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಡೇಟಾ ಹೊರತೆಗೆಯುವ ವೇಳಾಪಟ್ಟಿಯನ್ನು ರೂಪಿಸುತ್ತದೆ, ಕಚ್ಚಾ ಅಂಕಿಅಂಶಗಳನ್ನು ಕ್ಯಾಲ್ಕುಲೇಷನ್ ಮಾಡ್ಯೂಲ್‌ಗೆ ನೀಡುತ್ತದೆ, ಕರಡು ವರದಿಯನ್ನು ಪರಿಶೀಲನೆಗೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕೆಂದು ಅದಕ್ಕೆ ತಿಳಿದಿರುತ್ತದೆ.

ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಈ ಕೆಲಸಗಳನ್ನು ಮಾಡದಿದ್ದರೆ, ನಿಮಗೆ ಏಜೆಂಟ್ ಸಮಸ್ಯೆಯಿಲ್ಲ. ನಿಮಗೆ ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಸಮಸ್ಯೆ ಅಥವಾ ವರ್ಕ್‌ಫ್ಲೋ ಸಮಸ್ಯೆ ಇದೆ ಎಂದರ್ಥ. ಇದನ್ನು ಮೊದಲೇ ಒಪ್ಪಿಕೊಳ್ಳುವುದು ನೀವು ವಾರಗಟ್ಟಲೆ ಫ್ರೇಮ್‌ವರ್ಕ್‌ನ ಅತಿಯಾದ ಬಳಕೆಯಿಂದ ಪಾರಾಗಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಯಶಸ್ವಿ ತಂಡಗಳು ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಆದ್ಯತೆ ನೀಡುತ್ತವೆ

ನಂಬಿಕಾರ್ಹ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ತಂಡಗಳು ಕೇವಲ ಬೆಂಚ್‌ಮಾರ್ಕ್‌ನಲ್ಲಿ ಕೆಲವು ಅಂಕಗಳನ್ನು ಗಳಿಸಲು ಇತ್ತೀಚಿನ ಮಾಡೆಲ್ ಬಿಡುಗಡೆಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತಾ ಕುಳಿತುಕೊಳ್ಳುವುದಿಲ್ಲ. ಅವರು ಮೂರು ಸಾಮಾನ್ಯವಾದ ಆದರೆ ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ ಕ್ಷೇತ್ರಗಳ ಮೇಲೆ ಗಮನ ಹರಿಸುತ್ತಾರೆ.

ಟೂಲ್ ಡಿಸೈನ್ (Tool design). ನಿಮ್ಮ ಏಜೆಂಟ್ ನೀವು ನೀಡುವ ಟೂಲ್‌ಗಳಷ್ಟೇ ಸಮರ್ಥವಾಗಿರುತ್ತದೆ. ಒಂದು ಸರ್ಚ್ ಫಂಕ್ಷನ್ ಅಸಂಗತ ಫೀಲ್ಡ್ ಹೆಸರುಗಳಿರುವ ನೆಸ್ಟೆಡ್ JSON ಅನ್ನು ನೀಡಿದರೆ, ಮಾಡೆಲ್ ವಿಷಯದ ಬಗ್ಗೆ ಯೋಚಿಸುವ ಬದಲು ಆ ರಚನೆಯನ್ನು ಪಾರ್ಸ್ ಮಾಡಲು ತನ್ನ ಅಮೂಲ್ಯವಾದ ಕಾಂಟೆಕ್ಸ್ಟ್ ವಿಂಡೋವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ಟೂಲ್ ವಿವರಣೆಗಳು ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, ಮಾಡೆಲ್ ತಪ್ಪು ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ (hallucinate) ಮಾಡುತ್ತದೆ. ಟೂಲ್ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಕ್ಲೀನ್ ಇನ್‌ಪುಟ್‌ಗಳು, ಊಹಿಸಬಹುದಾದ ಔಟ್‌ಪುಟ್‌ಗಳು ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಎರರ್ ಸ್ಟೇಟ್‌ಗಳು ಬೇಕಾದ ಒಬ್ಬ ಜೂನಿಯರ್ ಡೆವಲಪರ್‌ಗೆ ನೀಡುವ API ಗಳಂತೆ ಪರಿಗಣಿಸಿ.

ಫೇಲ್ಯೂರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ (Failure handling). ರಿಟ್ರಿವಲ್ ಹಂತವು ಏನನ್ನೂ ನೀಡದಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ? ಅತೀ ಹೆಚ್ಚು ಪೈಪ್‌ಲೈನ್‌ಗಳು ಖಾಲಿ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಪ್ರಾಂಪ್ಟ್‌ಗೆ ತಳ್ಳುತ್ತವೆ ಮತ್ತು ಮಾಡೆಲ್ ತನ್ನ ತರಬೇತಿ ಡೇಟಾದಿಂದ ತಪ್ಪು ಉತ್ತರವನ್ನು ಹ್ಯಾಲ್ಯುಸಿನೇಟ್ ಮಾಡಲು ಬಿಡುತ್ತವೆ. ಇದು ಯಾವುದೇ ಫೀಚರ್ ಅಲ್ಲ; ಇದು ಸಂಭವಿಸಬಲ್ಲ ಪ್ರೊಡಕ್ಷನ್ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಸರಿಯಾದ ಸಿಸ್ಟಮ್ ಈ ಖಾಲಿ ಇರುವಿಕೆಯನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತದೆ. ಅದು ವಿಸ್ತೃತವಾದ ಕ್ವೇರಿಯೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಅದು ಮನುಷ್ಯನಿಗೆ ವಿಷಯವನ್ನು ವರ್ಗಾಯಿಸುತ್ತದೆ ಅಥವಾ ಸ್ಪಷ್ಟವಾದ ವಿವರಣೆಯೊಂದಿಗೆ ನಿಲ್ಲುತ್ತದೆ. ಏನೂ ಸಿಗದಿದ್ದಾಗ ಏನೋ ಸಿಕ್ಕಿದೆ ಎಂದು ಅದು ಎಂದಿಗೂ ನಟಿಸುವುದಿಲ್ಲ.

ಅಬ್ಸರ್ವೇಬಿಲಿಟಿ (Observability). ಏಜೆಂಟ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ನಿರ್ಧಾರವನ್ನು ಏಕೆ ತೆಗೆದುಕೊಂಡಿತು ಎಂಬುದನ್ನು ನೀವು ನೋಡಬೇಕಾಗುತ್ತದೆ. ಕೇವಲ ಅಂತಿಮ ಔಟ್‌ಪುಟ್ ಮಾತ್ರವಲ್ಲ—ಚೈನ್ ಆಫ್ ಥಾಟ್ (chain of thought), ಟೂಲ್ ಆಯ್ಕೆ, ರಿಟ್ರೀವ್ ಮಾಡಿದ ಚಂಕ್‌ಗಳು ಮತ್ತು ಹ್ಯಾಂಡ್‌ಆಫ್ ಲಾಗ್‌ಗಳನ್ನು ನೀವು ನೋಡಬೇಕು. ಆ ಟ್ರೇಸ್ ಇಲ್ಲದೆ, ಡೆಬಗ್ ಮಾಡುವುದು ಕೇವಲ ಊಹಾಪೋಹವಾಗುತ್ತದೆ. ಮುಂದಿನ ವಾರ ಬಳಕೆದಾರರು ತಪ್ಪು ಉತ್ತರದ ಬಗ್ಗೆ ದೂರು ನೀಡಿದಾಗ, ಯಾವ ರಿಟ್ರಿವಲ್ ಹಂತವು ತಪ್ಪು ಮಾಹಿತಿಯನ್ನು ನೀಡಿತು ಮತ್ತು ಏಕೆ ಎಂಬುದನ್ನು ನೀವು ನಿಖರವಾಗಿ ಮರುಸೃಷ್ಟಿಸಿ ನೋಡಲು ಸಾಧ್ಯವಾಗಬೇಕು.

ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬಾಳಿಕೆ ಬರುವ ಆರ್ಕಿಟೆಕ್ಚರ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು

LangChain, CrewAI ಮತ್ತು ಮುಂದಿನ ಆರು ತಿಂಗಳಲ್ಲಿ ಬರಲಿರುವ ಯಾವುದೇ ಹೊಸ ಫ್ರೇಮ್‌ವರ್ಕ್ ಕೇವಲ ಸ್ಕ್ಯಾಫೋಲ್ಡಿಂಗ್ (scaffolding) ಇದ್ದಂತೆ. ಆರ್ಕಿಟೆಕ್ಚರ್ ಎಂಬುದು ನಿಜವಾದ ಕಟ್ಟಡ. ನಿಮ್ಮ ವಿನ್ಯಾಸವು ದುರ್ಬಲವಾಗಿದ್ದರೆ, ಯಾವುದೇ ಫ್ರೇಮ್‌ವರ್ಕ್ ಅದನ್ನು ಉಳಿಸಲಾರದು. ಸಾಬೀತಾದ ಮತ್ತು ದೀರ್ಘಕಾಲ ಬಾಳಿಕೆ ಬರುವ ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಅನುಸರಿಸಿ:

  • ಯೋಜಿಸಿ, ನಂತರ ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಮಾಡೆಲ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಯೋಚನೆ ಮತ್ತು ಕಾರ್ಯವೈಖರಿಯನ್ನು ಮಾಡದಂತೆ ನೋಡಿಕೊಳ್ಳಿ. ಮೊದಲು, ಒಂದು ಯೋಜನೆಯನ್ನು ರೂಪಿಸಿ. ನಂತರ ಹಂತಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಿ. ಏನಾದರೂ ತಪ್ಪಾದಾಗ, ನೀವು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು. ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಬೆರೆತಿರುವ ಟೂಲ್ ಕರೆಗಳು (tool calls) ಮತ್ತು ಪ್ರವಾಹದಂತಿರುವ ತರ್ಕಬದ್ಧ ಚಿಂತನೆಗಳ (stream-of-consciousness reasoning) ಗೊಂದಲವನ್ನು ಸರಿಪಡಿಸಲು ನೀವು ಬಹಳ ಕಡಿಮೆ ಸಮಯವನ್ನು ವ್ಯಯಿಸುತ್ತೀರಿ.
  • ಮಾಹಿತಿ ಪಡೆಯುವುದನ್ನು (retrieval) ಮತ್ತು ತರ್ಕ ಮಾಡುವುದನ್ನು (reasoning) ಪ್ರತ್ಯೇಕಿಸಿ. ಸಂದರ್ಭವನ್ನು (context) ಪಡೆಯುವುದು ಒಂದು I/O ಕೆಲಸವಾಗಿದೆ. ಆ ಸಂದರ್ಭವನ್ನು ಬಳಸುವುದು ತರ್ಕದ ಕೆಲಸವಾಗಿದೆ. ಇವೆರಡನ್ನೂ ಬೆರೆಸುವುದರಿಂದ ನಿಮ್ಮ ರಿಟ್ರೈವರ್ (retriever) ಮಾಡೆಲ್‌ನ ಟೋಕನ್ ಮಿತಿಗಳಿಗೆ ಸೀಮಿತವಾಗುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಮಾಡೆಲ್ ಕಚ್ಚಾ ಮಾಹಿತಿಯ ಗೊಂದಲದಿಂದ (retrieval noise) ಕಲುಷಿತಗೊಳ್ಳುತ್ತದೆ. ರಿಟ್ರೈವಲ್ ಲೇಯರ್ (retrieval layer) ಹೆಚ್ಚು ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲಿ. ತರ್ಕ ಲೇಯರ್ (reasoning layer) ತನಗೆ ಸಿಕ್ಕ ಮಾಹಿತಿಯನ್ನು ವಿಮರ್ಶಾತ್ಮಕವಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲಿ.
  • ಸ್ಪಷ್ಟವಾದ ಹಸ್ತಾಂತರಗಳನ್ನು (handoffs) ಬಳಸಿ. ಒಂದು ಕೆಲಸದಲ್ಲಿ ಹಲವಾರು ಏಜೆಂಟ್‌ಗಳು ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಕೆಲಸವನ್ನು ವರ್ಗಾಯಿಸುವ ವಿಧಾನವನ್ನು ವ್ಯವಸ್ಥಿತಗೊಳಿಸಿ. ಸ್ಪಷ್ಟವಾದ ಔಟ್‌ಪುಟ್ ಸ್ಕೀಮಾಗಳು (output schemas), ಮಾಲೀಕತ್ವದ ಗಡಿಗಳು ಮತ್ತು ಹಸ್ತಾಂತರ ಲಾಗ್‌ಗಳನ್ನು (handoff logs) ವ್ಯಾಖ್ಯಾನಿಸಿ. ಏಜೆಂಟ್‌ಗಳ ನಡುವಿನ ಅಸ್ಪಷ್ಟ ಮತ್ತು ಅನೌಪಚಾರಿಕ ಚಾಟ್ ಮಾಡುವುದರಿಂದ ಕೆಲಸಗಳು ಕೈಬಿಡಲ್ಪಡಬಹುದು, ವೃತ್ತಾಕಾರದ ಲೂಪ್‌ಗಳು (circular loops) ಉಂಟಾಗಬಹುದು ಅಥವಾ ಕೆಲಸಗಳು ಪುನರಾವರ್ತನೆಯಾಗಬಹುದು. ಏಜೆಂಟ್-to-ಏಜೆಂಟ್ ಸಂವಹನವನ್ನು ಗ್ರೂಪ್ ಚಾಟ್‌ನಂತೆ ನೋಡದೆ, ಸುಸಂಘಟಿತ API ಒಪ್ಪಂದದಂತೆ (API contract) ಪರಿಗಣಿಸಿ.

ನಿಮ್ಮ RAG ಏಕೆ ಕಸದಂತಹ (garbage) ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತಿದೆ ಎಂಬುದರ ನಿಜವಾದ ಕಾರಣ

ನಿಮ್ಮ ರಿಟ್ರೈವಲ್-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್ (RAG) ಪೈಪ್‌ಲೈನ್ ನಿರಂತರವಾಗಿ ಪ್ರಯೋಜನವಿಲ್ಲದ ಫಲಿತಾಂಶಗಳನ್ನು ನೀಡುತ್ತಿದ್ದರೆ, ಎಂಬೆಡ್ಡಿಂಗ್ ಮಾಡೆಲ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ನಿಮ್ಮ ಚಂಕಿಂಗ್ (chunking) ತಂತ್ರವನ್ನು ಗಮನಿಸಿ. RAG ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಇದು ಅತ್ಯಂತ ನಿರ್ಲಕ್ಷಿಸಲ್ಪಟ್ಟ ವೈಫಲ್ಯದ ಅಂಶವಾಗಿದೆ.

ನೀವು ದಾಖಲೆಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿಗದಿತ ಗಾತ್ರದ ಚಂಕ್‌ಗಳಾಗಿ (chunks) ವಿಭಜಿಸಿದಾಗ, ನೀವು ಹೆಚ್ಚಾಗಿ ವಿಚಾರಗಳನ್ನು ಅನಾಥಗೊಳಿಸುತ್ತೀರಿ (orphan ideas). "ಆದರೆ, ಈ ವಿಧಾನವು ನಿಯಂತ್ರಕ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಗಣಿಸುವಲ್ಲಿ ವಿಫಲವಾಯಿತು" ಎಂದು ಪ್ರಾರಂಭವಾಗುವ ಪ್ಯಾರಾಗ್ರಾಫ್, ಆ ವಿಧಾನವನ್ನು ಹೆಸರಿಸಿದ ಹಿಂದಿನ ಪ್ಯಾರಾಗ್ರಾಫ್ ಇಲ್ಲದೆ ಯಾವುದೇ ಅರ್ಥವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಅಂತಹ ಪ್ರತ್ಯೇಕ ತುಣುಕನ್ನು ಮಾಡೆಲ್‌ಗೆ ನೀಡಿದಾಗ, ಮಾಡೆಲ್ ಅದಕ್ಕೆ ಬೇಕಾದ ಸಂದರ್ಭವನ್ನು ತಾನೇ ಸೃಷ್ಟಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಅದು ರಿಟ್ರೈವಲ್ ಅಲ್ಲ; ಅದು ಹ್ಯಾಲ್ಯುಸಿನೇಷನ್ ಫ್ಯಾಕ್ಟರಿ (hallucination factory).

ಈ ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿ:

  • ಓವರ್‌ಲ್ಯಾಪಿಂಗ್ ವಿಂಡೋಸ್ (Overlapping windows). ಪಕ್ಕದ ಚಂಕ್‌ಗಳು ಗಡಿಗಳಲ್ಲಿ ಒಂದು ಅಥವಾ ಎರಡು ವಾಕ್ಯಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವಂತೆ ಮಾಡಿ, ಇದರಿಂದ ಪರಿಕಲ್ಪನೆಗಳು ಅರ್ಧಂಬರ್ಧ ವಿಚಾರದಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುವುದಿಲ್ಲ.
  • ಸೆಮ್ಯಾಂಟಿಕ್ ಚಂಕಿಂಗ್ (Semantic chunking). ಅಕ್ಷರಗಳ ಸಂಖ್ಯೆಯ ಬದಲಿಗೆ ನೈಸರ್ಗಿಕ ಗಡಿಗಳು—ಪ್ಯಾರಾಗ್ರಾಫ್ ಅಂತ್ಯಗಳು, ಸೆಕ್ಷನ್ ಹೆಡರ್‌ಗಳು ಅಥವಾ ವಿಷಯದ ಬದಲಾವಣೆಗಳ ಬಳಿ ವಿಭಜಿಸಿ.
  • ಪೇರೆಂಟ್-ಡಾಕ್ಯುಮೆಂಟ್ ರಿಟ್ರೈವಲ್ (Parent-document retrieval). ಸೆಮ್ಯಾಂಟಿಕ್ ಮ್ಯಾಚಿಂಗ್‌ಗಾಗಿ ಸಣ್ಣ ಮತ್ತು ನಿಖರವಾದ ಚಂಕ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ, ಆದರೆ ಭಾಷಾ ಮಾಡೆಲ್‌ಗೆ ಪೂರ್ಣ ಪೇರೆಂಟ್ ಸೆಕ್ಷನ್ ಅಥವಾ ದಾಖಲೆಯನ್ನು ನೀಡಿ, ಇದರಿಂದ ಅದು ಉತ್ತರವನ್ನು ಸೃಷ್ಟಿಸುವಾಗ ಸುತ್ತಮುತ್ತಲಿನ ಸಂದರ್ಭವನ್ನು ಹೊಂದಿರಬಹುದು.
  • ಕಚ್ಚಾ ಪಠ್ಯದ ಬದಲಿಗೆ ರಚನಾತ್ಮಕ ಡೇಟಾವನ್ನು (structured data) ಸಂಗ್ರಹಿಸಿ. ಟ್ಯಾಬ್ಯುಲರ್ ಡೇಟಾ, ಕೀ-ವ್ಯಾಲ್ಯೂ ಜೋಡಿಗಳು ಮತ್ತು ಸಂಬಂಧಗಳು ಹೆಚ್ಚಾಗಿ ಗದ್ಯ ರೂಪದಲ್ಲಿ (prose) ಸರಿಯಾಗಿ ಎಂಬೆಡ್ ಆಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಮೂಲ ಮಾಹಿತಿ ರಚನಾತ್ಮಕವಾಗಿದ್ದರೆ, ಅದನ್ನು ಗ್ರಾಫ್ ಡೇಟಾಬೇಸ್ ಅಥವಾ ರಿಲೇಶನಲ್ ಸ್ಟೋರ್‌ನಲ್ಲಿ ರಚನಾತ್ಮಕವಾಗಿಯೇ ಇರಿಸಿ ಮತ್ತು ಎಂಬೆಡ್ ಮಾಡಿದ ಪಠ್ಯದ ತುಣುಕುಗಳಿಂದ ಊಹಿಸುವ ಬದಲು ಏಜೆಂಟ್ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಕ್ವೇರಿ (query) ಮಾಡಲು ಬಿಡಿ.

ನೀವು ನಂಬಬಹುದಾದ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಿ

ಬೆಂಚ್‌ಮಾರ್ಕ್‌ಗಳ ಬೆನ್ನಟ್ಟುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಲೀಡರ್‌ಬೋರ್ಡ್ ಸ್ಕೋರ್ ಎಂಬುದು ಪ್ರಯೋಗಾಲಯದ ಪರಿಸ್ಥಿತಿ ಮಾತ್ರ. ಪ್ರೊಡಕ್ಷನ್ (Production) ಪರಿಸ್ಥಿತಿಯು ಗೊಂದಲಮಯವಾಗಿರುತ್ತದೆ, ಸವಾಲಿನಿಂದ ಕೂಡಿರುತ್ತದೆ ಮತ್ತು ಅಸಿಂಕ್ರೋನಸ್ (async) ಆಗಿರುತ್ತದೆ. ನೀವು ಮಲಗಿದ್ದಾಗ, ಅಪ್‌ಸ್ಟ್ರೀಮ್ API ಅಸ್ಥಿರವಾಗಿದ್ದಾಗ ಮತ್ತು ಬಳಕೆದಾರರು ತರಬೇತಿ ಡೇಟಾದಲ್ಲಿ ಇಲ್ಲದ ಯಾವುದನ್ನಾದರೂ ಕೇಳಿದಾಗ ನಿಮ್ಮ ವ್ಯವಸ್ಥೆಯು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ ಎಂಬುದು ಮುಖ್ಯವಾಗುತ್ತದೆ.

ಸಿಸ್ಟಮ್ಸ್ ಡಿಸೈನ್ (systems design) ಮೇಲೆ ಗಮನಹರಿಸಿ. ರಿಟ್ರೈವಲ್ ಮತ್ತು ರೀಸನಿಂಗ್ ನಡುವೆ ಸ್ಪಷ್ಟವಾದ ಗಡಿಗಳನ್ನು ನಿರ್ಮಿಸಿ. ವೈಫಲ್ಯ ಸಂಭವಿಸಿದಾಗ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸುವ ಮತ್ತು ಸುಲಭವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳುವ ಟೂಲ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ. ನೀವು ನಿರ್ಧಾರಗಳನ್ನು ಲಾಗ್ (log) ಮಾಡಿ, ಇದರಿಂದ ನೀವು ಅವುಗಳನ್ನು ಆಡಿಟ್ ಮಾಡಬಹುದು. ಸಂದರ್ಭವು ಅಖಂಡವಾಗಿರಲು ನಿಮ್ಮ ದಾಖಲೆಗಳನ್ನು ಚಂಕ್‌ಗಳಾಗಿ ವಿಭಜಿಸಿ. ಇದನ್ನು ಮಾಡಿದರೆ, ನೀವು ಕೇವಲ ಡೆಮೊ ನೀಡಲು ಮಾತ್ರವಲ್ಲದೆ, ವಾಸ್ತವಿಕ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸುವಾಗಲೂ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರುವ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.

ಮೂಲ: The Overlooked Reason Your RAG Pipeline Keeps Returning Garbage

ಕಲಿಕಾ ಸಮುದಾಯಕ್ಕೆ ಸೇರಿ: GyaanSetu AI on Telegram