ನೀವು ಮಾಡೆಲ್‌ನ API ಅನ್ನು ಎಂದಿಗೂ ಕರೆಯದೆಯೇ, ಒಂದು LLM-ಚಾಲಿತ ಫೀಚರ್ ಮೇಲೆ 28 ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳನ್ನು (unit tests) ನಡೆಸಲು ತಂಡಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡುವ ಒಂದು ಆಂತರಿಕ ಸಾಧನವನ್ನು (internal tool) ನಿರ್ಮಿಸಿದ್ದೀರಿ. ನೀವು ಮಾಡೆಲ್ ಅನ್ನು ಒಂದು ಫೇಕ್ ಮಾಡಬಹುದಾದ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ (fakeable interface) ಸುತ್ತುವರಿಯುವ ಮೂಲಕ ಮತ್ತು ಮೂರು ಪದರಗಳ ನಿರ್ಧಾರಿತ (deterministic), ಹ್ಯೂರಿಸ್ಟಿಕ್ (heuristic) ಮತ್ತು LLM ಆಧಾರಿತ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಿದ್ದೀರಿ.

LLM ಗದ್ಯವನ್ನು (prose) ಸೃಷ್ಟಿಸಿದ ತಕ್ಷಣ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅಸರ್ಶನ್‌ಗಳು (standard assertions) ವಿಫಲವಾಗುತ್ತವೆ. ಒಂದೇ ಪ್ರಾಂಪ್ಟ್ ಪ್ರತಿ ಬಾರಿ ವಿಭಿನ್ನ ವಾಕ್ಯವನ್ನು ನೀಡಬಹುದು, ಆದ್ದರಿಂದ assertEqual(output, expected) ಮಾಡೆಲ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿದಾಗಲೂ ವಿಫಲತೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಎಂಜಿನಿಯರಿಂಗ್ ಗುಂಪುಗಳು ಫೀಚರ್ ಅನ್ನು ಯಾವುದೇ ಪರಿಶೀಲನೆಯಿಲ್ಲದೆ ಬಿಡುಗಡೆ ಮಾಡುತ್ತವೆ ಅಥವಾ ಮಾಡೆಲ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ, ಅಲ್ಲಿ ನಿರಂತರವಾಗಿ ಬದಲಾಗುವ ಗುರಿಯನ್ನು (shifting target) ಒಂದು ಸ್ಥಿರವಾದ ಲೈಬ್ರರಿಯಂತೆ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಈ ಸಮಸ್ಯೆಯು ಏಕೆ ಮುಖ್ಯ

LLMಗಳು ಈಗ ಗ್ರಾಹಕರಿಗೆ ಮುಖಾಮುಖಿಯಾಗಿರುವ ಕಾರ್ಯವಿprintlnಗಳಲ್ಲಿ (customer-facing workflows) ಇವೆ—ಇಮೇಲ್ ಸಂಪರ್ಕ, ಬೆಂಬಲ ಪ್ರತಿಕ್ರಿಯೆಗಳು (support replies), ಕಂಟೆಂಟ್ ಜನರೇಷನ್ ಇತ್ಯಾದಿ. ಒಂದು ಸಣ್ಣ ಭ್ರಮಿತ ಸತ್ಯ (hallucinated fact) ಅಥವಾ ಸೋರಿಕೆಯಾದ ಐಡೆಂಟಿಫೈಯರ್ ಬ್ರ್ಯಾಂಡ್ ಪ್ರತಿಷ್ಠೆಯನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದು, ಖಾಸಗಿ ಡೇಟಾವನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು ಅಥವಾ ಅನುಸರಣಾ ಉಲ್ಲಂಘನೆಗಳನ್ನು (compliance violations) ಉಂಟುಮಾಡಬಹುದು. ವಿಶ್ವಾಸಾರ್ಹ ಪರೀಕ್ಷಾ ತಂತ್ರವಿಲ್ಲದೆ, ತಂಡಗಳು ಅಸ್ಥಿರ ವಿಫಲತೆಗಳನ್ನು (flaky failures) ಪತ್ತೆಹಚ್ಚಲು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತವೆ ಅಥವಾ ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಬಗ್‌ಗಳನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತವೆ.

ವಿಧಾನ: ಮಾಡೆಲ್‌ನ ಜವಾಬ್ದಾರಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ

