ಎಂಡ್-ಟು-ಎಂಡ್ ಪ್ರೊಡಕ್ಷನ್: ಪರಿಶೀಲನೆ, ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಎಥಿಕ್ಸ್

ಲಾಭಗಳು:

• ಕಲ್ಪನೆಯಿಂದ ಉತ್ಪಾದನೆಗೆ LLM ವೈಶಿಷ್ಟ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಎಂಡ್-ಟು-ಎಂಡ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು
• ಪರಿಶೀಲನೆ ಜಾರಿ, ಮಾನವ ಅನುಮೋದನೆ ಮತ್ತು ಟ್ರ್ಯಾಕಿಂಗ್ (ಲಾಗಿಂಗ್/ಮೆಟ್ರಿಕ್ಸ್) ಪದರಗಳನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ
• ಗಡಿಗಳು ನೀತಿಶಾಸ್ತ್ರ ಮತ್ತು ಗೌಪ್ಯತೆ ತತ್ವಗಳನ್ನು ಉತ್ಪಾದನಾ ನಿರ್ಧಾರಗಳಾಗಿ ಭಾಷಾಂತರಿಸುತ್ತವೆ

ಹಿಂದಿನ ಹತ್ತು ಘಟಕಗಳಲ್ಲಿ, ನಾವು ಒಂದೊಂದಾಗಿ ಭಾಗಗಳನ್ನು ಕಲಿತಿದ್ದೇವೆ: ವಿನಂತಿ ರಚನೆ, ಟೋಕನ್ ಅರ್ಥಶಾಸ್ತ್ರ, ಹರಿವು, ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಮಾದರಿ ಆಯ್ಕೆ, ಸಂಗ್ರಹ, ಬ್ಯಾಚ್, ದೋಷ ನಿರ್ವಹಣೆ, ಸುರಕ್ಷಿತ ಕೀ ಮತ್ತು ಯಾಂತ್ರೀಕೃತಗೊಂಡ. ಈ ಕೊನೆಯ ಘಟಕದಲ್ಲಿ, ನಾವು ಭಾಗಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತೇವೆ ಮತ್ತು ಕಲ್ಪನೆಯಿಂದ ಉತ್ಪಾದನೆಗೆ LLM ವೈಶಿಷ್ಟ್ಯವನ್ನು ಹೊಂದಿರುವ ಸಮಗ್ರ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಸ್ಥಾಪಿಸುತ್ತೇವೆ. ಉತ್ಪಾದನೆಯು "ವರ್ಕಿಂಗ್ ಡೆಮೊ" ಗಿಂತ ಭಿನ್ನವಾಗಿದೆ: ಪರಿಶೀಲನೆ ಕಡ್ಡಾಯವಾಗಿದೆ, ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು, ಗಡಿಗಳು ಮತ್ತು ನೈತಿಕ ತತ್ವಗಳನ್ನು ನಿರ್ಧಾರಗಳಲ್ಲಿ ಹುದುಗಿಸಬೇಕು. ಈ ಘಟಕವು ಮಾಡ್ಯೂಲ್ನ ಕ್ಯಾರಿಯರ್ ಕಾಲಮ್ ಆಗಿದೆ; ಹಿಂದಿನವರೆಲ್ಲ ಇಲ್ಲಿ ಒಗ್ಗೂಡುತ್ತಾರೆ.

ಉತ್ಪಾದನಾ ವಾಸ್ತುಶಿಲ್ಪದ ಪದರಗಳು

ಘನ LLM ಅರ್ಹತೆಯು ಸರಿಸುಮಾರು ಐದು ಪದರಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

1. ಇನ್‌ಪುಟ್ ಲೇಯರ್: ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಿ, ಅದನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ, ಸೂಕ್ಷ್ಮ ಪ್ರದೇಶಗಳನ್ನು ಮಾಸ್ಕ್ ಮಾಡಿ, ಅಗತ್ಯವಿರುವದನ್ನು ಮಾತ್ರ ರವಾನಿಸಿ.
2. ಮಾದರಿ ಪದರ: ಸರಿಯಾದ ಮಾದರಿಯನ್ನು ಆಯ್ಕೆಮಾಡಿ (ಘಟಕ 5), ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸಿ (ಘಟಕ 4), ಸಂಗ್ರಹ (ಯುನಿಟ್ 6).
3. ಮೌಲ್ಯೀಕರಣ ಪದರ: ಅಗತ್ಯವಿದ್ದಲ್ಲಿ ಸ್ಕೀಮಾ/ನಿಯಮ, ಮೂಲ ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆಯ ವಿರುದ್ಧ ಔಟ್‌ಪುಟ್ ಪರಿಶೀಲಿಸಿ.
4. ಕ್ರಿಯೆಯ ಪದರ: ಮೌಲ್ಯೀಕರಿಸಿದ ಔಟ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸಿ; ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ಕ್ರಿಯೆಗಳನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ.
5. ಮಾನಿಟರಿಂಗ್ ಲೇಯರ್: ಪ್ರತಿ ಕರೆ, ವೆಚ್ಚ, ದೋಷ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ ಮತ್ತು ಅಳೆಯಿರಿ.

ಈ ಪದರಗಳು ಪೈಪ್ಲೈನ್; ಪ್ರತಿಯೊಂದೂ ಹಿಂದಿನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ ಏಕೆ ಅಗತ್ಯವಿದೆ?

LLMಗಳು ನಿರರ್ಗಳವಾಗಿ ಆದರೆ ಕೆಲವೊಮ್ಮೆ ತಪ್ಪಾದ ಔಟ್ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಹುದು. ಇದನ್ನು ಭ್ರಮೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ: ಮಾದರಿಯು ನಿಜವೆಂದು ತೋರುವ ಆದರೆ ಅಲ್ಲದ ಮಾಹಿತಿಯನ್ನು ತಯಾರಿಸಬಹುದು. ಚಾಟ್ ಆಟದಲ್ಲಿ ಇದು ಸಹನೀಯವಾಗಿದೆ; ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (ಸರಕುಪಟ್ಟಿ, ಆರೋಗ್ಯ, ಕಾನೂನು, ಹಣಕಾಸು) ಸಹಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಇದು ಹೊರಹೊಮ್ಮಿತು, ಕುರುಡಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ; ದೃಢಪಟ್ಟಿದೆ.

ಪರಿಶೀಲನಾ ಪದರಗಳು (ಪ್ರಭಾವದಿಂದ ಹೆಚ್ಚುತ್ತಿದೆ):

• ಫಾರ್ಮ್ಯಾಟ್/ಸ್ಕೀಮಾ ಮೌಲ್ಯೀಕರಣ: ಔಟ್‌ಪುಟ್ ನಿರೀಕ್ಷಿತ JSON ಸ್ಕೀಮಾಗೆ ಅನುಗುಣವಾಗಿದೆಯೇ? (ರಚನಾತ್ಮಕ ಔಟ್ಪುಟ್ ಇದನ್ನು ಹೆಚ್ಚಾಗಿ ಖಾತರಿಪಡಿಸುತ್ತದೆ.)
• ನಿಯಮ/ತರ್ಕ ಪರಿಶೀಲನೆ: ಮೌಲ್ಯಗಳು ಸಮಂಜಸವೇ? (ಮೊತ್ತವು ಋಣಾತ್ಮಕವಾಗಿದೆಯೇ, ಭವಿಷ್ಯದ ದಿನಾಂಕವಾಗಿದೆಯೇ, ವರ್ಗವು ಮಾನ್ಯವಾಗಿದೆಯೇ?)
• ಮೂಲ ಪರಿಶೀಲನೆ: ದಾಖಲಾತಿ ಒದಗಿಸಿದ ಆಧಾರದ ಮೇಲೆ ಹಕ್ಕು ಇದೆಯೇ? ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಏನನ್ನಾದರೂ ಮಾಡೆಲ್ ಹೇಳುತ್ತದೆಯೇ?
• ಮಾನವ ಅನುಮೋದನೆ: ತಜ್ಞರು ಹೆಚ್ಚಿನ ಪರಿಣಾಮ ಅಥವಾ ಅಸ್ಪಷ್ಟ ನಿರ್ಧಾರಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ.

