Một Base URL tương thích OpenAI cho kiểm thử prompt đa mô hình

Ứng dụng của bạn đã biết cách gọi một client tương thích với OpenAI. Việc thêm lựa chọn model không nên đòi hỏi phải xây dựng lại tích hợp đó cho từng nhà cung cấp.

Flatkey cung cấp cho bạn một base URL tương thích OpenAI:

https://router.flatkey.ai/v1

Trỏ client OpenAI SDK hiện có của bạn tới URL đó, dùng khóa API Flatkey, và chọn model bạn muốn kiểm thử trong trường model. Wrapper request, bộ dữ liệu prompt, rubric đánh giá và mã ứng dụng của bạn có thể vẫn tập trung trên một giao diện duy nhất.

Điều đó khiến Flatkey trở thành lựa chọn thực tế khi nhóm của bạn đã sẵn sàng so sánh các model, nhưng không muốn việc thiết lập tài khoản theo từng nhà cung cấp và viết lại client trở thành chính dự án đánh giá.

Lộ trình ít ma sát nhất từ một model đến danh sách rút gọn

Một quy trình đánh giá model điển hình bắt đầu bằng một câu hỏi đơn giản: liệu một model khác có thể cải thiện chất lượng, độ trễ hoặc chi phí cho khối lượng công việc này không?

Công việc triển khai có thể nhanh chóng lấn át câu hỏi đó. Các tích hợp riêng biệt tạo ra các biến môi trường, mẫu xác thực, hành vi retry, bộ chuyển đổi phản hồi, dashboard và quan hệ thanh toán riêng. Đến khi bộ khung kiểm thử sẵn sàng, thí nghiệm prompt ban đầu đã biến thành một dự án hạ tầng.

Một base URL tương thích OpenAI làm thay đổi trình tự này. Bạn giữ nguyên một kiểu client và biến model thành biến số chính.

Mục tiêu không phải là giả định mọi model đều hoạt động giống hệt nhau. Mục tiêu là loại bỏ các biến động tích hợp có thể tránh được để nhóm của bạn có thể dành nhiều thời gian hơn để đo lường những khác biệt thực sự quan trọng.

Thay đổi base URL, không phải toàn bộ lớp SDK của bạn

Nếu bạn đã sử dụng OpenAI Python SDK, thay đổi client cốt lõi là rất nhỏ:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FLATKEY_API_KEY"],
    base_url="https://router.flatkey.ai/v1",
)

Mẫu tương tự cũng hoạt động với OpenAI JavaScript client:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.FLATKEY_API_KEY,
  baseURL: "https://router.flatkey.ai/v1",
});

Sau đó, hãy dùng một model ID từ danh mục model hiện tại của Flatkey trong request. Đừng hardcode các giả định về model từ một bảng tính hay bài viết cũ; tính khả dụng và khả năng của model có thể thay đổi.

response = client.chat.completions.create(
    model=os.environ["EVAL_MODEL_ID"],
    messages=[
        {"role": "system", "content": "Trả lời bằng cách sử dụng chính sách được cung cấp."},
        {"role": "user", "content": evaluation_prompt},
    ],
    temperature=0,
    max_tokens=800,
)

Đây là lợi thế cốt lõi khi áp dụng: ứng dụng của bạn có thể giữ nguyên client tương thích OpenAI trong khi đánh giá của bạn thay đổi lựa chọn mô hình.

Quy trình kiểm thử prompt đa mô hình tập trung

Hãy sử dụng quy trình sau để biến việc di chuyển base URL thành một quyết định mà đội ngũ của bạn có thể bảo vệ.

1. Đóng băng hợp đồng yêu cầu

Bắt đầu từ một yêu cầu đã đại diện cho khối lượng công việc trong môi trường production. Giữ nguyên các yếu tố sau xuyên suốt lượt so sánh đầu tiên:

• Prompt hệ thống và user
• Các ví dụ đầu vào
• Temperature và giới hạn token
• Định nghĩa tool hoặc schema phản hồi
• Chính sách timeout
• Thang đánh giá

Nếu bạn thay đổi prompt, mô hình và chính sách retry cùng lúc, bạn sẽ không biết thay đổi nào tạo ra kết quả đó.

2. Tạo một bộ đánh giá nhỏ, đại diện

Đừng bắt đầu với hàng trăm prompt tổng hợp. Hãy bắt đầu với 20 đến 50 ví dụ bao phủ các trường hợp mà người dùng của bạn thực sự tạo ra:

• Các yêu cầu phổ biến, tần suất cao
• Đầu vào dài hoặc lộn xộn
• Chỉ dẫn mơ hồ
• Các trường hợp nhạy cảm về an toàn hoặc dễ bị từ chối
• Các trường hợp đầu ra có cấu trúc, biên
• Các trường hợp gọi tool, nếu ứng dụng của bạn sử dụng tool

Xóa dữ liệu riêng tư và bí mật trước khi gửi lưu lượng đánh giá. Bộ đánh giá tốt nhất là đủ nhỏ để kiểm tra và đủ đại diện để phơi bày các lỗi có ý nghĩa.

3. Chạy cùng một bộ trường hợp qua từng mô hình ứng viên

Giữ nguyên base URL của Flatkey và wrapper yêu cầu. Lần lượt lặp qua các model ID trong danh sách rút gọn của bạn.

import time

candidate_models = [
    "MODEL_ID_A",
    "MODEL_ID_B",
    "MODEL_ID_C",
]

results = []

for model_id in candidate_models:
    for case in evaluation_cases:
        started_at = time.perf_counter()
        try:
            response = client.chat.completions.create(
                model=model_id,
                messages=case["messages"],
                temperature=0,
                max_tokens=case.get("max_tokens", 800),
            )
            elapsed_ms = round((time.perf_counter() - started_at) * 1000)
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": elapsed_ms,
                "output": response.choices[0].message.content,
                "usage": response.usage.model_dump() if response.usage else None,
                "error": None,
            })
        except Exception as error:
            results.append({
                "case_id": case["id"],
                "model": model_id,
                "latency_ms": None,
                "output": None,
                "usage": None,
                "error": type(error).__name__,
            })

Sử dụng các placeholder trong các ví dụ dùng chung và chọn các model ID hiện tại từ thư mục trực tiếp trước khi chạy kiểm thử. Đồng thời xác nhận rằng mọi ứng viên đều hỗ trợ các khả năng mà khối lượng công việc của bạn cần.

4. Chấm điểm kết quả, không phải danh tiếng của model

Một bảng chấm điểm hữu ích sẽ tách các yêu cầu bắt buộc khỏi các ưu tiên.

Từ chối bất kỳ ứng viên nào không đạt một yêu cầu bắt buộc, ngay cả khi nó rẻ. Trong số các model còn lại, hãy so sánh những đánh đổi quan trọng đối với sản phẩm của bạn.

5. Kiểm thử lại các ứng viên cuối cùng với hành vi sản xuất

Lượt kiểm thử đầu tiên nên được kiểm soát. Lượt kiểm thử vòng cuối nên mang tính thực tế.

Kiểm thử streaming nếu giao diện của bạn có streaming. Kiểm thử lời gọi công cụ nếu agent của bạn dùng công cụ. Kiểm thử đầu ra có cấu trúc nếu mã phía sau phân tích payload. Thực hiện các thiết lập timeout và retry thực tế của bạn, và xác minh ứng dụng của bạn xử lý giới hạn tốc độ, luồng bị gián đoạn, phản hồi định dạng sai và các trạng thái hoàn tất mơ hồ như thế nào.

Nhật ký sử dụng của Flatkey có thể giúp bạn xác nhận rằng các yêu cầu đã đến gateway và kiểm tra hoạt động của yêu cầu. Hãy lưu cả ID yêu cầu và dữ liệu thời gian ở phía ứng dụng, ताकि bạn có thể liên kết khả năng quan sát ở gateway với trải nghiệm người dùng.

Để biết chi tiết về retry và chuyển đổi, hãy dùng hướng dẫn di chuyển OpenAI client cho giới hạn tốc độ và retry.

Tính tương thích là điểm khởi đầu, không phải lời hứa về hành vi giống hệt

Một API tương thích OpenAI giúp giảm công việc di chuyển client. Nó không làm cho các model khác nhau trở nên hoán đổi cho nhau.

Trước khi phê duyệt một model cho môi trường sản xuất, hãy xác minh:

• Model ID chính xác hiện đang có sẵn.
• Model hỗ trợ endpoint và modality bạn cần.
• Các tham số bắt buộc được chấp nhận và hoạt động như mong đợi.
• Các lời gọi công cụ, JSON hoặc đầu ra có cấu trúc, và streaming đều vượt qua kiểm thử của bạn.
• Giới hạn token phù hợp với đầu vào và đầu ra thực tế của bạn.
• Hành vi an toàn phù hợp với yêu cầu sản phẩm của bạn.
• Timeout, retry và xử lý lỗi không tạo ra công việc trùng lặp hoặc mơ hồ.
• Mức giá hiện tại phù hợp với cơ cấu lưu lượng dự kiến.