ಮೊದಲ ಹಂತವೆಂದರೆ LLM ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದು. ಲೇಖಕರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಮಾಡೆಲ್ ಕೇವಲ ಸಂಪರ್ಕ ಸಂದೇಶಗಳನ್ನು (outreach messages) ಸಿದ್ಧಪಡಿಸುತ್ತದೆ. ಎಲ್ಲಾ ರೂಟಿಂಗ್ ಲಾಜಿಕ್, ಸ್ಟೇಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಮತ್ತು ಸೇಫ್ಟಿ ಚೆಕ್‌ಗಳು ಸಾಮಾನ್ಯ ಕೋಡ್‌ನಲ್ಲಿಯೇ ಇರುತ್ತವೆ. ಮಾಡೆಲ್ ಅನ್ನು ಒಂದೇ, ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಔಟ್‌ಪುಟ್‌ಗೆ ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ, ಸುತ್ತಲಿನ ವ್ಯವಸ್ಥೆಯು ನಿರ್ಧಾರಿತವಾಗಿ (deterministic) ಮತ್ತು ಪರೀಕ್ಷಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಇರುತ್ತದೆ.

ಅದನ್ನು ಸಾಧ್ಯವಾಗಿಸಲು, LLM ಒಂದು ಪ್ರೊವೈಡರ್ ಇಂಟರ್ಫೇಸ್‌ನ ಹಿಂದೆ ಇರುತ್ತದೆ, ಇದು ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಫೇಕ್ ವರ್ಷನ್ ಅನ್ನು ಬಳಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಬಾಹ್ಯ API ಅನ್ನು ಕರೆಯುತ್ತದೆ; ಟೆಸ್ಟ್ ಸೂಟ್‌ನಲ್ಲಿ ಒಂದು ಲೈಟ್‌ವೇಯಿಟ್ ಫೇಕ್ (lightweight fake) ಸಿದ್ಧಪಡಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು (canned response) ನೀಡುತ್ತದೆ. ಉಳಿದ ಕೋಡ್ ಕೇವಲ ಇಂಟರ್ಫೇಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವುದರಿಂದ, ಇಡೀ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮುಟ್ಟದ ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳ ಮೂಲಕ ಪರೀಕ್ಷಿಸಬಹುದು. ಇದರ ಪರಿಣಾಮವಾಗಿ 28 ಟೆಸ್ಟ್‌ಗಳು ಪರಿಶೀಲಿಸುವ ಒಂದು ಊಹಿಸಬಹುದಾದ (predictable) ಕೋರ್ ಸಿಗುತ್ತದೆ.

ಒಂದು ಪ್ರಾಮಾಣಿಕ ಮೌಲ್ಯಮಾಪನ ಹಾರ್ನೆಸ್ (evaluation harness)

