Skip to content

Nhật ký thay đổi

Những gì đã ra mắt, và điều đó thay đổi gì cho một quyết định phát hành.

  1. SDK

    Oloproof đã có trên PyPI

    oloproof 0.1.0a1 đã được phát hành, nên lộ trình chuẩn bắt đầu bằng pip install oloproof trong một môi trường sạch và đi thẳng tới oloproof init và oloproof run. Các bản phát hành được build và xuất bản từ một commit có gắn tag trong CI, qua trusted publishing của PyPI, không lưu token nào.

  2. Workbench

    Phát lại cách một lần chạy đi đến quyết định

    Một lần chạy hoặc một phép so sánh dừng sớm giờ ghi lại mọi lần xem xét mà nó đã thực hiện, và workbench phát lại chúng: khoảng anytime-valid thu hẹp ở mỗi lần xem xét so với một ngưỡng không đổi, và lần xem xét mà tại đó mọi quy tắc đã quyết định. Nó chỉ vẽ những khoảng mà engine đã ghi lại. Một khoảng cỡ mẫu cố định không bao giờ được hoạt họa như thể đang trực tiếp, vì theo dõi nó cho đến khi trông có vẻ tốt sẽ làm mất hiệu lực đảm bảo của nó.

  3. Workbench

    Bảng lệnh, điều hướng bằng bàn phím và chuỗi bằng chứng

    ⌘K hoặc Ctrl+K liệt kê mọi đích đến bạn có thể xem, và dán một ID lần chạy hoặc digest của phép so sánh sẽ mở ngay nó. g rồi một chữ cái để điều hướng, j và k để di chuyển giữa các hàng của bảng, và ? liệt kê mọi phím tắt. Một trường hợp mở ra bên cạnh lần chạy của nó, cùng chuỗi bằng chứng và những người đã gán nhãn cho nó. Mọi hoạt ảnh đều dừng khi bật chế độ giảm chuyển động.

  4. Lưu trữ

    Workbench lưu trữ trên oloproof.com

    Workbench giờ đã chạy trên oloproof.com, và lộ trình chuẩn end-to-end đã vượt qua trên máy chủ: một người đánh giá đã gán nhãn 80 trường hợp mà không gian làm việc rút ra, tìm thấy 7 câu trả lời sai mà giám khảo đã cho qua, và không gian làm việc đã quyết định Đạt trên mẫu đã xác minh của nó (91,2%, khoảng từ 74,5% đến 100,0%) trong khi riêng lần chạy được đẩy lên thì không đủ bằng chứng. Truy cập theo lời mời.

  5. Trace

    Trace OpenTelemetry vào oloproof collect

    oloproof collect nhận OTLP/HTTP từ một OpenTelemetry SDK tiêu chuẩn, ghép các span GenAI và OpenInference thành các trace được định địa chỉ theo nội dung, và giữ nội dung của chúng trên máy của bạn; một lần đẩy tuân theo chính sách egress của bạn. oloproof traces promote biến một trace thành một trường hợp kiểm thử kèm nguồn gốc của nó, và từ chối các bản trùng lặp.

  6. Trace

    Quyết định trên các mẫu lưu lượng production

    Collector của bạn ký một cam kết cho mọi trace mà nó niêm phong mỗi giờ. Sau đó không gian làm việc rút một mẫu bằng nguồn ngẫu nhiên của riêng nó và đối chiếu từng trace được rút với cam kết, nên không thể chọn lọc mẫu bằng cách giữ lại trace. oloproof traces evaluate chấm mẫu dựa trên các đầu ra đã ghi lại, không gian làm việc quyết định nó theo bản đánh giá mà một Owner đã cố định, và một chuỗi tin cậy theo dõi từng chỉ số qua các mẫu trên trang Production của dự án.

  7. Xem xét

    Hàng đợi đánh giá trong trình duyệt

    Một Owner hoặc Admin mở một hàng đợi và phân công người đánh giá, những người gán nhãn bằng bàn phím: đạt hoặc không đạt, một điểm trên thang đã khai báo, hoặc một lựa chọn ưu tiên mù giữa hai lần chạy, mỗi nhãn được ghi theo tài khoản. Trình duyệt của người đánh giá lấy nội dung trường hợp từ oloproof collect ở phía bạn bằng một vé đã ký có hiệu lực năm phút, nên không gian làm việc không bao giờ giữ nội dung đó.

  8. Cổng

    Thực thi đã xác minh

    Một lần chạy có thể được ký bởi một khóa runner mà Owner đã đăng ký, hoặc bởi worker được quản lý. Một Owner cố định toàn bộ bản đánh giá (bộ kiểm thử, bộ đánh giá, chỉ số và lần chạy cơ sở) cùng chính sách cổng của nó, và không gian làm việc quyết định từng phiên bản hệ thống ở lần chạy đầu tiên của chính bản đánh giá đó, so với lần chạy đã cố định. Nhãn của con người chỉ được tính từ những người gán nhãn độc lập, tính theo tài khoản.

  9. Giám khảo

    Mẫu con người do không gian làm việc rút

    Một khoảng PPI hiệu chỉnh giám khảo bằng một mẫu ngẫu nhiên nhãn của con người, và đảm bảo của nó cần một mẫu không do ai chọn. Không gian làm việc giờ rút mẫu đó sau khi bằng chứng của lần chạy đã được đóng băng tại đó, giữ seed cho riêng mình, và kiểm tra khoảng đã hiệu chỉnh bằng engine của chính nó. Trang lần chạy cho biết không gian làm việc đã xác minh một khoảng hay chưa; một mẫu được rút trên máy của chính bạn vẫn được gắn nhãn thiện chí.

  10. Đánh giá

    Dừng sớm, và tỷ lệ của giám khảo được con người hiệu chỉnh

    Một chính sách với early_stopping: true chạy các trường hợp theo từng lô có seed và dừng một lần chạy, hoặc một ứng viên cùng lần chạy cơ sở của nó theo nhịp đồng bộ, ngay khi mọi quy tắc đã quyết định, được ghi là DECIDED_EARLY cùng các trường hợp không cần đến. Các tỷ lệ đã dừng dùng một khoảng cá cược anytime-valid, nên xem xét sau mỗi lô vẫn giữ được đảm bảo của nó. Tỷ lệ đạt của một giám khảo có thể được đặt cổng trên một khoảng PPI kết hợp giám khảo với một mẫu ngẫu nhiên mù gồm nhãn của con người, hiển thị bên cạnh khoảng chỉ của giám khảo và khoảng chỉ của con người.

  11. Email

    Thông báo qua email

    Bốn thông báo, mỗi loại là một danh mục mà thành viên có thể tắt ngay từ chính email: một tác vụ được quản lý đã hoàn tất hoặc thất bại, một lần chạy hoặc phép so sánh được đẩy lên có cổng chặn phát hành, mức sử dụng đạt 80% và 100% hạn mức miễn phí, và một thành viên mới tham gia. Email về cổng trích dẫn quyết định đã lưu và liên kết tới lần chạy, không kèm nội dung trường hợp. Chỉ email: không có Slack, máy nhắn tin hay webhook.

  12. Tài khoản

    Mật khẩu, và xóa tài khoản của bạn

    Đăng nhập bằng địa chỉ email và mật khẩu cũng như bằng một nhà cung cấp, với địa chỉ đã xác minh và đặt lại mật khẩu. Một người có thể xóa tài khoản của chính mình: người dùng và mọi không gian làm việc chỉ có riêng họ là thành viên bị xóa cùng lúc, và worker dọn sạch bằng chứng của các không gian làm việc đó.

  13. Giám khảo

    Giám khảo xác suất, hiệu chuẩn và cascade

    Một giám khảo có thể trả lời một câu hỏi có kiểu (có hoặc không, một lựa chọn, một điểm theo các mức) bằng một xác suất cho mọi câu trả lời, đọc từ xác suất token của một mô hình cục bộ trong một lượt truyền xuôi. Mức hiệu chuẩn của nó được đo so với nhãn của con người và ghi vào mục registry của nó, và một cascade chỉ gửi những trường hợp mà giám khảo rẻ không chắc chắn sang một giám khảo mạnh hơn. Một bộ phân loại đã huấn luyện cũng có thể là một bộ đánh giá, không cần khóa và không cần mạng.

  14. Giám khảo

    Giám khảo được đối chiếu với nhãn của con người

    Gán nhãn các trường hợp của một lần chạy từ một tệp hoặc từ terminal, và thử một giám khảo nháp với các nhãn đó trước khi chấp nhận nó. Một giám khảo báo cáo độ lệch bên cạnh mức đồng thuận, giám khảo có độ lệch vượt quá biên đã khai báo sẽ bị cấm làm cổng, và một lần xác thực không còn được tính khi mô hình mà nó đo thay đổi. Các phép thăm dò không cần nhãn kiểm tra xem một phán quyết có thay đổi khi không có gì quan trọng thay đổi hay không, và các phép so sánh theo cặp được hỏi theo cả hai thứ tự, nên một câu trả lời chỉ được ưa thích vì vị trí của nó sẽ lộ ra mà không cần ai gán nhãn.

  15. Agent

    Bằng chứng đa agent

    Một quỹ đạo ghi lại agent nào đã thực hiện từng bước, và mọi lần chuyển giao. Các bộ đánh giá chấm việc định tuyến (yêu cầu có đến được agent cần xử lý nó không), quyền dùng công cụ (có agent nào gọi một công cụ không thuộc quyền của nó không) và các agent chuyền qua lại quyền điều khiển thay vì hoàn thành, và các lát cắt nhóm các trường hợp theo tuyến.

  16. Đánh giá

    Lặp lại và số trường hợp chập chờn

    Một bộ kiểm thử có thể đo mỗi trường hợp nhiều lần. Các lần lặp được tổng hợp theo từng trường hợp trước mọi khoảng, các phép so sánh ghép cặp chúng dưới dạng phân số, và lần chạy báo cáo có bao nhiêu trường hợp tự mâu thuẫn với chính mình. Một hệ thống có thể đánh dấu một lỗi là tạm thời để runner thử lại: trên một hệ thống RAG đang chạy thật, điều đó đã khôi phục 18 trên 22 trường hợp bị thiếu và thu hẹp khoảng 39%.