Cách dùng nhiều mô hình AI cùng lúc (bốn cách thực sự hiệu quả)

Vì sao một mô hình là chưa đủ

Lý do thường được nêu ra để dùng nhiều mô hình AI là mỗi mô hình giỏi một thứ, nên bạn nên chọn cái tốt nhất cho từng việc. Đúng, nhưng đó lại là lý do ít thú vị nhất.

Lý do hay hơn là một mô hình không thể nhìn thấy điểm mù của chính nó. Bảo một mô hình tự kiểm tra bài của mình thì phần lớn nó sẽ xác nhận là ổn, vì chính những trọng số tạo ra lỗi cũng đã tạo ra sự tự tin đó. Hỏi một mô hình khác, được huấn luyện khác trên dữ liệu khác với kiểu lỗi khác, và nó sẽ thấy những thứ cái đầu tiên không thấy được. Đây không phải mẹo vặt, đây chính là lý do bạn nhờ đồng nghiệp đọc email trước khi gửi cho khách hàng.

Lý do thứ hai mang tính thực tế: ngôi đầu giữa các mô hình liên tục đổi chủ. Mô hình giỏi lập trình nhất quý này có thể không còn giỏi nhất quý sau. Một quy trình xây trên một nhà cung cấp duy nhất phải làm lại mỗi lần thứ hạng thay đổi. Một quy trình xây trên ý tưởng rằng bạn sẽ đổi mô hình thì không gặp vấn đề đó.

Dưới đây là bốn cách làm, xếp theo giá trị mang lại so với công sức bỏ ra. Bạn không cần cả bốn. Phần lớn mọi người đã lấy được gần như toàn bộ giá trị từ hai cách đầu tiên.

Cách 1: soạn bản nháp, rồi phản biện bằng một mô hình khác

Đây là cách có giá trị cao nhất, và cũng là cách gần như không ai dùng. Viết bằng một mô hình, soi lại bằng một mô hình khác.

Nó hiệu quả vì tạo ra và đánh giá là hai việc khác nhau. Một mô hình đang sinh văn bản thì tối ưu cho một mạch viết liền lạc. Một mô hình đánh giá văn bản mà nó không viết ra thì chẳng có ràng buộc gì với lập luận đó, nên nó sẽ nói thẳng rằng đoạn thứ ba không ăn nhập, thay vì lấp liếm cho trôi.

Prompt ở đây cực kỳ quan trọng. Hỏi "bạn thấy bài này thế nào" thì bạn chỉ nhận được lời khen. Hãy yêu cầu như thế này:

Bạn không viết đoạn văn bản dưới đây và bạn không có lợi ích gì trong đó. Hãy soi lại nó như một biên tập viên khó tính. Liệt kê theo thứ tự: 1) mọi khẳng định dữ kiện sai, thiếu căn cứ hoặc nói quá, 2) mọi chỗ mà lập luận thực ra không suy ra được, 3) đoạn văn yếu nhất và lý do chính xác vì sao. Đừng viết lại bất cứ gì. Đừng nói cho tôi biết chỗ nào hay.

Ba prompt ở cuối mới là phần làm việc thật sự. "Đừng viết lại" ngăn nó tạo ra một phiên bản bằng giọng của nó, thứ bạn không hề yêu cầu. "Đừng nói chỗ nào hay" loại bỏ những lời khen phản xạ vốn làm phồng phần lớn phản hồi của AI. "Bạn không viết cái này" là một cách đóng khung hiệu quả đến bất ngờ, vì nó khiến mô hình thôi bảo vệ những lựa chọn mà nó tưởng là của mình.

Sau đó mang phần phản biện bạn đồng tình quay lại mô hình đầu tiên. Bạn là người biên tập quyết định nhận ghi chú nào, và đó chính xác là cách phân chia công việc hợp lý.

Đáng bỏ ra hai phút này khi: bài gửi cho khách hàng, nội dung công khai, hoặc bất cứ việc gì mà sai là tốn kém. Không đáng khi: một tin nhắn nội bộ, một dàn ý nháp, một danh sách mua sắm.

Cách 2: phép kiểm tra bất đồng

Đây là thứ gần nhất với một công cụ phát hiện bịa đặt đáng tin mà không bắt bạn phải xác minh thủ công mọi thứ.

Hỏi hai mô hình khác nhau cùng một câu hỏi dữ kiện, độc lập với nhau, bằng cùng một prompt. Rồi so sánh. Chỗ chúng đồng ý thì có lẽ bạn ổn. Chỗ chúng bất đồng chính là điểm cần kiểm tra.

