Auto-Ontology: מי אישר מהו לקוח פעיל?

דוח מבקש את מספר הלקוחות הפעילים. צוות אחד סופר רכישות וצוות אחר סופר כניסות לחשבון. שתי שאילתות SQL תקינות יכולות להחזיר מספרים שונים. Auto-Ontology של NVIDIA מציע לשמור את ההגדרות בשכבה שאנשים בודקים לפני שהסוכן משתמש בה.

זו סקירת תיעוד וקוד מ-4 בנובמבר. לא התקנתי את השירות ולא מדדתי את דיוק התשובות. ההבטחה לפחות שגיאות נשארת טענה של הפרויקט. בניסוי מוצע הייתי מחפש הגדרה שאנליסט נוסף יכול להסביר ושאילתה שאפשר לשחזר.

מה נשמר בשכבה

המאגר הרשמי מתאר חילוץ סכמות, אפיון עמודות ודגימת ערכים. השירות מציע מונחים, קשרים בין טבלאות ותכונות SQL. ההקשר נשמר ב-Postgres עם embeddings של pgvector. דגימות עשויות להכיל ערכים אמיתיים, ולכן צריך לבדוק את יעדי המידע ואת הגדרות המודל לפני החיבור.

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

מוכנות וכיסוי השאלה

מדריך MCP מפריד בין check_readiness ל-check_answerable. הראשון בודק שכבה מקומפלת וחיבור פעיל. הקטלוג עשוי להישאר אחרי שהחיבור אבד, ולכן מילון קריא אינו הוכחה שאפשר להריץ SQL. השני מעריך אם השכבה מכסה את השאלה; גם הגדרה שגויה יכולה להיראות מתאימה.

ask_question מפעיל את מסלול הטקסט ל-SQL ומחזיר בנפרד תשובה, SQL ושורות. מספר השורות המוחזרות מוגבל ל-100, והשדות row_count ו-truncated מציינים את ההגבלה. אין להתייחס לרשימה המוצגת כאל התוצאה המלאה בלי לבדוק אותם. מדד מצטבר דורש גם בדיקה של הביטוי והמסננים.

ההרשאות שייכות למשתמש

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

שירות MCP פונה ל-API הציבורי של Next.js. התיעוד מתאר כניסה אישית ובדיקת אסימונים אטומים דרך UserInfo. ניסוי מוצע צריך לכלול שני חשבונות סינתטיים בעלי הרשאות שונות, בקשה מותרת, בקשה שנדחית וניסיון נוסף אחרי ביטול הרשאה. הסקירה אינה מאשרת הגנה זהה ל-backend פנימי שנחשף בנפרד.

מה קורה בלי Vault מלא

מדריך החיבורים קובע ש-Vault כבוי כברירת מחדל. דרושים כל ארבעת המשתנים VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID, VAULT_SECRET_ID. הגדרה חלקית נזנחת עם אזהרה, ופרטי החיבור נשמרים בטקסט גלוי ב-Postgres. מודול Vault ושירות החיבורים מאשרים את הבחירה בקוד.

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

ניסוי קטן שאפשר להסביר

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

Apache-2.0 מגדיר את תנאי השימוש החוזר. בגרסה שנבדקה יש commit מ-3 בנובמבר שמשנה את מודלי ברירת המחדל. תחזוקה עדכנית אינה הוכחה להתאמה לנתוני עבודה. הייתי מתחיל במדד אחד ובמסד לקריאה בלבד, ומרחיב גישה אחרי בדיקת ההגדרות, הסירובים ושמירת פרטי החיבור.