ಎಚ್ಚರಿಕೆ: "ಮಾದರಿಯು ತುಂಬಾ ಉತ್ತಮವಾಗಿದೆ, ಹೆಚ್ಚಿನ ಪರಿಶೀಲನೆ ಅಗತ್ಯವಿಲ್ಲ" ಎಂಬುದು ಅತ್ಯಂತ ಅಪಾಯಕಾರಿ ಉತ್ಪಾದನಾ ತಪ್ಪು. ಮಾದರಿ ಎಷ್ಟೇ ಉತ್ತಮವಾಗಿದ್ದರೂ, ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಪರಿಶೀಲನೆ ಪದರವು ಸುರಕ್ಷತಾ ನಿವ್ವಳವಾಗಿದೆ. ಒಂದು ತಪ್ಪು ಸ್ವಯಂಚಾಲಿತ ನಿರ್ಧಾರವು ಎಲ್ಲಾ ಸಮಯವನ್ನು ಉಳಿಸಬಹುದು.

ಮಾನವ-ಇನ್-ದ-ಲೂಪ್

ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರವೂ ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿರಬೇಕಾಗಿಲ್ಲ. ಮಾನವ-ಇನ್-ಲೂಪ್ ವಿಧಾನದಲ್ಲಿ, ಮಾದರಿಯು ಕೆಲಸವನ್ನು ವೇಗಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಮಾನವನು ಅದನ್ನು ಅನುಮೋದಿಸುತ್ತಾನೆ. ಸರಿಯಾದ ಸಮತೋಲನವು ನಿರ್ಧಾರದ ಪ್ರಭಾವ ಮತ್ತು ಆ ಕಾರ್ಯದ ಮೇಲೆ ಮಾದರಿಯ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.

ನಿರ್ಧಾರದ ಪರಿಣಾಮ

ಅಪ್ರೋಚ್

ಕಡಿಮೆ (ಲೇಬಲ್ ಸಲಹೆ, ಕರಡು)

ಪೂರ್ಣ ಯಾಂತ್ರೀಕೃತಗೊಂಡ; ದೋಷವು ಅಗ್ಗವಾಗಿದೆ ಮತ್ತು ಹಿಂತಿರುಗಿಸಬಹುದಾಗಿದೆ

ಮಧ್ಯಮ (ರೂಟಿಂಗ್, ಆದ್ಯತೆ)

ಆಟೊಮೇಷನ್ + ಮಾದರಿ ನಿಯಂತ್ರಣ

ಅಧಿಕ (ಹಣ, ಒಪ್ಪಂದ, ಆರೋಗ್ಯ, ಅಳಿಸುವಿಕೆ)

ಮಾನವ ಒಪ್ಪಿಗೆ ಕಡ್ಡಾಯವಾಗಿದೆ; ಮಾದರಿ ಮಾತ್ರ ಸೂಚಿಸುತ್ತದೆ

ಮಾನಿಟರಿಂಗ್: ನೀವು ನೋಡದಿರುವುದನ್ನು ನೀವು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

ಉತ್ಪಾದನೆಯಲ್ಲಿ, ನೀವು ಪ್ರತಿ ಕರೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು. ಮೇಲ್ವಿಚಾರಣೆಯಿಲ್ಲದೆ, ನೀವು ವೆಚ್ಚ, ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ಅಥವಾ ಸಮಸ್ಯೆಯನ್ನು ಮೊದಲೇ ಹಿಡಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ದಾಖಲಿಸಲು ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳು:

• ಬಳಕೆ/ವೆಚ್ಚ: ಪ್ರತಿ ವಿನಂತಿ ಮತ್ತು ಒಟ್ಟು ಟೋಕನ್‌ಗಳು, ಮಾದರಿ ವಿತರಣೆ, ದೈನಂದಿನ ಖರ್ಚು.
• ಸುಪ್ತತೆ: ಸರಾಸರಿ ಮತ್ತು ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ.
• ದೋಷ ದರ: 429/500 ದರಗಳು, ಮರುಪ್ರಯತ್ನಗಳು, ತ್ಯಜಿಸುವಿಕೆಗಳು.
• ಗುಣಮಟ್ಟ: ಪರಿಶೀಲನೆ ಲೇಯರ್‌ನಲ್ಲಿ ತಿರಸ್ಕರಿಸಿದ ಔಟ್‌ಪುಟ್ ದರ, ಮಾನವ ಅನುಮೋದನೆಯಲ್ಲಿ ತಿದ್ದುಪಡಿ ದರ, ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆ.

ಸಲಹೆ: ಲಾಗ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು (ವೈಯಕ್ತಿಕ ಮಾಹಿತಿ, ಕೀಗಳು) ಬರೆಯಬೇಡಿ. ಗೌಪ್ಯತೆಯ ವ್ಯಾಪ್ತಿಯೊಳಗೆ ಲಾಗ್‌ಗಳನ್ನು ಪರಿಗಣಿಸಿ; ಅಗತ್ಯವಿದ್ದರೆ ಮರೆಮಾಚುವ ಮೂಲಕ ರೆಕಾರ್ಡ್ ಮಾಡಿ (ಘಟಕ 9).

ನೀತಿಶಾಸ್ತ್ರ ಮತ್ತು ಗಡಿಗಳು

ತಾಂತ್ರಿಕ ನಿಖರತೆಯಂತೆಯೇ ನೈತಿಕ ಜವಾಬ್ದಾರಿಯು ಉತ್ಪಾದನಾ ನಿರ್ಧಾರದ ಒಂದು ಭಾಗವಾಗಿದೆ:

• ಪಾರದರ್ಶಕತೆ: ಅವರು ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದಾರೆಯೇ ಅಥವಾ ಮಾನವರೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದ್ದಾರೆಯೇ ಎಂದು ಬಳಕೆದಾರರು ತಿಳಿದಿರಬೇಕು.
• ನ್ಯಾಯಸಮ್ಮತತೆ ಮತ್ತು ಪಕ್ಷಪಾತ: ಮಾದರಿಯು ತರಬೇತಿ ಪಡೆದ ಡೇಟಾದಿಂದ ಪಕ್ಷಪಾತವನ್ನು ಹೊಂದಿರಬಹುದು; ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ ನಿರ್ಧಾರಗಳಲ್ಲಿ ತಾರತಮ್ಯದ ಪರಿಣಾಮಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ (ನೇಮಕ, ಕ್ರೆಡಿಟ್).
• ಹೊಣೆಗಾರಿಕೆ: ಸ್ವಯಂಚಾಲಿತ ನಿರ್ಧಾರವು ಹಾನಿಯನ್ನುಂಟುಮಾಡಿದರೆ, ನೀವು ಜವಾಬ್ದಾರರಾಗಿರುತ್ತೀರಿ; "ಮಾದರಿಯು ಹಾಗೆ ಹೇಳಿದೆ" ಎಂಬುದು ರಕ್ಷಣೆಯಲ್ಲ.
• ಮಿತಿಗಳ ಸ್ವೀಕಾರ: ಮಾದರಿಯು ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ; ಅವುಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸದಿರುವುದು ಸಹ ವಿನ್ಯಾಸ ನಿರ್ಧಾರವಾಗಿದೆ.

ನಕಲಿಸಬಹುದಾದ ಟೆಂಪ್ಲೇಟ್‌ಗಳು

# ಮೌಲ್ಯೀಕರಣ ಪರಿಶೀಲನಾಪಟ್ಟಿ (ಔಟ್‌ಪುಟ್ ಉತ್ಪಾದನೆಯ ನಂತರ) 1) ಸ್ಕೀಮಾ ಮಾನ್ಯವಾಗಿದೆಯೇ? (ರಚನಾತ್ಮಕ ಔಟ್‌ಪುಟ್ ಮೌಲ್ಯೀಕರಣ) 2) ಮೌಲ್ಯಗಳು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆಯೇ? (ನಿಯಮ ಪರಿಶೀಲನೆ: ಶ್ರೇಣಿ, ದಿನಾಂಕ, enum)3) ಹಕ್ಕು ಮೂಲವನ್ನು ಆಧರಿಸಿದೆಯೇ? (ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ ತಿರಸ್ಕರಿಸಿ)4) ಪರಿಣಾಮ ಹೆಚ್ಚಿದೆಯೇ? → ಮಾನವ ಅನುಮೋದನೆಗಾಗಿ ಕಳುಹಿಸಿ5) ಎಲ್ಲಾ ಅಂಗೀಕರಿಸಿದರೆ → ಕ್ರಿಯೆಯನ್ನು ಅನುಮತಿಸಿ, ಉಳಿಸಿ

