AI ಏಜೆಂಟ್‌ಗಳು ಮತ್ತು ಟೂಲ್ ಬಳಕೆ

ಲಾಭಗಳು:

• ಏಜೆಂಟ್ ಅನ್ನು 'ಮಾದರಿ + ಉಪಕರಣಗಳು + ಲೂಪ್' ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುವುದು ಮತ್ತು ಅದು ಯಾವಾಗ ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವುದು
• ಹೆಸರು, ವಿವರಣೆ ಮತ್ತು ಇನ್ಪುಟ್_ಸ್ಕೀಮಾದೊಂದಿಗೆ ಉಪಕರಣದ ವ್ಯಾಖ್ಯಾನವನ್ನು ಬರೆಯುವುದು
• Tool_use ಮತ್ತು tool_result ಲೂಪ್‌ನ ಹರಿವು ಮತ್ತು ದೋಷ ನಿರ್ವಹಣೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು

ಇಲ್ಲಿಯವರೆಗೆ, ಮಾದರಿಯು ಯಾವಾಗಲೂ ಒಂದು ಕೆಲಸವನ್ನು ಮಾಡಿದೆ: ಪಠ್ಯ ಇನ್ಪುಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ಪಠ್ಯ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಉತ್ಪಾದಿಸಿ. ಆದರೆ ನೈಜ ಕೆಲಸವು ಸಾಮಾನ್ಯವಾಗಿ ಪಠ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಬಯಸುತ್ತದೆ; ಲೆಕ್ಕಾಚಾರವನ್ನು ನಿರ್ವಹಿಸುವುದು, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುವುದು, API ಗೆ ಕರೆ ಮಾಡುವುದು, ಪ್ರಸ್ತುತ ವಿನಿಮಯ ದರವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು. ಮಾಡೆಲ್ ಈ ಕೆಲಸಗಳನ್ನು ಸ್ವತಃ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ - ಆದರೆ ಅವುಗಳನ್ನು ಯಾವಾಗ ಮಾಡಬೇಕೆಂದು ಅವಳು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಮಾಡಲು ಯಾರನ್ನಾದರೂ ಕೇಳಬಹುದು. ಇದು ಉಪಕರಣದ ಬಳಕೆಯು ಮಾದರಿಯನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ಇದು AI ಏಜೆಂಟ್‌ಗಳ ಆಧಾರವಾಗಿದೆ. ಈ ಘಟಕದಲ್ಲಿ, ಏಜೆಂಟ್ ಎಂದರೇನು, ಉಪಕರಣವನ್ನು ಹೇಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಮತ್ತು tool_use ಲೂಪ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ಕಲಿಯುತ್ತೇವೆ.

ಏಜೆಂಟ್ ಎಂದರೇನು? ಮಾದರಿ + ಪರಿಕರಗಳು + ಲೂಪ್

AI ಏಜೆಂಟ್ ಮೂರು ಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ಮಾದರಿ (ನಿರ್ಧಾರ ಮಾಡುವ ಮೆದುಳು), ಉಪಕರಣಗಳು (ಮಾದರಿಯು ಕರೆಯಬಹುದಾದ ಕಾರ್ಯಗಳು: ಹವಾಮಾನ, ಡೇಟಾಬೇಸ್ ಪ್ರಶ್ನೆ, ಇಮೇಲ್ ಕಳುಹಿಸು), ಮತ್ತು ಲೂಪ್ (ಲೂಪ್; ಮಾದರಿಯು ಉಪಕರಣವನ್ನು ಕರೆಯುತ್ತದೆ, ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುತ್ತದೆ, ಏನು ಮಾಡಬೇಕೆಂದು ಮತ್ತೆ ನಿರ್ಧರಿಸುತ್ತದೆ, ಇತ್ಯಾದಿ).

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

