API suy luận đang khiến các cuộc hội thoại AI trở nên 'bị khóa' vào nhà cung cấp

Lời hứa ban đầu của một inference API (API suy luận) vốn vô cùng đơn giản: gửi đầu vào, nhận đầu ra. Nếu bạn lưu giữ cả hai, bạn sẽ có được cuộc hội thoại. Bạn có thể kiểm tra, lưu trữ, phát lại hoặc chuyển nó cho một mô hình khác.

Sự trừu tượng hóa đó chưa bao giờ hoàn toàn đúng. Prompt cache nằm trên GPU của người khác, tokenization (cách chia token) khác biệt giữa các mô hình và việc lấy mẫu (sampling) không thể tái lập (và điều này hoàn toàn có chủ đích). Tuy nhiên, bản ghi ngữ nghĩa của một phiên làm việc dưới dạng transcript (bản ghi chép) vẫn có thể thuộc về người dùng. Một transcript nên chứa các chỉ dẫn, tin nhắn, lệnh gọi công cụ và kết quả của công cụ đó. Một mô hình khác đủ năng lực có thể không tiếp tục phiên làm việc một cách giống hệt, nhưng nó có thể hiểu chuyện gì đã xảy ra và tiếp quản công việc.

Các inference API đang dần rời xa đặc tính đó một cách đáng thất vọng. Chúng ngày càng trả về sự kết hợp giữa văn bản và trạng thái bị ràng buộc với nhà cung cấp, vốn được thiết kế rất có chủ đích để không thể di chuyển (non-portable).

Mỗi tính năng đều đi kèm với một lý do biện minh cơ bản mà nhà cung cấp dễ dàng đưa ra, cùng với những lập luận thuyết phục về việc tại sao điều này tốt cho người dùng. Tổng hợp lại, tất cả những điều này làm thay đổi thực tế về quyền sở hữu phiên làm việc AI: transcript trên máy của bạn không còn là phiên làm việc của bạn nữa, mà chỉ là một phần góc nhìn của một phiên làm việc có trạng thái vận hành thuộc về nhà cung cấp inference chứ không phải bạn.

Chúng tôi không ủng hộ xu hướng này và muốn thảo luận một chút về ý nghĩa của nó đối với bạn, với tư cách là người dùng, và đối với chúng tôi, những người đang phát triển các công cụ trong lĩnh vực này.

Một bài kiểm tra thực tế về quyền sở hữu phiên làm việc

Với một phiên làm việc có tính di động (portable), chúng tôi không có ý nói rằng việc chuyển từ mô hình này sang mô hình khác phải tạo ra cùng một token tiếp theo. Đó là điều hiển nhiên vì các mô hình có năng lực, cá tính được huấn luyện, ngữ cảnh (context window) và cách thức làm việc với công cụ khác nhau. Và dù sao thì mọi thứ cũng khá phi định hướng. Tính di động mang ý nghĩa khiêm tốn hơn:

Bản lưu trữ phải chứa đủ thông tin dễ hiểu để một mô hình khác có thể tiếp tục công việc. Nó không được yêu cầu nhà cung cấp cũ phải giải mã ID, giải mã blob, ghi nhớ kết quả tìm kiếm hoặc tái cấu trúc bản tóm tắt.

Điều này mang lại cho chúng ta năm bài kiểm tra hữu ích:

Một response ID không phải là một transcript, một văn bản mã hóa mà người dùng không thể giải mã không phải là trạng thái do người dùng kiểm soát, một danh sách trích dẫn không phải là bằng chứng đã được đưa vào ngữ cảnh của mô hình thông qua kết quả tìm kiếm.

Mã hóa cho ai?

Việc đặt tên và tiếp thị xung quanh các tính năng này có thể gây hiểu lầm. encrypted_content nghe có vẻ như một tính năng bảo mật nằm dưới sự kiểm soát của người dùng. Thông thường, đó là một "viên nang" mà client không thể đọc được và chỉ nhà cung cấp mới có thể mở. Nhà cung cấp chọn khóa, giải mã nội dung cho các mô hình của riêng họ và xác định nơi dữ liệu có thể được phát lại.

