ಮೌಲ್ಯಮಾಪನ-ಚಾಲಿತ ಏಜೆಂಟ್ ಅಭಿವೃದ್ಧಿ: ಕೇವಲ ಅನುಭವದ ಆಧಾರದ ಮೇಲೆ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಸರಿಪಡಿಸುವುದನ್ನು ನಾನು ಹೇಗೆ ನಿಲ್ಲಿಸಿದೆ

ನಾನು ಒಂದು ಪ್ರಾಂಪ್ಟ್ ಬದಲಾಯಿಸಿದೆ. ಮುಂದಿನ ರನ್ ಉತ್ತಮವಾಗಿ ಕಂಡಿತು. ಆ ಬದಲಾವಣೆಯು ಸಹಾಯ ಮಾಡಿತೇ ಅಥವಾ ನಾನು ಅದೃಷ್ಟವಂತನಾಗಿದ್ದೇನೆಯೇ?

ಬಹಳ ಕಾಲದವರೆಗೆ, ನನ್ನ ಉತ್ತರ "ಹಾಗೆ ಅನಿಸುತ್ತದೆ" ಎಂದೇ ಇತ್ತು. ನಾನು ಒಂದು ಕಮಾಂಡ್ ಅನ್ನು ಸ್ವಲ್ಪ ಬದಲಾಯಿಸುತ್ತಿದ್ದೆ, ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತಿದ್ದೆ, ಅದು ಯಶಸ್ವಿಯಾಗುವುದನ್ನು ಗಮನಿಸುತ್ತಿದ್ದೆ ಮತ್ತು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಿದ್ದೆ. ಇದು vibes-based engineering (ಅನುಭವದ ಆಧಾರಿತ ಎಂಜಿನಿಯರಿಂಗ್). ಏಜೆಂಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಇದನ್ನೇ ಮಾಡುತ್ತಾರೆ ಏಕೆಂದರೆ ಪರ್ಯಾಯ ಮಾರ್ಗಗಳು ಕಷ್ಟವೆನಿಸುತ್ತವೆ.

ಆದರೆ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳು non-deterministic (ನಿರ್ದಿಷ್ಟವಲ್ಲದ). ನೀವು ಒಂದೇ ಕಾರ್ಯವನ್ನು ಎರಡು ಬಾರಿ ಮಾಡಬಹುದು ಮತ್ತು ಎರಡು ವಿಭಿನ್ನ ಫಲಿತಾಂಶಗಳನ್ನು ಪಡೆಯಬಹುದು. ಒಂದು ಉತ್ತಮ ರನ್ ನಿಮಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ನಿಮ್ಮ ಬದಲಾವಣೆ ಕೆಲಸ ಮಾಡಿತೇ ಅಥವಾ ಕೇವಲ ಅದೃಷ್ಟದಿಂದ ಫಲಿತಾಂಶ ಬಂದಿತೇ ಎಂದು ನೀವು ಹೇಳಲು ಸಾಧ್ಯವಿಲ್ಲ.

ನಾನು ಮೆಷಿನ್ ಲರ್ನಿಂಗ್ ಶಿಸ್ತನ್ನು ಬಳಸುವ ಮೂಲಕ ಇದನ್ನು ಪರಿಹರಿಸಿದೆ. ನನ್ನ ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಒಳಗೊಳ್ಳಲು ನಾನು ಒಂದು ಮೌಲ್ಯಮಾಪನ ಚೌಕಟ್ಟನ್ನು (evaluation framework) ನಿರ್ಮಿಸಿದೆ.

ಈ ಚೌಕಟ್ಟು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದು ಇಲ್ಲಿದೆ:

• Target: ಸ್ಥಿರವಾದ ಕೋಡ್ ಬೇಸ್‌ಕೋಡ್ (frozen codebase). ಸ್ಕೋರ್‌ಗಳು ಹೋಲಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಇದು ಬದಲಾಗದೆ ಇರುತ್ತದೆ. • Task: ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ಒರಾಕಲ್ (oracle) ಹೊಂದಿರುವ ಒಂದು ನಿರ್ದಿಷ್ಟ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಐಟಂ. • Oracle: ಒಂದು ನಿರ್ದಿಷ್ಟ ಪರಿಶೀಲನೆ (deterministic check). ಇವು ಕಡ್ಡಾಯವಾಗಿ ಪಾಸಾಗಬೇಕಾದ ಶೆಲ್ ಕಮಾಂಡ್‌ಗಳು. • Variant: ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ನಿರ್ದಿಷ್ಟ ಬದಲಾವಣೆ, ಉದಾಹರಣೆಗೆ ಹೊಸ ಪ್ಲಾನರ್. • Trial: ಒಂದು ಏಕೈಕ ರನ್. ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು (randomness) ಪರಿಗಣಿಸಲು ನಾನು ಪ್ರತಿಯೊಂದು ಕಾರ್ಯವನ್ನು ಹಲವಾರು ಬಾರಿ ರನ್ ಮಾಡುತ್ತೇನೆ.