ಒಂದು ಪ್ರಮುಖ ಸಂಗತಿ: ಮಾದರಿಯು ಸ್ವತಃ ವಾಹನವನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಮಾದರಿಯು ಕೇವಲ "ನಾನು ಈ ಇನ್‌ಪುಟ್‌ಗಳೊಂದಿಗೆ ಈ ಉಪಕರಣವನ್ನು ಕರೆಯಲು ಬಯಸುತ್ತೇನೆ" ಎಂದು ಹೇಳುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ (ಸರಂಜಾಮು ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ) ಉಪಕರಣವನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಮಾದರಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಭದ್ರತೆಗೆ ಇದು ಅತ್ಯಗತ್ಯ: ಮಾದರಿಯು ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಅನ್ನು ನೇರವಾಗಿ ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ; ಪ್ರತಿಯೊಂದು ಕ್ರಿಯೆಯು ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿದೆ.

ಸಲಹೆ: ಏಜೆಂಟ್‌ನೊಂದಿಗೆ ಪ್ರತಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಡಿ. ಏಜೆಂಟ್; ವಿಳಂಬ, ವೆಚ್ಚಗಳು ಮತ್ತು ದೋಷಗಳ ಅಪಾಯವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಮೊದಲು ಕೇಳಿ: "ಇದನ್ನು ಒಂದೇ ಕರೆ ಅಥವಾ ಸ್ಥಿರ ಕೆಲಸದ ಹರಿವಿನೊಂದಿಗೆ ಪರಿಹರಿಸಲಾಗುತ್ತದೆಯೇ?" ಉತ್ತರ ಹೌದು ಎಂದಾದರೆ, ಏಜೆಂಟ್ ಅಗತ್ಯವಿಲ್ಲ. ಏಜೆಂಟ್ ಮುಕ್ತ ಕಾರ್ಯಗಳಿಗಾಗಿರುತ್ತದೆ, ಅಲ್ಲಿ ಹಂತಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ತಿಳಿಯಲಾಗುವುದಿಲ್ಲ.

ಪರಿಕರದ ವ್ಯಾಖ್ಯಾನ: ಹೆಸರು, ವಿವರಣೆ, input_schema

ಮಾದರಿಯಲ್ಲಿ ಉಪಕರಣವನ್ನು ಪರಿಚಯಿಸಲು, ನೀವು ಮೂರು ವಿಷಯಗಳನ್ನು ನೀಡುತ್ತೀರಿ:

• ಹೆಸರು: ವಾಹನದ ಗುರುತು, ಉದಾ. ಪಡೆಯಿರಿ_ಹವಾಮಾನ.
• ವಿವರಣೆ: ಉಪಕರಣವು ಏನು ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಯಾವಾಗ ಕರೆಯಬೇಕು. ಮಾದರಿಯು ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಸರಿಯಾದ ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿಸುವ ಪ್ರಮುಖ ಪ್ರದೇಶವಾಗಿದೆ. "ಏನು ಮಾಡುತ್ತದೆ" ಮಾತ್ರವಲ್ಲದೆ "ಯಾವಾಗ ಕರೆ ಮಾಡಿ" ಎಂದು ಬರೆಯಿರಿ.
• input_schema (ಇನ್‌ಪುಟ್ ಸ್ಕೀಮಾ): JSON ಸ್ಕೀಮಾ, ಇದು ಉಪಕರಣವು ಯಾವ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ, ಯಾವ ಪ್ರಕಾರದಲ್ಲಿದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

# ವಾಹನದ ವ್ಯಾಖ್ಯಾನ (ಪರಿಕಲ್ಪನಾ - JSON ಸ್ಕೀಮಾ){ "ಹೆಸರು": "get_order_status", "description": "ಆರ್ಡರ್‌ನ ಪ್ರಸ್ತುತ ಶಿಪ್ಪಿಂಗ್ ಸ್ಥಿತಿಯನ್ನು ಹಿಂಪಡೆಯುತ್ತದೆ. ಆರ್ಡರ್ ಸಂಖ್ಯೆ ಎಲ್ಲಿದೆ ಅಥವಾ ಅದು ಯಾವಾಗ ಬರುತ್ತದೆ ಎಂದು ಬಳಕೆದಾರರು ಕೇಳಿದಾಗ ಕರೆ ಮಾಡಿ.", "input_schema": { "type": "object"no:" "properties": "properties": "properties" "string", "ವಿವರಣೆ": "ಆರ್ಡರ್ ಸಂಖ್ಯೆ, ಉದಾ. SP-1024"} }, "ಅಗತ್ಯವಿದೆ": ["order_no"] }}

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

