Framework Đánh Giá LLM Mã Nguồn Mở Tốt Nhất 2026 (Một Cái Không Thực Sự Mã Nguồn Mở)

Framework Đánh Giá LLM Mã Nguồn Mở Tốt Nhất 2026 (Một Cái Không Thực Sự Mã Nguồn Mở)

Dòng đầu tiên trong file LICENSE của repo Arize Phoenix ghi "Elastic License 2.0 (ELv2)". Không phải Apache. Không phải MIT. Một framework đánh giá LLM mã nguồn mở được khuyên dùng rộng rãi lại không phải mã nguồn mở theo định nghĩa của OSI, và gần như mọi trang xếp hạng cho truy vấn này vẫn lặp lại tuyên bố đó. Trang của chúng tôi cũng từng như vậy, cho đến hôm nay. Vào ngày 2026-08-04 chúng tôi đã đọc thủ công file giấy phép và log commit trên nhánh mặc định của tám framework, cộng thêm ba framework khác mà các trang xếp hạng đầu vẫn đang khuyên dùng, sau đó cài đặt sáu framework và chạy cùng 10 case qua từng cái. Chúng tôi không bán framework đánh giá nào, vì vậy không có nhận định nào dưới đây bảo vệ cho một sản phẩm.

Những Điểm Chính

• Arize Phoenix chạy dưới Elastic License 2.0, giấy phép mà OSI không công nhận là mã nguồn mở.
• Commit cuối cùng của UpTrain vào nhánh main là ngày 2024-07-29. Đừng bắt đầu dự án mới trên nó.
• pip install promptfoo cho bạn một wrapper của bên thứ ba. Dự án thật được phát hành trên npm.
• Ragas không có commit nào kể từ 2026-02-24 và đã chuyển tổ chức GitHub sang vibrantlabsai.

Nên Cài Framework Đánh Giá LLM Mã Nguồn Mở Nào Trong Năm 2026?

Chọn theo ràng buộc thực tế, không theo bảng xếp hạng. Với các assertion kiểu pytest bên trong bộ test có sẵn, hãy cài DeepEval. Với cấu hình YAML và CLI phù hợp với mọi ngôn ngữ, hãy cài promptfoo. Với sự phân tách rõ ràng nhất giữa câu trả lời tốt và xấu mà chúng tôi đo được, hãy cài Opik. Cả ba đều dùng giấy phép Apache-2.0 hoặc MIT.

Đây là kết quả kiểm tra. Tám framework nằm trong phạm vi, cộng thêm ba framework khác mà các trang xếp hạng đầu cho truy vấn này vẫn khuyên dùng.

Ngày tháng là commit cuối trên nhánh mặc định của mỗi dự án tính đến 2026-08-04. Trang repo của GitHub hiển thị lần push cuối lên bất kỳ nhánh nào, muộn hơn với hai dự án ở đây: UpTrain 2024-08-18 và Deepchecks 2025-12-28. Không repo nào bị archive.

Cột chi phí chuyển đổi là cột mọi người hay bỏ qua rồi sau đó hối hận. Điểm số chỉ là con số, nên chuyển giữa DeepEval, Ragas, Opik và phoenix-evals chủ yếu chỉ là viết lại một vòng lặp. Chuyển khỏi promptfoo hoặc Inspect AI nghĩa là viết lại định dạng cấu hình hoặc task mà không có gì tương đương ở nơi khác, còn chuyển khỏi Evidently nghĩa là phải rà lại từng ngưỡng bạn từng viết, vì thang điểm của nó chạy theo chiều ngược lại. Hai trong số các framework mà các trang xếp hạng đầu vẫn khuyên dùng đã không phát hành bản mới nào kể từ 2024.

Muốn xem các tier, nền tảng có trả phí và một bảng xếp hạng rõ ràng? Đó là một việc khác, và chúng tôi đã làm rồi trong bảng so sánh xếp hạng công cụ đánh giá LLM bao gồm cả nền tảng trả phí.

Tám Framework Đánh Giá LLM, Phân Nhóm Theo Cách Cài Đặt

Hình thức cài đặt là thứ bạn phải sống chung, nên đó là cách chúng tôi phân nhóm.

Thư viện Python bạn import vào test

