ನಾನು ಬಿಡುಗಡೆ ಮಾಡಿದ AI ಏಜೆಂಟ್ 23 ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣವಾಯಿತು, ಆದರೆ ಲೈವ್ ಆದ ಒಂದು ಗಂಟೆಯೊಳಗೆ ಅದು ಒಂದು ಉತ್ಪನ್ನದ ವೈಶಿಷ್ಟ್ಯವನ್ನು (product feature) ಕಲ್ಪಿಸಿಕೊಂಡು, ವಾಸ್ತವಕ್ಕಿಂತ ಮೂರು ಪಟ್ಟು ಕಡಿಮೆ ಬೆಲೆಯನ್ನು ತಿಳಿಸಿತು. ಬಳಕೆದಾರರು ಅದನ್ನು ಪ್ರಶ್ನಿಸಿದಾಗ, ಬಾಟ್ ತನ್ನ ತಪ್ಪನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವ ಬದಲು ವಾದ ಮಾಡಿತು, ಇದರಿಂದ ಸಂಭಾಷಣೆ ಕೊನೆಗೊಂಡಿತು ಮತ್ತು ನಾನು ಒಬ್ಬ ಗ್ರಾಹಕನನ್ನು ಕಳೆದುಕೊಂಡೆ. ಈ ತಪ್ಪನ್ನು ನೋಡಿದಾಗ, ಕೇವಲ ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ (deterministic) ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳ ಮೂಲಕ ಏಜೆಂಟ್‌ನ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸಾಬೀತಾಯಿತು.

ಯಾಕೆ AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಸಾಲದು

ಸಾಂಪ್ರದಾಯಿಕ ಕೋಡ್‌ಗಳಿಗೆ ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಏಕೆಂದರೆ ಒಂದೇ ಇನ್‌ಪುಟ್‌ಗೆ ಯಾವಾಗಲೂ ಒಂದೇ ಔಟ್‌ಪುಟ್ ಸಿಗುತ್ತದೆ. “2 + 2 = 4” ಎಂಬುದು ಸರಳ ಸಮಾನತಾ ಪರಿಶೀಲನೆಯೊಂದಿಗೆ (equality check) ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದಾದ ವಿಷಯ. ಆದರೆ, LLM-ಚಾಲಿತ ಏಜೆಂಟ್, ಪ್ರಾಂಪ್ಟ್ (prompt), ಸುತ್ತಮುತ್ತಲಿನ ಸಂದರ್ಭ (context) ಮತ್ತು ಅದು ಬಳಸುವ ಬಾಹ್ಯ ಟೂಲ್‌ಗಳ ಸ್ಥಿತಿಯೊಂದಿಗೆ ತನ್ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ನಿಖರವಾದ ಸ್ಟ್ರಿಂಗ್ ಸಮಾನತೆಯನ್ನು (string equality) ಮಾತ್ರ ಪರಿಶೀಲಿಸುವ ಟೆಸ್ಟ್, ಹ್ಯಾಲ್ಯುಸಿನೇಷನ್‌ಗಳು (hallucinations), ಧ್ವನಿಯ ಬದಲಾವಣೆಗಳು (tone shifts) ಅಥವಾ ಗಾರ್ಡ್‌ರೈಲ್ ಉಲ್ಲಂಘನೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಒಬ್ಬ ಗ್ರಾಹಕನನ್ನು ಕಳೆದುಕೊಳ್ಳುವಂತೆ ಮಾಡಿದ ಆ ಮೌನ ವೈಫಲ್ಯವು, ನೀವು ಕೇವಲ ಪ್ರತ್ಯೇಕ ಫಂಕ್ಷನ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಇಡೀ ಸಂವಹನವನ್ನು (interaction) ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಯಾವುದೇ ಫೀಚರ್ ಕೋಡ್ ಬರೆಯುವ ಮೊದಲು ಎವ್ಯಾಲ್ಯೂಯೇಶನ್ ಹಾರ್ನೆಸ್ ನಿರ್ಮಿಸುವುದು

