חשבונאות עלויות API של סוכן פיננסי

בחרו יחידת עבודה לפני אומדן עלות

הגדירו אם אתם מודדים תדריך על חברה אחת, השוואת רווחים אחת, עדכון watchlist אחד או ניסוי כמותי אחד. יישום רב-סוכני יכול לבצע בקשות מודל רבות בתוך יחידה כזו. הפרידו משימות שהושלמו מבחינה טכנית מתוצרים שבודק קיבל. עלות לתוצר שהתקבל כוללת ניסיונות חוזרים ועבודה שנדחתה שמדד עלות לתגובה מפספס. שמרו את הגדרת המשימה יציבה בהשוואת מודלים, אחרת הרצה זולה יותר עשויה פשוט לקרוא פחות מקורות או לדלג על שלב בדיקה נדרש.

נהלו יומן בקשות המחובר למשימה

תעדו זהות משימה, שלב, תפקיד מודל, מודל שהתבקש, זהות בקשה שנצפתה, מספר ניסיון וסטטוס סופי. שמרו שימוש באסימונים ורשומת חיוב רלוונטית כאשר היא זמינה. timeout של לקוח אינו מוכיח שלא היה חישוב או שהבקשה הייתה בחינם. השאירו מצב חיוב שלא נפתר עד שאפשר להתאים אותו. לעולם אל תשימו מפתחות, prompts פרטיים או מסמכי מקור מורשים מלאים ביומן עלויות שישותף עם קהל רחב יותר.

{
  "job_id": "REQUIRED",
  "stage": "research_synthesis",
  "model_role": "review",
  "requested_model": "CURRENT_CATALOG_MODEL_ID",
  "request_id": null,
  "attempt": 1,
  "input_tokens": null,
  "output_tokens": null,
  "charge": null,
  "billing_status": "unreconciled",
  "artifact_status": "pending"
}

החילו את חוזה החיוב בפועל

השתמשו במקור המחירים העדכני של המודל שנבחר ותעדו את הגרסה שלו או את תאריך האחזור עם האומדן. הבחינו בין קלט רגיל, קלט במטמון, פלט וכל קטגוריה מחויבת אחרת לפי החוזה. אל תספרו פעמיים תת-קבוצה במטמון שכבר נכללת בקלט הכולל. מחירי ספק רשמיים וחיובי gateway הם חוזים שונים; אף אחד מהם לא צריך להחליף את האחר בשקט. אם תגובה חסרה usage, השתמשו בראיית חיוב מוסמכת כאשר היא זמינה והשאירו את אי-הוודאות עד אז.

התחשבו בחלקים שאינם LLM במחקר פיננסי

הוסיפו גישה לנתונים פיננסיים, חילוץ מסמכים, אחסון, חישוב מקומי ובדיקה אנושית כקטגוריות נפרדות. ניסוי Qlib או הרצת אימון FinRL יכולים לצרוך משאבים משמעותיים בלי לבצע בקשת chat. מחברת FinGPT יכולה לשלב שיחת סוכן מרוחקת עם הסקת סנטימנט מקומית. שמירת המסלולים האלה נפרדים מסבירה היכן אופטימיזציה יכולה לעזור. כאשר מדווחים על עלויות מנוי או תשתית משותפות, ציינו את שיטת ההקצאה במקום להעמיד פנים שכל משימה יצרה חיוב עצמאי.

הבינו מדוע עלויות רב-סוכן מוכפלות

ל-TradingAgents יש תפקידי מודל ושלבי מחקר איטרטיביים נפרדים; הסכום תלוי בנפח המקורות בפועל ובמספר הסבבים שהוגדר. מסגרות אחרות מוסיפות תיאום, אחזור, ניסיונות חוזרים או תיקוני קוד חוזרים. ספרו את הפעולות מתוך יומנים במקום לאמוד לפי מספר הסוכנים בעלי השם. אותו דיווח ארוך עשוי לחזור בכמה prompts. בדקו היכן ההקשר בשימוש חוזר והאם כל בדיקה נוספת מפיקה תועלת קבלה מובחנת. גרף גדול יותר אינו אוטומטית תהליך מחקר חסכוני או מדויק יותר.

צמצמו עבודה חוזרת תוך שמירת ראיות

חלצו מסמכים פעם אחת לכל מקור וגרסת parser, ואז העבירו חבילות ראיות מוגבלות לשלבים הבאים. השתמשו מחדש בחישובים דטרמיניסטיים לפי קלט וזהות נוסחה. הגבילו סבבי דיון וניסיונות חוזרים ובחרו תפקידי מודל לפי דרישות המשימה בפועל. אמתו את ההשפעה על הפלט שהתקבל, לא רק את מספר הבקשות. סיכום אגרסיבי עלול להשמיט את ההסתייגות החשובה ביותר; שימוש חוזר במטמון עלול להחזיר דיווח ישן. כל אופטימיזציה צריכה דרך לזהות קלטים מיושנים ולשמור את המקור לבדיקה.

השוו תהליכים על אותה חבילת משימה

השתמשו באותה קבוצת מנפיקים, מועד חיתוך, חבילת מקורות וקריטריוני קבלה. תעדו תוצרים שהושלמו, תוצרים שנדחו, משימות חלקיות ותיקונים אנושיים. השוו את התפלגות עלויות המשימה שנוצרה במקום לבחור הרצה חיובית אחת. עבור watchlist מתוזמן הפרידו אירועים שלא השתנו מאירועי מקור חדשים מפני שהעבודה שונה. עבור מחקר כמותי כללו את מספר ההיפותזות שנוסו ואת החישוב המקומי. פרסמו את התצורה ואת גבולות הראיות לצד כל נתון שנמדד בהמשך, כדי שבודק אחר יוכל לדעת על מה ההשוואה באמת מכסה.

סטטוס ראיות ומדידה

הדף הזה מספק שיטת חשבונאות, לא מחיר מדוד לדוח או טבלת מחירי מודלים עדכנית. מקורות פרויקט רשמיים מבססים את האחריויות השונות בזמן ריצה; דף המחירים העדכני מספק תנאים מסחריים. לא נוצר עבור המדריך הזה יומן שימוש של תהליך פיננסי ב-APIsRouter. מקרה מדוד צריך לכלול ראיות בקשות מושחרות, חיובים מותאמים, עלויות משאבים שאינם מודל ומספר תוצרים שהתקבלו.

שאלות נפוצות