DeepEval (pip install deepeval, Apache-2.0) bọc các chỉ số LLM trong assertion kiểu pytest: xây một LLMTestCase, đưa nó cho assert_test, và test sẽ fail nếu dưới ngưỡng bạn đặt. Mạnh nhất khi đặt một cổng chất lượng ngay cạnh các unit test mà đội bạn đã chạy sẵn. Chọn cái này nếu eval của bạn thuộc về cùng CI job với mọi thứ khác.

Một tiết lộ, nói một lần: DeepEval được xây dựng bởi Confident AI, đối tác trả phí trên hai bài viết khác trên trang này, bao gồm cả bảng so sánh xếp hạng mà trang này liên kết tới. Nó không nhận được ưu ái nào ở đây, và mọi liên kết DeepEval trên trang này đều trỏ tới repo GitHub.

Ragas (pip install ragas, Apache-2.0) là lựa chọn chuyên cho RAG: evaluate() nhận các hàng câu hỏi, ngữ cảnh và câu trả lời, rồi trả về điểm theo từng chỉ số một cách bất đồng bộ. Mạnh nhất khi đo chất lượng truy xuất bên trong pipeline Python. Repo của nó đã chuyển từ explodinggradients sang vibrantlabsai, bản phát hành cuối là v0.4.3 vào ngày 2026-01-13, và không có commit nào kể từ 2026-02-24. Chọn cái này nếu chỉ số RAG là toàn bộ công việc và một repo im ắng vẫn chấp nhận được, và xem thêm bộ công cụ RAG rộng hơn.

Opik (pip install opik, Apache-2.0, từ Comet) cung cấp các chỉ số bạn có thể gọi độc lập. Đặt OPIK_TRACK_DISABLE=true và AnswerRelevance().score() chạy được mà không cần tài khoản, không cần server local, không cần file cấu hình — điều mà cách quảng bá sản phẩm không nhắc tới. Mạnh nhất khi cần một điểm số thật với ít dòng code nhất. Chọn cái này nếu bạn muốn có chỉ số ngay bây giờ và nền tảng thì để sau.

Evidently (pip install evidently, Apache-2.0) coi eval là các descriptor trên một dataset và ghi ra báo cáo HTML như một hiệu ứng phụ. Mạnh nhất khi báo cáo hàng loạt trên nhiều dòng thay vì một cổng nhị phân. Điểm số LLM của nó bị đảo ngược: 1.0 nghĩa là không trung thực (unfaithful). Chọn cái này nếu thứ bạn nợ ai đó là một báo cáo có thể chia sẻ, không phải một build đỏ.

Giskard (pip install giskard, Apache-2.0) quét một mô hình để tìm lỗ hổng thay vì chấm điểm một dataset bạn tự viết. Gói PyPI phân giải về dòng v2, và README của chính dự án này ghi rõ rằng v2 "không còn được bảo trì tích cực". Mạnh nhất khi quét kiểu red-team tự động. Chọn cái này nếu bạn muốn lỗ hổng được tìm ra giúp bạn thay vì tự định nghĩa chỉ số LLM-as-a-judge.

Công cụ CLI-và-cấu-hình bạn chạy trên file YAML

promptfoo (npm install promptfoo, MIT) là một CLI đọc file YAML: khai báo provider, test case và assertion, chạy npx promptfoo eval, rồi nhận kết quả pass/fail cho từng case cộng một UI kết quả local. Mạnh nhất khi đánh giá prompt lúc ứng dụng của bạn không viết bằng Python. Chọn cái này nếu cổng chất lượng của bạn nên là một file cấu hình mà đồng đội không rành Python cũng sửa được.

Nhóm harness và nhóm đóng gói nền tảng

Inspect AI (pip install inspect-ai, MIT) đến từ UK AI Safety Institute và đánh giá mô hình dựa trên các task bạn tự định nghĩa bằng Python, với các abstraction solver và scorer thật cùng một run viewer. Mạnh nhất khi benchmark ở cấp mô hình với các định nghĩa task có thể tái lập. Chọn cái này nếu thứ đang được kiểm thử là một mô hình chứ không phải ứng dụng của bạn.

Arize Phoenix (pip install arize-phoenix-evals) cho bạn các evaluator dựng sẵn như FaithfulnessEvaluator và CorrectnessEvaluator, trả về một nhãn nhị phân cộng một điểm số. Mạnh nhất khi cần nhãn tất định mà bạn có thể gate mà không phải chọn ngưỡng cắt. Giấy phép của nó là lý do bài viết này có một cụm trong ngoặc ở tiêu đề, và điều đó có phần riêng ngay sau đây.