ನಾನು ಅಭಿವೃದ್ಧಿಯ ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸಿದೆ: ಮೊದಲು ನಾಲ್ಕು-ಪದರಗಳ ಎವ್ಯಾಲ್ಯೂಯೇಶನ್ ಹಾರ್ನೆಸ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದೆ, ನಂತರ ಏಜೆಂಟ್ ಅನ್ನು ಬರೆದೆ. ಈ ಹಾರ್ನೆಸ್ ಒಂದೇ ಬಾರಿಗೆ 131 ಟೆಸ್ಟ್‌ಗಳನ್ನು ನಡೆಸುತ್ತದೆ, ಪ್ರತಿ ರನ್‌ಗೆ ಅಂದಾಜು ಮೂರು ಸೆಂಟ್ಸ್‌ಗಳ ವೆಚ್ಚವಾಗುತ್ತದೆ ಮತ್ತು ಸುಮಾರು ಹನ್ನೊಂದು ನಿಮಿಷಗಳಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ. ನಾನು ಪ್ರತಿಯೊಂದು ಟೆಸ್ಟ್‌ ಅನ್ನು ಅದನ್ನು ನಿಭಾಯಿಸಬಲ್ಲ ಅತ್ಯಂತ ಸಣ್ಣ ಮಾಡೆಲ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತೇನೆ, ದೊಡ್ಡ ಮತ್ತು ದುಬಾರಿ ಮಾಡೆಲ್‌ಗಳನ್ನು ಅವು ನಿಜವಾಗಿಯೂ ಮೌಲ್ಯವನ್ನು ನೀಡುವ ಸಂದರ್ಭಗಳಿಗಾಗಿ ಉಳಿಸಿಕೊಳ್ಳುತ್ತೇನೆ.

ಪದರ 1 – ಟೂಲ್ ಕಾರ್ಯಕ್ಷಮತೆ (Tool functionality)

ಮೊದಲ ರಕ್ಷಣಾ ಕವಚವು ಏಜೆಂಟ್ ತನ್ನ ಟೂಲ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಬಳಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಟೆಸ್ಟ್‌ಗಳು ಯಶಸ್ವಿ ಹುಡುಕಾಟಗಳು (searches), ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತಪ್ಪಾದ ಕ್ವೆರಿಗಳು (malformed queries) ಮತ್ತು ಸಿಮ್ಯುಲೇಟೆಡ್ API ವೈಫಲ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿವೆ. ಟೂಲ್ ಬಳಕೆ ಹೆಚ್ಚಾಗಿ ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಆಗಿರುವುದರಿಂದ—ಅಂದರೆ ವಿನಂತಿಯು ಸರಿಯಾಗಿ ರೂಪಿತವಾಗಿದ್ದರೆ ಅಥವಾ API ದೋಷವನ್ನು ನೀಡಿದರೆ—ಸರಳ Python assertions ಸಾಕು. ಇಲ್ಲಿ ತಪ್ಪಾದ ವಿನಂತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚುವುದು ಮುಂದಿನ ಗೊಂದಲಗಳನ್ನು ತಡೆಯುತ್ತದೆ.

ಪದರ 2 – ಸೂಚನೆಗಳ ಪಾಲನೆ (Instruction following)

ನಂತರ ಹಾರ್ನೆಸ್ ಏಜೆಂಟ್ ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು ಗೌರವಿಸುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಸಣ್ಣದಾದ ಒಂದು LLM ಮೌಲ್ಯಮಾಪಕವಾಗಿ (evaluator) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಏಜೆಂಟ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಿ ಅನುಸರಣೆಯನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ: ಪಾತ್ರದಲ್ಲಿ ಇರುವುದು, ನಿಷೇಧಿತ ವಿಷಯಗಳನ್ನು ತಪ್ಪಿಸುವುದು ಮತ್ತು ಅಗತ್ಯವಿರುವ JSON schema ಅನ್ನು ನೀಡುವಿಕೆ ಇತ್ಯಾದಿ. ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಪತ್ತೆಹಚ್ಚಲಾಗದ ಸೆಮ್ಯಾಂಟಿಕ್ ಡ್ರಿಫ್ಟ್ (semantic drift) ಅನ್ನು ಈ ಪದರ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಅನಿರೀಕ್ಷಿತ ವ್ಯಕ್ತಿತ್ವಕ್ಕೆ ಬದಲಾಗುವುದು ಅಥವಾ ಆಂತರಿಕ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಸೋರಿಕೆಯಾಗುವುದು.

