LLM-First hay Code-First? Nơi trí tuệ thuộc về trong AI sản xuất

Cách quyết định phần nào mô hình nên xử lý, phần nào mã của bạn nên xử lý, và cách kết nối chúng lại với nhau.

Vài năm trước, kiến trúc của một ứng dụng AI trông như: gửi một lời nhắc tới mô hình ngôn ngữ lớn -> nhận phản hồi -> hiển thị cho người dùng. Đó không còn là toàn bộ câu chuyện nữa trong thời gian gần đây. Các mô hình được yêu cầu giải thích ý định, truy xuất thông tin, chọn công cụ, gọi API, lập kế hoạch và thực hiện các quy trình đa bước.

Sự chuyển đổi đó đã chia lĩnh vực thành hai – LLM-First hoặc Code-First

Trong kiến trúc LLM-first, mô hình nằm ở trung tâm và quyết định những gì sẽ xảy ra tiếp theo. Nó đọc yêu cầu, chọn công cụ, quyết định thứ tự thực hiện, kiểm tra kết quả trung gian, và thay đổi hướng khi cần thiết.

Trong kiến trúc code-first, phần mềm/mã vẫn chịu trách nhiệm về việc sắp xếp thứ tự, quy tắc kinh doanh, xác thực, quyền hạn và thực thi. LLM ở đây giống như một chuyên gia mà mã gọi khi cần hiểu hoặc tạo ngôn ngữ.

Mọi người thích tranh cãi về cái nào tốt hơn. Tôi cho rằng đó là lập luận sai. Câu hỏi quan trọng hơn là mỗi loại trí tuệ nên thuộc về đâu. Những hệ thống sản xuất mạnh nhất mà tôi từng thấy hiếm khi chỉ là một trong hai. Chúng kết hợp lý luận xác suất với điều khiển xác định, và làm như vậy một cách có chủ đích.

Tại sao LLM-First lại hấp dẫn đến vậy

Phần mềm truyền thống hoạt động tuyệt vời khi bạn có thể mô tả chi tiết các yêu cầu. Ví dụ, người dùng chọn một sản phẩm, nhập số tiền và thực hiện thanh toán. Bạn định nghĩa các trạng thái cho phép, các quy tắc xác thực, các điều kiện lỗi và trình tự giao dịch trong mã. Xong.

Ngôn ngữ tự nhiên không hợp tác như vậy. Hãy tưởng tượng một người dùng gõ: “Tìm các giao dịch có vẻ bất thường, giải thích những gì đã xảy ra, và cho tôi biết tôi nên điều tra gì đầu tiên.”

Không có một lộ trình cố định cho yêu cầu đó. Hệ thống ở đây phải quyết định “bất thường” nghĩa là gì, xác định dữ liệu nào quan trọng, có thể gọi một vài công cụ, cân nhắc phản hồi, và viết một lời giải thích mà người dùng có thể sử dụng. Không đội ngũ kỹ sư/không có mã nào có thể dự đoán mọi cách diễn đạt và mọi kết hợp yêu cầu trước thời điểm thực hiện.

Đây là nơi một LLM đóng vai trò quan trọng, hoạt động như một lớp lý luận linh hoạt giữa ngôn ngữ con người và các dịch vụ xác định của bạn. Đó cũng là lý do tại sao các tác nhân đang nhận được nhiều sự chú ý. Google Cloud’s hướng dẫn kiến trúc AI có tính đại lý mô tả một tác nhân như một ứng dụng mà mô hình AI đóng vai trò là động cơ lý luận, trong khi các công cụ cho phép nó tiếp cận các hệ thống và dữ liệu bên ngoài.

Anthropic’s Xây dựng các tác nhân AI hiệu quả hướng dẫnđưa ra một phân biệt mà tôi luôn quay lại. Trong một quy trình làm việc, các mô hình và công cụ theo các đường dẫn mà mã của bạn định nghĩa. Trong một tác nhân, LLM tự chỉ đạo quy trình của mình và quyết định cách sử dụng các công cụ. Hướng dẫn tương tự khuyến nghị bắt đầu với kiến trúc đơn giản nhất giải quyết vấn đề, thay vì thêm độ phức tạp đại lý một cách phản xạ. Tôi sẽ gạch chân lời khuyên đó hai lần.