Arize Phoenix Có Phải Là Mã Nguồn Mở Không?

Không, không theo định nghĩa mà Open Source Initiative duy trì. Arize Phoenix chạy dưới Elastic License 2.0 (ELv2). Dòng đầu tiên trong file LICENSE của repo ghi rõ điều đó, và PyPI độc lập khai báo license: Elastic-2.0 trên v19.15.0. Mã nguồn có thể đọc, fork và tự host được. Chỉ một cách dùng bị hạn chế.

Hạn chế quan trọng: ELv2 cấm cung cấp phần mềm cho bên thứ ba dưới dạng dịch vụ được host hoặc quản lý. Hãy đọc kỹ, vì nó chỉ ràng buộc một số ít người hơn nhiều so với vẻ ngoài của nó. Nếu bạn cài arize-phoenix-evals để chấm điểm ứng dụng của chính mình, ELv2 không đụng tới bạn. Nếu bạn là một công ty tư vấn hoặc một đội nền tảng đóng gói Phoenix thành dịch vụ eval bán cho khách hàng bên ngoài, nó có đụng tới. Đó là toàn bộ khác biệt, và Open Source Definition chính là thứ mà ELv2 không đạt, cụ thể là các điều khoản về hạn chế lĩnh vực sử dụng (field-of-use).

Mọi trang hiện đang xếp hạng cho truy vấn này đều xếp Phoenix vào "mã nguồn mở", và chúng tôi cũng từng vậy. Bảng so sánh xếp hạng công cụ đánh giá LLM của chính chúng tôi mô tả Phoenix là hoàn toàn mã nguồn mở, điều đó sai, và đang được sửa lại. Phoenix là source-available, không phải mã nguồn mở, và sự khác biệt này chỉ thực sự quan trọng nếu bạn định bán nó như một dịch vụ. Nếu thứ bạn thực sự cần là tracing chứ không phải chấm điểm, điều đó thuộc về nền tảng observability AI, không phải bài viết này.

Cái Nào Trong Số Này Vẫn Đang Được Bảo Trì Tích Cực?

Hầu hết đều còn. Sáu trong số mười một repo chúng tôi kiểm tra có commit vào main vào ngày 2026-08-03 hoặc 2026-08-04: DeepEval, promptfoo, Opik, Arize Phoenix, Inspect AI và Giskard. Hai cái không phát hành bản mới nào kể từ 2024. Một cái đã im ắng trong năm 2026 sau khi đổi tổ chức GitHub.

Các framework chúng tôi sẽ không bắt đầu dự án mới trong năm 2026

UpTrain đã chết. Commit cuối cùng vào main là ngày 2024-07-29 và bản phát hành cuối, v0.7.1, là ngày 2024-05-14, khiến nó nguội lạnh hai năm theo cả hai thước đo. Repo vẫn còn đó và vẫn dùng Apache-2.0, nên không có gì ngăn cản bạn, nhưng bắt đầu công việc mới trên một thư viện đánh giá bị bỏ rơi là quyết định bạn sẽ phải giải thích sau này.

Deepchecks xứng đáng được nói chính xác. Nó không có bản phát hành nào kể từ 0.19.1 vào ngày 2024-12-15, dù repo vẫn nhận commit, với commit cuối trên main vào ngày 2025-11-24. Người ta vẫn đang làm việc trên nó; chỉ là chưa ai cắt một phiên bản mới trong hơn mười tám tháng qua. Cả UpTrain lẫn Deepchecks đều không bị archive trên GitHub, và cả hai đều chưa đóng cửa với đóng góp.

Ragas chỉ nhận ngày tháng, không gì khác. Bản phát hành cuối v0.4.3 vào ngày 2026-01-13, không có commit nào kể từ 2026-02-24, và repo đã chuyển từ explodinggradients sang vibrantlabsai. Chúng tôi không tìm thấy lý giải nào có thể xác minh được về lý do đổi tổ chức, nên chúng tôi sẽ không bịa ra một cái. Một repo im ắng không có nghĩa là hỏng: mã Apache-2.0 tính điểm faithfulness hôm nay vẫn sẽ tính đúng như vậy vào năm sau. Rủi ro nằm ở các dependency chưa được vá, chính là điều đã gây khó cho chúng tôi trong phần test bên dưới.

