Dùng GPT-4.1 mini để hợp nhất tài liệu: từ lời gọi API đến dữ liệu có thể kiểm tra

GPT-4.1 mini là một model nhỏ hơn trong dòng GPT-4.1, được OpenAI giới thiệu ngày 14/4/2025. Model nhận văn bản và hình ảnh, trả về văn bản, đồng thời hỗ trợ gọi hàm và đầu ra có cấu trúc. Với một ứng dụng đọc tài liệu, khả năng đáng quan tâm là đặt nhiều bản ghi liên quan vào cùng một yêu cầu rồi trích xuất thông tin theo quy tắc.

Vì sao vẫn xem xét model này trong năm 2026? Một chức năng lấy người phụ trách, hạn chót và điều kiện nghiệm thu có phạm vi khá rõ. Theo bảng giá API chính thức của OpenAI tại thời điểm kiểm tra, đơn giá văn bản đầu vào và đầu ra ở chế độ Standard của GPT-4.1 mini thấp hơn flagship mới hơn là GPT-6 Astra. Đây là lý do để đánh giá nó cho một công đoạn cụ thể; lợi ích thực tế còn phụ thuộc vào việc kiểm tra kết quả có tốn nhiều công hay không. So sánh này không phải chi phí của các lần gọi Crazyrouter bên dưới.

Ngày 30/10/2026, tôi dùng Crazyrouter API để thử hợp nhất một bộ tài liệu dự án bằng tiếng Trung giản thể. Model ghép đúng các thay đổi của một nhiệm vụ, nhưng ở nhiệm vụ khác, nó tìm được hai hạn chót mâu thuẫn mà vẫn giữ trạng thái có thể khiến ứng dụng hiểu sai. Bài này đi từ cách gọi đến cách quyết định dữ liệu nào cần giữ lại để kiểm tra.

GPT-4.1 mini có thể đảm nhận phần nào của chức năng đọc tài liệu?

Tài liệu model của OpenAI nêu cửa sổ ngữ cảnh 1.047.576 token, đầu ra tối đa 32.768 token và mốc kiến thức 1/6/2024. Cửa sổ lớn cho phép cung cấp tài liệu gốc cùng các bản sửa đổi. Nó không bảo đảm model tìm đúng mọi chi tiết, và cũng không phải số lượng từ mà model luôn xử lý chính xác.

Tôi sẽ bắt đầu bằng một việc có đầu ra xác định: trích xuất các trường từ tài liệu, trả lời câu hỏi kèm nguồn, hoặc hợp nhất những thay đổi đã có hiệu lực. Đọc mã nguồn và giải thích hình ảnh là những hướng sử dụng khác dựa trên khả năng được công bố, chưa được kiểm tra trong thử nghiệm này. Gọi hàm cũng cần ứng dụng thực thi thao tác bên ngoài; model không tự có quyền sửa hệ thống dự án.

Trong ví dụ này, đầu ra mong muốn là một dòng cho mỗi nhiệm vụ, gồm id, owner, deadline, status, acceptance, sources và conflicts. Muốn dùng được dòng đó, ứng dụng cần biết cả giá trị lẫn lý do giá trị được chọn.

Chuẩn bị lời gọi qua Crazyrouter

Model cũng có đường truy cập qua OpenAI API; các yêu cầu được phân tích ở đây sử dụng giao diện Chat Completions tương thích OpenAI của Crazyrouter. Tạo hoặc đăng nhập tài khoản, tạo API key và kiểm tra điều kiện gọi hiện tại. Có thể đối chiếu mã model tại trang GPT-4.1 mini của Crazyrouter.

Với client cho phép cấu hình kết nối, dùng:

Base URL: https://api.crazyrouter.com/v1
Model: gpt-4.1-mini
API key: khóa Crazyrouter của bạn, đọc từ cấu hình an toàn

Nếu gửi HTTP trực tiếp, dùng POST tới https://api.crazyrouter.com/v1/chat/completions, xác thực Bearer và nội dung JSON. Trong body, model là mã phía trên, còn messages chứa hướng dẫn và văn bản nguồn. Client tự thêm đường dẫn endpoint chỉ cần Base URL; không thêm /chat/completions lần nữa. Giữ khóa ngoài mã nguồn và ảnh chia sẻ.