Một thuật ngữ chính xác hơn là trạng thái bị niêm phong bởi nhà cung cấp (provider-sealed state).

Việc niêm phong bởi nhà cung cấp có thể mang lại lợi ích bảo mật thực sự. Ví dụ, OpenAI có thể trả về suy luận đã mã hóa cho client bằng cách sử dụng store: false, sau đó giải mã nó trong bộ nhớ ở yêu cầu tiếp theo mà không cần lưu trữ trạng thái trung gian. Điều đó tốt hơn so với việc yêu cầu lưu trữ cuộc hội thoại phía máy chủ, đặc biệt là đối với các khách hàng sử dụng chính sách Zero Data Retention. Nhưng hãy nhớ rằng, ngay từ đầu thực sự không có gì cần phải mã hóa cả!

Quan trọng nhất, việc mã hóa này không che giấu dữ liệu khỏi nhà cung cấp inference; nó che giấu dữ liệu đó khỏi chính bạn.

Các cuộc hội thoại được lưu trữ biến transcript thành một con trỏ

Responses API của OpenAI lưu trữ các phản hồi theo mặc định. Tài liệu của họ cho biết các đối tượng phản hồi được giữ lại ít nhất 30 ngày theo mặc định; các mục đính kèm vào một Conversation không chịu sự ràng buộc của TTL 30 ngày đó. Tùy chọn store: false hiện đã có sẵn và nên được sử dụng, vì nó giúp API hoạt động giống như các completions: dữ liệu không được lưu trữ trên máy chủ của OpenAI.

Gemini Interactions API mới cũng đưa ra lựa chọn tương tự. Nó mặc định là store: true; trên gói trả phí, các tương tác được giữ lại trong 55 ngày và trên gói miễn phí là một ngày.

Và rõ ràng, ý tưởng lưu trữ trạng thái trên máy chủ khá hấp dẫn:

Ứng dụng gửi ít dữ liệu hơn, nhà cung cấp có thể bảo toàn các suy luận ẩn và trạng thái công cụ, đồng thời việc định tuyến bộ nhớ đệm trở nên dễ dàng hơn. Nhưng nếu ứng dụng cục bộ chỉ ghi lại các tin nhắn của người dùng và văn bản cuối cùng, thì first.id giờ đây trở thành một khóa ngoại (foreign key) trỏ vào một cơ sở dữ liệu mà nó không kiểm soát.

Không có suy luận cho bạn

Tất cả các phòng thí nghiệm lớn đều tuyên bố có lý do chính đáng để không tiết lộ chuỗi suy nghĩ (chain of thought) thô. Kết quả là, trên các mô hình không mở trọng số (non-open-weights), chúng ta thường không thấy các token này.

Suy luận thô không hiển thị thông qua API. Với các phản hồi được lưu trữ, suy luận trước đó có thể được khôi phục thông qua previous_response_id. Với store: false, API trả về encrypted_content, mà client phải bảo toàn và phát lại. Suy luận đã lưu trữ vẫn không thể truy cập được ngay cả khi reasoning.context: "all_turns" cho phép một mẫu lấy mẫu sau đó sử dụng nó.

Anthropic trả về toàn bộ suy nghĩ đã mã hóa trong một trường chữ ký. Văn bản suy nghĩ có thể đọc được, khi được bật, là một bản tóm tắt do một mô hình khác tạo ra, không phải là chuỗi suy nghĩ thô. Các khối suy nghĩ (thinking blocks) phải được gửi trả lại nguyên trạng trong các lượt sử dụng công cụ. Tài liệu của Anthropic cũng cho biết các khối suy nghĩ gắn liền với mô hình đã tạo ra chúng và nên bị loại bỏ khi chuyển đổi mô hình. Vì vậy, các dấu vết suy luận này không cố gắng trở nên di động trong hệ sinh thái của Anthropic.

