ಲಾಭಗಳು:
- LLM API ವಿನಂತಿಯ ಮೂಲ ರಚನೆಯನ್ನು ವಿವರಿಸಬಹುದು (ಅಂತ್ಯಬಿಂದು, ಮಾದರಿ, ಸಂದೇಶಗಳು, max_tokens)
- ಸಿಸ್ಟಮ್, ಬಳಕೆದಾರ ಮತ್ತು ಸಹಾಯಕ ಪಾತ್ರಗಳು ಮತ್ತು ಸ್ಥಿತಿಯಿಲ್ಲದ ಸಂಭಾಷಣೆ ಇತಿಹಾಸದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ
- ಹಿಂತಿರುಗಿದ ಪ್ರತಿಕ್ರಿಯೆಯ ಕ್ಷೇತ್ರಗಳನ್ನು (ವಿಷಯ ಬ್ಲಾಕ್ಗಳು, stop_reason, ಬಳಕೆ) ಓದಬಹುದು ಮತ್ತು ಅರ್ಥೈಸಬಹುದು
ಹಿಂದಿನ ಮಾಡ್ಯೂಲ್ಗಳಲ್ಲಿ, ನಾವು ಚಾಟ್ ವಿಂಡೋದಿಂದ ಕೃತಕ ಬುದ್ಧಿಮತ್ತೆಯನ್ನು ಬಳಸಿದ್ದೇವೆ. ಆದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಉತ್ಪನ್ನ, ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಅಥವಾ ವರ್ಕ್ಫ್ಲೋಗೆ AI ಅನ್ನು ಎಂಬೆಡ್ ಮಾಡಲು ನೀವು ಬಯಸಿದರೆ, ಚಾಟ್ ಇಂಟರ್ಫೇಸ್ ಅದನ್ನು ಕಡಿತಗೊಳಿಸುವುದಿಲ್ಲ; ನೀವು ಪ್ರೋಗ್ರಾಮಿಕ್ ಆಗಿ ಮಾದರಿಯನ್ನು ಸಂಪರ್ಕಿಸಬೇಕು, ಅಂದರೆ, ಕೋಡ್ ಅಥವಾ ಯಾಂತ್ರೀಕೃತಗೊಂಡ ಉಪಕರಣದೊಂದಿಗೆ. ಈ ಸೇತುವೆಯ ಹೆಸರು API (ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್, ಎರಡು ಸಾಫ್ಟ್ವೇರ್ ಕೆಲವು ನಿಯಮಗಳೊಂದಿಗೆ ಮಾತನಾಡಲು ಅನುಮತಿಸುವ ಒಪ್ಪಂದ). ನೀವು ಈ ಘಟಕವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದಾಗ, LLM (ದೊಡ್ಡ ಭಾಷೆಯ ಮಾದರಿ) API ವಿನಂತಿಯನ್ನು ರೂಪಿಸುವುದು, ಸಂದೇಶದ ಪಾತ್ರಗಳು ಏನು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹೇಗೆ ಓದುವುದು ಎಂಬುದನ್ನು ನೀವು ತಿಳಿಯುವಿರಿ. ಉಳಿದ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ನಿರ್ಮಿಸುವ ಅಡಿಪಾಯ ಇದು.
API ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?
API ನಲ್ಲಿನ ಮೂಲ ಹರಿವು ಹೀಗಿದೆ: ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಸ್ವರೂಪದಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ; ಸರ್ವರ್ ನಿರ್ದಿಷ್ಟ ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುತ್ತದೆ. LLM ಗಳಲ್ಲಿ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ HTTP ಕರೆ (HTTP: ವೆಬ್ನಲ್ಲಿ ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸಾಗಿಸಲು ಪ್ರಮಾಣಿತ ಪ್ರೋಟೋಕಾಲ್) ಒಂದೇ ವಿಳಾಸಕ್ಕೆ (ಎಂಡ್ಪಾಯಿಂಟ್, ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್ನಲ್ಲಿನ ಸ್ಥಿರ ವಿಳಾಸ). ಉದಾಹರಣೆಗೆ, ಸಂದೇಶ ಕಳುಹಿಸುವ API ನಲ್ಲಿ, ಎಲ್ಲಾ ವಿನಂತಿಗಳು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ದೇಹದಲ್ಲಿ JSON (ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಆಬ್ಜೆಕ್ಟ್ ಸಂಕೇತ - ಮಾನವರು ಮತ್ತು ಯಂತ್ರಗಳೆರಡೂ ಓದಬಹುದಾದ ಕೀ/ಮೌಲ್ಯ ಜೋಡಿಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪಠ್ಯ ಸ್ವರೂಪ) ಎಂದು ಸಾಗಿಸಲಾಗುತ್ತದೆ.
ವಿನಂತಿಯಲ್ಲಿ, ನೀವು ಕನಿಷ್ಟ ಈ ಮೂರು ವಿಷಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ:
- ಮಾದರಿ: ನೀವು ಯಾವ ಮಾದರಿಯನ್ನು ಬಳಸುತ್ತೀರಿ (ಉದಾ. ವೇಗದ ಮತ್ತು ಅಗ್ಗದ ಮಾದರಿ ಅಥವಾ ಶಕ್ತಿಯುತ ಮಾದರಿ).
- max_tokens: ಮಾದರಿಯು ಉತ್ಪಾದಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಟೋಕನ್ಗಳು (ಪಠ್ಯವನ್ನು ಸಂಸ್ಕರಿಸುವ ಚಿಕ್ಕ ಘಟಕ, ಮುಂದಿನ ಘಟಕದಲ್ಲಿ ವಿವರವಾಗಿ ಸಂಸ್ಕರಿಸಲಾಗುತ್ತದೆ); ಅಂದರೆ ಔಟ್ಪುಟ್ ಮಿತಿ.
- ಸಂದೇಶಗಳು: ಸಂಭಾಷಣೆಯನ್ನು ರೂಪಿಸುವ ಸಂದೇಶಗಳ ಪಟ್ಟಿ.
ಹಂತ ಹಂತವಾಗಿ: ವಿನಂತಿಯನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು
- ಅಂತಿಮ ಬಿಂದು ಮತ್ತು ರುಜುವಾತುಗಳನ್ನು ತಯಾರಿಸಿ. ಶಿರೋಲೇಖದಲ್ಲಿನ ವಿನಂತಿಗೆ ನಿಮ್ಮ API ಕೀ (ನಿಮ್ಮ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸುವ ರಹಸ್ಯ ಸ್ಟ್ರಿಂಗ್) ಅನ್ನು ನೀವು ಸೇರಿಸುತ್ತೀರಿ. ನೀವು ಎಂದಿಗೂ ಕೋಡ್ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಎಂಬೆಡ್ ಮಾಡಿಲ್ಲ; ನಾವು ಘಟಕ 9 ರಲ್ಲಿ ಸುರಕ್ಷಿತ ಸಂಗ್ರಹಣೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತೇವೆ.
- ಮಾದರಿ ಮತ್ತು ಔಟ್ಪುಟ್ ಮಿತಿಯನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಸರಳವಾದ ಕಾರ್ಯಕ್ಕಾಗಿ ಹಗುರವಾದ ಮಾದರಿ + ಸಣ್ಣ max_tokens; ಸಂಕೀರ್ಣ ಕಾರ್ಯಕ್ಕಾಗಿ ಪ್ರಬಲ ಮಾದರಿ + ದೊಡ್ಡ ಮಿತಿ.
- ಸಂದೇಶ ಪಟ್ಟಿಯನ್ನು ಹೊಂದಿಸಿ. List the system instruction, user message, and past rounds (if any).
- ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ. ಹಿಂತಿರುಗಿದ JSON ನಿಂದ ಪಠ್ಯ ವಿಷಯವನ್ನು ಓದಿ, ಕಾರಣವನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಟೋಕನ್ ಬಳಕೆ.
ಸಂದೇಶ ಪಾತ್ರಗಳು: ಸಿಸ್ಟಮ್, ಬಳಕೆದಾರ, ಸಹಾಯಕ
ಸಂಭಾಷಣೆಯು ಒಂದು ಅನುಕ್ರಮದಲ್ಲಿ ಜೋಡಿಸಲಾದ ಸಂದೇಶಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ಸಂದೇಶವು ಒಂದು ಪಾತ್ರವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಮಾದರಿಯು ಪಠ್ಯವನ್ನು ಹೇಗೆ ಪರಿಗಣಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪಾತ್ರವು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಪಾತ್ರ
ಯಾರು ಬರೆಯುತ್ತಾರೆ
ಉದ್ದೇಶ
ವ್ಯವಸ್ಥೆ
ಡೆವಲಪರ್/ಆಪರೇಟರ್
ಸಂಪೂರ್ಣ ಸಂಭಾಷಣೆಯ ಉದ್ದಕ್ಕೂ ಅನ್ವಯವಾಗುವ ಶಾಶ್ವತ ಸೂಚನೆಗಳು, ವ್ಯಕ್ತಿತ್ವ ಮತ್ತು ನಿಯಮಗಳು
ಬಳಕೆದಾರ
ಅಂತಿಮ ಬಳಕೆದಾರ
ಬಳಕೆದಾರರ ಪ್ರಸ್ತುತ ಪ್ರಶ್ನೆ ಅಥವಾ ಇನ್ಪುಟ್
ಸಹಾಯಕ
ಮಾದರಿ
ಮಾದರಿಯಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಪ್ರತಿಕ್ರಿಯೆ (ಮತ್ತು ಹಿಂದಿನ ಪ್ರತಿಕ್ರಿಯೆಗಳು)
ಹೆಚ್ಚಿನ ಪೂರೈಕೆದಾರರಲ್ಲಿ ವಿನಂತಿಯ ದೇಹದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಪಾತ್ರವು ಪ್ರತ್ಯೇಕ ಸಿಸ್ಟಮ್ ಕ್ಷೇತ್ರವಾಗಿ ಲಭ್ಯವಿದೆ; ಸಂದೇಶಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಬಳಕೆದಾರರು ಮತ್ತು ಸಹಾಯಕರನ್ನು ಅನುಕ್ರಮವಾಗಿ ಪಟ್ಟಿಮಾಡಲಾಗಿದೆ. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "ನೀವು ಕಾರ್ಪೊರೇಟ್ ಬೆಂಬಲ ಸಹಾಯಕರಾಗಿದ್ದೀರಿ. ಚಿಕ್ಕದಾದ, ಔಪಚಾರಿಕ ಮತ್ತು ಪರಿಶೀಲಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡಿ. ನಿಮಗೆ ಖಚಿತವಾಗಿರದ ಮಾಹಿತಿಯನ್ನು ರಚಿಸಬೇಡಿ.", "ಸಂದೇಶಗಳು": [ { "role": "ಬಳಕೆದಾರ": "ನಾನು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕೇ?" } ]}
ಮಾತು ಸ್ಥಿತಿಯಿಲ್ಲ
ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆ ಇಲ್ಲಿದೆ: LLM API ಕರೆಗಳು ಸ್ಥಿತಿಯಿಲ್ಲ - ಎರಡು ವಿನಂತಿಗಳ ನಡುವೆ ಸರ್ವರ್ ಯಾವುದೇ ಮೆಮೊರಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ನಿಮ್ಮ ಹಿಂದಿನ ವಿನಂತಿಯನ್ನು ಮಾಡೆಲ್ ನೆನಪಿಲ್ಲ. ನೀವು ಬಹು ಸುತ್ತಿನ ಚಾಟ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತಿದ್ದರೆ, ಪ್ರತಿ ಹೊಸ ವಿನಂತಿಯೊಂದಿಗೆ ನೀವು ಹಿಂದಿನ ಸುತ್ತುಗಳನ್ನು ಮರುಕಳುಹಿಸಬೇಕಾಗುತ್ತದೆ. ಮಾದರಿಯ "ಮೆಮೊರಿ" ನೀವು ಕಳುಹಿಸಿದ ಸಂದೇಶಗಳ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿದೆ.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Hello, my name is Deniz." }, { "role": "ಸಹಾಯಕ", "ವಿಷಯ": "ಹಲೋ ಡೆನಿಜ್, ನಾನು ನಿಮಗೆ ಹೇಗೆ ಸಹಾಯ ಮಾಡಬಹುದು?" }, { "role": "user", "content": "ನಾನು ನನ್ನ ಹೆಸರನ್ನು ಹೇಳಿದ್ದೇನೆ, ನಿಮಗೆ ನೆನಪಿದೆಯೇ?" } ]}
ಮೂರನೇ ಸಂದೇಶಕ್ಕೆ ಸರಿಯಾಗಿ ಉತ್ತರಿಸುವುದು ನೀವು ಹಿಂದಿನ ಎರಡೂ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ನೀವು ಅದನ್ನು ಕಳುಹಿಸದಿದ್ದರೆ, ಮಾದರಿಯು "ಸಮುದ್ರ" ತಿಳಿದಿರುವುದಿಲ್ಲ ಮತ್ತು ತಪ್ಪಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಇದು ನೇರವಾಗಿ ವೆಚ್ಚದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ: ದೀರ್ಘ ಸಂಭಾಷಣೆ, ದೊಡ್ಡ ಪಟ್ಟಿ, ಪ್ರತಿ ವಿನಂತಿಯು ಹೆಚ್ಚು ಟೋಕನ್ಗಳನ್ನು ಸೇವಿಸುತ್ತದೆ.
ಸಲಹೆ: ಸುದೀರ್ಘ ಸಂಭಾಷಣೆಗಳಲ್ಲಿ, ಸಂಪೂರ್ಣ ಇತಿಹಾಸವನ್ನು ಕಳುಹಿಸುವ ಬದಲು ಹಳೆಯ ಸುತ್ತುಗಳನ್ನು (ಸಾರಾಂಶ + ಕೊನೆಯ ಕೆಲವು ಸುತ್ತುಗಳು) ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸುವುದು ಮತ್ತು ಚಲಿಸುವುದು ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಂದರ್ಭ ವಿಂಡೋವನ್ನು ಸಂರಕ್ಷಿಸುತ್ತದೆ. ನಾವು ಇದನ್ನು 6 ಮತ್ತು 11 ಘಟಕಗಳಲ್ಲಿ ಆಳಗೊಳಿಸುತ್ತೇವೆ.
ಉತ್ತರವನ್ನು ಓದಿ
ಮಾದರಿಯು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂದಿರುಗಿಸಿದಾಗ, ನೀವು ರಚನಾತ್ಮಕ ವಸ್ತುವನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ, ಸರಳ ಪಠ್ಯವಲ್ಲ. ವಿಶಿಷ್ಟ ಪ್ರದೇಶಗಳು:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "ರಿಟರ್ನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು, ನಿಮ್ಮ ಖಾತೆಯಲ್ಲಿ 'ನನ್ನ ಆರ್ಡರ್ಗಳು' ಪುಟಕ್ಕೆ ಹೋಗಿ... } } "input_tokens": 47, "output_tokens": 88 }}
- ವಿಷಯ: ಪ್ರತಿಕ್ರಿಯೆ ಸ್ವತಃ; ಇದು ಕಂಟೆಂಟ್ ಬ್ಲಾಕ್ಗಳ ಪಟ್ಟಿಯಾಗಿದೆ. ಪಠ್ಯ ಬ್ಲಾಕ್ನ ಪಠ್ಯ ಕ್ಷೇತ್ರವು ನಿಜವಾದ ಉತ್ತರವಾಗಿದೆ.
- ನಿಲ್ಲಿಸು_ಕಾರಣ: ಮಾದರಿ ಏಕೆ ನಿಲ್ಲಿಸಿತು. end_turn = ನೈಸರ್ಗಿಕ ಅಂತ್ಯ; max_tokens = ಔಟ್ಪುಟ್ ಮಿತಿಯಲ್ಲಿ ಸಿಲುಕಿಕೊಂಡಿದೆ (ಪ್ರತಿಕ್ರಿಯೆ ಅಪೂರ್ಣವಾಗಿರಬಹುದು); ನಿರಾಕರಣೆ = ಭದ್ರತಾ ಕಾರಣಗಳಿಗಾಗಿ ನಿರಾಕರಿಸಲಾಗಿದೆ. ನಿಮ್ಮ ಕೋಡ್ ಯಾವಾಗಲೂ stop_reason ಅನ್ನು ಮೊದಲು ನೋಡಬೇಕು.
- ಬಳಕೆ: ಇನ್ಪುಟ್ ಮತ್ತು ಔಟ್ಪುಟ್ ಟೋಕನ್ ಸಂಖ್ಯೆಗಳು. ಇದು ವೆಚ್ಚ ಮತ್ತು ಮಿತಿ ಟ್ರ್ಯಾಕಿಂಗ್ನ ಆಧಾರವಾಗಿದೆ.
ಗಮನ: stop_reason max_tokens ಆಗಿದ್ದರೆ, ಪ್ರತಿಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಂಡಿಲ್ಲ. ಇದನ್ನು "ಯಶಸ್ವಿ ಪ್ರತಿಕ್ರಿಯೆ" ಎಂದು ಪರಿಗಣಿಸುವುದು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಅರ್ಧ ಪಠ್ಯವನ್ನು ತೋರಿಸುವುದು ಉತ್ಪಾದನೆಯಲ್ಲಿನ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಒಂದೋ max_tokens ಹೆಚ್ಚಿಸಿ ಅಥವಾ ಸ್ಟ್ರೀಮಿಂಗ್ ಬಳಸಿ.
ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್
ಎರಡು ವಿಭಿನ್ನ ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ಗಳೊಂದಿಗೆ ಒಂದೇ ಕಾರ್ಯ:
# ದುರ್ಬಲ ನೀವು ಸಹಾಯಕರು. ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಿ.
# STRONGನೀವು ಕಾರ್ಪೊರೇಟ್ ಬೆಂಬಲ ಸಹಾಯಕರು. ನಿಯಮಗಳು:- ಒದಗಿಸಿದ ಪಾಲಿಸಿ ಡಾಕ್ಯುಮೆಂಟ್ನಲ್ಲಿನ ಮಾಹಿತಿಯನ್ನು ಮಾತ್ರ ಅವಲಂಬಿಸಿ; ಇದು ಡಾಕ್ಯುಮೆಂಟ್ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, "ನನ್ನ ಬಳಿ ಈ ಮಾಹಿತಿ ಇಲ್ಲ, ನಾನು ಅದನ್ನು ಸಂಬಂಧಿತ ಘಟಕಕ್ಕೆ ನಿರ್ದೇಶಿಸುತ್ತಿದ್ದೇನೆ" ಎಂದು ಹೇಳಿ. - ಉತ್ತರಗಳು 3 ವಾಕ್ಯಗಳನ್ನು ಮೀರಬಾರದು, ಔಪಚಾರಿಕ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕು. - ವೈಯಕ್ತಿಕ ಡೇಟಾವನ್ನು ಕೇಳಬೇಡಿ (TC ID ಸಂಖ್ಯೆ, ಕಾರ್ಡ್ ಸಂಖ್ಯೆ) ಮತ್ತು ಪುನರಾವರ್ತಿಸಬೇಡಿ. - ನೀವು ಖಚಿತವಾಗಿರದಿದ್ದಾಗ ಊಹಿಸಬೇಡಿ.
ಶಕ್ತಿಯುತ ಆವೃತ್ತಿ; ಇದು ವ್ಯಾಪ್ತಿ, ರೂಪ, ಸುರಕ್ಷತೆ ಅಂಚು ಮತ್ತು ಅನಿಶ್ಚಿತತೆಯ ನಡವಳಿಕೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ. ಮಾದರಿಯ ಔಟ್ಪುಟ್ನ ಸ್ಥಿರತೆ ಈ ಸ್ಪಷ್ಟತೆಯಿಂದ ನೇರವಾಗಿ ಬರುತ್ತದೆ.
ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು
ಪ್ರಕರಣ 1 - ಬೆಂಬಲ ಬೋಟ್ (ಸ್ಟೇಟ್ಲೆಸ್ನೆಸ್ ಟ್ರ್ಯಾಪ್). ಇ-ಕಾಮರ್ಸ್ ತಂಡವು ಬೋಟ್ ಅನ್ನು ನೇರಪ್ರಸಾರ ಮಾಡಿದೆ; ಬಳಕೆದಾರರು "ಹಿಂದಿನ ಆದೇಶವನ್ನು ರದ್ದುಮಾಡಿ" ಎಂದು ಹೇಳಿದಾಗ, ಬೋಟ್ ಆರ್ಡರ್ ಸಂಖ್ಯೆಯನ್ನು "ಮರೆತಿದೆ". ಕಾರಣ: ಅವರು ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಕೊನೆಯ ಸಂದೇಶದೊಂದಿಗೆ ಮಾತ್ರ ಕಳುಹಿಸುತ್ತಿದ್ದರು. ಪರಿಹಾರ: ಅವರು ಕೊನೆಯ 6 ಸುತ್ತುಗಳನ್ನು ಸಂದೇಶಗಳ ಪಟ್ಟಿಗೆ ಸೇರಿಸಿದ್ದಾರೆ. ಫಲಿತಾಂಶ: ಸಂದರ್ಭವನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ, ಆದರೆ ಪ್ರತಿ ವಿನಂತಿಯ ಇನ್ಪುಟ್ ಅನ್ನು 40 ಟೋಕನ್ಗಳಿಂದ ~600 ಟೋಕನ್ಗಳಿಗೆ ಹೆಚ್ಚಿಸಲಾಗಿದೆ - ನಾವು ಘಟಕ 2 ರಲ್ಲಿ ವೆಚ್ಚದ ಪಾಠವನ್ನು ಕವರ್ ಮಾಡುತ್ತೇವೆ.
ಪ್ರಕರಣ 2 - ಅಪೂರ್ಣ ಒಪ್ಪಂದದ ಸಾರಾಂಶ. ಕಾನೂನು ತಂಡವು 10-ಪುಟದ ಒಪ್ಪಂದಗಳನ್ನು ವಿವರಿಸಿದೆ; max_tokens: 300 ಕಡಿಮೆ ಉಳಿದಿದೆ, ಸಾರಾಂಶಗಳು ಮಧ್ಯ ವಾಕ್ಯವನ್ನು ಕತ್ತರಿಸುತ್ತಿವೆ. stop_reason ಪ್ರತಿ ಬಾರಿಯೂ max_tokens ಆಗಿತ್ತು ಆದರೆ ಯಾರೂ ನೋಡುತ್ತಿರಲಿಲ್ಲ. ಗರಿಷ್ಠ_ಟೋಕನ್ಗಳನ್ನು 1500ಕ್ಕೆ ಹೆಚ್ಚಿಸಲಾಗಿದೆ ಮತ್ತು ನಿಲ್ಲಿಸುವ_ಕಾರಣ ಪರಿಶೀಲನೆಯನ್ನು ಸೇರಿಸಲಾಗಿದೆ; ಮೊಟಕುಗೊಳಿಸಿದ ಸಾರಾಂಶ ದರವು 18% ರಿಂದ 0% ಕ್ಕೆ ಕಡಿಮೆಯಾಗಿದೆ.
ಪ್ರಕರಣ 3 - ಮಿಕ್ಸಿಂಗ್ ಪಾತ್ರಗಳು. ಮಾರ್ಕೆಟಿಂಗ್ ತಂಡವು ಬಳಕೆದಾರರ ಸಂದೇಶಕ್ಕೆ ಎಲ್ಲಾ ಸೂಚನೆಗಳನ್ನು ಬರೆಯುತ್ತಿದೆ, ಸಿಸ್ಟಮ್ ಅನ್ನು ಖಾಲಿ ಬಿಡುತ್ತಿದೆ. ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ಸೂಚನೆಯೊಂದಿಗೆ ಬೆರೆಸಿದಾಗ, ಮಾದರಿಯು ಕೆಲವೊಮ್ಮೆ "ಹಿಂದಿನ ನಿಯಮಗಳನ್ನು ಮರೆತುಬಿಡಿ" ಎಂಬ ಬಳಕೆದಾರರ ಆಜ್ಞೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ. ಅವರು ಶಾಶ್ವತ ನಿಯಮಗಳನ್ನು ವ್ಯವಸ್ಥೆಗೆ ಸ್ಥಳಾಂತರಿಸಿದರು; ಸೂಚನೆಯಿಂದ ಬಳಕೆದಾರರ ಇನ್ಪುಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ, ನಿಯಮ ಉಲ್ಲಂಘನೆಗಳು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ.
ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ಹಿಂದಿನದನ್ನು ಕಳುಹಿಸಲು ಮರೆಯುವುದು: ಮಾದರಿಯನ್ನು "ನೆನಪಿಲ್ಲ" ಎಂದು ಭಾವಿಸಲಾಗಿದೆ; ಆದರೆ ಅದು ಸ್ಥಿತಿಯಿಲ್ಲ. ನೀವು ಸಂದರ್ಭವನ್ನು ಒಯ್ಯುತ್ತೀರಿ.
- `stop_reason` ಅನ್ನು ನೋಡುತ್ತಿಲ್ಲ: max_tokens ನೊಂದಿಗೆ ನಿಲ್ಲಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ.
- `ಬಳಕೆದಾರ` ನಲ್ಲಿ ಸೂಚನೆಯನ್ನು ಎಂಬೆಡ್ ಮಾಡುವುದು: ಸಿಸ್ಟಮ್ನಲ್ಲಿ ನಿರಂತರ ನಿಯಮಗಳು; ತ್ವರಿತ ಇನ್ಪುಟ್ ಬಳಕೆದಾರರಿಗೆ ಹೋಗುತ್ತದೆ. ಮಿಶ್ರಣವು ಭದ್ರತಾ ದೋಷಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
- ಸರಳ ಸ್ಟ್ರಿಂಗ್ಗೆ `ವಿಷಯ~ ತಪ್ಪಾಗಿ: ಉತ್ತರವು ಬ್ಲಾಕ್ಗಳ ಪಟ್ಟಿಯಾಗಿದೆ; ಮೊದಲ ಪಠ್ಯ ಬ್ಲಾಕ್ನ ಪಠ್ಯ ಕ್ಷೇತ್ರವನ್ನು ಓದಿ, ಕುರುಡು ಸೂಚ್ಯಂಕದೊಂದಿಗೆ ವಿಷಯವನ್ನು[0] ಪಡೆಯುವ ಮೊದಲು ಅದರ ಪ್ರಕಾರವನ್ನು ಪರಿಶೀಲಿಸಿ.
- ಕೋಡ್ನಲ್ಲಿ ಕೀಲಿಯನ್ನು ಎಂಬೆಡ್ ಮಾಡುವುದು: ಪರಿಸರ ವೇರಿಯಬಲ್ ಅನ್ನು ಬಳಸಿ (ಘಟಕ 9).
ಆಳವಾದ: ಕಂಟೆಂಟ್ ಬ್ಲಾಕ್ಗಳು ಮತ್ತು ಬಹು-ಭಾಗ ಉತ್ತರಗಳು
ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿನ ವಿಷಯ ಕ್ಷೇತ್ರವು ಏಕೆ ಪಟ್ಟಿಯಾಗಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನೀವು ನಂತರ ಎದುರಿಸುವ ಸುಧಾರಿತ ವೈಶಿಷ್ಟ್ಯಗಳಿಗೆ ಮೂಲಭೂತವಾಗಿದೆ. ಕೆಲವೊಮ್ಮೆ ಮಾದರಿಯು ಪಠ್ಯದ ಒಂದು ಬ್ಲಾಕ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದರೆ ಹಲವಾರು ಬ್ಲಾಕ್ಗಳನ್ನು ನೀಡುತ್ತದೆ: ಚಿಂತನೆಯ ಬ್ಲಾಕ್, ನಂತರ ಪಠ್ಯದ ಬ್ಲಾಕ್; ಅಥವಾ ಟೂಲ್ ಯೂಸ್ ಬ್ಲಾಕ್ ನಂತರ ಪಠ್ಯದ ಬ್ಲಾಕ್. ಅದಕ್ಕಾಗಿಯೇ ವಿಷಯವನ್ನು[0] "ಉತ್ತರ" ಎಂದು ಕುರುಡಾಗಿ ಎಣಿಸುವುದು ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಪಟ್ಟಿಯ ಮೂಲಕ ಹೋಗಿ ಅದನ್ನು ಪ್ರಕಾರವಾಗಿ ವಿಂಗಡಿಸುವುದು ಸರಿಯಾದ ವಿಧಾನವಾಗಿದೆ: ನೀವು ಬ್ಲಾಕ್ಗಳ ಪಠ್ಯ ವಿಷಯವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೀರಿ, ಅದರ ಪ್ರಕಾರದ ಕ್ಷೇತ್ರ ಪಠ್ಯವಾಗಿದೆ ಮತ್ತು ಇತರ ಪ್ರಕಾರಗಳನ್ನು (ಚಿಂತನೆ, ಸಾಧನ) ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಗಣಿಸಿ.
ಈ ವ್ಯತ್ಯಾಸವು ಆಚರಣೆಯಲ್ಲಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂದರೆ ನೀವು ಮಾದರಿಯ ತಾರ್ಕಿಕತೆಯನ್ನು (ಯಾವುದಾದರೂ ಇದ್ದರೆ) ಬಳಕೆದಾರರಿಗೆ ಬಹಿರಂಗಪಡಿಸದೆಯೇ ಲಾಗ್ ಮಾಡಬಹುದು, ಪ್ರತ್ಯೇಕ ತರ್ಕಕ್ಕೆ ಮರುನಿರ್ದೇಶನ ಸಾಧನ ಕರೆಗಳು ಮತ್ತು ಪರದೆಯ ಮೇಲೆ ನಿಜವಾದ ಉತ್ತರವನ್ನು ಮಾತ್ರ ಮುದ್ರಿಸಬಹುದು. ಮಾಡ್ಯೂಲ್ ಮುಂದುವರೆದಂತೆ (ವಿಶೇಷವಾಗಿ 4 ಮತ್ತು 11 ಘಟಕಗಳಲ್ಲಿ) ಈ ಬ್ಲಾಕ್ ರಚನೆಯು ಔಟ್ಪುಟ್ ಅನ್ನು ಮೌಲ್ಯೀಕರಿಸಲು ಮತ್ತು ನಿರ್ದೇಶಿಸಲು ಎಷ್ಟು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡುತ್ತೀರಿ.
ಮತ್ತೊಂದು ಪ್ರಾಯೋಗಿಕ ಅಂಶ: ನೀವು ವಿವಿಧ ಪೂರೈಕೆದಾರರ ವೇದಿಕೆಗಳಿಂದ ಒಂದೇ ಮಾದರಿಯನ್ನು ಪ್ರವೇಶಿಸಬಹುದು (ನೇರ API, ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ ಮೂಲಕ). ಎಂಡ್ಪಾಯಿಂಟ್ ವಿಳಾಸ ಮತ್ತು ದೃಢೀಕರಣದ ಸ್ವರೂಪವು ಬದಲಾಗಬಹುದಾದರೂ, ಸಂದೇಶ ಪಾತ್ರಗಳು, ಸ್ಥಿತಿಯಿಲ್ಲದಿರುವಿಕೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ರಚನೆಯಂತಹ ಮೂಲಭೂತ ಪರಿಕಲ್ಪನೆಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ. ಆದ್ದರಿಂದ ನೀವು ಯಾವುದೇ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಿದರೂ ಈ ಘಟಕದಲ್ಲಿನ ಮೂಲಭೂತ ಅಂಶಗಳು ಅನ್ವಯಿಸುತ್ತವೆ.
ಸಾರಾಂಶದಲ್ಲಿ
LLM API ವಿನಂತಿಯು ಮಾದರಿ, ಔಟ್ಪುಟ್ ಮಿತಿ ಮತ್ತು ಸಂದೇಶ ಪಟ್ಟಿಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ; ಪಾತ್ರಗಳು (ಸಿಸ್ಟಮ್, ಬಳಕೆದಾರ, ಸಹಾಯಕ) ಮಾದರಿಯ ನಡವಳಿಕೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಕರೆಗಳು ಸ್ಥಿತಿಯಿಲ್ಲ: ನೀವು ಪ್ರತಿ ವಿನಂತಿಯೊಂದಿಗೆ ಸಂದರ್ಭವನ್ನು ಕೊಂಡೊಯ್ಯುತ್ತೀರಿ. ಪ್ರತಿಕ್ರಿಯೆಯು ರಚನಾತ್ಮಕ ವಸ್ತುವಾಗಿದೆ; ವಿಷಯವನ್ನು ಓದುವುದು ಮತ್ತು ಅರ್ಥೈಸುವುದು, ನಿಲ್ಲಿಸು_ಕಾರಣ ಮತ್ತು ಬಳಕೆಯ ಕ್ಷೇತ್ರಗಳು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಾಳಿಕೆಯ ಆಧಾರವಾಗಿದೆ.
ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ
ನಿಮ್ಮ ಸ್ವಂತ ವೃತ್ತಿಯಿಂದ ಕಾರ್ಯವನ್ನು ಆಯ್ಕೆಮಾಡಿ (ಉದಾ. ಒಳಬರುವ ಇಮೇಲ್ ಅನ್ನು ವಿಂಗಡಿಸುವುದು, ಸಂಕ್ಷಿಪ್ತ ಸಾರಾಂಶಗಳನ್ನು ರಚಿಸುವುದು). ಕಾಗದದ ತುಂಡು ಮೇಲೆ: (1) ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು 4-5 ನಿಯಮಗಳೊಂದಿಗೆ ಬರೆಯಿರಿ, (2) ಮಾದರಿ ಬಳಕೆದಾರ ಸಂದೇಶವನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ಯಾವುದಾದರೂ 2 ಸುತ್ತಿನ ಇತಿಹಾಸವನ್ನು ಹೊಂದಿಸಿ, (3) max_tokens ಗಾಗಿ ಸಮಂಜಸವಾದ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಿ ಮತ್ತು ಸಮರ್ಥನೆಯನ್ನು ಬರೆಯಿರಿ, (4) ಹಿಂತಿರುಗಿದ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು ಯಾವ stop_reason ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತೀರಿ ಮತ್ತು ಹೇಗೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ.
ಪರಿಶೀಲನಾಪಟ್ಟಿ
- [ ] ನಾನು ವಿನಂತಿಯ ಮೂರು ಕಡ್ಡಾಯ ಭಾಗಗಳನ್ನು ಎಣಿಸಬಹುದು (ಮಾದರಿ, max_tokens, ಸಂದೇಶಗಳು).
- [ ] ಸಿಸ್ಟಮ್, ಬಳಕೆದಾರ ಮತ್ತು ಸಹಾಯಕ ಪಾತ್ರಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ನಾನು ವಿವರಿಸಬಲ್ಲೆ.
- [ ] ಕರೆಗಳು ಸ್ಥಿತಿಯಿಲ್ಲವೆಂದು ನನಗೆ ತಿಳಿದಿದೆ ಮತ್ತು ನಾನು ಹಿಂದಿನದನ್ನು ಸಾಗಿಸಬೇಕಾಗಿದೆ.
- ನಾನು [ ] ವಿಷಯ, stop_reason ಮತ್ತು ಬಳಕೆಯ ಕ್ಷೇತ್ರಗಳನ್ನು ಓದಬಹುದು ಮತ್ತು ಕಾಮೆಂಟ್ ಮಾಡಬಹುದು.
- [ ] max_tokens ನೊಂದಿಗೆ ನಾನು ಮೊಟಕುಗೊಳಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಗಮನಿಸಬಹುದು ಮತ್ತು ನಿರ್ವಹಿಸಬಹುದು.