Yêu cầu đầu tiên nên dùng một bản ghi có đáp án rõ ràng, chẳng hạn lấy người phụ trách và ngày hoàn thành, trả về null nếu không có thông tin. Kiểm tra phản hồi có nội dung, kết thúc đầy đủ và khớp nguồn, rồi mới thêm một thông báo sửa đổi. Như vậy có thể phân biệt lỗi kết nối với lỗi hiểu tài liệu.

Các lần gọi chính thức của tôi đặt temperature=0, max_tokens=6000, stream=false và response_format=json_object. Đây là điều kiện thử nghiệm, không phải bộ tham số tối ưu cho mọi ứng dụng. JSON mode được bật, nhưng tôi không gửi strict JSON Schema. Kiểu dữ liệu và quy tắc nghiệp vụ nằm trong prompt, sau đó được kiểm tra bằng chương trình cục bộ.

Định nghĩa “hiện tại” trước khi yêu cầu hợp nhất

Bộ dữ liệu gồm 51 tài liệu ngắn, tổng cộng 12 nhiệm vụ: bản gốc, thay đổi được phê duyệt, bản nháp, thảo luận và tài liệu của các đợt cũ có mã nhiệm vụ trùng nhau. Tên người và sự kiện đều do tôi tạo cho thử nghiệm. Mỗi yêu cầu chính thức ghi nhận 26.430 token đầu vào; không phải phép thử ở giới hạn một triệu token.

Mốc đánh giá là 18:00 ngày 30/10/2026 trong tình huống giả lập. Tôi yêu cầu chỉ áp dụng thay đổi đã có hiệu lực, chỉ thay những trường được nêu rõ, giữ nguyên trường còn lại. Bản nháp và tài liệu đợt cũ không được ghi đè dữ liệu hiện tại. Thông tin thiếu phải để trống; hai quyết định chưa phân định ưu tiên phải được giữ lại cùng nguồn và chuyển nhiệm vụ sang trạng thái cần xác nhận.

Điều này khác với yêu cầu “tóm tắt các tài liệu”. Ứng dụng cần một trạng thái tại một thời điểm, nên ngày hiệu lực và phạm vi sửa đổi là một phần của đầu vào. Ví dụ T06 có thay đổi đã được phê duyệt nhưng chỉ có hiệu lực từ 2/11. Cả hai lần gọi đều giữ người phụ trách cũ và yêu cầu trả về 20 kết quả, chưa áp dụng yêu cầu mới là 50 kết quả.

Một dòng dữ liệu có thể được ghép từ nhiều nguồn

T01 ban đầu do Zhou Ning phụ trách, hạn chót 4/11 và phải giữ nhật ký kiểm toán 180 ngày. Tài liệu C01 đổi hạn thành 9/11; C02 chuyển người phụ trách sang Zheng Yan và giữ nguyên những trường khác.

GPT-4.1 mini trả về Zheng Yan, ngày 9/11/2026 và điều kiện giữ nhật ký 180 ngày. Cả hai lần gọi chính thức đều cho những giá trị này, kèm các nguồn B01, C01 và C02.

Hình 1. Sơ đồ tôi đã dựng từ tài liệu giả lập và phản hồi chính thức lần đầu, không phải ảnh giao diện. Hình giữ nguyên giá trị tiếng Trung và chú giải tiếng Anh; phần tiếng Việt ở trên diễn giải ý nghĩa. Quan hệ giữa từng trường và nguồn do tôi kiểm tra lại, không phải trích dẫn theo trường do API tự trả về.

Nếu chỉ lấy file mới nhất, ứng dụng sẽ thiếu những điều file đó không nhắc lại. Nếu chỉ đặt ba bản tóm tắt cạnh nhau, người dùng vẫn phải tự ghép. Kết quả này cho thấy model đã làm được bước hợp nhất trong bộ tài liệu có quy tắc rõ ràng.

Tuy nhiên, sources trong phản hồi là danh sách nguồn của cả nhiệm vụ. Muốn giao diện cho phép bấm vào từng trường để xem đúng đoạn làm căn cứ, cần yêu cầu thêm dữ liệu và kiểm chứng riêng. Sơ đồ không chứng minh đã có một giao diện dẫn nguồn như vậy.