ಪ್ರದೇಶ

ಅದು ಏನು ಮಾಡುತ್ತದೆ?

ಉತ್ತಮ ಉದಾಹರಣೆ

ಕೆಟ್ಟ ಉದಾಹರಣೆ

ಹೆಸರು

ವಾಹನ ID

ಆದೇಶ_ಸ್ಥಿತಿ_ಗೆಟಿರ್

ತರುತ್ತಾರೆ

ವಿವರಣೆ

ಅದು ಏನು ಮಾಡುತ್ತದೆ + ಯಾವಾಗ ಕರೆ ಮಾಡಬೇಕು

"ಸರಕು ಸ್ಥಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಆರ್ಡರ್ ಎಲ್ಲಿದೆ ಎಂದು ಬಳಕೆದಾರರು ಕೇಳಿದಾಗ ಕರೆ ಮಾಡಿ"

"ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ"

ಇನ್ಪುಟ್_ಸ್ಕೀಮಾ

ಪ್ಯಾರಾಮೀಟರ್ ಪ್ರಕಾರ ಮತ್ತು ಅವಶ್ಯಕತೆ

{order_no: ಸ್ಟ್ರಿಂಗ್, ಟಿಪ್ಪಣಿ}

ರೇಖಾಚಿತ್ರವಿಲ್ಲ / ವಿವರಣೆ ಇಲ್ಲ

tool_use → tool_result ಲೂಪ್

ಚಕ್ರವು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಹಂತ ಹಂತವಾಗಿ:

1. ನೀವು ಬಳಕೆದಾರರ ಪ್ರಶ್ನೆಯನ್ನು + ಟೂಲ್ ವಿವರಣೆಗಳನ್ನು ಮಾದರಿಗೆ ಕಳುಹಿಸುತ್ತೀರಿ.
2. ಮಾದರಿಯು ನೇರವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ ಅಥವಾ tool_use ಬ್ಲಾಕ್ ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ: "order_no=SP-1024 ಜೊತೆಗೆ order_durumu_getir ಗೆ ಕರೆ ಮಾಡಿ."
3. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ವಾಸ್ತವವಾಗಿ ಉಪಕರಣವನ್ನು ರನ್ ಮಾಡುತ್ತದೆ (ಡೇಟಾಬೇಸ್ ಅನ್ನು ಪ್ರಶ್ನಿಸುತ್ತದೆ).
4. ನೀವು ಫಲಿತಾಂಶವನ್ನು ಟೂಲ್_ಫಲಿತಾಂಶವಾಗಿ ಮಾದರಿಗೆ ಮರಳಿ ಕಳುಹಿಸುತ್ತೀರಿ.
5. ಈ ಫಲಿತಾಂಶದೊಂದಿಗೆ, ಮಾದರಿಯು ಅಂತಿಮ ಉತ್ತರವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಅಥವಾ ಇನ್ನೊಂದು ಸಾಧನವನ್ನು ಕರೆಯುತ್ತದೆ. "ನಾನು ಮುಗಿಸಿದ್ದೇನೆ" ಎಂದು ಮಾದರಿ ಹೇಳುವವರೆಗೆ ಚಕ್ರವು ಮುಂದುವರಿಯುತ್ತದೆ.

# ಏಜೆಂಟ್ ಲೂಪ್ (ಪರಿಕಲ್ಪನಾ) ಸಂದೇಶಗಳು = [ಬಳಕೆದಾರ_ಪ್ರಶ್ನೆ]ಸರಿಯಾಗಿದ್ದಾಗ: ಪ್ರತಿಕ್ರಿಯೆ = model.uret(messages, tools=tool_definitions) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # APPLICATION ರನ್‌ಗಳು ಸಂದೇಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸಿ # ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆ; ಲೂಪ್ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ

ಆಧುನಿಕ SDKಗಳು ನಿಮಗಾಗಿ ಈ ಲೂಪ್ ಅನ್ನು ರನ್ ಮಾಡುವ ಟೂಲ್ ರನ್ನರ್‌ಗಳನ್ನು ನೀಡುತ್ತವೆ; ನೀವು ಕೇವಲ ಉಪಕರಣದ ಕಾರ್ಯಗಳನ್ನು ಬರೆಯಿರಿ. ಆದರೆ ತೆರೆಮರೆಯಲ್ಲಿ ನಡೆಯುತ್ತಿರುವುದು ಅದೇ.

ದೋಷ ನಿರ್ವಹಣೆ

ಪರಿಕರಗಳು ವಿಫಲವಾಗಬಹುದು: ಆದೇಶ ಕಂಡುಬಂದಿಲ್ಲ, API ಸಮಯ ಮೀರಿದೆ, ಇನ್‌ಪುಟ್ ಅಮಾನ್ಯವಾಗಿದೆ. ನಿಮಗೆ ಉಪಕರಣವನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ದೋಷವನ್ನು ವಿವರಣಾತ್ಮಕ tool_result ("ದೋಷ: ಆದೇಶ ಸಂಖ್ಯೆ SP-9999 ಕಂಡುಬಂದಿಲ್ಲ") ಮತ್ತು ದೋಷ ಫ್ಲ್ಯಾಗ್‌ನಂತೆ ಮಾದರಿಗೆ ಹಿಂತಿರುಗಿ. ಮಾದರಿಯು ಇದನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಅದನ್ನು ಬಳಕೆದಾರರಿಗೆ ನಿಧಾನವಾಗಿ ವಿವರಿಸಬಹುದು ಅಥವಾ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪ್ರಯತ್ನಿಸಬಹುದು. ದೋಷವನ್ನು ನುಂಗಬೇಡಿ ಮತ್ತು ಖಾಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬೇಡಿ; ಏನು ತಪ್ಪಾಗಿದೆ ಎಂದು ಮಾಡೆಲ್ ತಿಳಿದಿರಬೇಕು.

ದುರ್ಬಲ/ಬಲವಾದ ವಾಹನದ ವಿವರಣೆ

ದುರ್ಬಲ (ಅನಿರ್ದಿಷ್ಟ ನಾಮಪದ, "ಯಾವಾಗ" ಇಲ್ಲ):

ಹೆಸರು: "ಡೇಟಾ", ವಿವರಣೆ: "ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ"# ಯಾವಾಗ ಮತ್ತು ಹೇಗೆ ಕರೆ ಮಾಡಬೇಕೆಂದು ಮಾದರಿಗೆ ತಿಳಿದಿಲ್ಲ; ಇದು ಒಂದೋ ಕರೆ ಮಾಡುವುದಿಲ್ಲ ಅಥವಾ ತಪ್ಪಾಗಿ ಕರೆ ಮಾಡುತ್ತದೆ.

ಪ್ರಬಲ (ನಿವ್ವಳ ಹೆಸರು + ಯಾವಾಗ + ಪ್ಯಾರಾಮೀಟರ್ ವಿವರಣೆ):

ಹೆಸರು: "musteri_bakiyesi_getir"ವಿವರಣೆ: "ಗ್ರಾಹಕರ ಚಾಲ್ತಿ ಖಾತೆಯ ಬ್ಯಾಲೆನ್ಸ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು ಡೆಬಿಟ್, ಕ್ರೆಡಿಟ್ ಅಥವಾ ಬ್ಯಾಲೆನ್ಸ್ ಕೇಳಿದಾಗ ಕರೆ ಮಾಡಿ. ಪಾವತಿ ಮಾಡುವುದಿಲ್ಲ." input_schema: {custeri_id: string ("ಗ್ರಾಹಕ ID")}# ಮಾದರಿಯು ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಅದರ ಮಿತಿಯನ್ನು ತಿಳಿದಿರುವ, ಅದರ ಮಿತಿಯೊಂದಿಗೆ ಕರೆ ಮಾಡುತ್ತದೆ.

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