ವಿಭಿನ್ನ ವೈಫಲ್ಯಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಾನು ಎರಡು ರೀತಿಯ ಸ್ಕೋರಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತೇನೆ:

  • Code Graders (Deterministic): ಇವು ಟೆಸ್ಟ್ ಪಾಸ್ ದರಗಳು, ವೆಚ್ಚ, ಸಮಯ ಮತ್ತು ಫೈಲ್ ಬದಲಾವಣೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತವೆ.
  • LLM Judge (Probabilistic): ಒಂದು ಪ್ರತ್ಯೇಕ, ಸ್ಥಿರವಾದ ಮಾಡೆಲ್ ಸ್ಪೆಕ್ ಕ್ವಾಲಿಟಿ ಮತ್ತು ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಫಿಡೆಲಿಟಿಯನ್ನು ಸ್ಕೋರ್ ಮಾಡುತ್ತದೆ.

ಕೋಡ್ ಗ್ರೇಡರ್‌ಗಳು ಕೋಡ್ ರನ್ ಆಗುತ್ತದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತವೆ. ಜಡ್ಜ್ ಕೋಡ್ ಉತ್ತಮವಾಗಿದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತದೆ. ನಿಮಗೆ ಎರಡೂ ಬೇಕು.

ನಾನು ಸರಾಸರಿಗಳನ್ನು (averages) ಬಳಸುವುದನ್ನು ಕೂಡ ನಿಲ್ಲಿಸಿದೆ. ಸರಾಸರಿಗಳು ಏಜೆಂಟ್‌ಗಳ ಬಗ್ಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತವೆ. ಒಂದು ಕಾರ್ಯವು 3 ರಲ್ಲಿ 2 ಬಾರಿ ಯಶಸ್ವಿಯಾದರೆ, ಅದು ಸರಿಯಾಗಿರುವಂತೆ ಕಾಣುತ್ತದೆ. ಆದರೆ ಅದು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ. ಬದಲಾಗಿ, ನಾನು ಎರಡು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತೇನೆ:

  • pass@k: ಏಜೆಂಟ್ ಕನಿಷ್ಠ ಒಂದು ಬಾರಿಯಾದರೂ ಯಶಸ್ವಿಯಾಯಿತೇ? (ಸಾಮರ್ಥ್ಯ - Capability)
  • pass^k: ಏಜೆಂಟ್ ಪ್ರತಿ ಬಾರಿಯೂ ಯಶಸ್ವಿಯಾಯಿತೇ? (ವಿಶ್ವಾಸಾರ್ಹತೆ - Reliability)

pass^k ನಲ್ಲಿನ ಏರಿಕೆ ನಿಜವಾದ ಗೆಲುವು. ಇದರರ್ಥ ನೀವು ಏಜೆಂಟ್ ಅನ್ನು ಕೇವಲ ಅದೃಷ್ಟವಂತನನ್ನಾಗಿ ಮಾಡಿಲ್ಲ, ಬದಲಾಗಿ ಸ್ಥಿರವಾಗಿರುವಂತೆ ಮಾಡಿದ್ದೀರಿ.

ವ್ಯವಸ್ಥೆಯನ್ನು ಚುರುಕಾಗಿಡಲು, ನಾನು ಆಳವಾದ ತಿಳುವಳಿಕೆಯ ಅಗತ್ಯವಿರುವ ಕಠಿಣ ಕಾರ್ಯಗಳನ್ನು ಸೇರಿಸುತ್ತೇನೆ. ಒಂದು ಏಜೆಂಟ್ ನೈಜ ಬಗ್‌ನಲ್ಲಿ ವಿಫಲವಾದಾಗ, ನಾನು ಆ ವೈಫಲ್ಯವನ್ನು ಶಾಶ್ವತ ಕಾರ್ಯವನ್ನಾಗಿ ಮಾಡುತ್ತೇನೆ. ಇದು ಒಂದು ಕ್ಲೋಸ್ಡ್ ಲೂಪ್ (closed loop) ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಉತ್ತಮವಾಗುತ್ತಿದ್ದಂತೆ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಕಠಿಣವಾಗುತ್ತಾ ಹೋಗುತ್ತದೆ.

ಈ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ಮಿಸುವುದು ತುಂಬಾ ಕೆಲಸದ ವಿಷಯವಾಗಿದೆ, ಆದರೆ ನಾನು ನಿರ್ಮಿಸಿದ ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ಪ್ರಭಾವ ಬೀರುವ (highest leverage) ವಿಷಯ ಇದಾಗಿದೆ. ಇದು "ಇದು ಉತ್ತಮವಾಗಿದೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ" ಎಂಬುದನ್ನು "ಇದು ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲಿ 20% ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ" ಎಂಬುದನ್ನಾಗಿ ಬದಲಾಯಿಸಿತು.

ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ಪ್ರದರ್ಶಿಸುವುದು (demo) ಸುಲಭ, ಆದರೆ ಅವುಗಳನ್ನು ನಂಬುವುದು ಕಷ್ಟ. ನೀವು ಕೇವಲ ಪ್ರದರ್ಶನಗಳಿಗಿಂತ ಮುಂದೆ ಹೋಗಬೇಕೆಂದರೆ, ನೀವು ಅಳತೆ ಮಾಡಲು (measure) ನಿರ್ಧರಿಸಬೇಕು.

ಮೂಲ: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: https://t.me/GyaanSetuAi