Toàn bộ kỹ thuật chỉ có vậy, và nó mạnh vì các lỗi bịa đặt thường không trùng nhau. Khi một mô hình bịa ra một con số thống kê, một tên vụ án, một chữ ký hàm hay một ngày tháng, một mô hình khác được huấn luyện khác hiếm khi bịa ra đúng cái đó. Sự đồng thuận là bằng chứng yếu cho tính đúng đắn. Sự bất đồng là bằng chứng mạnh rằng có gì đó sai, và nó chỉ thẳng vào chỗ sai.

Với những nội dung có nhiều khẳng định, hãy để phần so sánh làm việc thay bạn:

Dưới đây là hai câu trả lời cho cùng một câu hỏi, đánh dấu A và B. Bỏ qua văn phong và độ dài. Hãy liệt kê mọi điểm nội dung mà chúng bất đồng, gồm cả khác biệt về số liệu, ngày tháng, tên riêng và mức độ chắc chắn của khẳng định. Với mỗi điểm bất đồng, hãy nói bên nào nhiều khả năng đúng hơn và một nguồn duy nhất nào sẽ giải quyết được nó.

Bạn kết thúc với một danh sách ngắn những thứ cần kiểm tra thay vì một tài liệu dài phải rà soát, và danh sách đó thường chỉ đúng chỗ có vấn đề.

Hai lưu ý. Thứ nhất, các mô hình có thể mắc chung một lỗi nếu lỗi đó phổ biến trên internet, nên cách này bắt được sự bịa đặt chứ không bắt được thông tin sai lan rộng. Thứ hai, đừng bỏ qua khâu xác minh chỉ vì hai mô hình đồng ý. Cách này thu hẹp phạm vi bạn cần kiểm tra, chứ không xóa bỏ nhu cầu kiểm tra.

Dùng cho: số liệu thống kê, các khẳng định pháp lý và y tế, dữ kiện lịch sử, chi tiết API, bất cứ điều gì bạn sẽ bị trích dẫn lại. Bỏ qua với: quan điểm, công việc sáng tạo, và bất cứ chỗ nào đúng tương đối là đủ.

Cách 3: phân việc theo nhiệm vụ

Đây là cách hiển nhiên nhất, và đáng làm cho đến nơi đến chốn. Gửi từng loại công việc tới mô hình giỏi việc đó, thay vì gửi tất cả cho mô hình nào đang mở sẵn.

Nhiệm vụ	Chọn	Vì sao
Bản nháp đầu cho nội dung viết	Mô hình viết mạnh nhất	Bạn đang mua lại thời gian biên tập
Soi lại bản nháp đó	Một mô hình khác	Góc nhìn mới, kiểu lỗi khác
Bất cứ gì về tuần này	Mô hình có tìm kiếm trực tiếp	Dữ liệu huấn luyện luôn đi sau
Tài liệu hoặc mã nguồn rất dài	Mô hình ngữ cảnh lớn	Phải chứa hết mới hiểu được
Logic khó, toán, hoặc lỗi hóc búa	Mô hình suy luận có tư duy mở rộng	Chậm hơn nhưng chính xác hơn nhiều ở bài nhiều bước
Việc lặp lại số lượng lớn	Mô hình rẻ và nhanh	Dùng mô hình đầu bảng để phân loại và gắn thẻ là lãng phí
Nội dung nhạy cảm	Mô hình nào hợp quy định dữ liệu của bạn	Năng lực không thay thế được nghĩa vụ của bạn

Thói quen duy nhất đáng xây dựng: thôi dùng theo quán tính. Phần lớn mọi người dùng mô hình mà gói đăng ký của họ có sẵn cho mọi việc, kể cả những việc nó làm kém, rồi kết luận rằng AI dở ở những việc đó. Mười giây suy nghĩ xem mô hình nào hợp sẽ thay đổi kết quả nhiều hơn một giờ tinh chỉnh prompt.

Muốn xem phiên bản đầy đủ của quyết định này, hãy đọc cách chọn mô hình AI, và cửa sổ ngữ cảnh là gì để hiểu vì sao dòng về tài liệu dài lại tồn tại.

Cách 4: chuyền tay kèm bản bàn giao viết sẵn

Với công việc trải qua nhiều giai đoạn, điểm hỏng nằm ở khoảng trống giữa các giai đoạn. Bạn giải thích dự án cho một mô hình, đi được đến chỗ hữu ích, rồi chuyển sang mô hình khác và hoặc dán vào cả một bức tường lịch sử trò chuyện, hoặc giải thích lại tất cả một cách tệ hại.

Hãy khắc phục bằng cách yêu cầu một bản bàn giao rõ ràng trước khi chuyển:

Hãy viết một bản bàn giao cho một trợ lý khác chưa từng thấy cuộc trò chuyện này. Gồm: chúng ta đang muốn tạo ra cái gì, những quyết định đã chốt và lý do, các ràng buộc và những thứ cần tránh, những gì đã thử và bị loại, và chính xác điều tôi cần tiếp theo. Hãy cụ thể đến mức trợ lý đó có thể làm tiếp mà không cần hỏi tôi câu nào.

Điều này hữu ích ngay cả khi bạn không đổi mô hình. Đây là cách gọn nhất để thoát khỏi một cuộc trò chuyện dài đã trở nên chậm chạp và mơ hồ, vì bạn giữ lại phần nội dung và bỏ đi phần nhiễu tích tụ. Dán bản bàn giao vào một cuộc trò chuyện mới và chất lượng thường tăng lên ngay lập tức.

Một chuỗi chuyền tay thực tế trông như sau. Đưa một báo cáo 200 trang cho mô hình ngữ cảnh lớn và yêu cầu một bản tóm tắt có cấu trúc kèm mười đoạn quan trọng nhất, trích nguyên văn. Mang những đoạn đó sang một mô hình viết mạnh và tạo ra bản ghi chú gửi khách hàng. Chạy vòng phản biện của cách một với một mô hình thứ ba. Tổng thời gian khoảng mười lăm phút, và mỗi giai đoạn đều dùng đúng công cụ.

Khi nào không cần bận tâm

Quy trình nhiều mô hình có chi phí phụ trội, và giả vờ như không có chính là cách người ta rơi vào cảnh dựng cả một quy trình cầu kỳ để viết một email hai dòng.

Hãy dùng một mô hình khi: việc nhỏ, sai cũng chẳng tốn kém gì, bạn đang khám phá chứ chưa tạo ra sản phẩm, bạn đang lặp nhanh và sự vướng víu sẽ phá vỡ mạch làm việc, hoặc công việc thực sự mang tính sáng tạo và ý kiến thứ hai chỉ làm mờ giọng văn của bạn.

Hãy dùng từ hai mô hình trở lên khi: kết quả sẽ đến tay người khác, độ chính xác dữ kiện quan trọng, công việc có các giai đoạn riêng biệt cần những thế mạnh khác nhau, bạn đang bí và cần một góc nhìn thực sự khác, hoặc bạn sắp ra một quyết định dựa trên điều mô hình nói với bạn.

Một quy tắc hợp lý: nếu bạn sẽ nhờ đồng nghiệp xem qua, hãy hỏi thêm một mô hình thứ hai. Nếu bạn sẽ không nhờ, thì thôi.

Biến nó thành việc làm được

Tất cả những điều trên đều đơn giản về nguyên tắc và phiền phức trong thực tế, nếu mỗi mô hình nằm sau một gói đăng ký riêng. Sự vướng víu là có thật: các tab riêng, các lịch sử riêng, sao chép bối cảnh qua lại, mất định dạng, và một chút ngại ngần đủ để khiến bạn bỏ qua vòng phản biện đúng vào ngày bạn cần nó nhất.

Chính sự vướng víu đó là lý do những cách làm trên bị dùng quá ít. Chúng không khó, chỉ đủ lằng nhằng để bị bỏ qua khi bạn bận.

Đây chính là lý do một không gian làm việc đa mô hình tồn tại. Trong Whizi, các mô hình nằm chung một cuộc trò chuyện, nên một vòng phản biện chỉ là đổi mô hình rồi hỏi, chứ không phải mở một sản phẩm khác rồi dán bản nháp vào. Một lịch sử duy nhất, một ô tìm kiếm cho mọi thứ bạn từng hỏi, một hóa đơn. Xem đổi mô hình giữa cuộc trò chuyện và so sánh các mô hình cạnh nhau để biết hai bước đó thực sự hoạt động ra sao.

Nếu bạn thích tự lắp ghép từ các gói đăng ký riêng lẻ, những cách làm này vẫn hiệu quả và bạn vẫn nên dùng. Thứ duy nhất thay đổi là bạn có đủ kiên nhẫn để làm thường xuyên hay không. Nếu bạn đang trả tiền cho hai hoặc ba gói để làm được chuyện này, hãy chạy công cụ tính tiết kiệm trước, vì đó thường là cách tốn kém hơn để đạt cùng một kết quả.

Hãy bắt đầu từ cách một. Lấy thứ tiếp theo bạn viết mà người khác sẽ đọc, chạy prompt phản biện qua một mô hình khác, và xem nó tìm ra gì. Riêng thói quen đó đã đáng giá hơn toàn bộ phần còn lại của bài viết này.