# ಒದಗಿಸಿದ ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿರುವ ಮಾಹಿತಿಯ ಮೇಲೆ ಮಾತ್ರ ಮೂಲವನ್ನು ಅವಲಂಬಿಸುವಂತೆ ಒತ್ತಾಯಿಸುತ್ತದೆ ಎಂದು ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್. ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಯಾವುದನ್ನೂ ಸೇರಿಸಬೇಡಿ. ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಮಾಹಿತಿ ಇಲ್ಲದಿದ್ದರೆ, "ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಕಂಡುಬಂದಿಲ್ಲ" ಎಂದು ಬರೆಯಿರಿ. ವಿಷಯಗಳನ್ನು ಎಂದಿಗೂ ಊಹಿಸಬೇಡಿ ಅಥವಾ ರೂಪಿಸಬೇಡಿ.

# ಮಾನವ ಅನುಮೋದನೆ ಮಿತಿ (ನಿರ್ಧಾರ ನಿಯಮ)IF ನಿರ್ಧಾರ_ಪ್ರಕಾರ [ಹಣ, ಒಪ್ಪಂದ, ಅಳಿಸಿ, ಆರೋಗ್ಯ] → ಮಾನವ ಅನುಮೋದನೆ ಕಡ್ಡಾಯIF ಮಾದರಿ_ಟ್ರಸ್ಟ್ < ಮಿತಿ ಅಥವಾ ಮೌಲ್ಯೀಕರಣ "ಅನಿಶ್ಚಿತ" → ಮಾನವ ಅನುಮೋದನೆಗೆ ಸಲ್ಲಿಸಿOTHER → ಸ್ವಯಂ ಅನ್ವಯಿಸುವಿಕೆ + ಮಾದರಿ ನಿಯಂತ್ರಣ

# ಟ್ರೇಸ್ ಲಾಗ್ ಟೆಂಪ್ಲೇಟ್ (ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಬರೆಯುವುದು){ "ಸಮಯ":"...", "ಮಾದರಿ":"...", "ಇನ್‌ಪುಟ್_ಟೋಕನ್":..., "ಔಟ್‌ಪುಟ್_ಟೋಕನ್":..., "ವಿಳಂಬ_ಎಂಎಸ್":..., "ಸ್ಟಾಪ್_ಕಾರಣ":"...", "ದೃಢೀಕರಣ":"ಉತ್ತೀರ್ಣಗೊಂಡಿದೆ|ತಿರಸ್ಕರಿಸಲಾಗಿದೆ" //:co...} ದತ್ತಾಂಶ ಎಂದಿಗೂ ಬರೆದಿಲ್ಲ

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್ (ಉತ್ಪಾದನೆಯ ವಿಶ್ವಾಸಾರ್ಹತೆ)

# ದುರ್ಬಲ (ಯಾವುದೇ ಪರಿಶೀಲನೆಯಿಲ್ಲ, ಯಾವುದೇ ಮೂಲವಿಲ್ಲ, ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನ್ವಯಿಸುತ್ತದೆ) ಈ ವಿನಂತಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ, ಮರುಪಾವತಿ ನಿರ್ಧಾರವನ್ನು ಮಾಡಿ ಮತ್ತು ಅನ್ವಯಿಸಿ.

# STRONG (ಮೂಲ-ಆಧಾರಿತ, ಶಿಫಾರಸನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಮಾನವ ಅನುಮೋದನೆಗೆ ಬಿಡುತ್ತದೆ) ಈ ರಿಟರ್ನ್ ವಿನಂತಿಯನ್ನು ರಿಟರ್ನ್ ಪಾಲಿಸಿ ಡಾಕ್ಯುಮೆಂಟ್ ಆಧರಿಸಿ ಮಾತ್ರ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. ಸಮರ್ಥನೆಯೊಂದಿಗೆ ನಿರ್ಧಾರವನ್ನು ಶಿಫಾರಸು ಮಾಡಿ ಆದರೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಡಿ: {"ಶಿಫಾರಸು":"ಅನುಮೋದಿಸಿ|ತಿರಸ್ಕರಿಸಿ","ಕಾರಣ":"...","ನೀತಿ_ಷರತ್ತು":"..."}.ನೀತಿ ದಾಖಲೆಯಲ್ಲಿ ಯಾವುದೇ ಸ್ಪಷ್ಟ ಆಧಾರವಿಲ್ಲದಿದ್ದರೆ, "ಅಸ್ಪಷ್ಟ" ನೀಡಿ. ಪ್ರತಿನಿಧಿ ಅಂತಿಮ ನಿರ್ಧಾರವನ್ನು ಅನುಮೋದಿಸುತ್ತಾರೆ.

ಶಕ್ತಿಯುತ ಆವೃತ್ತಿ; ಇದು ನಿರ್ಧಾರವನ್ನು ಮೂಲಕ್ಕೆ ಆರೋಪಿಸುತ್ತದೆ, ಮಾದರಿಯನ್ನು "ಮಾಡುವವರ" ಬದಲಿಗೆ "ಸಲಹೆಗಾರ" ಎಂದು ಇರಿಸುತ್ತದೆ ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆಯ ಹಿಂದೆ ಹೆಚ್ಚಿನ ಪ್ರಭಾವದ ಹೆಜ್ಜೆ ಇರಿಸುತ್ತದೆ. ಇದು ಉತ್ಪಾದನಾ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ಮೂಲತತ್ವವಾಗಿದೆ.

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ಪರಿಶೀಲನೆ ಪದರವನ್ನು ಉಳಿಸಿದ ದಿನ. ಫಿನ್‌ಟೆಕ್ ಮಾದರಿಯು ವಹಿವಾಟಿನ ವಿವರಣೆಗಳನ್ನು ವರ್ಗೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಲೆಕ್ಕಪತ್ರ ದಾಖಲೆಗಳನ್ನು ರಚಿಸುತ್ತದೆ. ಅವರು ನಿಯಮ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಯನ್ನು ಸೇರಿಸಿದರು: ಒಮ್ಮೆ ಮಾದರಿಯು ಮೊತ್ತವನ್ನು ತಪ್ಪಾಗಿ ಔಟ್‌ಪುಟ್ ಮಾಡಿದರೆ (ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ 1,250 ರ ಬದಲಿಗೆ 12,500), "ಡಾಕ್ಯುಮೆಂಟ್‌ಗೆ ಮೊತ್ತವು ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ" ನಿಯಮವು ಔಟ್‌ಪುಟ್ ಅನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ ಮತ್ತು ದಾಖಲೆಯು ಮಾನವನಿಗೆ ಬಿದ್ದಿತು. ಯಾವುದೇ ಪರಿಶೀಲನೆ ಇಲ್ಲದಿದ್ದರೆ, ತಪ್ಪಾದ ದಾಖಲೆಯು ಮೌನವಾಗಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪ್ರವೇಶಿಸುತ್ತದೆ.

ಪ್ರಕರಣ 2 - ಪರಾರಿಯಾದ ವ್ಯಕ್ತಿ ಕಣ್ಗಾವಲು ಮೂಲಕ ಸಿಕ್ಕಿಬಿದ್ದ. SaaS ತಂಡವು ಮೇಲ್ವಿಚಾರಣಾ ಫಲಕವನ್ನು ಸ್ಥಾಪಿಸಿದೆ; ಒಂದು ಮುಂಜಾನೆ ದೈನಂದಿನ ವೆಚ್ಚ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚಾಯಿತು. ಒಂದು ಕ್ಲೈಂಟ್ ಲೂಪ್ ಅನ್ನು ನಮೂದಿಸಿ ಮತ್ತು ಅದೇ ವಿನಂತಿಯನ್ನು ಸಾವಿರಾರು ಬಾರಿ ಕಳುಹಿಸಿರುವುದು ಲಾಗ್‌ಗಳಿಂದ ಕಂಡುಬಂದಿದೆ. ಅವರು ಕೋಟಾ ಮತ್ತು ಡಿಡಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೇರಿಸಿದರು; ಕೆಲವೇ ಗಂಟೆಗಳಲ್ಲಿ ಸಮಸ್ಯೆ ಬಗೆಹರಿಯಿತು. ಟ್ರ್ಯಾಕಿಂಗ್ ಇಲ್ಲದೆ, ತಿಂಗಳ ಕೊನೆಯಲ್ಲಿ ಬಿಲ್ ಆಶ್ಚರ್ಯಕರವಾಗಿರುತ್ತದೆ.