ಪದರ 3 – ಗುರಿ-ಆಧಾರಿತ ನಡವಳಿಕೆ (Goal-oriented behavior)

ಮೂರನೇ ಪದರವು ಅತ್ಯಂತ ನಿರ್ಣಾಯಕವಾದುದು. ಏಜೆಂಟ್ ತನ್ನ ಉದ್ದೇಶವನ್ನು ನಿಜವಾಗಿಯೂ ಸಾಧಿಸುತ್ತಿದೆಯೇ ಎಂದು ಇದು ಕೇಳುತ್ತದೆ. ಲೀಡ್-ಜನರೇಷನ್ ಬಾಟ್‌ಗೆ (lead-generation bot), ಅಂದರೆ ಅದು ಸರಿಯಾದ ಅರ್ಹತಾ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಿದೆಯೇ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಮನುಷ್ಯನಿಗೆ ವರ್ಗಾಯಿಸುತ್ತಿದೆಯೇ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಎಂದರ್ಥ. ನಾನು ಇಲ್ಲಿ ರೀಸನಿಂಗ್-ಓರಿಯೆಂಟೆಡ್ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತೇನೆ ಏಕೆಂದರೆ ಅದು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸದೆ ಒಟ್ಟಾರೆ ಹರಿವನ್ನು (flow) ಮೌಲ್ಯಮಾಪನ ಮಾಡಬಲ್ಲದು. ಬಾಟ್ ತನ್ನ ಗುರಿಯನ್ನು ತಲುಪಲು ವಿಫಲವಾದರೆ—ಮೊದಲ ಎರಡು ಪದರಗಳಲ್ಲಿ ಉತ್ತೀರ್ಣವಾದರೂ ಸಹ—ಅದನ್ನು ಮರುವಿನ್ಯಾಸಕ್ಕಾಗಿ (redesign) ಗುರುತಿಸಲಾಗುತ್ತದೆ.

ಪದರ 4 – ಕಾರ್ಯಕ್ಷಮತೆ (Performance)

ಕೊನೆಯದಾಗಿ, ಹಾರ್ನೆಸ್ ಲೇಟೆನ್ಸಿ (latency) ಮತ್ತು ಟೋಕನ್-ಜನರೇಷನ್ ವೇಗವನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ನಿಧಾನಗತಿಯ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಬಳಕೆದಾರರ ಅನುಭವವನ್ನು ಕುಂದಿಸುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ರಿಯಲ್-ಟೈಮ್ ಚಾಟ್‌ನಲ್ಲಿ. ಈ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ಪತ್ತೆಹಚ್ಚುವ ಮೂಲಕ, ಏಜೆಂಟ್ ನಿಖರವಾಗಿಯೂ ಮತ್ತು ಸ್ಪಂದನಶೀಲವಾಗಿಯೂ (responsive) ಇರುವುದನ್ನು ನಾನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇನೆ.

ವೆಚ್ಚ ಉಳಿತಾಯದ ಆಯ್ಕೆಗಳು