Các trang khác ở trang một cho truy vấn này vẫn khuyên dùng cả UpTrain lẫn Deepchecks, không kèm ngày tháng nào cho khuyến nghị đó. Một framework không phát hành bản mới nào kể từ tháng 12/2024 là quyết định về dependency, không phải quyết định về tính năng.

Bạn Cần Một Eval Framework Hay Một Eval Harness?

Một application eval framework chấm điểm đầu ra của chính ứng dụng bạn trên dữ liệu của chính bạn. DeepEval, Ragas, promptfoo, Opik, phoenix-evals và Evidently đều làm việc đó. Một model eval harness (harness đánh giá mô hình) thì benchmark một mô hình theo các task công khai tiêu chuẩn thay vì vậy. lm-evaluation-harness và Inspect AI làm việc đó. Chọn sai loại là sai lầm tốn kém nhất trên trang này.

Kiểu lỗi này rất cụ thể. Ai đó nối lm-evaluation-harness vào để test chatbot RAG của họ, nhận về một loạt điểm MMLU, và không học được gì về việc retriever của họ có trả đúng đoạn văn hay không. Điểm số là thật. Chúng đang đo mô hình nền, thứ mà chẳng ai lo lắng cả.

Hình dạng của Inspect AI xuất phát từ nguồn gốc của nó: nó được xây tại UK AI Safety Institute dưới giấy phép MIT để đánh giá các mô hình frontier, nên solver, scorer và task là công dân hạng nhất còn ứng dụng của bạn không phải là một khái niệm mà nó có. Đó là lý do chính đáng để dùng nó cho đúng việc của nó. Nếu vấn đề của bạn là agent chứ không phải các lượt đơn, đánh giá agent trong production là một chuyên môn khác hẳn, và các server tool-calling có riêng một bài trong hướng dẫn đánh giá MCP server và tool của chúng tôi.

Chuyện Gì Xảy Ra Khi Chúng Tôi Cài Sáu Cái Và Chạy Cùng 10 Case

Vào ngày 2026-08-04 chúng tôi cài sáu framework này trong các venv Python 3.11.14 mới (cộng npm cho promptfoo) và chấm điểm cùng một bộ 10 mục RAG với cùng một giám khảo, openai/gpt-4o-mini qua OpenRouter ở temperature 0. Bảy mục đúng. Ba mục sai theo ba cách khác nhau: một mâu thuẫn với ngữ cảnh, một bịa ra chi tiết cụ thể, một là văn xuôi trôi chảy nhưng không bao giờ trả lời câu hỏi. Mỗi framework chạy hai lần, liên tiếp.

Năm trong sáu chỉ số grounding bắt được cả ba lỗi. Ba phát hiện dưới đây là lý do phần này tồn tại.

Chỉ số relevance không phải là chỉ số chất lượng, và hai trong số đó đã chấm một lời nói dối tự tin cao hơn một câu trả lời đúng. Ragas ResponseRelevancy chấm mục khẳng định rằng HTTP 404 là lỗi server 5xx ở mức 0.777, cao hơn hai trong bảy câu trả lời đúng, và mục bịa ra giới hạn rate limit ở mức 0.813, cao hơn bốn câu. promptfoo answer-relevance cũng làm y hệt: 0.800 cho mục 404, một pass sạch so với ngưỡng 0.7, trong khi lại fail câu q01 đúng ở mức 0.679. Không phải bug. Một câu trả lời sai nhưng tự tin vẫn giải quyết đúng câu hỏi một cách hoàn hảo. Nhưng nếu relevance là con số trên dashboard của bạn, một ảo giác trôi chảy sẽ trông như đầu ra tốt nhất của bạn.

Một cổng chỉ dựa trên faithfulness sẽ bỏ sót câu trả lời lạc đề. DeepEval chấm mục không bao giờ trả lời câu hỏi ở mức 1.000 faithfulness, một pass sạch, điều này có thể biện minh được: một câu trả lời không khẳng định gì về ngữ cảnh thì cũng không mâu thuẫn gì với nó. Chỉ có relevancy bắt được nó, ở mức 0.000. Đó là lần bỏ sót grounding duy nhất trong bảng trên. Mỗi chỉ số đứng riêng đều có lỗ hổng; cặp đôi che phủ cả hai.