ಪ್ರಕರಣ 3 - ಮಿತಿಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುವುದು. ಹೆಲ್ತ್‌ಕೇರ್ ಸ್ಟಾರ್ಟ್‌ಅಪ್ ರೋಗನಿರ್ಣಯದ ಶಿಫಾರಸನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ರೋಗಿಗೆ ತೋರಿಸಲು ಯೋಜಿಸುತ್ತಿದೆ. ನೈತಿಕತೆ ಮತ್ತು ಹೊಣೆಗಾರಿಕೆಯ ವಿಮರ್ಶೆಯಲ್ಲಿ, ಇದು ಮಿತಿಯಿಲ್ಲ ಎಂದು ಅವರು ನಿರ್ಧರಿಸಿದರು: ಮಾದರಿಯು ವೈದ್ಯರಿಗೆ ಸಾರಾಂಶ ಮತ್ತು ಸಂಭವನೀಯ ಅಂಶಗಳನ್ನು ಮಾತ್ರ ಒದಗಿಸುತ್ತದೆ, ವೈದ್ಯರು ರೋಗನಿರ್ಣಯವನ್ನು ಮಾಡುತ್ತಾರೆ. ಕೆಲಸವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸದಿರುವುದು ಸಹ ಪ್ರಬುದ್ಧ ವಿನ್ಯಾಸ ನಿರ್ಧಾರವಾಗಿದೆ.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• ಮೌಲ್ಯೀಕರಣವನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು: "ಮಾದರಿಯು ಉತ್ತಮವಾಗಿದೆ" ಎಂದು ಹೇಳುವ ಮೂಲಕ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಕುರುಡಾಗಿ ಅನ್ವಯಿಸುವುದು.
• ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ನಿರ್ಧಾರವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು: ಹಣ/ಆರೋಗ್ಯ/ಕಾನೂನುಗಳಲ್ಲಿ ಮಾನವ ಅನುಮೋದನೆ ಅತ್ಯಗತ್ಯ.
• ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲ: ವೆಚ್ಚ ಮತ್ತು ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಗಳನ್ನು ತಡವಾಗಿ ಕಂಡುಹಿಡಿಯಲಾಗುತ್ತದೆ.
• ಲಾಗ್‌ಗಳಿಗೆ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಬರೆಯುವುದು: ಗೌಪ್ಯತೆ ಉಲ್ಲಂಘನೆ; ಅದನ್ನು ಮರೆಮಾಚುವ ಮೂಲಕ ಉಳಿಸಿ.
• ಮೂಲವನ್ನು ಅವಲಂಬಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿಲ್ಲ: ಡಾಕ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಇಲ್ಲದಿರುವುದನ್ನು ಮಾದರಿಯು ರೂಪಿಸಬಹುದು.
• ಮಿತಿಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು: ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸದಿರುವುದು ಸರಿಯಾದ ನಿರ್ಧಾರವಾಗಿದೆ; ಪಾರದರ್ಶಕತೆ ಮತ್ತು ಜವಾಬ್ದಾರಿ ನಿಮ್ಮದು.

ಆಳವಾದ: ಬಿಡುಗಡೆ ನಿರ್ವಹಣೆ, ರೋಲ್ಬ್ಯಾಕ್ ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ನಿಯೋಜನೆ

LLM ವೈಶಿಷ್ಟ್ಯವನ್ನು ಉತ್ಪಾದನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅದನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಮರೆತುಬಿಡುವುದು ಅಲ್ಲ; ಕಾಲಾನಂತರದಲ್ಲಿ ಲೈವ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಮಾರ್ಪಡಿಸುವುದು. ಇದು ಮೂರು ಕಂಬಗಳನ್ನು ಹೊಂದಿದೆ.

ಆವೃತ್ತಿ. ನಿಮ್ಮ ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್, ಮಾದರಿ ಆಯ್ಕೆ ಮತ್ತು ಪರಿಶೀಲನಾ ನಿಯಮಗಳು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗುತ್ತವೆ. ಪ್ರತಿ ಮಹತ್ವದ ಬದಲಾವಣೆಯನ್ನು ಆವೃತ್ತಿ ಮಾಡಿ ಮತ್ತು ಯಾವ ಆವೃತ್ತಿಯು ಲೈವ್ ಆಗಿದೆ ಎಂಬುದನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಿ. ಒಂದು ದಿನ ಗುಣಮಟ್ಟ ಕುಸಿದರೆ, "ನಾವು ಏನು ಬದಲಾಯಿಸಿದ್ದೇವೆ?" ನೀವು ನಿಮಿಷಗಳಲ್ಲಿ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಆವೃತ್ತಿಯಿಲ್ಲದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ, ಹಿಂಜರಿತದ ಮೂಲ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ರೋಲ್ಬ್ಯಾಕ್. ಹೊಸ ಪ್ರಾಂಪ್ಟ್ ಅಥವಾ ಮಾದರಿಯು ಲೈವ್‌ನಲ್ಲಿ ನಿರೀಕ್ಷೆಗಿಂತ ಕೆಟ್ಟದಾಗಿ ವರ್ತಿಸಿದರೆ, ನೀವು ಹಿಂದಿನ, ಪ್ರಸಿದ್ಧ ಆವೃತ್ತಿಗೆ ತ್ವರಿತವಾಗಿ ಹಿಂತಿರುಗಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ರೋಲ್‌ಬ್ಯಾಕ್ ಯೋಜನೆ ಇಲ್ಲದ ಬದಲಾವಣೆಯು ನೇರ ಅಪಾಯವನ್ನು ಕುರುಡಾಗಿ ಸ್ವೀಕರಿಸುತ್ತಿದೆ. "ನಾನು ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಿದೆ, ಅದು ಕೆಟ್ಟದಾಗಿದೆ, ನಾನು ಹಿಂತಿರುಗಲು ಸಾಧ್ಯವಿಲ್ಲ" ಇದು ಅತ್ಯಂತ ದುಬಾರಿ ನಿರ್ಮಾಣ ಸನ್ನಿವೇಶವಾಗಿದೆ.

ಕ್ರಮೇಣ ರೋಲ್ಔಟ್. ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್‌ಗೆ ಒಂದೇ ಬಾರಿಗೆ ಬದಲಾವಣೆಯನ್ನು ಅನ್ವಯಿಸುವ ಬದಲು, ನೀವು ಅದನ್ನು ಮೊದಲು ಒಂದು ಸಣ್ಣ ಶೇಕಡಾವಾರು (ಉದಾ. 5%) ಗೆ ರೋಲ್ ಮಾಡಿ ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು (ಗುಣಮಟ್ಟ, ವೆಚ್ಚ, ದೋಷಗಳು) ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ. ಅದು ಒಳ್ಳೆಯದಾಗಿದ್ದರೆ, ನೀವು ಶೇಕಡಾವಾರು ಹೆಚ್ಚಿಸುತ್ತೀರಿ; ಅದು ಕೆಟ್ಟದಾಗಿದ್ದರೆ, ಕೇವಲ ಒಂದು ಸಣ್ಣ ವಿಭಾಗದ ಪರಿಣಾಮದೊಂದಿಗೆ ನೀವು ಅದನ್ನು ಮರಳಿ ಪಡೆಯುತ್ತೀರಿ. ಇದು ಅಪಾಯವನ್ನು ಬಹಳವಾಗಿ ಮಿತಿಗೊಳಿಸುತ್ತದೆ.