Nếu bạn cần một checklist kỹ thuật rộng hơn, hãy xem hướng dẫn chuyển đổi API gateway tương thích OpenAI. Trang này được cố ý thu hẹp phạm vi: dành cho các nhóm đã hiểu mẫu chuyển đổi và muốn biến một thay đổi base URL thành một bài kiểm thử đa mô hình công bằng.

Checklist chuyển đổi thực tiễn

Chỉ chuyển từ đánh giá sang production khi bạn có thể trả lời “có” cho từng mục.

• Độ tương đồng yêu cầu: Finalist hoạt động với các mẫu prompt, message, tool và đầu ra thực tế của bạn.
• Ngưỡng chất lượng: Nó đáp ứng các yêu cầu cứng trong rubric của bạn.
• Xử lý lỗi: Ứng dụng của bạn xử lý an toàn các giới hạn tốc độ, timeout và phản hồi bị gián đoạn.
• Khả năng quan sát: Bạn ghi nhận model, độ trễ, mức sử dụng, loại lỗi và một định danh request của ứng dụng.
• Mô hình chi phí: Bạn đã tính toán mức chi tiêu dự kiến từ giá hiện tại và mức sử dụng token thực tế.
• Rollback: Bạn có thể quay lại model hoặc cấu hình trước đó mà không cần phát hành code.
• Kế hoạch canary: Bạn có thể đưa thay đổi vào một phần lưu lượng giới hạn trước khi rollout toàn bộ.

Giao diện ổn định giúp rollback và các lần kiểm thử lặp lại dễ hơn vì bề mặt tích hợp luôn nhất quán. Quyết định về model của bạn có thể thay đổi mà không buộc mỗi lần phải đưa vào ứng dụng một lớp client riêng theo nhà cung cấp mới.

Bắt đầu với một base URL và một workload thực tế

Nếu nhóm của bạn đã dùng SDK tương thích OpenAI, bước hữu ích tiếp theo không phải là thêm một cuộc tranh luận về kiến trúc nữa. Đó là một bài kiểm thử có kiểm soát với chính prompt của bạn.

1. Tạo một tài khoản Flatkey và API key.
2. Đặt base_url thành https://router.flatkey.ai/v1.
3. Chọn một danh sách rút gọn các model từ thư mục hiện tại.
4. Chạy các ca đại diện giống nhau qua từng model.
5. Xem xét cùng lúc chất lượng, độ trễ, độ tin cậy, mức sử dụng và chi phí hiện tại.

So sánh giá model hiện tại và chọn danh sách rút gọn của bạn, rồi chạy bài đánh giá đầu tiên thông qua chính client mà ứng dụng của bạn đang dùng.

Câu hỏi thường gặp

Base URL tương thích OpenAI của Flatkey là gì?

Dùng https://router.flatkey.ai/v1. Cấu hình nó trong client tương thích OpenAI của bạn và xác thực bằng Flatkey API key.

Tôi có cần thay thế OpenAI SDK không?

Không. Hướng dẫn bắt đầu nhanh của Flatkey mô tả việc sử dụng OpenAI Python và JavaScript SDK với base URL của Flatkey. Bạn vẫn nên kiểm thử mọi tính năng request và khả năng của model mà ứng dụng của bạn phụ thuộc.

Tôi có thể so sánh nhiều model bằng cùng một code prompt không?

Có. Giữ ổn định client, bộ dữ liệu prompt và logic đánh giá, sau đó thay đổi giá trị model cho từng ứng viên. Các khả năng và tham số riêng theo model vẫn cần được xác thực.

Tính tương thích OpenAI có giống với hành vi model hoàn toàn giống nhau không?

Không. Tương thích giúp giảm thay đổi tích hợp. Các model có thể khác nhau về chất lượng đầu ra, việc sử dụng tool, hành vi đầu ra có cấu trúc, độ trễ, giới hạn, hành vi an toàn và chi phí.

Tôi nên đo lường gì trong một bài kiểm thử đa mô hình?

Đo độ chính xác tác vụ, khả năng làm theo chỉ dẫn, tính hợp lệ của schema hoặc tool, độ trễ, tỷ lệ lỗi, mức sử dụng token và chi phí hiện tại. Xác định các yêu cầu cứng trước khi so sánh sở thích.

Tôi nên kiểm tra giá mô hình ở đâu?

Hãy dùng trang giá trực tiếp của Flatkey thay vì sao chép giá vào một tài liệu đánh giá tồn tại lâu dài.