Các evaluator nhị phân ổn định ở temperature 0. Các evaluator có điểm theo thang thì không. Phoenix và DeepEval không xê dịch mục nào trong mười mục qua hai lần chạy giống hệt nhau. Opik xê dịch bốn mục, tất cả trên AnswerRelevance, trên lưới 0.05; Evidently cũng xê dịch bốn mục. Không có trôi dạt nào lật ngược verdict ở đây, nhưng câu q01 đúng của promptfoo rơi vào 0.679 rồi 0.642 so với ngưỡng 0.700, đúng hình dạng của một cổng CI chập chờn.

Hai ghi chú nhỏ hơn: ba trong sáu (DeepEval, Opik, Phoenix) cài đặt và chạy sạch ngay lần đầu, trong khi Ragas không import được cho đến khi chúng tôi pin langchain-community<0.4. Chỉ promptfoo báo cáo mức dùng token của giám khảo, 16.011 token assertion ở lần chạy 1 và 16.010 ở lần chạy 2.

Giới hạn của bài test này, nói thẳng. n = 10 là smoke test, không phải benchmark: nó cho bạn biết về trải nghiệm sử dụng và điểm mù, không phải độ chính xác của chỉ số. Một mô hình giám khảo duy nhất chấm mọi thứ, và một giám khảo lớn hơn sẽ làm thay đổi mọi con số, có lẽ bao gồm cả hai false positive mà DeepEval và Ragas cùng tạo ra trên cùng một mục đúng. Hai lần chạy chứng minh có trôi dạt nhưng không thể mô tả đặc điểm của nó. Các câu trả lời đã được viết sẵn từ trước, nên không có gì ở đây kiểm thử phần generation, tracing hay quản lý dataset, điều này khiến 337.9 giây cài đặt của promptfoo trông tệ hơn thực tế đáng có. "Tốt nhất" luôn có nghĩa là tốt nhất cho một ràng buộc cụ thể: một cổng CI, chỉ số RAG hay một UI đều thay đổi câu trả lời, cũng như sự khác biệt giữa đánh giá offline và online.

Cùng Một Kiểm Tra, Viết Theo Ba Cách

Cách nhanh nhất để chọn kiểu giao diện là đọc cùng một assertion ba lần. Đây là một kiểm tra grounding trên một mục trong DeepEval, Ragas và promptfoo, được cắt gọn từ các script chúng tôi thực sự đã chạy. Tên chỉ số khác nhau; chúng tôi liên kết tới cách các chỉ số LLM-as-a-judge thực sự hoạt động thay vì định nghĩa lại chúng ở đây.

# DeepEval 4.1.5: kiểu pytest, test fail nếu dưới ngưỡng
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3: chú ý đường dẫn import. `from ragas.metrics import Faithfulness`
# raise ImportError ở phiên bản này; chỉ số cụ thể đã di chuyển.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20: npm install promptfoo, sau đó npx promptfoo eval
providers:
  - id: echo          # chúng tôi chấm điểm câu trả lời viết sẵn thay vì tạo mới
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

Các dòng cài đặt chứa nhiều bẫy hơn cả code, và mỗi comment dưới đây là thứ đã tốn thời gian của chúng tôi vào ngày 2026-08-04:

# promptfoo thật được phát hành trên npm. Gói PyPI cùng tên là một
# wrapper của bên thứ ba: https://pypi.org/project/promptfoo/ so với
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard phân giải về dòng v2, thứ mà README của chính dự án
# đánh dấu là không còn được bảo trì tích cực.
pip install giskard

# lm-evaluation-harness được cài dưới tên gói lm-eval.
pip install lm-eval

# Evidently không kéo theo openai, và giám khảo crash lúc gọi hàm chứ
# không phải lúc import, sau khi bạn đã xây xong dataset.
pip install evidently openai

# Ragas 0.4.3 sẽ không import được với langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

Bạn Có Thể Làm Build Fail Dựa Trên Điểm Eval Không?

Có. Mọi framework ở đây đều trả về một điểm số hoặc nhãn nhị phân, và mỗi cái sẽ thoát với mã khác 0 khi một assertion ngưỡng fail, đó là tất cả những gì GitHub Actions cần để biến một build thành đỏ. Nối dây exit code là phần dễ. Chọn một ngưỡng mà mô hình giám khảo của bạn sẽ không vô tình vượt qua mới là phần tốn cả tuần.