ಈ ಮೂರು ಅಭ್ಯಾಸಗಳು ಹಿಂದಿನ ಎಲ್ಲಾ ಘಟಕಗಳಿಂದ ತಂತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತವೆ: eval (ಘಟಕ 5) ಅಳತೆಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ಬದಲಾಯಿಸುತ್ತದೆ, ಮೇಲ್ವಿಚಾರಣೆ (ಈ ಘಟಕ) ಪ್ರಸರಣದ ಸಮಯದಲ್ಲಿ ಮುಂಚಿನ ಎಚ್ಚರಿಕೆಯನ್ನು ನೀಡುತ್ತದೆ, ಪರಿಶೀಲನಾ ಪದರವು ಕಾರ್ಯಸಾಧ್ಯವಾಗುವ ಮೊದಲು ತಪ್ಪಾದ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಉತ್ಪಾದನೆಯು ಒಂದೇ ಸರಿಯಾದ ಸೆಟಪ್ ಅಲ್ಲ; ಇದು ಅಳೆಯುವ, ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಬದಲಾಯಿಸಬಹುದಾದ ನಿರಂತರ ಶಿಸ್ತು. ನೀವು ಈ ಶಿಸ್ತನ್ನು ಸ್ಥಾಪಿಸಲು ಸಂಪೂರ್ಣ ಮಾಡ್ಯೂಲ್ ಆಗಿದೆ.

ಸಾರಾಂಶದಲ್ಲಿ

ಉತ್ಪಾದನೆಯು ಕೆಲಸ ಮಾಡುವ ಡೆಮೊಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ: ಇದು ಇನ್‌ಪುಟ್, ಮಾದರಿ, ಪರಿಶೀಲನೆ, ಕ್ರಿಯೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣಾ ಲೇಯರ್‌ಗಳ ಪೈಪ್‌ಲೈನ್ ಆಗಿದೆ. ಪರಿಶೀಲನೆ ಇಲ್ಲದೆ ಔಟ್ಪುಟ್ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ; ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ನಿರ್ಧಾರಗಳು ಮಾನವ ಅನುಮೋದನೆಗೆ ಸಂಬಂಧಿಸಿವೆ; ಪ್ರತಿ ಕರೆಯನ್ನು ವೆಚ್ಚ, ದೋಷಗಳು ಮತ್ತು ಗುಣಮಟ್ಟಕ್ಕಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತದೆ. ನೈತಿಕತೆ, ಪಾರದರ್ಶಕತೆ, ಪಕ್ಷಪಾತ ನಿಯಂತ್ರಣ, ಹೊಣೆಗಾರಿಕೆ ಮತ್ತು ಮಿತಿಗಳ ಸ್ವೀಕಾರವು ತಾಂತ್ರಿಕ ನಿರ್ಧಾರಗಳಿಗೆ ಅವಿಭಾಜ್ಯವಾಗಿದೆ. ಈ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಕಲಿತ ಪ್ರತಿಯೊಂದು ತುಣುಕು ಈ ಸಮಗ್ರ ವಿನ್ಯಾಸದಲ್ಲಿ ಒಟ್ಟಿಗೆ ಬರುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ಎಂಡ್-ಟು-ಎಂಡ್ LLM ವೈಶಿಷ್ಟ್ಯವನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ. (1) ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಕ್ಕಾಗಿ ಐದು ಲೇಯರ್‌ಗಳನ್ನು (ಇನ್‌ಪುಟ್, ಮಾದರಿ, ಪರಿಶೀಲನೆ, ಕ್ರಿಯೆ, ಮೇಲ್ವಿಚಾರಣೆ) ಭರ್ತಿ ಮಾಡಿ. (2) ಯಾವ ನಿರ್ಧಾರಗಳಿಗೆ ಮಾನವ ಅನುಮೋದನೆಯ ಅಗತ್ಯವಿದೆ ಎಂಬುದನ್ನು ಪ್ರಭಾವದ ಮೂಲಕ ಗುರುತಿಸಿ. (3) ಕನಿಷ್ಠ ಮೂರು ಮೌಲ್ಯೀಕರಣ ಪರಿಶೀಲನೆಗಳನ್ನು ಬರೆಯಿರಿ (ಸ್ಕೀಮಾ, ನಿಯಮ, ಮೂಲ). (4) ನೀವು ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮತ್ತು ನೀವು ಯಾವುದನ್ನು ಲಾಗ್ ಮಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. (5) ಈ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ನೀವು ಸ್ವೀಕರಿಸುವ ಮಿತಿ ಮತ್ತು ನೈತಿಕ ತತ್ವವನ್ನು ಬರೆಯಿರಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು ಉತ್ಪಾದನಾ ಪೈಪ್‌ಲೈನ್‌ನ ಐದು ಪದರಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬಲ್ಲೆ.
• [ ] ನಾನು ಸ್ಕೀಮಾ, ನಿಯಮ ಮತ್ತು ಮೂಲದ ವಿರುದ್ಧ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಬಹುದು.
• [ ] ನಾನು ನಿರ್ಧಾರದ ಪ್ರಭಾವದ ಆಧಾರದ ಮೇಲೆ ಮಾನವ ಅನುಮೋದನೆಯ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಬಹುದು.
• [ ] ನಾನು ವೆಚ್ಚ, ದೋಷ ಮತ್ತು ಗುಣಮಟ್ಟವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇನೆ ಮತ್ತು ಲಾಗ್‌ಗಳಲ್ಲಿ ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಬರೆಯದೆ ಅಭ್ಯಾಸ ಮಾಡುತ್ತೇನೆ.
• [ ] ನಾನು ನೈತಿಕತೆ, ಜವಾಬ್ದಾರಿ ಮತ್ತು ಗಡಿಗಳನ್ನು ಉತ್ಪಾದನಾ ನಿರ್ಧಾರಗಳಾಗಿ ಪರಿವರ್ತಿಸಬಲ್ಲೆ.

ಮಾಡ್ಯೂಲ್ ಪರೀಕ್ಷೆ

1. LLM ಚಾಟ್ API ನಲ್ಲಿ 'ಸಿಸ್ಟಮ್' ಪಾತ್ರವು ಏನು ಮಾಡುತ್ತದೆ?

• A) ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಯ ಉದ್ದಕ್ಕೂ ಅನ್ವಯಿಸುವ ಮಾದರಿ ಶಾಶ್ವತ ಸೂಚನೆಗಳು ಮತ್ತು ನಡವಳಿಕೆಯ ನಿಯಮಗಳನ್ನು ನೀಡುತ್ತದೆ ✔
• ಬಿ) ಬಳಕೆದಾರರು ಬರೆದ ಕೊನೆಯ ಪ್ರಶ್ನೆಯನ್ನು ಇರಿಸುತ್ತದೆ
• ಸಿ) ಮಾದರಿಯಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ
• ಡಿ) API ಕೀಲಿಯನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ

ವಿವರಣೆ: ಸಿಸ್ಟಮ್ ಪಾತ್ರವು ಮಾದರಿಗೆ ನಿರಂತರ ಸೂಚನೆಗಳು, ವ್ಯಕ್ತಿತ್ವ ಮತ್ತು ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಯ ಉದ್ದಕ್ಕೂ ಅನ್ವಯಿಸುವ ನಿಯಮಗಳನ್ನು ನೀಡುತ್ತದೆ; ಇದು ಉನ್ನತ ಮಟ್ಟದ ಮರುನಿರ್ದೇಶನವಾಗಿದೆ, ಬಳಕೆದಾರರ ಸಂದೇಶಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿದೆ.

2. API ವಿನಂತಿಯಲ್ಲಿ ಪ್ರತಿ ಬಾರಿ ಸಂಭಾಷಣೆಯ ಇತಿಹಾಸವನ್ನು (ಹಿಂದಿನ ಸಂದೇಶಗಳು) ಏಕೆ ಕಳುಹಿಸಲಾಗಿದೆ?

• ಎ) ಸರ್ವರ್ ಇತಿಹಾಸವನ್ನು ಅಳಿಸಿದಂತೆ ಬ್ಯಾಕಪ್ ಮಾಡುವುದು ಅವಶ್ಯಕ
• ಬಿ) API ಕರೆಗಳು ಸ್ಥಿತಿಯಿಲ್ಲ; ✔ ಮಾದರಿಯು ಇತಿಹಾಸವನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳದ ಕಾರಣ ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲೂ ಸಂದರ್ಭವನ್ನು ಮರುಕಳುಹಿಸಲಾಗುತ್ತದೆ
• ಸಿ) ಇನ್‌ವಾಯ್ಸ್‌ಗೆ ಮಾತ್ರ ಅಗತ್ಯವಿದೆ, ಮಾದರಿಯ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ
• ಡಿ) ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ಇತಿಹಾಸವನ್ನು ಕಳುಹಿಸುವುದು ಕಡ್ಡಾಯವಾಗಿದೆ