ಪ್ರಕರಣ 1 - ಅನಗತ್ಯ ಏಜೆಂಟ್. ಒಂದು ತಂಡವು ಬಹು-ಸಾಧನ ಏಜೆಂಟ್‌ನೊಂದಿಗೆ "ಸಾರಾಂಶ ಪಠ್ಯ" ವ್ಯವಹಾರವನ್ನು ನಿರ್ಮಿಸಿದೆ; ಪ್ರತಿ ರೀಕ್ಯಾಪ್ 4 ಮಾದರಿ ಕರೆಗಳು ಮತ್ತು 9 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಕೆಲಸವು ವಾಸ್ತವವಾಗಿ ಒಂದು ಕರೆ ಕೆಲಸವಾಗಿತ್ತು. ನಾವು ಏಜೆಂಟ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಅದನ್ನು ಒಂದೇ ಕರೆಗೆ ಇಳಿಸಿದಾಗ, ಸಮಯವು 1.5 ಸೆಕೆಂಡುಗಳಿಗೆ ಕಡಿಮೆಯಾಯಿತು ಮತ್ತು ವೆಚ್ಚವು ಕಾಲುಭಾಗಕ್ಕೆ ಕಡಿಮೆಯಾಯಿತು. ಪಾಠ: ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದಾಗ ಏಜೆಂಟ್ ಅನ್ನು ಬಳಸಿ.

ಪ್ರಕರಣ 2 - ದುರ್ಬಲ ವಿವರಣೆ, ತಪ್ಪು ಕರೆ. ಒಂದು ಬೆಂಬಲ ಏಜೆಂಟ್‌ನಲ್ಲಿ, ಬ್ಯಾಲೆನ್ಸ್ ಪ್ರಶ್ನೆ ಮತ್ತು ಶಿಪ್ಪಿಂಗ್ ಪ್ರಶ್ನೆ ಎರಡರಲ್ಲೂ ಮಾಡೆಲ್‌ನಿಂದ ಫೆಚ್ ಎಂಬ ಅಸ್ಪಷ್ಟ ಸಾಧನವನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಕರೆಯಲಾಯಿತು. ವಾಹನಗಳನ್ನು balance_getir ಮತ್ತು cargo_durumu_getir ಎಂದು ವಿಂಗಡಿಸಿದಾಗ ಮತ್ತು "ಕರೆ ಮಾಡಿದಾಗ" ವಿವರಣೆಗಳನ್ನು ಸೇರಿಸಿದಾಗ, ತಪ್ಪಾದ ವಾಹನ ಆಯ್ಕೆಯು 50 ಉದಾಹರಣೆಗಳಲ್ಲಿ 18 ರಿಂದ 1 ಕ್ಕೆ ಕಡಿಮೆಯಾಗಿದೆ.

ಪ್ರಕರಣ 3 - ದೋಷವನ್ನು ನುಂಗಲಾಗಿದೆ. ಆರ್ಡರ್ ಸಿಗದಿದ್ದಾಗ ಏಜೆಂಟ್ ಖಾಲಿ ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತಿದ್ದರು; ಮಾಡೆಲ್ ಇದನ್ನು "ಆರ್ಡರ್ ಅನ್ನು ತಲುಪಿಸಲಾಗಿದೆ" ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಿದೆ ಮತ್ತು ಗ್ರಾಹಕರನ್ನು ದಾರಿ ತಪ್ಪಿಸುತ್ತದೆ. ದೋಷ ಸಂದೇಶವನ್ನು tool_result ("ಆರ್ಡರ್ ಕಂಡುಬಂದಿಲ್ಲ") ಗೆ ಸ್ಪಷ್ಟವಾಗಿ ಬರೆದಾಗ, ಮಾದರಿಯು ಸರಿಯಾಗಿ ಹೇಳುತ್ತದೆ "ನನಗೆ ಈ ಸಂಖ್ಯೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗಲಿಲ್ಲ, ನೀವು ಅದನ್ನು ಪರಿಶೀಲಿಸಬಹುದೇ?" ಅವರು ಹೇಳಲು ಪ್ರಾರಂಭಿಸಿದರು.

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