Đây là hình dạng workflow chúng tôi chạy, pin theo các phiên bản từ bài test ngày 2026-08-04:

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Chấm bộ dữ liệu golden
        env:
          # Pin giám khảo. Nâng cấp mô hình giữa quý sẽ làm thay đổi mọi điểm số.
          JUDGE_MODEL: openai/gpt-4o-mini
          # Ngưỡng nằm ở một nơi duy nhất, được đọc bởi constructor của chỉ số.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

Hai bẫy cắn bạn trước cả khi ngưỡng kịp cắn. Đầu tiên, các cuộc gọi giám khảo là network call: lần chạy DeepEval 10 mục của chúng tôi mất 126.8 giây vì .measure() chạy tuần tự, và một golden set 200 mục trên cùng đường code đó là một giờ giải lao cà phê trên mỗi pull request. Mọi framework khác trong bài test đều song song hóa mặc định, đây là đòn bẩy đơn lẻ lớn nhất lên thời gian CI thực tế.

Thứ hai, sự chập chờn. Ở temperature 0, Opik và Evidently mỗi cái xê dịch bốn trong mười mục giữa hai lần chạy liên tiếp, và câu trả lời đúng của promptfoo nằm ở 0.679 rồi 0.642 so với cổng 0.700. Các biện pháp giảm thiểu đơn giản và có hiệu quả: chạy một golden dataset cố định chỉ thay đổi theo pull request, pin mô hình giám khảo, ưu tiên evaluator nhị phân ở nơi một nhãn là đủ, và gate theo delta thay vì một mức sàn tuyệt đối. Điều cuối cùng đó quan trọng nhất với đánh giá đa lượt, nơi một cuộc hội thoại tạo ra nhiều điểm số mà mỗi cái đều có thể xê dịch.

Về quy mô: khảo sát State of Agent Engineering của LangChain (1.340 phản hồi, thu thập từ 18 tháng 11 đến 2 tháng 12 năm 2025, công bố ngày 12 tháng 6 năm 2026) cho thấy 89% tổ chức đã triển khai một hình thức observability nào đó cho agent của họ, trong khi chỉ 52.4% chạy đánh giá offline trên bộ test. Theo dõi thì phổ biến. Gate thì không.

Chúng Tôi Sẽ Cài Gì Trong Tuần Này

Bốn điều cần nhớ. Arize Phoenix là source-available theo Elastic License 2.0 và không được OSI công nhận là mã nguồn mở, điều này không thay đổi gì với hầu hết độc giả nhưng thay đổi mọi thứ nếu bạn bán lại công cụ eval. UpTrain đã chết, và các trang không ghi ngày tháng vẫn khuyên dùng nó. Deepchecks cũng chưa cắt bản phát hành nào kể từ tháng 12/2024, dù repo của nó vẫn nhận commit. Một chỉ số grounding và một chỉ số relevance mỗi cái đều có một lỗ hổng mà cái kia che phủ, nên hãy gate trên cả hai. Và điểm số theo thang trôi dạt ở temperature 0, nên hãy pin giám khảo của bạn và cho ngưỡng thêm khoảng dư.

Nếu tôi bắt đầu một bộ eval mới trong tuần này, tôi sẽ cài DeepEval cho cổng CI vì assertion thuộc về ngay cạnh test (tiết lộ ở trên), và thêm các chỉ số độc lập của Opik cho sự phân tách rõ ràng nhất mà chúng tôi đo được. Nếu stack của chúng tôi không phải Python, thì promptfoo, không do dự. Nếu bạn muốn ai đó khác nối dây golden set và workflow giúp bạn, đó là cuộc trò chuyện chúng tôi rất sẵn lòng có.

Câu Hỏi Thường Gặp

Framework đánh giá LLM mã nguồn mở tốt nhất là gì?

Không có một người chiến thắng duy nhất, chỉ có sự phù hợp tốt nhất cho từng ràng buộc. Với một cổng pass/fail bên trong bộ test Python, DeepEval. Với thiết lập YAML và CLI không phụ thuộc ngôn ngữ, promptfoo. Với chỉ số truy xuất RAG, Ragas, nếu bạn chấp nhận một repo không có commit nào kể từ 2026-02-24. Với sự phân tách rõ ràng nhất giữa câu trả lời tốt và xấu trong bài test 2026-08-04 của chúng tôi, Opik.

Arize Phoenix có phải là mã nguồn mở không?