Giới hạn của “Để mô hình quyết định”

Mô hình có thể suy luận về những gì nên xảy ra. Suy luận không đồng nghĩa với việc thực thi một quy tắc.

Ví dụ, hãy lấy một quy trình tài chính. Một LLM có thể xuất sắc trong việc hiểu “gửi cùng số tiền tôi đã gửi tháng trước cho cùng nhà cung cấp.” Nhưng nó có nên quyết định liệu chuyển tiền có được ủy quyền, tính giới hạn quy định, xác minh quyền sở hữu tài khoản, ghi đè chính sách bảo mật, và thực hiện giao dịch không?

Có lẽ không. Những công việc này là xác định, có thể kiểm tra, kiểm toán và thực thi, và đó chính là những gì phần mềm truyền thống giỏi. Rủi ro tăng lên khi các mô hình có quyền truy cập vào công cụ. OWASP’s hướng dẫn bảo mật AI sinh ra đánh dấu quyền tự chủ quá mức như một rủi ro đáng kể: cung cấp cho hệ thống dựa trên LLM nhiều chức năng, quyền hạn, hoặc tự chủ hơn nhu cầu nhiệm vụ của nó. Một đầu ra mô hình lạ hoặc bị thao túng là một vấn đề khi nó chỉ tạo ra văn bản. Đó là vấn đề lớn hơn rất nhiều khi mô hình có thể hành động trong thế giới thực.

Tất cả điều này không có nghĩa là các mô hình không bao giờ thực hiện hành động. Nó có nghĩa là quyền tự chủ của mô hình phải được giới hạn bởi quyền lực xác định.

Code-First vẫn quan trọng

Với AI phát triển nhanh như vậy, dễ cảm thấy rằng kỹ thuật truyền thống đã lỗi thời. Tôi lại cho rằng ngược lại. AI làm cho các hệ thống xác định tốt trở nên quan trọng hơn, không phải ít hơn.

Mã vẫn là lựa chọn đúng mỗi khi một nhiệm vụ đòi hỏi tính lặp lại chính xác. Xác thực là ví dụ đơn giản nhất. Một mô hình không nên “lý luận” về việc ai có quyền admin. Ứng dụng của bạn nên hỏi một hệ thống quản lý danh tính và quyền truy cập có thẩm quyền. Điều tương tự áp dụng cho các phép tính tiền tệ, kiểm tra quyền, xác thực dữ liệu, ràng buộc quy định, giới hạn giao dịch, xác thực schema, và bất kỳ thứ gì không thể đảo ngược. Những việc này cần hợp đồng rõ ràng, không phải ước lượng.

Điều này phù hợp với tư duy quản trị rộng hơn. Khung Quản lý Rủi ro AI của NIST yêu cầu các tổ chức quản lý rủi ro AI trên toàn bộ các giai đoạn thiết kế, phát triển, triển khai và sử dụng. Generative AI Profile cho biết các hệ thống sinh tạo có thể cần giám sát, tài liệu, đánh giá và kiểm soát bổ sung, tùy thuộc vào mức độ rủi ro liên quan.

Vì vậy, tôi thấy hữu ích khi chia mỗi quyết định thiết kế thành hai câu hỏi:

Điều gì nên xảy ra?

và

Điều gì được phép xảy ra?

LLM thường có thể hỗ trợ phần đầu tiên. Các hệ thống quyết định thường nên chịu trách nhiệm phần thứ hai.

Mô hình Lai: Lý luận Xác suất, Thực thi Quyết định

Đối với hầu hết các ứng dụng doanh nghiệp, câu trả lời thực tiễn là mô hình lai. LLM hoạt động như lớp diễn giải và lý luận. Các dịch vụ quyết định hoạt động như lớp thực thi và áp dụng.

Ví dụ sau. Giả sử một trợ lý AI giúp các nhà phát triển tạo nhanh các môi trường kiểm thử API tạm thời, và một nhà phát triển gõ: “Cho tôi một sandbox cho quy trình tiếp nhận khách hàng.”