• ಎಲ್ಲವನ್ನೂ ಏಜೆಂಟ್‌ಗೆ ತಿರುಗಿಸುವುದು: ಒಂದು ಕರೆ ಸಾಕು, ಏಜೆಂಟ್ ವೆಚ್ಚ ಮತ್ತು ವಿಳಂಬವನ್ನು ಸೇರಿಸುತ್ತಾನೆ.
• ಅಸ್ಪಷ್ಟ ವಾಹನ ವಿವರಣೆ: ಮಾದರಿಯು ಯಾವಾಗ ಕರೆ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲ; ತಪ್ಪು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ.
• ಮಾದರಿಯು ವಾಹನವನ್ನು ನಡೆಸುತ್ತದೆ ಎಂದು ಯೋಚಿಸುವುದು: ಸರಂಜಾಮು ವಾಹನವನ್ನು ಓಡಿಸುತ್ತದೆ; ಮಾದರಿಯು ಬಯಸುತ್ತದೆ.
• ದೋಷವನ್ನು ನುಂಗುವುದು: ಏನು ತಪ್ಪಾಗಿದೆ ಎಂದು ಮಾದರಿಯು ತಿಳಿದಿರಬೇಕು; ದೋಷವನ್ನು ತೆರೆದ ಟೂಲ್_ಫಲಿತಾಂಶ ಎಂದು ನೀಡಿ.
• ಹಲವಾರು ರೀತಿಯ ವಾಹನಗಳು: ಮಾದರಿ ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತದೆ; ಟೂಲ್‌ಸೆಟ್ ಅನ್ನು ಕೇಂದ್ರೀಕರಿಸಿ ಮತ್ತು ಕನಿಷ್ಠವಾಗಿ ಇರಿಸಿ.

ಗಮನ: ಮಾದರಿಯು "ಆ ವಾಹನಕ್ಕೆ ಕರೆ ಮಾಡಿ" ಎಂದು ಹೇಳುವುದರಿಂದ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂದು ಅರ್ಥವಲ್ಲ. ವಿನಾಶಕಾರಿ ಸಾಧನಗಳಲ್ಲಿ (ಅಳಿಸು, ಚೆಕ್‌ಔಟ್, ಇಮೇಲ್) ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕುರುಡಾಗಿ ಕರೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಬಾರದು - ಇದು ಮುಂದಿನ ಘಟಕದಲ್ಲಿ ಭದ್ರತಾ ವಿಷಯದ ಮುಖ್ಯ ಅಂಶವಾಗಿದೆ.

ಸಾರಾಂಶದಲ್ಲಿ

• ಏಜೆಂಟ್ = ಮಾದರಿ (ನಿರ್ಧಾರ) + ಉಪಕರಣಗಳು (ಕಾರ್ಯಗಳು) + ಲೂಪ್ (ಕರೆ ಉಪಕರಣ, ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯಿರಿ, ಮತ್ತೆ ನಿರ್ಧರಿಸಿ).
• ಒಂದೇ ಮಾದರಿಯ ಕರೆ ಏಜೆಂಟ್ ಅಲ್ಲ; ಏಜೆಂಟ್ ಒಂದು ಹಂತ-ಹಂತದ ಪ್ರಕ್ರಿಯೆ.
• ಮಾದರಿಯು ವಾಹನವನ್ನು ಓಡಿಸುವುದಿಲ್ಲ; ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ರನ್ (ಹಾರ್ನೆಸ್) ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು tool_result ಎಂದು ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
• ಪರಿಕರವನ್ನು ಹೆಸರು, ವಿವರಣೆ (ನಿರ್ದಿಷ್ಟವಾಗಿ "ಕರೆ ಮಾಡಿದಾಗ") ಮತ್ತು ಇನ್‌ಪುಟ್_ಸ್ಕೀಮಾ ಮೂಲಕ ಗುರುತಿಸಲಾಗಿದೆ.
• ಲೂಪ್ ಟೂಲ್_ಯೂಸ್ → ಹಾರ್ನೆಸ್ ರನ್‌ಗಳು → ಟೂಲ್_ಫಲಿತಾಂಶ → ಮಾದರಿಯು "ಮುಗಿದಿದೆ" ಎಂದು ಹೇಳುವವರೆಗೆ ಮುಂದುವರಿಯುತ್ತದೆ; ದೋಷಗಳನ್ನು ಮಾದರಿಗೆ ಸ್ಪಷ್ಟವಾಗಿ ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ.

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

