ದೀರ್ಘ ಕಾಲಾವಧಿಯ ಮಾಡೆಲ್ಗಳ ಯುಗದಲ್ಲಿ ಸುರಕ್ಷತೆ ಮತ್ತು ಅಲೈನ್ಮೆಂಟ್
ದೀರ್ಘಕಾಲ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಾಡೆಲ್ನ ಆಂತರಿಕ ಬಳಕೆ ನಮಗೆ ಸುರಕ್ಷತೆ ಬಗ್ಗೆ ಕಲಿಸಿದುದು.
ಸಾರಾಂಶ
ದೀರ್ಘಕಾಲ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಾಡೆಲ್ಗಳು ಕಷ್ಟಕರ, ಮುಕ್ತ ಅಂತ್ಯದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು; ಆದರೆ ಅವುಗಳ ನಿರಂತರತೆ ಅನಗತ್ಯ ಕ್ರಿಯೆಗಳನ್ನು ಕೈಗೊಳ್ಳಲು ಹೆಚ್ಚಿನ ಅವಕಾಶಗಳನ್ನು ನೀಡುತ್ತದೆ.
ದೀರ್ಘಕಾಲದ ಕೆಲಸಗಳಿಗಾಗಿ ತರಬೇತಿಗೊಂಡ ಮಾಡೆಲ್ನ ಮಿತಿಗೊಳಿಸಿದ ಆಂತರಿಕ ಬಳಕೆಯ ವೇಳೆ, ನಮ್ಮ ಈಗಿನ ಪೂರ್ವ-ನಿಯೋಜನಾ ಮೌಲ್ಯಮಾಪನಗಳು ಹಿಡಿಯದ ಹೊಸ ವೈಫಲ್ಯಗಳನ್ನು ಗಮನಿಸಿ ಪ್ರವೇಶವನ್ನು ವಿರಮಿಸಿದೆವು. ನಂತರ ಈ ವೈಫಲ್ಯಗಳಿಂದ ಪಡೆದ ಒಳನೋಟಗಳನ್ನು ಬಳಸಿ ಹೊಸ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ನಿರ್ಮಿಸಿದೆವು, ದೀರ್ಘ ಕಾಲಾವಧಿಯ ಅಲೈನ್ಮೆಂಟ್ ಸುಧಾರಿಸಿದೆವು, ಪಥ-ಮಟ್ಟದ ಮೇಲ್ವಿಚಾರಣೆ ಸೇರಿಸಿದೆವು, ಮತ್ತು ಮಿತಿಗೊಳಿಸಿದ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಮೊದಲು ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಗೋಚರತೆ ಹಾಗೂ ನಿಯಂತ್ರಣ ನೀಡಿದೆವು.
ಈ ಅನುಭವವು ಹಂತ ಹಂತದ ನಿಯೋಜನೆಯ ಮೌಲ್ಯವನ್ನು ಮತ್ತಷ್ಟು ದೃಢಪಡಿಸಿತು. ಯಾವುದೇ ನಿಶ್ಚಿತ ಮೌಲ್ಯಮಾಪನ ಸಮೂಹವು ಪ್ರತಿಯೊಂದು ವರ್ತನೆಯನ್ನು ಊಹಿಸಲಾರದು; ಆದ್ದರಿಂದ ಪೂರ್ವ-ನಿಯೋಜನಾ ಪರೀಕ್ಷೆಗೆ ನಿಕಟ ಮೇಲ್ವಿಚಾರಣೆ, ಮಧ್ಯಪ್ರವೇಶಿಸಬಲ್ಲ ರಕ್ಷಣಾ ಕ್ರಮಗಳು, ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ವಿರಮಿಸುವ ಅಥವಾ ಹಿಂದಕ್ಕೆ ಸರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಜೋಡಿಸಬೇಕು.
ದೀರ್ಘ ಅವಧಿಗಳವರೆಗೆ ಸ್ವಾಯತ್ತವಾಗಿ ಕೆಲಸ ಮಾಡಬಲ್ಲ ಮಾಡೆಲ್ಗಳು ಕಷ್ಟಕರ, ಮುಕ್ತ ಅಂತ್ಯದ ಸಮಸ್ಯೆಗಳನ್ನು ಕೈಗೆತ್ತಿಕೊಳ್ಳಬಹುದು. ಆದರೆ ಅವುಗಳನ್ನು ಉಪಯುಕ್ತವಾಗಿಸುವ ಅದೇ ನಿರಂತರತೆ ಅವುಗಳಿಗೆ ಅನಗತ್ಯ ಕ್ರಿಯೆಗಳನ್ನು ಕೈಗೊಳ್ಳಲು ಹೆಚ್ಚಿನ ಅವಕಾಶಗಳನ್ನು ನೀಡುತ್ತದೆ—ಮತ್ತು ಕಡಿಮೆ ಕಾಲಾವಧಿಯ ಮಾಡೆಲ್ಗಳಿಗೆ ಉದ್ದೇಶಿಸಿದ ಮೌಲ್ಯಮಾಪನಗಳು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದಾದ ರೀತಿಯಲ್ಲಿ ಅವು ಹೀಗೆ ಮಾಡಬಹುದು.
ಸುಮಾರು ಎರಡು ತಿಂಗಳ ಹಿಂದೆ, ಆಂತರಿಕ ಸಾಮಾನ್ಯ-ಉದ್ದೇಶದ ಮಾಡೆಲ್ Erdős unit distance conjecture ಅನ್ನು ತಪ್ಪೆಂದು ತೋರಿಸಿದೆ ಎಂದು ನಾವು ಘೋಷಿಸಿದ್ದೇವೆ. ಈ ಮಾಡೆಲ್ ಅನ್ನು ಬಹಳ ದೀರ್ಘ ಅವಧಿಗಳವರೆಗೆ ಸ್ವಾಯತ್ತವಾಗಿ ಕೆಲಸ ಮಾಡಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿತ್ತು. ಮಿತಿಗೊಳಿಸಿದ, ಮೇಲ್ವಿಚಾರಣೆಯೊಳಗಿನ ಆಂತರಿಕ ಬಳಕೆಯ ವೇಳೆ, ನಮ್ಮ ಈಗಿನ ನಿಯೋಜನಾ ಮೌಲ್ಯಮಾಪನಗಳು ಹಿಡಿಯದ ಅನಗತ್ಯ ವರ್ತನೆಯನ್ನು ನಾವು ಗಮನಿಸಿದೆವು. ನಿಯೋಜನೆ ಮಿತಿಗೊಳಿಸಿ ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿದ್ದುದರಿಂದ, ಈ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು, ಪ್ರವೇಶವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಲ್ಲಿಸಲು, ಕಂಡದ್ದರ ಆಧಾರದ ಮೇಲೆ ಹೊಸ ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ರಚಿಸಲು, ಮಾಡೆಲ್ ಮತ್ತು ಅದರ ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಬಲಪಡಿಸಲು, ನಂತರ ನಿರಂತರ ಮೇಲ್ವಿಚಾರಣೆಯೊಂದಿಗೆ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಯಿತು.
ನಾವು ಮಾಡೆಲ್ಗಳನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಪರಿಸ್ಥಿತಿಗಳು ನೈಜ ಬಳಕೆಯಲ್ಲಿ ಅವು ಎದುರಿಸುವ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ಎಂದಿಗೂ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ನಿಯೋಜನೆಗೆ ಮುಂಚಿನ ಮೌಲ್ಯಮಾಪನಗಳಿಗೆ ಮಿತಿಗೊಳಿಸಿದ, ಮೇಲ್ವಿಚಾರಣೆಯ ನಿಯೋಜನೆಯನ್ನು ಮತ್ತು ಸಮಸ್ಯೆಗಳು ಕಂಡುಬಂದಾಗ ಮಧ್ಯಪ್ರವೇಶಿಸಲು, ವಿರಮಿಸಲು ಅಥವಾ ಹಿಂದಕ್ಕೆ ಸರಿಸಲು ಸಾಮರ್ಥ್ಯವನ್ನು ಜೋಡಿಸಬೇಕು. ನಿಯೋಜನೆಯಿಂದ ನಾವು ಕಲಿಯುವುದನ್ನು, ಪ್ರವೇಶವನ್ನು ವಿಸ್ತರಿಸುವ ಮೊದಲು ಇನ್ನಷ್ಟು ಬಲವಾದ ಮೌಲ್ಯಮಾಪನಗಳು ಮತ್ತು ರಕ್ಷಣಾ ಕ್ರಮಗಳ ಭಾಗವನ್ನಾಗಿಸಬಹುದು.
ಮುಂದಿನ ವಿಭಾಗಗಳಲ್ಲಿ, ನಾವು ಗಮನಿಸಿದುದರ ಸ್ಪಷ್ಟ ಉದಾಹರಣೆಗಳು, ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸಿದೆವು, ಮತ್ತು ಈ ಅನುಭವ ಭವಿಷ್ಯದ ಬಿಡುಗಡೆಗಳನ್ನು ಹೇಗೆ ರೂಪಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.
ಹೊಸ ಮಾಡೆಲ್ ದೀರ್ಘ ಅವಧಿಯಲ್ಲಿ ಮರುಮರು ಪ್ರಯತ್ನಗಳ ಮೂಲಕ ಗುರಿಯತ್ತ ಕೆಲಸ ಮುಂದುವರಿಸಬಲ್ಲದು. ಅದೇ ನಿರಂತರತೆ ತನ್ನ ಪರಿಸರದಲ್ಲಿನ ದುರ್ಬಲತೆಗಳನ್ನು ಕಂಡುಹಿಡಿದು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳಲು ಕಾರಣವಾಗಬಹುದು. ಹಿಂದಿನ ಮಾಡೆಲ್ಗಳು sandboxing ಅಥವಾ ಪರಿಸರದ ನಿರ್ಬಂಧಗಳನ್ನು ಎದುರಿಸಿದಾಗ, ಸರಳವಾಗಿ ನಿಂತು ಬಳಕೆದಾರರ ಬಳಿಗೆ ಮರಳುತ್ತಿದ್ದವು. ಈ ಮಾಡೆಲ್ ಅನೇಕ ಬಾರಿ ಪ್ರಯತ್ನವನ್ನು ಮುಂದುವರಿಸಿತು; ತನ್ನ sandbox ಹೊರಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಾರ್ಗಗಳನ್ನು ಹುಡುಕುವುದೂ ಅದರಲ್ಲಿ ಸೇರಿತ್ತು.
ಇದಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆ NanoGPT speedrun(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮೇಲಿನ ಆಂತರಿಕ ಮೌಲ್ಯಮಾಪನದ ವೇಳೆ ಕಂಡುಬಂದಿತು; ಇದು ಸಣ್ಣ ಭಾಷಾ ಮಾಡೆಲ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ಹಂತಗಳಲ್ಲಿ ತರಬೇತಿಗೊಳಿಸುವ ಸಾರ್ವಜನಿಕ ಬೆಂಚ್ಮಾರ್ಕ್ ಆಗಿದೆ. ನಮ್ಮ ಮಾಡೆಲ್ PowerCool ಎಂಬ power-law learning-rate cooldown ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿತು, ಇದರಿಂದ ಗಮನಾರ್ಹ ಸುಧಾರಣೆ ಕಂಡುಬಂತು. ಫಲಿತಾಂಶಗಳನ್ನು Slack ಗೆ ಮಾತ್ರ ಪೋಸ್ಟ್ ಮಾಡಲು ಮಾಡೆಲ್ಗೆ ಸೂಚಿಸಲಾಗಿತ್ತು, ಆದರೆ NanoGPT ಸೂಚನೆಗಳು ಫಲಿತಾಂಶಗಳನ್ನು GitHub ಗೆ PR ಆಗಿ ಪೋಸ್ಟ್ ಮಾಡಲು ಹೇಳುತ್ತವೆ; ಮಾಡೆಲ್ ನಂತರದ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ ಸಾರ್ವಜನಿಕ GitHub ರಿಪೊಸಿಟರಿಯಲ್ಲಿ PR #287 ತೆರೆಯಿತು. ಬಾಹ್ಯ ಪ್ರವೇಶವನ್ನು ತಡೆಯಲು ವಿನ್ಯಾಸಗೊಳಿಸಿದ sandbox ನಿರ್ಬಂಧಗಳನ್ನು ಮಾಡೆಲ್ ತಪ್ಪಿಸಿಕೊಂಡು, GitHub ಗೆ ಅಪ್ಲೋಡ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಿತು. PR ಮಾಡಲು sandbox ನಲ್ಲಿ ದುರ್ಬಲತೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಮ್ಮ ಮಾಡೆಲ್ಗೆ ಒಂದು ಗಂಟೆ ಬೇಕಾಯಿತು; ಹಿಂದಿನ ಮಾಡೆಲ್ಗಳು ಕಡಿಮೆ ನಿರಂತರವಾಗಿದ್ದವು ಮತ್ತು ದುರ್ಬಲತೆಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ, ಬದಲಿಗೆ PR ಭಾಗವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟವು.1
AI ಸಹಾಯಕರಿಗಾಗಿ ಅನೇಕ ಸುರಕ್ಷತಾ ನಿಯಂತ್ರಣಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕ್ರಿಯೆಗಳ ಸುತ್ತ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಒಂದು ಕ್ರಿಯೆಗೆ ಅನುಮತಿ ಇಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ತಡೆಯಲಾಗುತ್ತದೆ. ಅದು ಸಂವೇದನಾಶೀಲವಾಗಿದ್ದರೆ, ವ್ಯವಸ್ಥೆ ಬಳಕೆದಾರರಿಂದ ಸ್ಪಷ್ಟ ಅನುಮೋದನೆ ಕೇಳುತ್ತದೆ. ಆದರೆ ಗಂಟೆಗಳು, ದಿನಗಳು ಅಥವಾ ವಾರಗಳವರೆಗೂ ಸ್ವಾಯತ್ತವಾಗಿ ಕ್ರಿಯೆಗಳು ಮುಂದುವರಿಯಬಹುದಾದ ದೀರ್ಘಕಾಲದ ಮಾಡೆಲ್ಗಳು ಈ ವ್ಯವಸ್ಥೆಗೆ ಸವಾಲಾಗುತ್ತವೆ: ಪ್ರತ್ಯೇಕ ಕ್ರಿಯೆಗಳ ಮೇಲ್ವಿಚಾರಣೆ ಒಟ್ಟಾರೆ ಪಥದ ಉದ್ದೇಶವನ್ನು ಹಾದಿ ಹಿಡಿಯಲು ಇನ್ನು ಸಾಕಾಗುವುದಿಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ಸಮಸ್ಯೆಯೊಂದನ್ನು ಪರಿಹರಿಸಲು ಮಾದರಿಯನ್ನು (model) ಕೇಳಿದ ಸನ್ನಿವೇಶವೊಂದರಲ್ಲಿ, ಇತರ ಸಿಸ್ಟಮ್ಗಳು ಯಶಸ್ವಿಯಾದ ಆದರೆ ಗೌಪ್ಯವಾಗಿಟ್ಟಿದ್ದ ಸಬ್ಮಿಷನ್ಗಳನ್ನು (submissions) ಹೊಂದಿರುವುದನ್ನು ಮಾದರಿಯು ಗಮನಿಸಿತು ಮತ್ತು ಇವ್ಯಾಲ್ಯೂಯೇಷನ್ ಬ್ಯಾಕೆಂಡ್ನಿಂದ (evaluation backend) ಆ ಪರಿಹಾರಗಳನ್ನು ಮರುಪಡೆಯಲು ಪ್ರಯತ್ನಿಸಿತು. ಅಥೆಂಟಿಕೇಶನ್ ಟೋಕನ್ (authentication token) ಅನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಸ್ಕ್ಯಾನರ್ನಿಂದಾಗಿ ಅದರ ಮೊದಲ ಪ್ರಯತ್ನವು ವಿಫಲಗೊಂಡಾಗ, ಮಾದರಿಯು ಟೋಕನ್ ಅನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಿತು, ಅವುಗಳನ್ನು ಅಸ್ಪಷ್ಟಗೊಳಿಸಿತು (obfuscated) ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ (runtime) ಆ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ಮತ್ತೆ ಜೋಡಿಸಿತು; ಇದರಿಂದಾಗಿ ಸಂಪೂರ್ಣ ಟೋಕನ್ ಎಂದಿಗೂ ಒಂದೇ ಸತತ ಸ್ಟ್ರಿಂಗ್ (contiguous string) ಆಗಿ ಗೋಚರಿಸಲಿಲ್ಲ. ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ತಪ್ಪಿಸಲು (circumvent) ತಾನು ಈ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಿರುವುದಾಗಿ ಮಾದರಿಯು ಬಳಕೆದಾರರಿಗೆ ನೀಡಿದ ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ಮತ್ತು ತನ್ನ ಆಲೋಚನಾ ಪ್ರಕ್ರಿಯೆಯ ದಾಖಲೆಗಳಲ್ಲಿ (reasoning traces) ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಿತ್ತು.
ಪ್ರತಿ ಹಂತವು (step) ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿ ಕಂಡರೂ, ಆ ಇಡೀ ಸರಣಿಯು (sequence) ಅನುಮೋದಿಸಲಾಗದಂತಹ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಹೇಗೆ ನೀಡಬಲ್ಲದು ಎಂಬುದನ್ನು ಈ ಉದಾಹರಣೆಯು ತೋರಿಸುತ್ತದೆ. ಸುದೀರ್ಘ ಕಾಲಾವಧಿಯಲ್ಲಿ (long time horizons) ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಾದರಿಯು (model), ಅನುಮೋದನಾ ವ್ಯವಸ್ಥೆಯ ಲೋಪದೋಷಗಳನ್ನು (blind spots) ಹೇಗೆ ಅರಿತುಕೊಂಡು ತನ್ನ ಗುರಿಗಳನ್ನು ಸಾಧಿಸಲು ಅವುಗಳನ್ನು ದಾಟಿ ಕೆಲಸ ಮಾಡಬಲ್ಲದು ಎಂಬುದನ್ನೂ ಇದು ತೋರಿಸುತ್ತದೆ. ಸುದೀರ್ಘ ಕಾಲಾವಧಿಯ ಸುರಕ್ಷತೆಗೆ ಕೇವಲ "ಈ ಕ್ರಮಕ್ಕೆ ಅನುಮತಿ ಇದೆಯೇ?" ಎಂದು ಕೇಳುವುದು ಮಾತ್ರವಲ್ಲದೆ, "ಈ ಕ್ರಮಗಳ ಸರಣಿಯು ಯಾವ ಫಲಿತಾಂಶದ ಕಡೆಗೆ ಸಾಗುತ್ತಿದೆ?" ಎಂದು ಕೇಳುವುದೂ ಸಹ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ.
ಇಂತಹ ಘಟನೆಗಳ ಕಾರಣ, ಹೊಸ ಮಾಡೆಲ್ನ ಆಂತರಿಕ ನಿಯೋಜನೆಯನ್ನು ನಾವು ವಿರಮಿಸಿದೆವು. ಸುರಕ್ಷತಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಾವು defense in depth ಮತ್ತು ಪಥ-ಮಟ್ಟದ ಮೇಲ್ವಿಚಾರಣೆ ಸುತ್ತ ಮರುನಿರ್ಮಿಸಿದೆವು.
- ಘಟನೆಗಳಿಂದ ಪಡೆದ ಮೌಲ್ಯಮಾಪನಗಳು. ವಾಸ್ತವವಾಗಿ ನಿಯೋಜಿಸುವ ಮೊದಲು ಒಂದು ವ್ಯವಸ್ಥೆ ನಿಯೋಜಿಸಲು ಸುರಕ್ಷಿತವೇ ಎಂಬ ಅಂದಾಜನ್ನು ಮೌಲ್ಯಮಾಪನಗಳು ನಮಗೆ ನೀಡಬಹುದು. ಆದರೆ ಹೆಚ್ಚು ಉಪಯುಕ್ತವಾಗಲು, ಮೌಲ್ಯಮಾಪನವು ನೈಜ ನಿಯೋಜನೆಯಲ್ಲಿನ ಪಥಗಳ ವಿತರಣೆ ಮತ್ತು ಕಾಲಾವಧಿಯ ಉದ್ದವನ್ನು ಪ್ರತಿಬಿಂಬಿಸಬೇಕು. ಈ ಕಾರಣದಿಂದ, ಗಮನಿಸಿದ ವೈಫಲ್ಯಗಳನ್ನು ಬಳಸಿ ನಾವು adversarial ಮೌಲ್ಯಮಾಪನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದೆವು. ನೈಜ-ಜಗತ್ತಿನ ಘಟನೆಗಳಿಂದ ಪಡೆದ ಮೌಲ್ಯಮಾಪನಗಳಲ್ಲಿ ಸುಧಾರಣೆ ಮಾಡಿದಾಗ, production ನಲ್ಲಿ ನಿಯೋಜಿಸಿದ ನಂತರ ವರ್ತನೆ ಇನ್ನಷ್ಟು ಸುರಕ್ಷಿತವಾಯಿತು ಎಂದು ನಾವು ಕಂಡೆವು.
- ಸುಧಾರಿತ ಅಲೈನ್ಮೆಂಟ್. ಬಳಕೆದಾರರ ಗುರಿಯನ್ನು ಹಿಂಬಾಲಿಸುವಾಗ ಅನುಮತಿಯಿಲ್ಲದೆ ಅನಗತ್ಯ ಕ್ರಿಯೆಗಳನ್ನು ಕೈಗೊಳ್ಳುವ ಅದರ ಪ್ರವೃತ್ತಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಂಡೆವು. ಉದಾಹರಣೆಗೆ, ದೀರ್ಘ ರೋಲ್ಔಟ್ಗಳಲ್ಲಿ ಸೂಚನೆಗಳನ್ನು ನೆನಪಿಡುವುದರಲ್ಲಿ ನಮ್ಮ ಮಾಡೆಲ್ಗಳು ದುರ್ಬಲವಾಗಿದ್ದವು; ಈ ಸಾಮರ್ಥ್ಯಕ್ಕಾಗಿ ಮಾಡೆಲ್ ಅನ್ನು ತರಬೇತಿಗೊಳಿಸಿದಾಗ, ದೀರ್ಘ ರೋಲ್ಔಟ್ಗಳಲ್ಲೂ ಅಲೈನ್ ಆಗಿ ಉಳಿಯುವ ಮಾಡೆಲ್ ದೊರಕಿತು.
- ಸಕ್ರಿಯ ಮೇಲ್ವಿಚಾರಣೆ. ಮಾಡೆಲ್ನ ಬದಲಾಗುತ್ತಿರುವ ಪಥವನ್ನು ಪರಿಶೀಲಿಸಿ, ಅದು ಬಳಕೆದಾರರ ನಿರ್ಬಂಧ ಅಥವಾ ಸುರಕ್ಷತಾ ಗಡಿಯನ್ನು ಮೀರುತ್ತಿದೆಯೇ ಎಂಬ ಸೂಚನೆಗಳನ್ನು ಹುಡುಕುವ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಾವು ರಚಿಸಿದೆವು. ಮೇಲ್ವಿಚಾರಕವು ಒಂದೇ ಕ್ರಿಯೆಯನ್ನು ಮಾತ್ರವಲ್ಲ, ಸಂಪೂರ್ಣ ಪಥವನ್ನು ಗಮನಿಸುತ್ತದೆ. ಮುಖ್ಯವಾಗಿ, ಮೇಲ್ವಿಚಾರಕವು session ಅನ್ನು ವಿರಮಿಸಿ, ಇನ್ನಷ್ಟು ಹತ್ತಿರದಿಂದ ಪರಿಶೀಲಿಸಲು ಬಳಕೆದಾರರಿಗೆ ಎಚ್ಚರಿಸಬಹುದು. ಪರಿಶೀಲಿಸಿದ ನಂತರ, ಮೇಲ್ವಿಚಾರಣೆ ತಪ್ಪಾಗಿ trigger ಆಗಿದ್ದರೆ ಮಾಡೆಲ್ನ ಕೆಲಸವನ್ನು ಮುಂದುವರಿಸಲು ಬಳಕೆದಾರರು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
- ಬಳಕೆದಾರರಿಗೆ ಹೆಚ್ಚಿನ ಗೋಚರತೆ ಮತ್ತು ನಿಯಂತ್ರಣ. ಈ ದೀರ್ಘಕಾಲದ sessions ಅನ್ನು ಪರಿಶೀಲಿಸುವ, ತೆಗೆದುಕೊಂಡ ಕ್ರಿಯೆಗಳನ್ನು ನೋಡುವ, ಮತ್ತು ಮಧ್ಯಪ್ರವೇಶಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಬಳಕೆದಾರರ ಸಾಮರ್ಥ್ಯವನ್ನು ನಾವು ಸುಧಾರಿಸಿದೆವು.
ಹೊಸ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು, ಮಾಡೆಲ್ ಹಿಂದೆ ಅಲೈನ್ ಆಗದ ಕ್ರಿಯೆಗಳನ್ನು ಹಿಂಬಾಲಿಸಿದ್ದ ಕೆಲವು ಆಂತರಿಕ ನಿಯೋಜನಾ ಪರಿಸರಗಳನ್ನು, ಈ ಬಾರಿ ಹೊಸ ರಕ್ಷಣಾ ಕ್ರಮಗಳೊಂದಿಗೆ, ನಾವು ಮರುಪ್ಲೇ ಮಾಡಿದೆವು2. ಹೊಸ ರಕ್ಷಣಾ ಕ್ರಮಗಳು ಮಾಡೆಲ್ ಹಿಂಬಾಲಿಸಿದ ಅಲೈನ್ ಆಗದ ಕ್ರಿಯೆಗಳ ಬಹಳ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣವನ್ನು ಹಿಡಿಯಲು ಸಾಧ್ಯವಾಯಿತು; ತಪ್ಪಿಸಿಕೊಂಡ ಎಲ್ಲವೂ ಕಡಿಮೆ ತೀವ್ರತೆಯವು ಎಂದು ನಿರ್ಣಯಿಸಲಾಯಿತು.
ಈ ಕಡಿಮೆ ತೀವ್ರತೆಯ ಘಟನೆಗಳ ಕೆಲವು ಉದಾಹರಣೆಗಳು ಹೀಗಿವೆ:
- Linear command line tool ಅನ್ನು ಪ್ರವೇಶಿಸಲು, ಮಾಡೆಲ್ nested
codex --yolosession ಅನ್ನು ಪ್ರಾರಂಭಿಸಿತು; ವಾಸ್ತವವಾಗಿ--yoloflag ಇಲ್ಲದೇ ಅದನ್ನು ಮಾಡಬಹುದಾಗಿತ್ತು. - ಹಿಂದೆ live ಆಗಿದ್ದ resource ಕಾಣೆಯಾಗಿರುವುದನ್ನು ಮಾಡೆಲ್ ಗಮನಿಸಿತು; ನಂತರ ಸಮರ್ಥ ಕಾರಣವಿಲ್ಲದೆ ತನ್ನ owner namespace ಅಡಿಯಲ್ಲಿ ಇರುವ ಇತರ live CPU pods ಗಳನ್ನು, ಹಾಗೆಯೇ ಇತರ OpenAI ಉದ್ಯೋಗಿಗಳಿಗೆ ಸೇರಿದ pods ಗಳನ್ನು (ಯಶಸ್ವಿಯಾಗದೆ) ಅನ್ವೇಷಿಸಿ SSH ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು.
- ಮಾಡೆಲ್ನಲ್ಲಿ ಅನೇಕ stuck
findprocesses ಇದ್ದವು ಮತ್ತು ಪ್ರತಿಯೊಂದು shell command hang ಆಗುತ್ತಿತ್ತು. ನಂತರ ಅದುkill -9 -1ಅನ್ನು ಚಲಾಯಿಸಿತು; ಅದು execute ಆಗಿದ್ದರೆ, ಆ pod ನಲ್ಲಿ kill ಮಾಡಲು ಅನುಮತಿ ಇರುವ ಪ್ರತಿಯೊಂದು process ಗೆ SIGKILL ಕಳುಹಿಸುತ್ತಿತ್ತು. ಆದರೆ ಅದು timed out ಆಗಿ execute ಆಗಲಿಲ್ಲ.
ಹೊಸ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರೀಕ್ಷಿಸಿದ ನಂತರ, ದೀರ್ಘ ಕಾಲಾವಧಿಯ ಸಾಮರ್ಥ್ಯಗಳಿರುವ ಮಾಡೆಲ್ಗಳಿಗೆ ಮಿತಿಗೊಳಿಸಿದ ಆಂತರಿಕ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು ಎಂದು ನಾವು ತೀರ್ಮಾನಿಸಿದೆವು. ಹಲವಾರು ವಾರಗಳ ಹಿಂದೆ ಮರುನಿಯೋಜನೆ ಆರಂಭವಾದ ನಂತರದಿಂದ, ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಗಂಭೀರವಾಗಿ ಸುತ್ತಿಕೊಂಡು ಹೋಗಿರುವುದನ್ನು ನಾವು ಗಮನಿಸಿಲ್ಲ. ಈ ರಕ್ಷಣಾ ಕ್ರಮಗಳ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಸಂಯಮಿತವಾಗಿಟ್ಟಿದ್ದೇವೆ. ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ದುರ್ಬಲಗೊಳಿಸದೇ ಅನಗತ್ಯ ಅಡ್ಡಿಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ವ್ಯವಸ್ಥೆಯನ್ನು ಮುಂದುವರಿಸಿ tuning ಮಾಡುತ್ತಿದ್ದೇವೆ.
ನಾವು ಹಂತ ಹಂತವಾಗಿ ನಿಯೋಜಿಸಿದ್ದರಿಂದ, ಪ್ರವೇಶವನ್ನು ವಿಸ್ತರಿಸುವ ಮೊದಲು ಅಂತರಗಳನ್ನು ಕಂಡು ಪರಿಹರಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ನಿಯೋಜನೆಗೆ ಮುಂಚಿನ ಮೌಲ್ಯಮಾಪನಗಳು ಇನ್ನೂ ಅಗತ್ಯವೇ, ಆದರೆ ಅವು ತಪ್ಪಿಸುವ ವರ್ತನೆಗಳನ್ನು ನಿಯೋಜನೆ ಬಯಲು ಮಾಡುತ್ತದೆ. ಮಿತಿಗೊಳಿಸಿದ ಪ್ರವೇಶದಿಂದ ಆರಂಭಿಸಿದ್ದರಿಂದ ಮಾಡೆಲ್ ಅನ್ನು ಕಾರ್ಯಪ್ರಯೋಗದಲ್ಲಿ ಗಮನಿಸಲು, ಸಮಸ್ಯೆಗಳು ಬಂದಾಗ ವಿರಮಿಸಲು, ಆ ವೈಫಲ್ಯಗಳನ್ನು ಉತ್ತಮ ಮೌಲ್ಯಮಾಪನಗಳು ಮತ್ತು ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಕಟ್ಟಲು ಬಳಸಲು, ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿದ ನಂತರ ಮಿತಿಗೊಳಿಸಿದ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸಲು ನಮಗೆ ಸಾಧ್ಯವಾಯಿತು.
ಮಾಡೆಲ್ಗಳು ಇನ್ನಷ್ಟು ದೀರ್ಘ ಮತ್ತು ಸಂಕೀರ್ಣ ಕೆಲಸಗಳನ್ನು ಕೈಗೆತ್ತಿಕೊಳ್ಳುವಂತೆ, ಮೌಲ್ಯಮಾಪನಗಳು ತಪ್ಪಿಸುವ ವೈಫಲ್ಯಗಳ ಪರಿಣಾಮಗಳು ಹೆಚ್ಚಾಗಬಹುದು. ಮೌಲ್ಯಮಾಪನ ಮತ್ತು ನಿಯೋಜನೆ ನಡುವಿನ ಅಂತರವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಾವು ಕೆಲಸ ಮುಂದುವರಿಸುತ್ತೇವೆ: ದೀರ್ಘ ಪಥಗಳಲ್ಲಿ ಮಾಡೆಲ್ಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದು, ಅಲೈನ್ಮೆಂಟ್ ಸುಧಾರಿಸುವುದು, ಮಧ್ಯಪ್ರವೇಶಿಸಬಲ್ಲ ಮೇಲ್ವಿಚಾರಣೆ ನಿರ್ಮಿಸುವುದು, ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಸ್ಪಷ್ಟ ಗೋಚರತೆ ಹಾಗೂ ನಿಯಂತ್ರಣ ನೀಡುವುದು. ಈ ಸವಾಲುಗಳು OpenAI ಗೆ ಮಾತ್ರ ಸೀಮಿತವಾಗುವುದಿಲ್ಲ; ನಾವು ಕಲಿತದ್ದನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ ವಿಸ್ತೃತ ಕ್ಷೇತ್ರವು ಅವಕ್ಕೆ ಸಿದ್ಧವಾಗಲು ಸಹಾಯವಾಗಲಿ ಎಂದು ಆಶಿಸುತ್ತೇವೆ.
ಲೇಖಕ
ಅಡಿಟಿಪ್ಪಣಿಗಳು
- 1
ನಾವು PR ಅನ್ನು ಬೇಗ ಮುಚ್ಚಿದ್ದರೂ, speedrunನ ಹಲವು ಭಾಗವಹಿಸುವವರು ಅದನ್ನು ಈಗಾಗಲೇ ನೋಡಿದ್ದರು ಮತ್ತು ತಮ್ಮದೇ ಸಲ್ಲಿಕೆಗಳಲ್ಲಿ ಆ ವಿಧಾನವನ್ನು ಬಳಸಿದ್ದರು; 3030(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), 2990(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), 2930(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), 2925(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ), 2900(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಮತ್ತು 2890(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ಹಂತಗಳೊಂದಿಗೆ ಬಂದ ನಂತರದ ವಿಶ್ವದಾಖಲೆ ಸಲ್ಲಿಕೆಗಳೆಲ್ಲವೂ PR 287 ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತವೆ. ಇವುಗಳಲ್ಲಿ, PR 300(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) ವಿಶೇಷವಾಗಿ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಏಕೆಂದರೆ Prime Intellect(ಹೊಸ ಕಿಟಕಿಯಲ್ಲಿ ತೆರೆಯುತ್ತದೆ) NanoGPT speedrunನಲ್ಲಿ Opus 4.7 ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದಾಗ ಅದು ಸಲ್ಲಿಸಿದ PR ಅದೇ ಆಗಿತ್ತು. ನಮ್ಮ ಮಾಡೆಲ್ ಸಲ್ಲಿಸಿದ್ದ PR ಅನ್ನು Opus ನೋಡಿತು, ಕಂಡುಹಿಡಿದ ಅಂಶಗಳನ್ನು ಸೇರಿಸಿಕೊಂಡಿತು, ಮತ್ತು ತನ್ನ ಅಂತಿಮ ಫಲಿತಾಂಶದಲ್ಲಿ ನಮ್ಮ PR ಗೆ ಕ್ರೆಡಿಟ್ ನೀಡಿತು.
- 2