ವಿವರಣೆ: LLM API ಕರೆಗಳು ಸ್ಥಿತಿಯಿಲ್ಲ; ಮಾದರಿಯು ಹಿಂದಿನ ಸುತ್ತುಗಳನ್ನು ನೆನಪಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಂದರ್ಭವನ್ನು ಸಂರಕ್ಷಿಸಲು ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲೆ ಎಲ್ಲಾ ಸಂಬಂಧಿತ ಇತಿಹಾಸವನ್ನು ಮರುಕಳಿಸಲಾಗುತ್ತದೆ.

3. LLM ಬೆಲೆಯಲ್ಲಿ 'ಟೋಕನ್' ಎಂದರೇನು?

• A) API ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಲು ಬಳಸುವ ಒಂದು-ಬಾರಿ ಪಾಸ್‌ವರ್ಡ್
• ಬಿ) ಪ್ರತಿ ವಿನಂತಿಯ ಮೇಲೆ ನಿಗದಿತ ಶುಲ್ಕವನ್ನು ಪಾವತಿಸಲಾಗುತ್ತದೆ
• ಸಿ) ಮಾದರಿಯು ಪಠ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಚಿಕ್ಕ ಘಟಕ; ಸಾಮಾನ್ಯವಾಗಿ ಪದ ಭಾಗ ✔ ಗೆ ಅನುರೂಪವಾಗಿದೆ
• ಡಿ) ಔಟ್‌ಪುಟ್‌ನ ಉದ್ದವನ್ನು ಮಾತ್ರ ಅಳೆಯುವ ಘಟಕ

ವಿವರಣೆ: ಟೋಕನ್ ಮಾದರಿಯು ಪಠ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಚಿಕ್ಕ ಘಟಕವಾಗಿದೆ; ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಪದದ ತುಣುಕಿಗೆ ಅನುರೂಪವಾಗಿದೆ ಮತ್ತು ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಧರಿಸಿ ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಎರಡನ್ನೂ ವಿಧಿಸಲಾಗುತ್ತದೆ.

4. ಹೆಚ್ಚಿನ LLM ಪೂರೈಕೆದಾರರಲ್ಲಿ ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳಿಗಿಂತ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಏಕೆ ಹೆಚ್ಚು ದುಬಾರಿಯಾಗಿದೆ?

• ಎ) ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಯಾವಾಗಲೂ ಇನ್‌ಪುಟ್‌ಗಿಂತ ಉದ್ದವಾಗಿರುತ್ತದೆ
• ಬಿ) ಇನ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಉಚಿತ
• ಸಿ) ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳನ್ನು ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಎರಡು ಬಾರಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ
• ಡಿ) ಯುನಿಟ್ ವೆಚ್ಚ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ ಏಕೆಂದರೆ ಔಟ್‌ಪುಟ್ ಉತ್ಪಾದನೆಗೆ ಪ್ರತಿ ಟೋಕನ್‌ಗೆ ಹೆಚ್ಚುವರಿ ಲೆಕ್ಕಾಚಾರಗಳು ಬೇಕಾಗುತ್ತವೆ ✔

ವಿವರಣೆ: ಪ್ರತಿಯೊಂದು ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳಿಗೆ ಮಾದರಿಯು ಹಂತ-ಹಂತದ ಉತ್ಪಾದನೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿದೆ (ಗಣನೆ); ಈ ಉತ್ಪಾದನಾ ವೆಚ್ಚವು ಇನ್‌ಪುಟ್ ಅನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಔಟ್‌ಪುಟ್ ಘಟಕದ ಬೆಲೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ.

5. ಯಾವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ?

• ಎ) ದೀರ್ಘ ಉತ್ತರಗಳಲ್ಲಿ; ಗ್ರಹಿಸಿದ ವಿಳಂಬವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಮಯ ಮೀರುವುದನ್ನು ತಡೆಯುತ್ತದೆ ✔
• ಬಿ) ಬಹಳ ಚಿಕ್ಕದಾದ, ಒಂದು ಪದದ ಉತ್ತರಗಳಲ್ಲಿ ಮಾತ್ರ
• ಸಿ) ವೆಚ್ಚವನ್ನು ಶೂನ್ಯಕ್ಕೆ ತಗ್ಗಿಸಲು
• ಡಿ) API ಕೀಲಿಯನ್ನು ಮರೆಮಾಡಲು

ವಿವರಣೆ: ದೀರ್ಘ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿ, ಸ್ಟ್ರೀಮಿಂಗ್ ಮೊದಲ ಪದಗಳನ್ನು ತಕ್ಷಣವೇ ಗೋಚರಿಸುವಂತೆ ಮಾಡುವ ಮೂಲಕ ಗ್ರಹಿಸಿದ ಸುಪ್ತತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ max_tokens ಮೌಲ್ಯಗಳಲ್ಲಿ HTTP ಸಮಯ ಮೀರುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

6. ಆಧುನಿಕ ಮಾದರಿಗಳಲ್ಲಿ 'ಪ್ರಯತ್ನ' ನಿಯತಾಂಕವನ್ನು ಹೆಚ್ಚಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?

• ಎ) ಉತ್ತರವನ್ನು ಯಾವಾಗಲೂ ಚಿಕ್ಕದಾಗಿಸಿ
• ಬಿ) API ಕೀಲಿಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ತಿರುಗಿಸುತ್ತದೆ
• ಸಿ) ಇದು ಇನ್‌ಪುಟ್ ಟೋಕನ್ ಬೆಲೆಯನ್ನು ಮಾತ್ರ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ
• ಡಿ) ಚಿಂತನೆಯ ಆಳ ಮತ್ತು ಟೋಕನ್ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ; ಇದು ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ ಇದು ಸುಪ್ತತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ✔

ವಿವರಣೆ: ಪ್ರಯತ್ನದ ನಿಯತಾಂಕವು ಮಾದರಿಯು ಕಾರ್ಯದ ಬಗ್ಗೆ ಎಷ್ಟು ಆಳವಾಗಿ ಯೋಚಿಸುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಹೊಂದಿಸುತ್ತದೆ; ನವೀಕರಣವು ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಬಹುದು, ಆದರೆ ಇದು ಸುಪ್ತತೆ ಮತ್ತು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಸರಳ ಕಾರ್ಯಗಳಿಗಾಗಿ, ಕಡಿಮೆ ಪ್ರಯತ್ನ ಸಾಕು.

7. ಸರಳವಾದ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ವರ್ಗೀಕರಣ ಕಾರ್ಯಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ವೆಚ್ಚ-ಪರಿಣಾಮಕಾರಿ ವಿಧಾನ ಯಾವುದು?

• ಎ) ಯಾವಾಗಲೂ ಅತ್ಯಂತ ದುಬಾರಿ ಮತ್ತು ಶಕ್ತಿಶಾಲಿ ಮಾದರಿಯನ್ನು ಬಳಸಿ
• ಬಿ) ಪ್ರತಿ ವಿನಂತಿಗೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಎಲ್ಲಾ ಮಾದರಿಗಳನ್ನು ಕರೆಯುವುದು
• ಸಿ) ಹಗುರವಾದ/ಅಗ್ಗದ ಮಾದರಿಯನ್ನು ಆಯ್ಕೆಮಾಡುವುದು, ಅದನ್ನು ಸ್ವಲ್ಪ ಮಟ್ಟದಿಂದ ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಕಾರ್ಯವನ್ನು ಸಾಧಿಸುವುದು ✔
• D) max_tokens ಮೌಲ್ಯವನ್ನು ಅನಗತ್ಯವಾಗಿ ಅತಿ ಹೆಚ್ಚು ಇರಿಸುವುದು