ಪ್ರತಿ ರನ್‌ಗೆ $0.03 ಎಂಬ ಅಂಕಿಅಂಶವು ಕೇವಲ ಮಾರ್ಕೆಟಿಂಗ್ ಗಿಮಿಕ್ ಅಲ್ಲ; ಇದು ಟೆಸ್ಟ್ ಸಂಕೀರ್ಣತೆಯನ್ನು ಮಾಡೆಲ್ ಗಾತ್ರಕ್ಕೆ ಹೊಂದಿಸುವ ಮೂಲಕ ಬಂದಿದೆ. ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಟೂಲ್ ಚೆಕ್‌ಗಳು ಅಗ್ಗದ ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತವೆ, ಸೂಚನೆಗಳ ಅನುಸರಣೆಗೆ ಲೈಟ್‌ವೇಟ್ ಮಾಡೆಲ್ ಬಳಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಗುರಿ-ಆಧಾರಿತ ಮೌಲ್ಯಮಾಪನಗಳು ಮಾತ್ರ ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವುಳ್ಳ, ಆದರೆ ದುಬಾರಿಯಾದ ಮಾಡೆಲ್ ಅನ್ನು ಬಳಸುತ್ತವೆ. ಈ ಹಂತ ಹಂತದ ವಿಧಾನವು ಪ್ರತಿ ಕೋಡ್ ಬದಲಾವಣೆಯಲ್ಲೂ ಪೂರ್ಣ ಸರಣಿಯನ್ನು ನಡೆಸಲು ಅನುಕೂಲವಾಗುವಂತೆ ಒಟ್ಟು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಇರಿಸುತ್ತದೆ.

ವಿನಿಮಯ: ವೇಗ ಮತ್ತು ಸುರಕ್ಷತೆ (speed versus safety)

ಹಾರ್ನೆಸ್ ಅನ್ನು ಪರಿಚಯಿಸುವುದರಿಂದ ಆರಂಭಿಕ ಅಡಚಣೆಗಳು ಉಂಟಾದವು. ಅಭಿವೃದ್ಧಿ ಚಕ್ರಗಳು (development cycles) ವಿಸ್ತರಿಸಿದವು ಮತ್ತು ಬಿಡುಗಡೆಯ ಸಮಯವು ವಿಳಂಬವಾಯಿತು.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದವುಗಳು

  • ಮಾಡಲ್-ಡ್ರಿವನ್ ಎವ್ಯಾಲ್ಯೂಯೆಟರ್‌ಗಳು (Model-driven evaluators): LLMಗಳು ಸುಧಾರಿಸುತ್ತಿದ್ದಂತೆ, ಪದರ 2 ರಲ್ಲಿನ ಎವ್ಯಾಲ್ಯೂಯೆಟರ್ ಹೆಚ್ಚು ಸೂಕ್ಷ್ಮವಾಗಬಹುದು, ಇದು ಸಣ್ಣ ಮಟ್ಟದ ನೀತಿ ಉಲ್ಲಂಘನೆಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಜೊತೆಗೆ ತಪ್ಪು ಪಾಸಿಟಿವ್‌ಗಳನ್ನು (false positives) ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಸಾರಾಂಶ (Takeaway)

ನೀವು ಪ್ರೊಡಕ್ಷನ್ (production) ಗಾಗಿ AI ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಪದರಗಳ ಎವ್ಯಾಲ್ಯೂಯೇಶನ್ ಹಾರ್ನೆಸ್ ಎಂಬುದು ಕಡ್ಡಾಯವಲ್ಲ; ಅದು ಮೂಲಭೂತವಾಗಿದೆ. ಸಮಗ್ರ ಪರೀಕ್ಷೆಯ ವೆಚ್ಚವನ್ನು ಮೊದಲೇ ಭರಿಸುವ ಮೂಲಕ—ಪ್ರತಿ ರನ್‌ಗೆ $0.03, ಪ್ರತಿ ಸರಣಿಗೆ ಹನ್ನೊಂದು ನಿಮಿಷ—ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಪತ್ತೆಹಚ್ಚಲಾಗದ ಮೌನ ವೈಫಲ್ಯಗಳಿಂದ ನೀವು ರಕ್ಷಿಸಿಕೊಳ್ಳಬಹುದು.