ಏಜೆಂಟ್‌ಗೆ ನೀಡಬಹುದಾದ ನಿಮ್ಮ ಸ್ವಂತ ವ್ಯಾಪಾರದಿಂದ 3 ಪರಿಕರಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ. (1) ಹೆಸರು, ವಿವರಣೆಯನ್ನು "ಕರೆ ಮಾಡಿದಾಗ" ಮತ್ತು ಪ್ರತಿಯೊಂದಕ್ಕೂ ಇನ್‌ಪುಟ್_ಸ್ಕೀಮಾ ಬರೆಯಿರಿ; ಕನಿಷ್ಠ ಒಂದು ವಿನಾಶಕಾರಿಯಲ್ಲದ ಓದುವ ಸಾಧನವಾಗಲಿ ಮತ್ತು ಒಂದು ಲೆಕ್ಕಾಚಾರವಾಗಲಿ. (2) ವಾಸ್ತವಿಕ ಬಳಕೆದಾರ ಪ್ರಶ್ನೆಯನ್ನು ಆರಿಸಿ ಮತ್ತು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹಂತ ಹಂತವಾಗಿ ಬರೆಯಿರಿ (ಲೂಪ್‌ನಲ್ಲಿ) ಇವುಗಳಲ್ಲಿ ಯಾವ ಸಾಧನಗಳನ್ನು ಮಾದರಿಯು ಯಾವ ಇನ್‌ಪುಟ್‌ಗಳೊಂದಿಗೆ ಕರೆಯುತ್ತದೆ ಮತ್ತು tool_result ಬಂದ ನಂತರ ಅದು ಏನು ಮಾಡುತ್ತದೆ. (3) ಉಪಕರಣಗಳಲ್ಲಿ ಒಂದು ವಿಫಲವಾದ ಸನ್ನಿವೇಶವನ್ನು ಹೊಂದಿಸಿ ಮತ್ತು ದೋಷ ಸಂದೇಶವು ಮಾದರಿಗೆ ಹೇಗೆ ಮರಳುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

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

• [ ] ನಾನು ಏಜೆಂಟ್ ಅನ್ನು "ಮಾದರಿ + ಉಪಕರಣಗಳು + ಲೂಪ್" ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು ಮತ್ತು ಅದು ಯಾವಾಗ ಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಬಹುದು.
• [ ] ಸರಂಜಾಮು ವಾಹನವನ್ನು ಓಡಿಸುತ್ತದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ, ಮಾದರಿಯು ಅದನ್ನು ಬಯಸುತ್ತದೆ.
• ನಾನು ಘನ ವಾಹನ ವಿವರಣೆಯನ್ನು [ ] ಹೆಸರು, ವಿವರಣೆ ("ಕರೆ ಮಾಡಿದಾಗ") ಮತ್ತು ಇನ್‌ಪುಟ್_ಸ್ಕೀಮಾದೊಂದಿಗೆ ಬರೆಯಬಹುದು.
• ನಾನು [ ] tool_use → tool_result ಸೈಕಲ್ ಅನ್ನು ಹಂತ ಹಂತವಾಗಿ ಅನುಸರಿಸಬಹುದು.
• [ ] ನಾನು ಉಪಕರಣದ ದೋಷಗಳನ್ನು ಮಾದರಿಗೆ ತೆರೆದ tool_result ಎಂದು ವರದಿ ಮಾಡುತ್ತೇನೆ.