ವಿವರಣೆ: ಕಾರ್ಯವು ಸಂಕೀರ್ಣವಾಗಿಲ್ಲದಿದ್ದರೆ, ಅತ್ಯಂತ ದುಬಾರಿ ಮತ್ತು ಶಕ್ತಿಯುತ ಮಾದರಿಯನ್ನು ಬಳಸುವ ಬದಲು ಕೆಲಸವನ್ನು ಸುಲಭವಾಗಿ ಸಾಧಿಸುವ (ಉದಾಹರಣೆಗೆ ಹೈಕು ವರ್ಗ) ವೇಗವಾದ ಮತ್ತು ಅಗ್ಗದ ಮಾದರಿಯನ್ನು ಆರಿಸುವುದರಿಂದ ವೆಚ್ಚವನ್ನು ಗಣನೀಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

8. ಯಾವ ಸನ್ನಿವೇಶದಲ್ಲಿ ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶಿಂಗ್ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ?

• ಎ) ದೊಡ್ಡ ಮತ್ತು ಸ್ಥಿರ ಸಂದರ್ಭವನ್ನು ಅನೇಕ ವಿನಂತಿಗಳಲ್ಲಿ ಪದೇ ಪದೇ ಬಳಸಿದಾಗ ✔
• ಬಿ) ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ಪಠ್ಯವನ್ನು ಕಳುಹಿಸಿದಾಗ
• ಸಿ) ಒಂದೇ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ
• ಡಿ) ಔಟ್ಪುಟ್ ಟೋಕನ್ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು

ವಿವರಣೆ: ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯಾಗಿದೆ; ಅನೇಕ ವಿನಂತಿಗಳಲ್ಲಿ ದೊಡ್ಡದಾದ, ಬದಲಾಗದ ಸಂದರ್ಭವನ್ನು (ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು) ಮರುಬಳಕೆ ಮಾಡುವ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಂಗ್ರಹದಿಂದ ಓದುವುದು ಪೂರ್ಣ ಬೆಲೆಯ ಒಂದು ಸಣ್ಣ ಭಾಗವಾಗಿದೆ (~0.1x).

9. ಪ್ರಾಂಪ್ಟ್ ಕ್ಯಾಶ್ ಹಿಟ್ ಆಗುವಂತೆ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ನಾನು ಹೇಗೆ ಎಡಿಟ್ ಮಾಡಬೇಕು?

• ಎ) ವೇರಿಯಬಲ್ ವಿಷಯವನ್ನು ಆರಂಭದಲ್ಲಿ ಮತ್ತು ಸ್ಥಿರ ವಿಷಯವನ್ನು ಕೊನೆಯಲ್ಲಿ ಹಾಕುವುದು
• ಬಿ) ಪ್ರತಿ ವಿನಂತಿಗೆ ಸಿಸ್ಟಂ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಪ್ರಸ್ತುತ ದಿನಾಂಕ ಮತ್ತು ಸಮಯವನ್ನು ಎಂಬೆಡ್ ಮಾಡಿ
• ಸಿ) ಸ್ಥಿರ ವಿಷಯವನ್ನು (ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳು) ಆರಂಭದಲ್ಲಿ ಮತ್ತು ವೇರಿಯಬಲ್ ವಿಷಯವನ್ನು ಕೊನೆಯಲ್ಲಿ ಹಾಕುವುದು ✔
• ಡಿ) ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಪರಿಕರ ಪಟ್ಟಿಯ ಕ್ರಮವನ್ನು ಬದಲಾಯಿಸುವುದು

ವಿವರಣೆ: ಸಂಗ್ರಹವು ಪೂರ್ವಪ್ರತ್ಯಯ ಹೊಂದಾಣಿಕೆಯಾಗಿರುವುದರಿಂದ, ಸ್ಥಿರ/ಬದಲಾಗದ ವಿಷಯ (ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್, ದಾಖಲೆಗಳು) ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ; ವೇರಿಯಬಲ್ ವಿಷಯ (ದಿನಾಂಕ, ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆ, ವಿನಂತಿ ID) ಅನ್ನು ಕೊನೆಯಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾರಂಭದಲ್ಲಿ ಬದಲಾದ ಒಂದು ಬೈಟ್ ಕೂಡ ಸಂಗ್ರಹವನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ.

10. ಯಾವ ರೀತಿಯ ಕೆಲಸದ ಹೊರೆಗೆ ಬ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆಯು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ?

• ಎ) ಬಳಕೆದಾರರು ಪರದೆಯ ಮೇಲೆ ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವ ಲೈವ್ ಚಾಟ್
• ಬಿ) ಕೇವಲ ಒಂದು ಸಣ್ಣ ಪ್ರಶ್ನೆ
• ಸಿ) API ಕೀಲಿಯನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ
• D) ವಿಳಂಬ ಸಹಿಷ್ಣು, ದೊಡ್ಡ ಪ್ರಮಾಣದ ಮತ್ತು ತಕ್ಷಣದ ಫಲಿತಾಂಶಗಳ ಅಗತ್ಯವಿಲ್ಲದ ಉದ್ಯೋಗಗಳು ✔

ವಿವರಣೆ: ತಕ್ಷಣದ ಪ್ರತಿಕ್ರಿಯೆಯ ಅಗತ್ಯವಿಲ್ಲದ ಮತ್ತು ವಿಳಂಬವನ್ನು ಸಹಿಸಿಕೊಳ್ಳುವ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಉದ್ಯೋಗಗಳಿಗೆ ಬ್ಯಾಚ್ ಪ್ರಕ್ರಿಯೆಯು ಸೂಕ್ತವಾಗಿದೆ; ಫಲಿತಾಂಶಗಳನ್ನು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ತಲುಪಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಘಟಕದ ವೆಚ್ಚವು ಸಾಮಾನ್ಯವಾಗಿ ಕಡಿಮೆ ಇರುತ್ತದೆ.

11. ಫಲಿತಾಂಶಗಳು ಬ್ಯಾಚ್‌ನಲ್ಲಿ ಸೇರಿರುವ ವಿನಂತಿಯನ್ನು ಆತ್ಮವಿಶ್ವಾಸದಿಂದ ಹೊಂದಿಸಲು ಯಾವುದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ?

• ಎ) ವಿನಂತಿಗಳ ಆದೇಶ (ಸ್ಥಾನ) ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ
• ಬಿ) ಉತ್ತರಗಳ ಉದ್ದ
• ಸಿ) API ಕೀಲಿಯ ಕೊನೆಯ 4 ಅಂಕೆಗಳು
• D) ಪ್ರತಿ ವಿನಂತಿಗೆ ಒಂದು ಅನನ್ಯ ಕಸ್ಟಮ್_ಐಡಿ ನೀಡಲಾಗಿದೆ ✔

ಟಿಪ್ಪಣಿ: ಸಲ್ಲಿಕೆ ಆದೇಶಕ್ಕಿಂತ ವಿಭಿನ್ನ ಕ್ರಮದಲ್ಲಿ ಬೃಹತ್ ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು; ಆದ್ದರಿಂದ ಪ್ರತಿ ವಿನಂತಿಗೆ ನೀಡಿದ ಅನನ್ಯ ಕಸ್ಟಮ್_ಐಡಿಯೊಂದಿಗೆ ID ಯಿಂದ ಫಲಿತಾಂಶಗಳನ್ನು ಹೊಂದಿಸುವುದು ಅವಶ್ಯಕ, ಸ್ಥಳವಲ್ಲ.

12. ನೀವು API ನಿಂದ 429 (ದರ ಮಿತಿ) ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಶಿಫಾರಸು ಮಾಡಲಾದ ನಡವಳಿಕೆ ಏನು?

• ಎ) ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಒತ್ತಾಯಿಸುವುದು
• ಬಿ) ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್‌ನೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ, ಮರುಪ್ರಯತ್ನದ ನಂತರ ಶಿರೋನಾಮೆ ✔
• ಸಿ) ವಿನಂತಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ರದ್ದುಗೊಳಿಸಿ ಮತ್ತು ದೋಷವನ್ನು ಬಳಕೆದಾರರಿಗೆ ಕ್ರ್ಯಾಶ್ ಆಗಿ ತೋರಿಸಿ
• ಡಿ) API ಕೀಯನ್ನು ಬದಲಾಯಿಸುವುದು

ವಿವರಣೆ: 429 ಮರುಪ್ರಯತ್ನಿಸಬಹುದಾದ ದೋಷವಾಗಿದೆ; ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್‌ನೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಸರಿಯಾದ ವಿಧಾನವಾಗಿದೆ, ಮರುಪ್ರಯತ್ನದ ನಂತರ ಹೆಡರ್ ಅನ್ನು ಗೌರವಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಅಧಿಕೃತ SDK ಗಳು ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡುತ್ತವೆ.