ವ್ಯಾಪ್ತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಿದರೂ ಸಹ, ಮಾಡೆಲ್‌ನ ಔಟ್‌ಪುಟ್ ನಿರ್ಧಾರಿತವಾಗಿರುವುದಿಲ್ಲ (nondeterministic). ಆದ್ದರಿಂದ ಲೇಖಕರು ಮೂರು ಪದರಗಳ ಮೌಲ್ಯಮಾಪನ ಹಾರ್ನೆಸ್ ಅನ್ನು ನಿರ್ಮಿಸಿದರು, ಪ್ರತಿಯೊಂದು ಪದರವು ವಿಭಿನ್ನ ರೀತಿಯ ಅಪಾಯವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

  • ಲೇಯರ್ 1 – ನಿರ್ಧಾರಿತ (Deterministic) ಪರಿசோதனೆಗಳು ಸರಳ ರೆಗ್ಯುಲರ್-ಎಕ್ಸ್‌ಪ್ರೆಶನ್ (regular-expression) ನಿಯಮಗಳು ತಪ್ಪು ಬಿಲ್ಡಿಂಗ್ ಐಡಿ ಅಥವಾ ನಿಷೇಧಿತ ಟೋಕನ್‌ಗಳಂತಹ ನಿರ್ದಿಷ್ಟ ತಪ್ಪುಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತವೆ. ಈ ಪರಿசோதனೆಗಳು ವೇಗವಾಗಿರುತ್ತವೆ ಮತ್ತು ಬೈನರಿ ಪಾಸ್/ಫೇಲ್ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತವೆ.

  • ಲೇಯರ್ 2 – ಹ್ಯೂರಿಸ್ಟಿಕ್ (Heuristic) ಪರಿசோதனೆಗಳು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಭ್ರಮಿತ ಸಂಖ್ಯೆಗಳು ಅಥವಾ ದಿನಾಂಕಗಳನ್ನು ಹುಡುಕುತ್ತವೆ, ಸ್ಪಷ್ಟವಾದ ಸತ್ಯಾಧಾರಿತ ಸುಳ್ಳುಗಳನ್ನು ಗುರುತಿಸುತ್ತವೆ. ಸಂಖ್ಯೆಯ ಸೂಚನೆಗಳಿಲ್ಲದ ಸುಳ್ಳು ಹೇಳಿಕೆಗಳನ್ನು ಇವು ಪತ್ತೆಹಚ್ಚಲು ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಲೇಖಕರು ಈ ಮಿತಿಯನ್ನು ಮುಕ್ತವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಾರೆ.

  • ಲೇಯರ್ 3 – LLM ಜಡ್ಜ್ (LLM judge) ಎರಡನೇ ಮಾಡೆಲ್ ಧಾಟಿ (tone) ಮತ್ತು ವೃತ್ತಿಪರತೆಯನ್ನು ರೇಟ್ ಮಾಡುತ್ತದೆ. ಈ ಹಂತವು ಮತ್ತೊಂದು ಸಂಭಾವ್ಯತೆಯ ವ್ಯವಸ್ಥೆಯನ್ನು (probabilistic system) ಅವಲಂಬಿಸಿರುವುದರಿಂದ, ನಿರ್ಧಾರಿತ ನಿಯಮಗಳು ಅಸಾಧ್ಯವಾದ ವಿಷಯಾತ್ಮಕ (subjective) ಅಂಶಗಳಿಗಾಗಿ ಇದನ್ನು ಮಾತ್ರ ಬಳಸಲಾಗುತ್ತದೆ.

ಹಾರ್ನೆಸ್‌ನ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಮೌಲ್ಯಮಾಪನಕ್ಕೆ ಬಳಸುವ ಡೇಟಾಸೆಟ್. ಲೇಖಕರು ತಿಳಿದಿರುವ ವಿಫಲತೆಯ ಮಾದರಿಗಳನ್ನು—ನಿರ್ದಿಷ್ಟ ಟ್ರ್ಯಾಪ್‌ಗಳು ಮತ್ತು ಡೊಮೇನ್ ಜ್ಞಾನವನ್ನು—ಎನ್ಕೋಡ್ ಮಾಡಿದ್ದಾರೆ, ಇದರಿಂದ ಹಾರ್ನೆಸ್ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಂಡುಬಂದ ತಪ್ಪುಗಳನ್ನೇ ನಿಖರವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತದೆ. ಇದು ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ಮಾಂತ್ರಿಕ ಸಾಧನವಲ್ಲ, ಬದಲಿಗೆ ಒಂದು ಗುರಿ ಹೊಂದಿದ ಸುರಕ್ಷತಾ ಜಾಲ (safety net).