Câu chuyện tương tự lặp lại với tất cả các mô hình đóng trọng số (closed-weights).

Các cơ chế mã hóa này cho phép tính liên tục bên trong một hệ sinh thái nhưng chúng không tạo ra một transcript có tính di động để có thể mang sang mô hình của nhà cung cấp khác. Một bản lưu trữ phiên làm việc có thể chứa blob đó, nhưng một mô hình khác không thể sử dụng ý nghĩa của nó:

Tìm kiếm ẩn

Tìm kiếm web phía máy chủ là một trong những ví dụ rõ ràng nhất về việc một transcript có những lỗ hổng bị che giấu khỏi người dùng. Một công cụ tìm kiếm phía client hoạt động giống như bất kỳ công cụ nào khác:

Người dùng có thể kiểm tra thứ hạng và các đoạn trích, tìm nạp lại các trang, lưu trữ một bản sao hoặc cung cấp cùng bằng chứng đó cho một mô hình khác.

Với tìm kiếm được lưu trữ (hosted search), nhà cung cấp thực hiện một vòng lặp công cụ riêng tư. OpenAI, Google và Anthropic hiển thị các hành động tìm kiếm, trích dẫn và tùy chọn danh sách các URL nguồn, nhưng không phải toàn bộ ngữ cảnh văn bản được sử dụng để tạo ra câu trả lời. Một URL không phải là một bản phát lại ổn định: nội dung của nó có thể thay đổi, biến mất, trở nên được cá nhân hóa hoặc đã bị rút gọn thành một đoạn trích dành riêng cho nhà cung cấp trước khi mô hình nhìn thấy nó.

Câu trả lời cuối cùng có thể rất tốt. Vấn đề xuất hiện ở lượt tiếp theo:

So sánh nguồn thứ ba với nguồn đầu tiên, kiểm tra lại con số đang tranh cãi và tiếp tục nghiên cứu này bằng một mô hình khác.

Mô hình mới nhận được một câu trả lời và một vài URL. Nó không nhận được thứ hạng kết quả, các đoạn trích đã lọc, tài liệu bị loại bỏ hoặc bằng chứng chính xác mà mô hình đầu tiên đã sử dụng. Nhà cung cấp cũ vẫn là một phần của phiên làm việc ngay cả khi yêu cầu tiếp theo đi đến nơi khác.

Tìm kiếm được lưu trữ nên có chế độ xuất dữ liệu đầy đủ (full-fidelity) chứa các truy vấn, siêu dữ liệu kết quả, các đoạn trích được truy xuất, dấu thời gian, mã băm nội dung và các bước lọc. Các trích dẫn ngắn gọn có thể vẫn là giao diện người dùng; nhưng chúng không nên là bản ghi duy nhất.

Nén dữ liệu không minh bạch (Opaque Compaction)

Các phiên làm việc của tác nhân (agent) kéo dài cuối cùng sẽ cần phải nén. Một bản tóm tắt có thể nhìn thấy và do client kiểm soát tuy có mất mát dữ liệu, nhưng ít nhất nó có thể kiểm tra và chuyển đổi được. Người dùng có thể xem lại, chỉnh sửa hoặc yêu cầu một mô hình khác tạo ra bản tóm tắt mới.

Thay vào đó, tính năng nén phía máy chủ của OpenAI phát ra một mục nén đã mã hóa. Tài liệu mô tả nó là "không minh bạch và không dành cho con người diễn giải". Endpoint /responses/compact độc lập trả về một "cửa sổ ngữ cảnh tiếp theo chuẩn" mà các client được hướng dẫn chuyển tiếp nguyên trạng.

Về mặt khái niệm, quá trình chuyển đổi trông như thế này:

OpenAI có thể tiếp tục từ ý nghĩa đã được nén, nhưng một nhà cung cấp khác chỉ nhìn thấy một chuỗi ký tự không thể đọc được cộng với một hậu tố gần đây (thực ra là sẽ nhìn thấy, vì chúng ta không bao giờ chuyển loại thông tin này cho nhà cung cấp khác).