13. ಕೆಳಗಿನ ಯಾವ HTTP ದೋಷ ಕೋಡ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮರುಪ್ರಯತ್ನಿಸಬಹುದೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ?

• ಎ) 400 (ಅಮಾನ್ಯ ವಿನಂತಿ)
• ಬಿ) 401 (ದೃಢೀಕರಣ ದೋಷ)
• ಸಿ) 529 (ಸರ್ವರ್ ಓವರ್‌ಲೋಡ್ ಆಗಿದೆ) ✔
• ಡಿ) 404 (ಕಂಡುಬಂದಿಲ್ಲ)

ವಿವರಣೆ: 429 (ವೇಗದ ಮಿತಿ), 500 (ಸರ್ವರ್ ದೋಷ) ಮತ್ತು 529 (ಓವರ್‌ಲೋಡ್) ತಾತ್ಕಾಲಿಕ ದೋಷಗಳಾಗಿವೆ ಮತ್ತು ಬ್ಯಾಕ್ ಆಫ್ ಮಾಡುವ ಮೂಲಕ ಮರುಪ್ರಯತ್ನಿಸಬಹುದು. 400 ಮತ್ತು 401 ರಂತಹ ದೋಷಗಳು ವಿನಂತಿ/ಗುರುತಿನ ಸಮಸ್ಯೆಗಳಾಗಿವೆ; ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿದರೂ ಅದು ಪರಿಹಾರವಾಗುವುದಿಲ್ಲ.

14. API ಕೀಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಈ ಕೆಳಗಿನವುಗಳಲ್ಲಿ ಯಾವುದು ಸುರಕ್ಷಿತ ಮಾರ್ಗವಾಗಿದೆ?

• ಎ) ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್/ಹಿಡನ್ ಮ್ಯಾನೇಜರ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು, ಕೋಡ್‌ನಲ್ಲಿ ಅದನ್ನು ಎಂಬೆಡ್ ಮಾಡದೆ ಮತ್ತು ನಿಯಮಿತವಾಗಿ ತಿರುಗುವುದು ✔
• ಬಿ) ಕೀಲಿಯನ್ನು ನೇರವಾಗಿ ಮೂಲ ಕೋಡ್‌ಗೆ ಬರೆಯಿರಿ ಮತ್ತು ಅದನ್ನು ರೆಪೊಸಿಟರಿಗೆ ಕಳುಹಿಸಿ
• ಸಿ) ಕ್ಲೈಂಟ್ ಸೈಡ್ (ಬ್ರೌಸರ್) ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್‌ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಹಾಕುವುದು
• ಡಿ) ಇಮೇಲ್ ಮೂಲಕ ಇಡೀ ತಂಡದೊಂದಿಗೆ ಒಂದೇ ಕೀಲಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದು

ವಿವರಣೆ: ಮೂಲ ಕೋಡ್ ಅಥವಾ ರೆಪೊಸಿಟರಿಗೆ ಕೀಲಿಗಳನ್ನು ಎಂದಿಗೂ ಬರೆಯಲಾಗುವುದಿಲ್ಲ; ಇದನ್ನು ಪರಿಸರ ವೇರಿಯಬಲ್ ಅಥವಾ ಗುಪ್ತ ನಿರ್ವಹಣಾ ಸಾಧನದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ, ಕನಿಷ್ಠ ಸವಲತ್ತುಗಳೊಂದಿಗೆ ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ನಿಯಮಿತವಾಗಿ ತಿರುಗಿಸಲಾಗುತ್ತದೆ.

15. ಗೌಪ್ಯತೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಸ್ವಯಂಚಾಲನ ಉಪಕರಣದೊಂದಿಗೆ (n8n, Zapier, Make) LLM ಏಕೀಕರಣಕ್ಕೆ ಉತ್ತಮ ವಿಧಾನ ಯಾವುದು?

• ಎ) ಎಲ್ಲಾ ಕಚ್ಚಾ ಡೇಟಾವನ್ನು ಮಾದರಿಗೆ ಕಳುಹಿಸುವುದು, ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೂ ಸಹ
• ಬಿ) ಹರಿವಿನ ಹಂತದ ಒಳಗೆ ಸರಳ ಪಠ್ಯದಲ್ಲಿ API ಕೀಲಿಯನ್ನು ಬರೆಯುವುದು
• ಸಿ) ಸೂಕ್ಷ್ಮ ಡೇಟಾವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮತ್ತು ಮರೆಮಾಚುವುದು ಮತ್ತು ಕೀಲಿಯನ್ನು ರಹಸ್ಯ ರುಜುವಾತುಗಳಾಗಿ ಸಂಗ್ರಹಿಸುವುದು ✔
• ಡಿ) ಹರಿವಿನ ಇತಿಹಾಸದಲ್ಲಿ ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು ಶಾಶ್ವತವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು

ವಿವರಣೆ: ಥರ್ಡ್-ಪಾರ್ಟಿ ಸಿಸ್ಟಮ್‌ಗಳು ಮತ್ತು ಮಾದರಿಯ ಮೂಲಕ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಡೇಟಾವನ್ನು ಪ್ರವೇಶಿಸುವುದರಿಂದ, ಸೂಕ್ಷ್ಮ/ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು ಕಡಿಮೆಗೊಳಿಸಬೇಕು, ಮುಖವಾಡ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಕ್ಷೇತ್ರಗಳನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಬೇಕು; API ಕೀಲಿಯನ್ನು ಸಹ ಟೂಲ್‌ನಲ್ಲಿ ರಹಸ್ಯ ರುಜುವಾತುಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ.

16. LLM ಆಧಾರಿತ ಉತ್ಪಾದನಾ ವೈಶಿಷ್ಟ್ಯದಲ್ಲಿ ಔಟ್‌ಪುಟ್‌ನ ಮೌಲ್ಯೀಕರಣವು ಏಕೆ ಕಡ್ಡಾಯವಾಗಿದೆ?

• ಎ) ಕೇವಲ ಫಾರ್ಮ್ಯಾಟಿಂಗ್ ಅಗತ್ಯವಿದೆ ಏಕೆಂದರೆ ಮಾದರಿಯು ಎಂದಿಗೂ ತಪ್ಪುಗಳನ್ನು ಮಾಡುವುದಿಲ್ಲ
• ಬಿ) ಏಕೆಂದರೆ ಮಾದರಿಯು ದ್ರವವಾಗಿ ಆದರೆ ಕೆಲವೊಮ್ಮೆ ತಪ್ಪಾಗಿ ಉತ್ಪಾದಿಸಬಹುದು; ಸ್ಕೀಮಾ/ನಿಯಮವನ್ನು ಸಂಪನ್ಮೂಲ ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆಯೊಂದಿಗೆ ಆಡಿಟ್ ಮಾಡಬೇಕು ✔
• ಸಿ) ಮೌಲ್ಯೀಕರಣವನ್ನು ತಪ್ಪಿಸಬೇಕು ಏಕೆಂದರೆ ಇದು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ
• ಡಿ) ಪರಿಶೀಲನೆಯು ಟೋಕನ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮಾತ್ರ

ವಿವರಣೆ: LLM ಗಳು ನಿರರ್ಗಳವಾಗಿ ಆದರೆ ಕೆಲವೊಮ್ಮೆ ತಪ್ಪಾದ (ಭ್ರಮೆಯ) ಔಟ್‌ಪುಟ್ ಅನ್ನು ಉತ್ಪಾದಿಸಬಹುದು; ಆದ್ದರಿಂದ ಇದು ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ನಿರ್ಧಾರಗಳಲ್ಲಿ ಹೊರಬಂದಿತು; ಅಗತ್ಯವಿದ್ದಾಗ ಸ್ಕೀಮಾ/ನಿಯಮಗಳ ಪರಿಶೀಲನೆ, ಮೂಲ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆ ಮತ್ತು ಮಾನವ ಅನುಮೋದನೆಯ ಮೂಲಕ ಅದನ್ನು ಆಡಿಟ್ ಮಾಡಬೇಕು.