הגיע הזמן למחרוזות חיבור מסוג llm://

פישוט הגדרות המודל והספק באמצעות כתובות llm://

עדכון: המאמר הזה הוביל ל־Internet-Draft עבור סכמת ה־URI של llm:// ולחבילת npm תומכת בשם llm-strings. המימוש נמצא גם ב־GitHub.

זוכרים את הימים הרעים ההם, שבהם חיבור למסד נתונים דרש לתמרן אוסף אקראי של משתני סביבה?

זה היה מגדל של הגדרות עדינות ושבריריות. DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME… או רגע, אולי זה היה DB_USERNAME? זה DB_PASS או DB_PWD? הפעם צריך את הקידומות PG_*? ואיפה לעזאזל מגדירים את ה־timeout?

זה היה מגדל קלפים רעוע, שהיה מוכן להפיל את ה־build של הפרודקשן רק כי שכחת לכתוב HOST באותיות גדולות.

ואז למישהו היה רעיון מבריק: פשוט להשתמש ב־URL¹:

postgres://user:pass@host:5432/dbname

מחרוזת אחת. כל מה שצריך. ניתנת ל־parsing באופן אוניברסלי. ניידת. אני מעז לומר… יפה?

אז למה אנחנו מתייחסים ל־LLM כאילו אנחנו ב־1999?

פיצוץ משתני הסביבה

נכון לעכשיו, קובץ ה־.env שלי נראה כמו בית קברות למפתחות API נטושים. OPENAI_API_KEY, ANTHROPIC_API_KEY, MISTRAL_API_KEY, GROQ_API_KEY. ואל תתחילו איתי על Azure — צריך endpoint, שם deployment, גרסת API ומפתח רק כדי להגיד “שלום”.

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

מה אם פשוט… נגנוב נשאיל את הרעיון של כתובות URL למסדי נתונים?

היכרות עם מחרוזות חיבור ל־LLM

דמיינו שאתם מגדירים את ממשק המודל כולו בשורה אחת:

llm://api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7&max_tokens=1500
llm://api.z.ai/glm-4.7?top_p=0.9&cache=true

אנטומיה של מחרוזת חיבור ל־LLM

הסכמה היא llm://. ה־host הוא כתובת הבסיס של ה־API של הספק. הנתיב הוא שם המודל. פרמטרי השאילתה מטפלים בכל אפשרויות זמן הריצה שבדרך כלל מעמיסות על הקוד שלכם.

צריך אימות? מצוין, הוסיפו אותו.

בדיוק כמו ב־postgres://, אפשר לשלב את פרטי האימות ישירות במחרוזת:

llm://app-name:sk-proj-123456@api.openai.com/gpt-5.2?reasoning_effort=none&temp=0.7

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

עמידות? למה לעזאזל לא.

ספריות מסדי נתונים רבות תומכות ב־failover בסבב, באמצעות הגדרה של כמה hosts. למה שלסוכני ה־AI שלנו לא תהיה אותה רמת אמינות?

llms://primary.gpt,backup.gpt/gpt-6?temp=0.9

ה־s ב־llms:// אינו טעות הקלדה. זה רבים. אם primary.gpt נתקע, הלקוח מנסה אוטומטית את backup.gpt. אין צורך בלוגיקת ניתוב מורכבת.

מחרוזת אחת שמכילה הכול — מה־auth דרך ה־endpoint ועד ל־hyperparameters שלכם.

פורמטים חלופיים

אני לא נשוי ל־llm://. הסכמה הספציפית חשובה פחות מהתקן עצמו.

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

ollama://localhost:11434/llama3
vercel://anthropic/sonnet-4.5?temp=0.8&web_search={"maxUses":3}
bedrock://us-west-2.aws/anthropic/sonnet-4.5?temp=0.8&cacheControl=ephemeral

בלי קשר לתחביר המדויק, היתרונות המרכזיים ברורים:

1. ניידות: העתיקו והדביקו את כל התצורה שלכם מסקריפט מקומי ל־worker בענן.
2. ידידותי ל־CLI: העבירו ארגומנט יחיד לסקריפטים שלכם. my-agent --model "llm://..." עדיף על my-agent --model gpt-4 --temp 0.7 --key $KEY --host ....
3. בלתי תלוי בשפה: לכל שפת תכנות יש מנתח URL אמין. אנחנו מקבלים ולידציה, ניתוח וניקוי — בחינם.

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

פסק הדין

אנחנו לא צריכים עוד תקן תצורה מסובך או קובץ מניפסט חדש מבוסס YAML. אנחנו פשוט צריכים להשתמש בכלי האחד שעובד עבור שאר האינטרנט כבר 30 שנה.

בואו נפסיק להמציא מחדש את הגלגל ונתחיל להתייחס לחיבורי ה־LLM שלנו באותו כבוד שאנחנו נותנים למסדי הנתונים. קובץ ה־.env שלכם — והשפיות שלכם — יודו לכם.