LLM có thể diễn giải yêu cầu đó, xác định quy trình nào có khả năng được đề cập, đọc tài liệu và đề xuất các API có thể liên quan. Tuy nhiên, việc thực sự tạo môi trường không nên phụ thuộc vào văn bản tự do được tạo ra. Mã nguồn có thể xác nhận các API được yêu cầu tồn tại, kiểm tra hợp đồng của chúng, xác thực quyền, áp dụng giới hạn tài nguyên, tạo cấu hình đã được phê duyệt và thực hiện triển khai.

Phân chia sơ bộ trông như sau:

• LLM: hiểu, lý luận, phân loại, đề xuất, tóm tắt.
• Mã: xác thực, ủy quyền, tính toán, lưu trữ, áp dụng, thực thi.

Mỗi bên thực hiện công việc mà chúng giỏi nhất, và không bên nào bị yêu cầu giả vờ có khả năng của bên kia.

Ranh giới quan trọng hơn khi các tác nhân trở nên mạnh mẽ hơn

Sự tách biệt này trở nên quan trọng hơn khi chúng ta chuyển từ trợ lý sang tác nhân. Một trợ lý đưa ra câu trả lời sai gây bất tiện cho người dùng. Một tác nhân có quyền ghi vào môi trường sản xuất có thể gây ra rắc rối lớn hơn nhiều.

Giải pháp không nhất thiết là loại bỏ hoàn toàn tính tự chủ. Thay vào đó là thêm tính tự chủ dần dần trong khi vẫn duy trì các điểm kiểm soát rõ ràng.Hướng dẫn của Google về hệ thống đa tác nhân đề xuất kết hợp hành vi AI động với các kiểm soát bảo mật quyết định, khả năng quan sát, tự chủ được định nghĩa rõ ràng và giám sát con người cho các kịch bản quan trọng đối với doanh nghiệp.

Việc phê duyệt của con người cũng có thể được tích hợp vào quy trình làm việc thay vì chỉ là một lưới an toàn không chính thức. Tài liệu khung tác nhân của Microsoft, ví dụ, hỗ trợ các lời gọi công cụ tạm dừng cho đến khi một người dùng xác nhận rõ ràng thao tác được yêu cầu.

Nguyên tắc rất đơn giản: càng hậu quả của một hành động lớn, các kiểm soát quyết định xung quanh nó càng phải mạnh mẽ.

Năm Câu Hỏi Cần Đặt Ra Trước Khi Giao Nhiệm Vụ cho LLM

Khi tôi quyết định một thành phần nên ưu tiên LLM hay mã, tôi xem xét các câu hỏi sau:

1. Nhiệm vụ có một đáp án đúng khách quan không? Nếu có, nên ưu tiên mã quyết định. Các phép tính thuế, quyền truy cập và xác thực schema không nên thay đổi chỉ vì mô hình đọc chúng khác hôm nay.
2. Liệu nó có liên quan đến ngôn ngữ mơ hồ hoặc thông tin không có cấu trúc không? Nếu có, LLM có thể mang lại giá trị thực sự.
3. Điều gì sẽ xảy ra nếu mô hình sai? Kiến trúc phù hợp cho bản tóm tắt cuộc họp rất khác so với kiến trúc phù hợp cho việc khởi tạo thanh toán.
4. Kết quả có thể được xác thực độc lập không? Các kế hoạch do LLM tạo ra sẽ an toàn hơn nhiều khi các quy tắc quyết định có thể kiểm tra hành động kết quả trước khi thực thi.
5. Liệu thực sự cần một tác nhân không? Nếu bạn đã biết các bước, một quy trình làm việc thông thường với một vài lời gọi LLM mục tiêu thường đơn giản hơn, rẻ hơn, dễ kiểm thử và dễ vận hành.

Câu hỏi cuối cùng này đáng được chú ý thêm. Các tác nhân mạnh mẽ vì chúng có thể xử lý các tình huống mà bạn không thể dự đoán mọi bước.có thể dự đoán các bước, việc biến chúng thành một vấn đề lý luận mở thường chỉ tăng tính biến đổi mà không tăng trí tuệ.

Độ Tin Cậy Là Thuộc Tính Kiến Trúc, Không Phải Prompt

Nhiều đội bắt đầu cố gắng cải thiện độ tin cậy gần như hoàn toàn bằng kỹ thuật prompt. Prompt quan trọng, nhưng chúng không thể gánh vác toàn bộ trách nhiệm.

Một hệ thống sản xuất nên giả định rằng đầu ra của mô hình đôi khi sẽ không đầy đủ, sai dạng, không mong đợi, hoặc chỉ đơn giản là sai. OWASP Top 10 cho các ứng dụng LLM liệt kê các rủi ro như prompt injection và improper output handling, điều này củng cố một thói quen quan trọng: coi đầu ra mô hình là đầu vào không đáng tin cậy cho các hệ thống hạ nguồn, chứ không phải là hướng dẫn để tự động thực thi.

Điều đó thay đổi câu hỏi bạn đặt ra. Thay vì “Làm sao tôi viết một prompt luôn khiến mô hình tuân theo quy tắc?”, hãy hỏi “Làm sao tôi thiết kế hệ thống để quy tắc không thể bị phá vỡ ngay cả khi mô hình mắc lỗi?”

Đó là vấn đề kiến trúc phần mềm, không phải vấn đề prompt. Một prompt có thể yêu cầu một tác nhân không thực hiện hành động không được ủy quyền. Một dịch vụ ủy quyền mới thực sự có thể ngăn chặn nó. Hai kiểm soát này không tương đương.

Vượt ra ngoài cuộc tranh luận: Hệ thống Định hướng Ý định

Khi suy nghĩ về tất cả những điều này, tôi đã đi đến kết luận rằng cuộc tranh luận LLM-first so với code-first hướng tới một ý tưởng thứ ba: định hướng ý định kiến trúc.

Trong một hệ thống định hướng ý định, ứng dụng bắt đầu bằng việc hiểu người dùng đang cố gắng đạt được gì. Đó là nơi mà LLM có giá trị nhất, vì con người hiếm khi mô tả chính xác những gì họ muốn. Từ đó, hệ thống dần dần chuyển đổi sự mơ hồ đó thành các hoạt động có cấu trúc, quyết định.

Một yêu cầu như “Giúp tôi giải quyết vấn đề thanh toán của khách hàng” có thể chuyển thành một chuỗi quy trình: hiểu ý định, truy xuất giao dịch, xác định nguyên nhân lỗi, đề xuất giải pháp, yêu cầu phê duyệt, thực thi thao tác đã được phê duyệt.

Một số giai đoạn này hưởng lợi từ khả năng suy luận của mô hình ngôn ngữ. Các phần khác nên là các dịch vụ cố định. Kiến trúc không được xác định bởi việc AI hay mã “chiến thắng”. Nó được xác định bởi nơi mà sự không chắc chắn được chấp nhận.

Kết luận

Khi các mô hình cải thiện, sẽ có sức hấp dẫn trong việc giao cho chúng kiểm soát các phần ngày càng lớn của ngăn xếp. Đôi khi đó sẽ là quyết định đúng. Trong các hệ thống khác, thiết kế tinh vi nhất sẽ là thiết kế cố ý cho mô hình ít quyền hạn.

Việc kỹ thuật AI trong sản xuất, cuối cùng, là đặt trí tuệ ở ranh giới thích hợp. Sử dụng mô hình ngôn ngữ ở nơi mà việc giải thích, suy luận, tổng hợp và thích nghi tạo ra giá trị. Sử dụng phần mềm quyết định ở nơi mà tính nhất quán, ủy quyền, độ chính xác và thực thi quan trọng. Sau đó kết nối hai phần này qua các giao diện hẹp, có thể quan sát và đã được kiểm thử kỹ lưỡng.

Tương lai của AI doanh nghiệp có lẽ không hoàn toàn là LLM-first hay hoàn toàn là code-first. Nó là LLM ở những nơi mà sự không chắc chắn đòi hỏi trí tuệ, và mã ở những nơi mà sự chắc chắn đòi hỏi kiểm soát.

Sự phân biệt này có thể quan trọng hơn nhiều so với việc bạn chọn mô hình nào.