כיצד לשלב את LiteLLM עם תהליכי העבודה של git, GitHub ו-GitLab?

LiteLLM הוא דרך מעשית להוסיף יכולות בינה מלאכותית (AI) לאוטומציה מבוססת Git מבלי להינעל על ספק מודל יחיד.

עבור צוותים המשתמשים ב-GitHub או ב-GitLab, הוא יכול לשמש כגשר (gateway) בינה מלאכותית מאוחד באמצע לצורך סקירת קוד, סיוע ב-commit, ניתוח בקשות מיזוג (merge requests) ואוטומציות מונחות CI.

זה הופך אותו לשימושי במיוחד כאשר רוצים גמישות בין ספקים שונים, משילות (governance) ריכוזית ו-API עקבי עבור תהליכי העבודה (pipelines) שלכם.

מדוע LiteLLM מתאים לתהליכי עבודה של Git

בסביבות מבוססות git, אותה יכולת בינה מלאכותית נדרשת לעיתים קרובות לעבוד בשלבים שונים: שלב ה-commit, סקירת pull request או merge request, הכנת גרסה (release) ובדיקות CI.

LiteLLM עוזר בכך שהוא מספק נקודת קצה (endpoint) אחת תואמת OpenAI (OpenAI-compatible) שיכולה לנתב בקשות לספקי מודלים רבים מאחורי הקלעים. המשמעות היא שהאוטומציה שלכם יכולה להישאר יציבה גם אם תחליפו מודלים, תוסיפו גיבויים (fallbacks) או תעבירו חלק מעומסי העבודה לאירוח עצמי (self-hosted).

עבור צוותי DevOps ו-DevSecOps, זהו דפוס פעולה חזק מכיוון שהוא שומר על שימוש ריכוזי ב-AI.

ניתן להוסיף בקרת מדיניות, רישום יומנים (logging), רשימות מודלים מאושרים (allowlists) ומעקב עלויות בשכבת הפרוקסי (proxy layer), במקום לפזר את הנושאים הללו על פני סקריפטים ומאגרים (repositories) רבים.

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

מקרי שימוש נפוצים

להלן דרכים מעשיות לשימוש ב-LiteLLM בתהליכי עבודה מבוססי git:

1. סקירת pull request או merge request.
2. יצירת הודעות commit.
3. בדיקות אבטחה ותאימות (compliance).
4. טיוטות להערות שחרור (release notes).
5. סיוע בכתיבת תיעוד.
6. העשרת תהליכי CI (CI pipelines).

דוגמה עבור GitHub Actions

דוגמה זו מציגה דפוס פשוט שבו GitHub Actions קורא לפרוקסי של LiteLLM במהלך תהליך עבודה של pull request. ניתן להתאים את ההנחיה (prompt) כדי ליצור סיכום סקירה, טיוטת יומן שינויים (changelog) או רשימת תיוג לאבטחה.

textname: AI Review with LiteLLMt

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Get diff
        run: |
          git fetch origin ${{ github.base_ref }} --depth=1
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff

      - name: Call LiteLLM proxy
        env:
          LITELLM_API_KEY: ${{ secrets.LITELLM_API_KEY }}
        run: |
          PROMPT=$(cat <<'EOF'
          Review the following pull request diff and provide:
          1. A short summary
          2. Potential risks
          3. Suggested improvements

          Diff:
          EOF
          )
          DIFF_CONTENT=$(cat pr.diff)

          curl -s https://litellm.example.com/v1/chat/completions \
            -H "Authorization: Bearer ${LITELLM_API_KEY}" \
            -H "Content-Type: application/json" \
            -d "$(jq -n \
              --arg model 'gpt-4o-mini' \
              --arg system "$PROMPT" \
              --arg user "$DIFF_CONTENT" \
              '{
                model: $model,
                messages: [
                  {role: "system", content: $system},
                  {role: "user", content: $user}
                ]
              }')"

דפוס זה עובד היטב כאשר רוצים לקבל את פלט ה-AI כחלק מתהליך העבודה, במקום כשלב סקירה ידני נפרד. ניתן גם לשמור את התגובה כהערה ב-PR, כתוצר בניה (build artifact) או כסיכום משימה (job summary).

דוגמה עבור GitLab CI

ב-GitLab, אותו רעיון מתמפה בצורה נקייה לתהליך עבודה (pipeline) של merge request. דוגמה זו משתמשת במשימה (job) המביאה את ה-diff ושולחת אותו לפרוקסי של LiteLLM.

textstages:
  - ai_review

ai_review:
  stage: ai_review
  image: alpine:3.20
  variables:
    GIT_DEPTH: "1"
  before_script:
    - apk add --no-cache git curl jq
  script:
    - git fetch origin "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" --depth=1
    - git diff "origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME...HEAD" > mr.diff
    - |
      PROMPT="Review the following merge request diff and provide:
      1. A short summary
      2. Potential risks
      3. Suggested improvements"
      DIFF_CONTENT="$(cat mr.diff)"

      curl -s https://litellm.example.com/v1/chat/completions \
        -H "Authorization: Bearer ${LITELLM_API_KEY}" \
        -H "Content-Type: application/json" \
        -d "$(jq -n \
          --arg model 'gpt-4o-mini' \
          --arg system "$PROMPT" \
          --arg user "$DIFF_CONTENT" \
          '{
            model: $model,
            messages: [
              {role: "system", content: $system},
              {role: "user", content: $user}
            ]
          }')"
  rules:
    - if: $CI_MERGE_REQUEST_IID

זהו התאמה מצוינת עבור GitLab מכיוון שתהליכי עבודה של merge request הם כבר מקום טבעי לבדיקות אוטומטיות. ניתן להרחיב את אותה משימה כדי לפרסם את התגובה כתוצר של המשימה (job artifact), לפרסם הערה ב-merge request או להזין את הפלט לתוך בקרת איכות (quality gate) בהמשך התהליך.

הערות יישום

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

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

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

עבור סביבות עתירות GitLab, LiteLLM יכול להיות שימושי גם כשכבת תאימות (compatibility layer) מול מערכות AI באירוח עצמי או מערכות פנימיות.

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

חברתנו מספקת רישיונות מנוי, תמיכה ושירותים מנוהלים עבור LiteLLM, git, GitLab ו-GitHub.
צרו קשר לכל שאלה: litellm@almtoolbox.com
או התקשרו אלינו: 072-240-5222