Không, theo định nghĩa của Open Source Initiative. Arize Phoenix chạy dưới Elastic License 2.0, thứ mà PyPI khai báo là license: Elastic-2.0 trên v19.15.0 và dòng đầu tiên trong file LICENSE của repo ghi rõ trực tiếp. Nó là source-available: bạn có thể đọc, fork, sửa và tự host nó. Hạn chế duy nhất là cung cấp phần mềm cho bên thứ ba dưới dạng dịch vụ được host hoặc quản lý.

Ragas có còn được bảo trì không?

Các sự thật có thể xác minh, tính đến 2026-08-04: bản phát hành cuối là v0.4.3 vào ngày 2026-01-13, không có commit nào kể từ 2026-02-24, và repo đã chuyển từ tổ chức explodinggradients sang vibrantlabsai. Repo không bị archive. Chúng tôi không tìm thấy lời giải thích công khai đáng tin cậy nào cho việc đổi tổ chức và sẽ không suy đoán về nó. Mã Apache-2.0 vẫn chạy tốt; rủi ro nằm ở các dependency chưa được vá.

Tôi cần một eval framework hay một nền tảng observability?

Cả hai, cuối cùng thì vậy, nhưng chúng trả lời những câu hỏi khác nhau. Một eval framework cho bạn biết một thay đổi có làm đầu ra của bạn tốt hơn hay tệ hơn trước khi bạn ship nó, trên một dataset bạn kiểm soát. Một nền tảng observability cho bạn biết điều gì thực sự đã xảy ra trên production sau khi bạn ship. Bắt đầu với eval framework nếu bạn có pipeline CI; xem nền tảng observability AI cho phía production.

Tôi có thể chạy LLM eval trong CI/CD không?

Có. Mọi framework được đề cập ở đây đều thoát với mã khác 0 khi một assertion ngưỡng fail, đó là tất cả những gì một job GitHub Actions cần. Các ràng buộc thực tế là thời gian thực thi (các cuộc gọi giám khảo là network call, và lần chạy DeepEval tuần tự của chúng tôi mất 126.8 giây cho 10 mục) và tính không tất định của giám khảo. Hình dạng workflow và các biện pháp giảm thiểu nằm trong phần CI ở trên.

Sự khác biệt giữa DeepEval và Ragas là gì?

Kiểu giao diện và phạm vi, không phải chất lượng. DeepEval có kiểu pytest và mục đích chung: bạn viết test case và assert trên các ngưỡng chỉ số, và nó bao phủ đầu ra ứng dụng thuộc nhiều loại. Ragas là một thư viện chuyên cho RAG mà evaluate() chạy bất đồng bộ trên một dataset gồm các hàng câu hỏi, ngữ cảnh và câu trả lời. DeepEval phù hợp hơn với cổng CI một cách tự nhiên; Ragas đi sâu hơn về truy xuất.

Tại sao pip install promptfoo lại cho tôi gói sai?

Vì promptfoo là một dự án Node. Dự án thật được phát hành trên npm dưới giấy phép MIT và cài bằng npm install promptfoo. Gói PyPI cùng tên là một wrapper của bên thứ ba, không phải dự án gốc, và cài nó là một cách phổ biến để bạn phải debug một CLI không phải cái mà tài liệu mô tả.

lm-evaluation-harness có phải là một framework đánh giá LLM không?

Nó là một harness đánh giá mô hình, một công việc liên quan nhưng khác. lm-evaluation-harness (cài đặt dưới tên pip install lm-eval) benchmark một mô hình theo các task công khai tiêu chuẩn như MMLU. Nó sẽ không cho bạn biết pipeline truy xuất của bạn có trả về đúng đoạn văn hay không, vì ứng dụng của bạn không phải là một khái niệm mà nó có. Xem phần framework-so-với-harness ở trên để biết sự khác biệt.

Các framework này có miễn phí sử dụng không?

Về mặt giấy phép, có. DeepEval, Ragas, Opik, Evidently và Giskard dùng Apache-2.0; promptfoo, Inspect AI và lm-evaluation-harness dùng MIT. Cả hai giấy phép đều cho phép dùng thương mại, sửa đổi và phân phối lại. Arize Phoenix là ngoại lệ: Elastic License 2.0 cho phép tự host nhưng không cho phép cung cấp phần mềm cho bên thứ ba dưới dạng dịch vụ quản lý. Chi phí sử dụng API mô hình giám khảo được nhà cung cấp của bạn tính riêng.