GitHub Actions merge queue ನಲ್ಲಿ ಎಂಟು ತಿಂಗಳು ಕಳೆದರೆ, ಫೀಚರ್ ಹೋಲಿಕೆ ಮ್ಯಾಟ್ರಿಕ್ಸ್ (feature comparison matrices) ಎಂದಿಗೂ ಕಲಿಸದ ಒಂದು ವಿಷಯ ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ. ಒಂದು ಫ್ರೇಮ್ವರ್ಕ್ ಐವತ್ತು ಮೆಟ್ರಿಕ್ಗಳು, ಸುಂದರವಾದ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳು ಮತ್ತು ಗೌರವಾನ್ವಿತ ಸಂಶೋಧನಾ ಪ್ರಯೋಗಾಲಯಗಳ ಉಲ್ಲೇಖಗಳನ್ನು ನೀಡಬಹುದು. ಆದರೆ ಒಂದೇ ರೀತಿಯ ಕೋಡ್ಗೆ 'vibe check' ಸ್ಕೋರ್ 0.72 ರಿಂದ 0.68 ಕ್ಕೆ ಬದಲಾದ ಕಾರಣ ಅದು ನಿಮ್ಮ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಅನ್ನು ತಡೆದರೆ, ಅದು ಪ್ರಯೋಜನವಿಲ್ಲದಿದ್ದಕ್ಕಿಂತಲೂ ಕೆಟ್ಟದ್ದು. ಇದು ನಿಮ್ಮ ಶಿಪ್ಪಿಂಗ್ ವೇಗಕ್ಕೆ (shipping velocity) ಸಕ್ರಿಯ ಬೆದರಿಕೆಯಾಗುತ್ತದೆ.
ಹೆಚ್ಚಿನ LLM ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ರೌಂಡ್ಅಪ್ಗಳು (evaluation roundups) ತಪ್ಪಿಸಿಕೊಳ್ಳುವ ಫಿಲ್ಟರ್ ಇದೇ ಆಗಿದೆ. ಅವು ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಎಣಿಸುತ್ತವೆ. ಆದರೆ ಮರ್ಜ್ ಕ್ಯೂನಲ್ಲಿ (merge queue) ಅತ್ಯಂತ ಪ್ರಮುಖವಾದ ಏಕೈಕ ಪ್ರಶ್ನೆಯನ್ನು ಅವು ಕೇಳುವುದಿಲ್ಲ: "ಈ ಚೆಕ್ ಪ್ರತಿ ಬಾರಿಯೂ ರನ್ ಆದಾಗ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಪಾಸ್ ಅಥವಾ ಫೇಲ್ ಆಗುತ್ತದೆಯೇ?"
ಕಷ್ಟಕರವಾದ ಕೆಲಸವನ್ನು ಮಾಡುವುದರ ಮೂಲಕ ನಾನು ಇದನ್ನು ಕಲಿತೆ. ನಾನು ಆರು ಓಪನ್-ಸೋರ್ಸ್ LLM ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಫ್ರೇಮ್ವರ್ಕ್ಗಳನ್ನು ನೈಜ CI ಪೈಪ್ಲೈನ್ಗೆ ಜೋಡಿಸಿದೆ. ಅವು ಎಂಟು ತಿಂಗಳುಗಳ ಕಾಲ ಲೈವ್ ಪ್ರೊಡಕ್ಷನ್ ಪುಲ್ ರಿಕ್ವೆಸ್ಟ್ಗಳ (pull requests) ವಿರುದ್ಧ ರನ್ ಆದವು. ಎರಡು ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಗೇಟ್ಕೀಪರ್ಗಳಾಗಿ ಉಳಿಯುವ ಅರ್ಹತೆಯನ್ನು ಪಡೆದವು. ಉಳಿದವುಗಳನ್ನು ಕೇವಲ ಸಲಹಾ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಾಗಿ ಇಳಿಕೆ ಮಾಡಲಾಯಿತು, ನೈಟ್ಲಿ ಜಾಬ್ಗಳಿಗೆ (nightly jobs) ವರ್ಗಾಯಿಸಲಾಯಿತು ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕಲಾಯಿತು. ಪಾಠವು ಕಠಿಣ ಮತ್ತು ದುಬಾರಿಯಾಗಿತ್ತು: ನೀವು ಮೇನ್ ಬ್ರಾಂಚ್ ಅನ್ನು ರಕ್ಷಿಸುತ್ತಿರುವಾಗ, ಪ್ರೊಬಾಬಲಿಸ್ಟಿಕ್ ಗುಣಮಟ್ಟಕ್ಕಿಂತ (probabilistic quality) ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ರಚನೆಯೇ (deterministic structure) ಉತ್ತಮ.
ಮರ್ಜ್ ಗೇಟ್ನ ನಿಜವಾದ ಕೆಲಸ
CI ಗೇಟ್ ಎಂಬುದು ಸಂಶೋಧನಾ ವಾತಾವರಣವಲ್ಲ. ಅದು ಒಬ್ಬ ಬೌನ್ಸರ್ ಇದ್ದಂತೆ. ಅದರ ಸಂಪೂರ್ಣ ಉದ್ದೇಶವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆಯನ್ನು ನೋಡಿ 'ಹೌದು' ಅಥವಾ 'ಅಲ್ಲ' ಎಂದು ಉತ್ತರಿಸುವುದು. ಹೌದು, ಈ PR ಮೇನ್ ಬ್ರಾಂಚ್ ಅನ್ನು ಸೇರಬಹುದು. ಇಲ್ಲ, ಅದು ಸೇರಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆ ಉತ್ತರವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಬರಬೇಕು, ಅತ್ಯಲ್ಪ ವೆಚ್ಚದಲ್ಲಿರಬೇಕು ಮತ್ತು ಎಂದಿಗೂ ಹಿಂದಿನ ನಿರ್ಧಾರವನ್ನು ಬದಲಿಸಬಾರದು. ನೀವು ಒಂದು ಶಾಂತವಾದ ಮಂಗಳವಾರ ಮತ್ತು ಒಂದು ಗಡಿಬಿಡಿಯ ಶುಕ್ರವಾರದಂದು ಒಂದೇ ಕಮಿಟ್ಗೆ (commit) ಅದೇ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಮರು ರನ್ ಮಾಡಿದರೆ, ಫಲಿತಾಂಶವು ಒಂದೇ ಆಗಿರಬೇಕು.
ಹೆಚ್ಚಿನ LLM ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಎಡವುವ ಸ್ಥಳವಿದು. ಅವುಗಳನ್ನು ಡೇಟಾ ಸೈಂಟಿಸ್ಟ್ಗಳು, ಡೇಟಾ ಸೈಂಟಿಸ್ಟ್ಗಳಿಗಾಗಿಯೇ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಅವು ಒಳನೋಟ (insight), ಅನ್ವೇಷಣೆ (exploration) ಮತ್ತು ಸೂಕ್ಷ್ಮ ಸ್ಕೋರಿಂಗ್ಗಾಗಿ (nuanced scoring) ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತವೆ. ಆದರೆ ಮರ್ಜ್ ಕ್ಯೂಯು ಬೈನರಿ ನಿರ್ಧಾರಗಳು, ವೇಗ ಮತ್ತು ಶೂನ್ಯ ಫ್ಲೇಕಿನೆಸ್ಗಾಗಿ (zero flakiness) ಆಪ್ಟಿಮೈಸ್ ಮಾಡುತ್ತದೆ. ಈ ಎರಡು ಗುರಿಗಳು ಕೇವಲ ಭಾಗಶಃ ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ.
LLM-as-Judge ಏಕೆ ಮರ್ಜ್ ಕ್ಯೂ ಅನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ
ನನ್ನ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾದ ಪರಿಕರಗಳು ಒಂದೇ ವಿನ್ಯಾಸದ ತಪ್ಪು ಮಾಡಿದ್ದವು: ಅವು ಪ್ರಾಥಮಿಕ ಗೇಟ್ ಮೆಕ್ಯಾನಿಸಂ ಆಗಿ LLM-as-judge ಕರೆಗಳ ಮೇಲೆ ಅತಿಯಾಗಿ ಅವಲಂಬಿತವಾಗಿದ್ದವು.
ಒಂದು LLM-as-judge ಪ್ರಾಂಪ್ಟ್ ಒಂದು ಮಾಡೆಲ್ ಅನ್ನು ಔಟ್ಪುಟ್ಗೆ ಒಂದುದಿಂದ ಹತ್ತು ರೇಟಿಂಗ್ ನೀಡಲು, ಅಥವಾ ಎರಡು ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ ಉತ್ತಮವಾದುದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು, ಅಥವಾ ಸತ್ಯಾಸತ್ಯತೆಯನ್ನು ರೇಟ್ ಮಾಡಲು ಕೇಳುತ್ತದೆ. ಗುಣಮಟ್ಟದ ಪ್ರವೃತ್ತಿಗಳನ್ನು (quality trends) ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ವಿಧಾನವು ಶಕ್ತಿಯುತವಾಗಿದೆ. ಆದರೆ ಬ್ಲಾಕಿಂಗ್ CI ಚೆಕ್ಗೆ ಇದು ವಿಷವಿದ್ದಂತೆ. ಟೆಂಪರೇಚರ್ (temperature), ಮಾಡೆಲ್ ವರ್ಷನಿಂಗ್ ಮತ್ತು ಪ್ರಾಂಪ್ಟ್ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಎಲ್ಲವೂ ನಾಯ್ಸ್ (noise) ಅನ್ನು ಪರಿಚಯಿಸುವುದರಿಂದ, ಒಂದೇ ಇನ್ಪುಟ್ ಬೇರೆ ಬೇರೆ ದಿನಗಳಲ್ಲಿ ಬೇರೆ ಬೇರೆ ಸ್ಕೋರ್ಗಳನ್ನು ನೀಡಬಹುದು. ಆ ಸ್ಕೋರ್ ಅನ್ನು ಒಂದು ಕಟ್ಟುನಿಟ್ಟಾದ ಮಿತಿ (hard threshold) ಮತ್ತು ಎಕ್ಸಿಟ್ ಕೋಡ್ಗೆ (exit code) ಜೋಡಿಸಿದಾಗ, ನಿಮ್ಮ ಕ್ಯೂಯು ಕಲ್ಪಿತ ಸಮಸ್ಯೆಗಳ (ghosts) ಕಾರಣದಿಂದ ತಡೆಯಲ್ಪಡುತ್ತದೆ.
ವಿಫಲತೆಗಳು ವೇಗವಾಗಿ ಹರಡುತ್ತವೆ. ನಾನ್-ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಚೆಕ್ (nondeterministic check) ಕ್ಯೂನಲ್ಲಿ ಹಿನ್ನೆಡೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಎಂಜಿನಿಯರ್ಗಳು ಸ್ಕೋರ್ ಅನುಕೂಲಕರವಾಗಿ ಬರುವವರೆಗೆ ಮರುಪ್ರಯತ್ನಿಸಲು ಕಲಿಯುತ್ತಾರೆ, ಇದು ಕೆಂಪು ಬಿಲ್ಡ್ಗಳನ್ನು (red builds) ನಿರ್ಲಕ್ಷಿಸಲು ತಂಡವನ್ನು ಅಭ್ಯಾಸಗೊಳಿಸುತ್ತದೆ. ಪ್ರತಿ ಮರುಪ್ರಯತ್ನವೂ ಹೆಚ್ಚಿನ API ಕ್ರೆಡಿಟ್ಗಳನ್ನು ಖರ್ಚು ಮಾಡುವುದರಿಂದ ಟೋಕನ್ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ. ಎಲ್ಲಕ್ಕಿಂತ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ, ಸಿಗ್ನಲ್ ಅರ್ಥಹೀನವಾಗುತ್ತದೆ. ಕೆಂಪು ಬಿಲ್ಡ್ ಎಂದರೆ "ನೀವು ಬಗ್ ಅನ್ನು ಪರಿಚಯಿಸಿದ್ದೀರಿ" ಎಂದಿರಬೇಕು. ಆದರೆ ಅದು "ಜಡ್ಜ್ ಮಾಡೆಲ್ ಇಂದು ಹೆಚ್ಚು ವಿವೇಚನಾಶೀಲವಾಗಿದೆ" ಎಂದಾದರೆ, ನಂಬಿಕೆ ಕುಸಿಯುತ್ತದೆ.
ಉಳಿದುಕೊಂಡವುಗಳು ಏನನ್ನು ವಿಭಿನ್ನವಾಗಿ ಮಾಡುತ್ತವೆ
Promptfoo ಮತ್ತು DeepEval ಉಳಿದುಕೊಂಡವು ಏಕೆಂದರೆ ಅವು ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಚೆಕ್ಗಳನ್ನು ಪ್ರಥಮ ದರ್ಜೆಯ ಪ್ರಮುಖ ಅಂಶಗಳಾಗಿ ಮತ್ತು LLM ಜಡ್ಜ್ ಸ್ಕೋರ್ಗಳನ್ನು ದ್ವಿತೀಯಕ, ನಾನ್-ಬ್ಲಾಕಿಂಗ್ ಸಿಗ್ನಲ್ಗಳಾಗಿ ಪರಿಗಣಿಸುತ್ತವೆ. ಗೇಟ್ಗೆ ಒಂದು ಎಕ್ಸಿಟ್ ಕೋಡ್ ಬೇಕು, ಅಭಿಪ್ರಾಯ ಹೊಂದಿರುವ ಫ್ಲೋಟಿಂಗ್-ಪಾಯಿಂಟ್ ನಂಬರ್ (floating-point number) ಬೇಕಾಗಿಲ್ಲ ಎಂಬುದು ಅವುಗಳಿಗೆ ತಿಳಿದಿದೆ.
Promptfoo, MIT ಲೈಸೆನ್ಸ್ ಅಡಿಯಲ್ಲಿ ಬಿಡುಗಡೆಯಾಗಿದ್ದು, ಕಮಾಂಡ್ ಲೈನ್ (command line) ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಇದು regex matches, JSON schema validation, contains checks ಮತ್ತು exact string comparisons ನಂತಹ ಅಸರ್ಶನ್ಗಳನ್ನು (assertions) ರನ್ ಮಾಡುತ್ತದೆ. ಇವು ಅತಿ ಸುಂದರವಾದವುಗಳಲ್ಲ. ಇವು ಕೇವಲ ಸುಧಾರಿತ grep ಮತ್ತು jq ಕಮಾಂಡ್ಗಳಿದ್ದಂತೆ. ಅದಕ್ಕಾಗಿಯೇ ಇವು CI ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ಒಂದು regex ಹೊಂದಿಕೆಯಾಗಬಹುದು ಅಥವಾ ಆಗದಿರಬಹುದು. ಒಂದು JSON schema ವ್ಯಾಲಿಡೇಟ್ ಆಗಬಹುದು ಅಥವಾ ಎರರ್ ನೀಡಬಹುದು. Promptfoo ಪ್ರಮಾಣಿತ Unix exit codes ಅನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ GitHub Actions ಮರ್ಜ್ ಅನ್ನು ಯಾವಾಗ ನಿಲ್ಲಿಸಬೇಕೆಂದು ನೈಸರ್ಗಿಕವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಇದು CLI ಟೂಲ್ ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದರಿಂದ ಯಾವುದೇ ಭಾಷೆಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ (language-agnostic). ಔಟ್ಪುಟ್ಗಳನ್ನು ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಲು ನೀವು Node.js ಸರ್ವಿಸ್ ರೆಪೋದಲ್ಲಿ Python ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಇನ್ಸ್ಟಾಲ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.
DeepEval, Apache 2.0 ಅಡಿಯಲ್ಲಿ ಲೈಸೆನ್ಸ್ ಹೊಂದಿದ್ದು, Python ತಂಡಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ. ಇದು pytest ನಂತೆ ಇಂಟಿಗ್ರೇಟ್ ಆಗುತ್ತದೆ. ನೀವು ಪರಿಚಿತ ಸಿಂಟ್ಯಾಕ್ಸ್ನಲ್ಲಿ (syntax) ಪರೀಕ್ಷೆಗಳನ್ನು ಬರೆಯಬಹುದು ಮತ್ತು ವಿಫಲವಾದರೆ ಅದು ನೈಸರ್ಗಿಕವಾಗಿ ಸ್ಯೂಟ್ ಅನ್ನು ತಡೆಯುತ್ತದೆ. DeepEval ದೊಡ್ಡ ಮಟ್ಟದ ಮೆಟ್ರಿಕ್ಗಳ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಪ್ರಮುಖ ವಿಷಯವೆಂದರೆ ನೀವು ಅವುಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಬೇಕು. ಗೇಟ್ಗಳಿಗಾಗಿ ಡಿಟರ್ಮಿನಿಸ್ಟಿಕ್ ಅಥವಾ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ಅವಲಂಬಿಸಿ. ನೀವು G-Eval ಅಥವಾ ಇತರ ಜಡ್ಜ್-ಆಧಾರಿತ ಸ್ಕೋರರ್ಗಳನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಅವುಗಳನ್ನು ಹಾರ್ಡ್ ಅಸರ್ಟ್ಗಳಿಗಿಂತ (hard asserts) ನಾನ್-ಬ್ಲಾಕಿಂಗ್ ರಿಪೋರ್ಟ್ ಜನರೇಟರ್ಗಳಲ್ಲಿ ಬಳಸಬೇಕು. ಈ ರೀತಿಯಾಗಿ ಬಳಸಿದಾಗ, DeepEval ಸಂಶೋಧನಾ ನೋಟ್ಬುಕ್ನ ಅಸ್ಥಿರತೆ (flakiness) ಇಲ್ಲದೆ ನಿಮಗೆ ಟೆಸ್ಟಿಂಗ್ ಫ್ರೇಮ್ವರ್ಕ್ನ ಅನುಕೂಲತೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಉಳಿದ ನಾಲ್ಕು ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಎಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ
ಗೇಟ್ಗಳಾಗಿ ಉಳಿಯದ ಆ ನಾಲ್ಕು ಫ್ರೇಮ್ವರ್ಕ್ಗಳು ಇನ್ನೂ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿವೆ. ಅವು ನಿಮ್ಮ ಟೂಲ್ಚೈನ್ (toolchain) ನ
Future AGI (Apache 2.0) ಐವತ್ತಿಗೂ ಹೆಚ್ಚು ಮೆಟ್ರಿಕ್ಗಳನ್ನು (metrics) ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಕಸ್ಟಮ್ SDKಗಳನ್ನು ನಿರ್ಮಿಸುವ ತಂಡಗಳನ್ನು ಗುರಿಯಾಗಿಸಿಕೊಂಡಿದೆ. ಈ ಮೆಟ್ರಿಕ್ಗಳು ಸಮಗ್ರವಾಗಿವೆ. ಆದರೆ ಸಮಸ್ಯೆ ಏನೆಂದರೆ, CI ಕ್ಯೂನಲ್ಲಿ (queue) ಇದನ್ನು ಬಳಸಲು ನೀವು ಸ್ವಂತ ಹಾರ್ನೆಸ್ (harness) ಅನ್ನು ಬರೆಯಬೇಕೆಂದು ಈ ಟೂಲ್ ನಿರೀಕ್ಷಿಸುತ್ತದೆ. ಸಂಶೋಧನಾ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಸಮಂಜಸವಾದ ವಿನಿಮಯವಾಗಿದೆ. ಆದರೆ ಮರ್ಜ್ ಕ್ಯೂನಲ್ಲಿ (merge queue), ಪ್ರತಿಯೊಂದು ಕಸ್ಟಮ್ ವೈರಿಂಗ್ ಹಂತವೂ ಅಸ್ಥಿರತೆಯ ಹೊಸ ಮೂಲವಾಗುತ್ತದೆ. ಇದು ಸಮರ್ಥವಾದ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಇಂಜಿನ್ ಆಗಿದೆಯೇ ಹೊರತು, ಸಿದ್ಧವಾದ ಗೇಟ್ಕೀಪರ್ (gatekeeper) ಅಲ್ಲ.
RAGAS (Apache 2.0) ರಿಟ್ರಿವಲ್-ಆಗ್ಮೆಂಟೆಡ್ ಜನರೇಷನ್ (retrieval-augmented generation) ಗುಣಮಟ್ಟವನ್ನು ಅಳೆಯುವಲ್ಲಿ ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಇದರ faithfulness ಮತ್ತು answer relevance ಮೆಟ್ರಿಕ್ಗಳು ನಾಲಗೆಯ ಜ್ಞಾನ ಕೋಶವು (knowledge base) ಕಾಲಾನಂತರದಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಜವಾಗಿಯೂ ಉಪಯುಕ್ತವಾಗಿವೆ. ದುರದೃಷ್ಟವಶಾತ್, ಈ ಮೆಟ್ರಿಕ್ಗಳು LLM ಜಡ್ಜ್ಗಳ ಮೇಲೆ ಹೆಚ್ಚು ಅವಲಂಬಿತವಾಗಿವೆ. Slack ಗೆ ಟ್ರೆಂಡ್ಗಳನ್ನು ಪೋಸ್ಟ್ ಮಾಡುವ ರಾತ್ರಿ ಸಮಯದ ಗುಣಮಟ್ಟದ ಕೆಲಸಕ್ಕೆ (nightly quality job) ಇವು ಅತ್ಯುತ್ತಮವಾಗಿವೆ. ಆದರೆ ಪಲ್ ರಿಕವೆಸ್ಟ್ (pull request) ಗಾಗಿ ಇವು ಸರಿಯಾದ ಬೌನ್ಸರ್ಸ್ಗಳಲ್ಲ. RAGAS ಅನ್ನು ನಿಮ್ಮ ಮರ್ಜ್ ಬ್ಲಾಕರ್ಸ್ಗಳಿಗಿಂತ (merge blockers), ನಿಗದಿತ ವಿಶ್ಲೇಷಣಾ ಪೈಪ್ಲೈನ್ಗೆ (scheduled analysis pipeline) ವರ್ಗಾಯಿಸಿ.
Arize Phoenix ಎಲಾಸ್ಟಿಕ್ ಲೈಸೆನ್ಸ್ 2.0 ಅನ್ನು ಹೊಂದಿದ್ದು, ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಉದ್ದೇಶವನ್ನು ಹೊಂದಿದೆ. ಇದು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಟ್ರೇಸಿಂಗ್ ಅನ್ನು ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಇದರಿಂದ ಒಂದು ಮಾಡೆಲ್ ಏಕೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ವರ್ತಿಸಿತು ಎಂಬುದನ್ನು ನೀವು ಗಮನಿಸಬಹುದು (observability). ಪ್ರೊಡಕ್ಷನ್ ಘಟನೆಯನ್ನು ಡಿಬಗ್ ಮಾಡುವಾಗ ಅಥವಾ ಹ್ಯಾಲ್ಯುಸಿನೇಶನ್ ಅನ್ನು (hallucination) ತಪ್ಪಾದ ರಿಟ್ರಿವಲ್ ಚಂಕ್ಗೆ ಹಿಂಬಾಲಿಸುವಾಗ ನಿಮಗೆ ಇದು ಬೇಕಾಗುತ್ತದೆ. ಆದರೆ ಒಬ್ಬ ಜೂನಿಯರ್ ಡೆವಲಪರ್ನ ಫೀಚರ್ ಬ್ರಾಂಚ್ ಅನ್ನು ಶಿಪ್ ಮಾಡಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಲು ನೀವು ಟ್ರೇಸಿಂಗ್ ಟೂಲ್ ಅನ್ನು ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ. ಇದರ ಆರ್ಕಿಟೆಕ್ಚರ್ ಒಳನೋಟಕ್ಕಾಗಿ (insight) ನಿರ್ಮಿಸಲಾಗಿದೆವೇ ಹೊರತು, ಬೈನರಿ ಗೇಟ್ಗಳಿಗಾಗಿ ಅಲ್ಲ.
MLflow Evaluate (Apache 2.0) ತನ್ನ ಹಿನ್ನೆಲೆಯನ್ನು ಎಕ್ಸ್ಪೆರಿಮೆಂಟ್ ಟ್ರ್ಯಾಕಿಂಗ್ನಿಂದ ಪಡೆದಿದೆ. ಇದು ತುಂಬಾ ಭಾರವಾಗಿದೆ (heavy). ಇದನ್ನು ಲೀನ್ CI ಇಮೇಜ್ಗೆ ಸೇರಿಸುವುದು ಸ್ಟಾರ್ಟ್ಅಪ್ ಸಮಯ ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು (dependencies) ಹೆಚ್ಚಿಸುತ್ತದೆ, ಇದು ಪ್ರತಿಯೊಂದು ಕೆಲಸವನ್ನೂ ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ನೀವು ಪೈಪ್ಲೈನ್ ಒಳಗೆ ಇದನ್ನು ಕಡ್ಡಾಯವಾಗಿ ಬಳಸಬೇಕೆಂದಿದ್ದರೆ, ಸ್ಟ್ರಕ್ಚರಲ್ ಚೆಕ್ಗಳಿಗಾಗಿ ಅದರ ہیಯೂರಿಸ್ಟಿಕ್ ಮೆಟ್ರಿಕ್ಗಳಿಗೆ (heuristic metrics) ಸೀಮಿತವಾಗಿರಿ. ಅಷ್ಟಾಗಿಯೂ, ನೀವು ಫ್ರೇಮ್ವರ್ಕ್ನ ಮೂಲಭೂತ ವಿನ್ಯಾಸದ ವಿರುದ್ಧ ಹೋರಾಡುತ್ತಿರುತ್ತೀರಿ. MLflow ವಾರಗಟ್ಟಲೆ ರನ್ಗಳನ್ನು ಲಾಗ್ ಮಾಡಲು ಮತ್ತು ಎಕ್ಸ್ಪೆರಿಮೆಂಟ್ಗಳನ್ನು ಹೋಲಿಸಲು ಬಯಸುತ್ತದೆ. ಆದರೆ ಮರ್ಜ್ ಕ್ಯೂ ಒಂದು ನಿಮಿಷದ ಒಳಗೇ ತೀರ್ಪನ್ನು ಬಯಸುತ್ತದೆ.
ಗೇಟಿಂಗ್ಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು
ಈ ಪ್ರಯೋಗದಿಂದ ನೀವು ಬೇರೇನನ್ನೂ ತೆಗೆದುಕೊಳ್ಳದಿದ್ದರೂ, ಈ ಮೂರು ನಿಯಮಗಳನ್ನು ನೆನಪಿಡಿ.
ಮೊದಲನೆಯದಾಗಿ, ವೈಬ್ (vibe) ಅಲ್ಲ, ಸ್ಟ್ರಕ್ಚರ್ ಅನ್ನು ಗೇಟ್ ಮಾಡಿ. ಔಟ್ಪುಟ್ ಸರಿಯಾದ JSON ಆಗಿರಬೇಕು ಎಂದು ನೀವು ಕಡ್ಡಾಯಗೊಳಿಸಬಹುದು. ಅದರಲ್ಲಿ ಅಗತ್ಯವಿರುವ ಕೀಗಳು (keys) ಇರಬೇಕು ಎಂದು ನೀವು ಕಡ್ಡಾಯಗೊಳಿಸಬಹುದು. ವರ್ಗೀಕರಣ ಲೇಬಲ್ (classification label) ಅನುಮತಿಸಲಾದ ಎನಮ್ (enum) ಗೆ ಸೇರಬೇಕು ಎಂದು ನೀವು ಕಡ್ಡಾಯಗೊಳಿಸಬಹುದು. ಈ ಪರಿசோதனೆಗಳು ವೇಗವಾಗಿವೆ, ಅಗ್ಗವಾಗಿವೆ ಮತ್ತು ನಿರ್ಣಾಯಕವಾಗಿವೆ (deterministic). ಸಾರಾಂಶವು "ಸ್ನೇಹಪರವಾಗಿದೆ" ಅಥವಾ ಮರುಬರಹವು "ಸೃಜನಶೀಲವಾಗಿದೆ" ಎಂದು ನೀವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕಡ್ಡಾಯಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂತಹ ಗುಣಗಳು ಮಾನವ ವಿಮರ್ಶೆ ಅಥವಾ ನಿಯತಕಾಲಿಕ ಬ್ಯಾಚ್ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ಗೆ ಸೇರಿದ್ದೇ ಹೊರತು, ಸ್ವಯಂಚಾಲಿತ ಗೇಟ್ಗಳಿಗೆ ಅಲ್ಲ.
ಎರಡನೆಯದಾಗಿ, ಬದಲಾಗದ ಇನ್ಪುಟ್ಗೆ ಸ್ಕೋರ್ ಬದಲಾಗುತ್ತಿದ್ದರೆ, ಅದನ್ನು ತಕ್ಷಣವೇ ಕೆಳಗಿಳಿಸಿ. ಒಂದೇ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ (artifact) ವಿರುದ್ಧ ನಿಮ್ಮ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಸೂಟ್ ಅನ್ನು ಎರಡು ಬಾರಿ ರನ್ ಮಾಡಿ. ಯಾವುದೇ ಮೆಟ್ರಿಕ್ ಪಾಸ್ನಿಂದ ಫೇಲ್ ಆಗಿ ಬದಲಾದರೆ, ಅದು ಮರ್ಜ್ ಅನ್ನು ತಡೆಯುವ ಹಕ್ಕನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದನ್ನು ವ್ಯತ್ಯಾಸಗಳು (variance) ನಿರೀಕ್ಷಿತ ಮತ್ತು ಸಹನೀಯವಾಗಿರುವ ಸಲಹಾ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗೆ (advisory dashboard) ವರ್ಗಾಯಿಸಿ.
ಮೂರನೆಯದಾಗಿ, ಎಕ್ಸಿಟ್ ಕೋಡ್ಗೆ (exit code) ಗೌರವ ನೀಡಿ. ಕೆಂಪು ಬ್ಯಾನರ್ ಹೊಂದಿರುವ ಸುಂದರವಾದ HTML ವರದಿಯು ಮರ್ಜ್ ಅನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಶೂನ್ಯವಲ್ಲದ (nonzero) ಎಕ್ಸಿಟ್ ಕೋಡ್ ಮಾತ್ರ ಅದನ್ನು ತಡೆಯುತ್ತದೆ. ನಿಮ್ಮ ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಟೂಲ್ ನಿಮ್ಮ CI ಪ್ಲಾಟ್ಫಾರ್ಮ್ನ ಮೂಲ ಭಾಷೆಯಲ್ಲಿ ಮಾತನಾಡಬೇಕು. ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಔಟ್ (Standard out) ಮನುಷ್ಯರಿಗಾಗಿ. ಎಕ್ಸಿಟ್ ಕೋಡ್ಗಳು ಯಂತ್ರಗಳಿಗಾಗಿ.
ಸಾರಾಂಶ
LLM ಚಾಲಿತ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಬೇಕೆಂದು ಕಂಡುಹಿಡಿಯುವಲ್ಲಿ ನಾವು ಇನ್ನೂ ಆರಂಭಿಕ ಹಂತದಲ್ಲಿದ್ದೇವೆ. ಇವ್ಯಾಲ್ಯೂಯೇಶನ್ ಅನ್ನು ಮಾನವನ ಗ್ರೇಡಿಂಗ್ ರೂಬ್ರಿಕ್ನಂತೆ (grading rubric) ಪರಿಗಣಿಸುವುದು ಒಂದು ಆಕರ್ಷಣೆಯಾಗಿರುತ್ತದೆ: ಸೂಕ್ಷ್ಮವಾದ, ಸಂದರ್ಭೋಚಿತ ಮತ್ತು ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ವ್ಯಕ್ತಿನಿಷ್ಠವಾದದ್ದು. ಇದು ಸಂಶೋಧನಾ ಪತ್ರಿಕೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ಮರ್ಜ್ ಕ್ಯೂನಲ್ಲಿ ಇದು ವಿಫಲವಾಗುತ್ತದೆ.
ಎಂಟು ತಿಂಗಳ ಪ್ರೊಡಕ್ಷನ್ ಟ್ರಾಫಿಕ್ ನಂತರ, ನನ್ನ ಪೈಪ್ಲೈನ್ ಈಗ ಸರ್ವಿಸ್ಗಳಾದ ಸ್ಟ್ರಕ್ಚರಲ್ ಮತ್ತು ಸ್ಕೀಮಾ ಅಸರ್ಶನ್ಗಳಿಗಾಗಿ (structural and schema assertions) Promptfoo ಅನ್ನು ಮತ್ತು ಪಾಸ್-ಫೇಲ್ ಕಂಡೀಷನ್ಗಳಿಗೆ ಸುಲಭವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವ ಪೈಥಾನ್-ಸೈಡ್ ಬಿಹೇವಿಯರಲ್ ಚೆಕ್ಗಳಿಗಾಗಿ (Python-side behavioral checks) DeepEval ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಉಳಿದೆಲ್ಲವೂ ರಾತ್ರಿ ಸಮಯದ ಡ್ಯಾಶ್ಬೋರ್ಡ್ಗಳಿಗೆ ವರದಿ ಮಾಡುತ್ತದೆ. ಕ್ಯೂ ಸ್ಥಿರವಾಗಿದೆ. ಸಿಗ್ನಲ್ ಸ್ಪಷ್ಟವಾಗಿದೆ. ತಂಡವು ಮತ್ತೆ ಕೆಂಪು ಬಿಲ್ಡ್ ಅನ್ನು (red build) ನಂಬುತ್ತದೆ.
ನಿಮ್ಮ ಗೇಟ್ನಲ್ಲಿ ನಿಮಗೆ ಹೆಚ್ಚಿನ ಮೆಟ್ರಿಕ್ಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಪ್ರತಿ ಬಾರಿಯೂ ಸತ್ಯವನ್ನು ಹೇಳುವ ಕಡಿಮೆ ಮೆಟ್ರಿಕ್ಗಳ ಅಗತ್ಯವಿದೆ.
Based on original testing and write-up shared on Dev.to. For more discussions on building reliable AI systems, join the GyaanSetu community on Telegram.