JSON hợp lệ vẫn có thể chứa một nhiệm vụ chưa sẵn sàng

T02 có hai quyết định cùng hiệu lực: hạn 10/11 và 12/11, không quyết định nào hủy quyết định còn lại. Model đặt deadline thành null và giữ cả hai ngày cùng nguồn. Nhưng status vẫn là 待办, nghĩa là “việc cần làm”, thay vì 待确认, nghĩa là “cần xác nhận”, như yêu cầu.

Trường conflicts còn chứa một mảng lồng bên trong, trong khi quy ước yêu cầu mảng các chuỗi. JSON vẫn phân tích được. Chỉ kiểm tra cú pháp sẽ không phát hiện hai vấn đề này.

Hình 2. Hai trường hợp từ phản hồi đã lưu: thay đổi tương lai ở T06 và quyết định mâu thuẫn ở T02. Hình dùng tiếng Trung gốc cùng giải thích tiếng Anh. Trạng thái sai và mảng lồng được giữ nguyên; hướng xử lý là đề xuất của tôi, chưa phải kết quả sửa lỗi bằng model.

Tôi sẽ tách việc kiểm tra kết quả thành ba phần trước khi nhập dữ liệu: cấu trúc và kiểu trường; giá trị có đối chiếu được với nguồn hay không; các trường có tuân thủ quan hệ nghiệp vụ hay không. T02 cho một quy tắc cụ thể ở phần cuối: khi hạn chót còn tranh chấp, trạng thái phải yêu cầu xác nhận. Một danh sách nguồn đầy đủ không thay thế được quy tắc đó.

Nếu kiểm tra không đạt, nên giữ phản hồi gốc cùng tài liệu liên quan để người dùng quyết định. Tự chuyển một mảng lồng thành chuỗi có thể sửa hình dạng dữ liệu, nhưng không giải quyết được việc ai có quyền chọn hạn chót. Tôi chưa xây dựng hàng đợi duyệt hay đo hiệu quả sửa lỗi trong một hệ thống thật.

Phạm vi kết quả và cách giữ lại bài kiểm tra khi đổi model

Trước khi gọi, tôi đã chuẩn bị đáp án rồi dùng chương trình so sánh và đọc lại nguồn. Với cùng 12 nhiệm vụ được gọi hai lần, mỗi lần có 47/48 trường cốt lõi khớp, 12/12 dòng đạt kiểm tra nguồn và 11/12 dòng đạt cấu trúc. Cả hai kết quả đều chưa đạt toàn bộ yêu cầu vì T02. Một lần chạy thử ba nhiệm vụ trước đó cũng gặp cùng loại lỗi. Tổng cộng có ba yêu cầu sinh nội dung, không có lần gọi sửa lỗi hay chỉnh tay đáp án.

Đó là hai lần quan sát cùng bộ dữ liệu, không phải 24 nhiệm vụ độc lập. Prompt, tài liệu và đầu ra đều bằng tiếng Trung giản thể; bài viết tiếng Việt không phải một phép thử tiếng Việt mới. Hình ảnh, gọi công cụ, strict schema và giới hạn ngữ cảnh chưa được kiểm tra.

Cũng cần tính đến vòng đời model. Thông báo ngày 14/10/2026 của OpenAI lên lịch loại bỏ gpt-4.1-mini-2025-04-14 khỏi OpenAI API vào 14/1/2027. Crazyrouter trả lời được trong thử nghiệm này, nhưng điều đó không xác nhận lịch cung cấp tương lai của dịch vụ hay cho phép áp dụng nguyên lịch của OpenAI cho Crazyrouter.

Với chức năng hợp nhất tài liệu, tôi sẽ giữ bộ nguồn, đáp án và các trường hợp phải chờ xác nhận làm tài sản kiểm thử. Trước khi nạp tiền và thử model, kiểm tra khả năng cung cấp cùng điều kiện tính phí hiện tại. Sau một yêu cầu ngắn để xác nhận kết nối, dùng vài tài liệu mà mình biết rõ đáp án. Phần đáng giữ lâu dài là cách xác định một dòng dữ liệu đã đủ điều kiện sử dụng; điều đó vẫn cần thiết khi đổi sang model khác.