ಇದು ತಂಡಗಳಿಗೆ ಏನನ್ನು ಸೂಚಿಸುತ್ತದೆ

  • LLM ನ ಕೆಲಸವನ್ನು ಸೀಮಿತವಾಗಿಡಿ. ಕಡಿಮೆ ಜವಾಬ್ದಾರಿಗಳು ಐಸೊಲೇಶನ್ ಮತ್ತು ಟೆಸ್ಟಿಂಗ್ ಅನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತವೆ.
  • ರೂಟಿಂಗ್, ಸ್ಟೇಟ್ ಮತ್ತು ಸೇಫ್ಟಿಯನ್ನು ಕೋಡ್‌ನಲ್ಲಿ ಇರಿಸಿ. ಸಾಂಪ್ರದಾಯಿಕ ಲಾಜಿಕ್ ನಿರ್ಧಾರಿತವಾಗಿ ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಪರೀಕ್ಷಿಸಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಇರುತ್ತದೆ.
  • ಫೇಕ್ ಮಾಡಬಹುದಾದ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಮಾಡೆಲ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಿ. ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳು ಬಾಹ್ಯ ಕರೆಗಳಿಲ್ಲದೆ ಚಲ運行ವಾಗುತ್ತವೆ, ಇದು ಟೆಸ್ಟ್ ಸೂಟ್ ಅನ್ನು ವೇಗವಾಗಿ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಡುತ್ತದೆ.
  • ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ಪದರಗಳಾಗಿ ವಿಂಗಡಿಸಿ. ನಿರ್ಧಾರಿತ ನಿಯಮಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ, ತಿಳಿದಿರುವ ಭ್ರಮೆಗಳಿಗಾಗಿ ಹ್ಯೂರಿಸ್ಟಿಕ್ಸ್ ಸೇರಿಸಿ ಮತ್ತು ವಿಷಯಾತ್ಮಕ ಗುಣಮಟ್ಟದ ಪರಿசோதனೆಗಳಿಗಾಗಿ LLM ಜಡ್ಜ್‌ಗಳನ್ನು ಮೀಸಲಿಡಿ.
  • ಮಿತಿಗಳನ್ನು ತಿಳಿಸಿ. ಯಾವುದೇ ಪದರವು ಪರಿಪೂರ್ಣತೆಯನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ; ನೀವು ಏನನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಪ್ರೋಗ್ರಾಂ ಮಾಡಿದ್ದೀರೋ ಅದನ್ನು ಮಾತ್ರ ಹಾರ್ನೆಸ್ ಪತ್ತೆಹಚ್ಚುತ್ತದೆ.

ವಿರೋಧಾಭಿಪ್ರಾಯ: ನೀವು ಇನ್ನೂ ಮಾಡೆಲ್ ಅನ್ನು ಯೂನಿಟ್-ಟೆಸ್ಟ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ

ಮಾಡೆಲ್ ಎಂಬುದು ನಿರಂತರವಾಗಿ ಬದಲಾಗುವ ಗುರಿ (moving target) ಎಂದು ಲೇಖಕರು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಾರೆ. LLM ಜಡ್ಜ್ ಪದರವು ಸಹ ಅದು ಅಳೆಯಲು ಪ್ರಯತ್ನಿಸುವ ಅದೇ ಅನಿರ್ಧಾರತೆಯನ್ನು (nondeterminism) ಹೊಂದಿರುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಪ್ರತಿ ಭ್ರಮೆ ಅಥವಾ ಪಾಲಿಸಿ ಉಲ್ಲಂಘನೆಯನ್ನು ಬಿಡುಗಡೆಗಿಂತ ಮೊದಲು ಪತ್ತೆಹಚ್ಚಲಾಗುವುದು ಎಂದು ಈ ವ್ಯವಸ್ಥೆಯು ಎಂದಿಗೂ ಖಾತರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ವಿಧಾನವು ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೋಗಲಾಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹೊಸ ವಿಫಲತೆಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದಂತೆ ಮೌಲ್ಯಮಾಪನ ಡೇಟಾವನ್ನು ಅಪ್‌ಡೇಟ್ ಆಗಿ ಇರಿಸುವ ತಂಡದ ಸಾಮರ್ಥ್ಯದ ಮೇಲೆ ಇದು ಅವಲಂಬಿತವಾಗಿದೆ.

ಸಾರಾಂಶ (Takeaway)

LLM ನ ನಿಖರವಾದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಖಚಿತಪಡಿಸುವ ಸಾಂಪ್ರದಾಯಿಕ ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಅನ್ನು ನೀವು ಬರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದರೆ ಮಾಡೆಲ್‌ನ ಪ್ರಭಾವವನ್ನು ಮಿತಿಗೊಳಿಸುವ, ಅದರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದಾದ ಮತ್ತು ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪದರಗಳ ಮೂಲಕ ಪಾರದರ್ಶಕವಾಗಿ ಪರಿಶೀಲಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀವು ನಿರ್ಮಿಸಬಹುದು. ಈ ಸಂಯೋಜನೆಯು ಅಸ್ಥಿರ ಘಟಕವನ್ನು (flaky component) ದೊಡ್ಡದಾದ, ಪರೀಕ್ಷಿಸಬಹುದಾದ ಅಪ್ಲಿಕೇಶನ್‌ನ ಊಹಿಸಬಹುದಾದ ಭಾಗವನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ.