Tôi viết bài này như một hướng dẫn mà tôi đã mong muốn có được trước khi chuyển sang lĩnh vực Kỹ thuật AI Ứng dụng.
Vai trò này nhìn chung có nhiều điểm chồng chéo với kỹ thuật phần mềm truyền thống, nhưng nó bổ sung thêm một vài khái niệm quan trọng mà hầu hết các kỹ sư phần mềm phải tự học khi chuyển đổi. Tôi khuyên bạn nên dùng bài viết này như một dàn ý về các chủ đề cốt lõi cần hiểu, sau đó theo dõi các tài liệu tham khảo được liên kết xuyên suốt bài viết khi bạn muốn tìm hiểu sâu hơn.
Đến cuối bài, bạn sẽ hiểu rõ hơn nhiều về Kỹ thuật AI Ứng dụng là gì, công việc thực sự đòi hỏi những gì và nó mở rộng ra sao so với kỹ thuật phần mềm truyền thống.
Nếu bạn quan tâm đến việc giải quyết một số vấn đề thú vị nhất trong lĩnh vực AI Ứng dụng cùng với một đội ngũ kỹ sư tài năng, chúng tôi luôn tuyển dụng. Hãy nộp đơn trên trang web của chúng tôi tại varickagents.com hoặc giới thiệu ứng viên để nhận thưởng giới thiệu 20.000 đô la.
Tuy nhiên, cách tốt nhất để hiểu Kỹ thuật AI Ứng dụng là bắt đầu với sự thay đổi trong cách bạn nghĩ về việc xây dựng phần mềm.
Kỹ thuật phần mềm so với Kỹ thuật AI
Sự khác biệt lớn nhất giữa một kỹ sư phần mềm và một kỹ sư AI là kỹ thuật phần mềm truyền thống rèn luyện bạn tư duy theo hướng tất định, trong khi AI ứng dụng buộc bạn phải tư duy theo hướng xác suất.
Trong phần mềm thông thường, bạn viết logic, chạy nó và khi có thứ gì đó hỏng, bạn thường có thể truy vết được – một đầu vào có cấu trúc sẽ tất định cho ra một đầu ra có cấu trúc.
AI Ứng dụng không hoạt động như vậy. Bạn đang xây dựng xung quanh một lệnh gọi API không tất định tới trí thông minh, điều đó có nghĩa là cùng một đầu vào có thể cho ra kết quả khác nhau mỗi lần. Vì lý do này, công việc không chỉ dừng lại ở việc xây dựng phần mềm, mà thay vào đó trở thành việc đo lường xem hệ thống có thực sự hoạt động như mong đợi hay không.
Cách chúng tôi làm điều đó là thông qua các bài đánh giá (evals), vì vậy tôi sẽ phân tích cách xây dựng một bộ đánh giá đảm bảo rằng tác nhân (agent) bạn phát triển không mắc lỗi. Tôi đã nhận ra rằng đây là một trong những kỹ năng quan trọng nhất của một nhà phát triển AI ứng dụng, do tính chất không tất định của công việc chúng tôi làm.
Phần tiếp theo của bài viết đề cập đến việc phát triển từng phần của một tác nhân AI (tất nhiên là ngoại trừ chính mô hình), bởi vì bạn có thể gọi API tới một mô hình nhưng bạn cần tự xây dựng mọi thứ khác. Đây được gọi là kỹ thuật khung (harness engineering).
Và cuối cùng, tôi sẽ đề cập đến cách chuyển từ một tác nhân trong sản xuất lên nhiều tác nhân – và tại sao đó lại là một vấn đề của hệ thống phân tán. Nếu bạn có thể đọc đến cuối bài viết này, không có lý do gì bạn không thể chuyển đổi thành công thành một kỹ sư AI Ứng dụng.
Đánh giá (Evals)
Một kỹ sư AI ứng dụng biến sự không chắc chắn thành sự tự tin có thể đo lường được bằng cách sử dụng các bài đánh giá. Trong phát triển phần mềm truyền thống, bạn tin tưởng hệ thống vì bạn đã viết logic và kiểm thử mã. Trong AI ứng dụng, bạn không thể tin tưởng hệ thống theo cách đó vì mô hình có thể hoạt động khác nhau qua các lần chạy. Vì vậy, kỹ sư AI phải xây dựng một lớp đo lường xung quanh tác nhân.
Một bài đánh giá là quá trình giao cho tác nhân một nhiệm vụ, để nó chạy và chấm điểm những gì nó đã làm. Mục tiêu là chứng minh hai điều: tác nhân đã hoàn thành công việc một cách chính xác và tác nhân đã hoạt động trong các ranh giới được giao.
Bước đầu tiên là chấm điểm kết quả. Đây là bước dễ nhất trong quy trình đánh giá. Đối với một tác nhân xử lý hóa đơn, loại tôi thường làm việc, điều đó có nghĩa là đảm bảo hóa đơn được chuyển đến đúng nơi hoặc hóa đơn trùng lặp được gắn cờ. Bạn chỉ đang so sánh kết quả cuối cùng với những gì đáng lẽ phải xảy ra.
Bước thứ hai là chấm điểm quỹ đạo (trajectory). Đây là con đường mà tác nhân đã đi để đạt được kết quả đó: các công cụ nó đã gọi, các trường nó đã chạm vào, các đối số nó đã truyền và các hành động nó đã thử trong suốt quá trình. Điều này quan trọng vì một tác nhân có thể đạt được câu trả lời cuối cùng đúng trong khi vẫn làm điều gì đó nguy hiểm trong quá trình đó. Nó có thể phân loại hóa đơn chính xác trong khi cũng thay đổi thông tin ngân hàng hoặc gửi thanh toán trước khi được phê duyệt.
Bản thân quỹ đạo chỉ là một bản ghi (log): một danh sách có thứ tự của mọi công cụ mà tác nhân đã gọi và các đối số nó đã truyền – để chấm điểm nó chỉ đơn giản là viết các kiểm tra dựa trên bản ghi đó.
Một số kiểm tra mang tính tất định – đảm bảo rằng send_payment không bao giờ xuất hiện trước một lệnh gọi phê duyệt, kiểm tra rằng các trường duy nhất được ghi vào là những trường tác nhân được phép ghi. Một số khác là các đánh giá mang tính phán đoán – liệu việc leo thang (escalation) có phù hợp không, liệu lý do có biện minh cho hành động không. Những việc đó được chuyển cho một mô hình thứ hai với một tiêu chí chấm điểm (rubric).
Nguyên tắc chung cần tuân theo là các kiểm tra tất định thường phát hiện các vi phạm an toàn, trong khi mô hình phán đoán (judge model) chấm điểm chất lượng.
Kết quả là hai điểm số cho mỗi trường hợp kiểm thử: tác nhân có nhận được câu trả lời đúng không và nó có hành xử đúng đắn để đạt được điều đó không. Những điều này cần được báo cáo riêng biệt, bởi vì một tác nhân phân loại hóa đơn chính xác 95% thời gian nhưng lại chạm vào một trường bị cấm trong 4% số lần chạy trông có vẻ tuyệt vời trên một điểm số tổng hợp nhưng lại gây ra các biến chứng kinh doanh lớn trong sản xuất.
Bài viết này đóng vai trò như một lời giới thiệu về các bài đánh giá và tất cả các chủ đề khác được đề cập, vì vậy tôi đã liên kết các tài liệu tham khảo khác để giúp bạn tìm hiểu sâu hơn. Một số tài liệu đã giúp tôi hiểu cách xây dựng các bài đánh giá hiệu quả là:
- Khóa học đánh giá của Anthropic
- Hướng dẫn toàn diện về đánh giá của Lenny
- Câu hỏi thường gặp về đánh giá của Hamel
Tôi khuyên bạn nên xem qua từng tài liệu, nhưng hãy bắt đầu với của Lenny và Hamel trước khi xem khóa học đánh giá (khóa học này thiên về thực hành hơn một chút).
Nhưng một bài đánh giá vẫn cần một tác nhân để kiểm thử, và mọi thứ xung quanh mô hình đều phải do bạn xây dựng. Hệ thống xung quanh đó được gọi là khung (harness) – phần tiếp theo đề cập đến cách suy nghĩ về từng phần của quy trình kỹ thuật khung, từ gọi công cụ đến tối ưu hóa cửa sổ ngữ cảnh.
Kỹ thuật Khung (Harness Engineering)
Một mô hình tự nó không phải là một tác nhân. Một mô hình có thể suy luận, phân loại, viết và đưa ra quyết định, nhưng nó không thể tự mình hoạt động bên trong một công ty. Nó có thể nói hành động nào nên xảy ra, nhưng nó không thể thực hiện hành động đó một cách an toàn trừ khi bạn xây dựng hệ thống xung quanh nó – và hệ thống đó chính là khung.
Khung là mọi thứ xung quanh mô hình biến một lệnh gọi API thành một tác nhân hoạt động: các công cụ nó có thể sử dụng, ngữ cảnh nó nhìn thấy, trạng thái nó ghi nhớ, các rào chắn (guardrails) ràng buộc nó và vòng lặp cho phép nó tiếp tục làm việc cho đến khi nhiệm vụ hoàn thành.
Phần đầu tiên của khung là thực thi công cụ.
Các mô hình chỉ đọc và viết văn bản, vì vậy khi một mô hình quyết định làm điều gì đó, nó không thực sự thực thi điều đó. Nó phát ra một yêu cầu có cấu trúc (một chuỗi JSON) để cập nhật một bản ghi, gửi email hoặc tìm kiếm cơ sở dữ liệu.
Khung nhận yêu cầu đó, xác thực nó, chạy thao tác thực tế và gửi kết quả trở lại mô hình dưới dạng văn bản.
Phần thứ hai là quản lý ngữ cảnh. Mọi hướng dẫn, menu công cụ, kết quả công cụ và tin nhắn trước đó đều chiếm dung lượng trong cửa sổ ngữ cảnh của mô hình. Khung phải quyết định những gì mô hình cần thấy ngay bây giờ, những gì nên được tóm tắt và những gì nên được loại bỏ. Nếu không có điều này, các tác nhân sẽ bị lạc trong lịch sử không liên quan.
Tôi sẽ viết một bài viết toàn diện hơn đi sâu hơn vào từng phần của quy trình phát triển khung, nhưng hiện tại, tôi khuyên bạn nên nghe bài nói chuyện này của một kỹ sư tại Arize, nền tảng học tập liên tục cho các tác nhân, đi sâu vào quy trình suy nghĩ của họ về quản lý ngữ cảnh.
Để tìm hiểu thêm về cách áp dụng quản lý ngữ cảnh hiệu quả cho các tác nhân của bạn trong thực tế, hãy đọc qua các blog sau:
- Bài viết về quản lý ngữ cảnh của OpenAI
- Hướng dẫn thực tế về quản lý ngữ cảnh
- Hướng dẫn kỹ thuật ngữ cảnh của Anthropic
Phần thứ ba trong kỹ thuật khung là trạng thái và bộ nhớ. Các mô hình là phi trạng thái (stateless) giữa các lần gọi, vì vậy bất cứ thứ gì tác nhân cần nhớ đều phải tồn tại bên ngoài mô hình (thường là trong cơ sở dữ liệu, kho lưu trữ tệp hoặc bản ghi nhiệm vụ). Ngữ cảnh là những gì mô hình đang xem xét ngay bây giờ. Trạng thái là mọi thứ tác nhân biết nhưng hiện không xem xét.
Phần thứ tư là các rào chắn (guardrails). Vì mô hình có thể yêu cầu hành động sai với cùng mức độ tự tin như hành động đúng, khung phải kiểm tra quyền hạn, xác thực đầu vào, chặn các hành động không an toàn và chuyển các bước có rủi ro cao cho con người.
Cuối cùng, tất cả những điều này được kết nối với nhau trong vòng lặp tác nhân: xây dựng ngữ cảnh, gọi mô hình, kiểm tra phản hồi của nó, thực thi công cụ nếu được phép, lưu trữ kết quả, cập nhật ngữ cảnh và lặp lại cho đến khi nhiệm vụ hoàn thành.
Kỹ thuật khung là phần lớn công việc bạn sẽ làm với tư cách là một kỹ sư AI Ứng dụng, vì vậy hãy dành thời gian cho phần này. Với tư cách là một kỹ sư AI ứng dụng, toàn bộ công việc của bạn là xây dựng môi trường hoạt động cho phép một hệ thống xác suất làm việc bên trong phần mềm tất định.
Nhưng sản xuất thường không dừng lại ở một tác nhân.
Khi quy trình làm việc trở nên lớn hơn, bản năng tự nhiên là chia nhỏ công việc. Nhưng một khi bạn thêm tác nhân thứ hai đó, thiết kế hệ thống sẽ thay đổi.
Với một tác nhân, hầu hết sự phức tạp nằm trong một vòng lặp. Với nhiều tác nhân, giờ đây bạn có nhiều vòng lặp hoạt động trên cùng một môi trường. Mỗi tác nhân có thể đọc trạng thái mà một tác nhân khác vừa thay đổi, ghi vào bộ nhớ mà tác nhân khác phụ thuộc vào hoặc gọi một công cụ mà kết quả của nó ảnh hưởng đến toàn bộ quy trình làm việc.
Tại thời điểm đó, phần khó khăn không còn chỉ là việc tạo prompt, đánh giá hay thiết kế khung. Nó trở thành một vấn đề của hệ thống phân tán: ai sở hữu trạng thái nào, ai có thể ghi vào bộ nhớ, công cụ nào an toàn để thử lại và điều gì xảy ra khi hai tác nhân hợp lý thực hiện các hành động theo sai thứ tự.
Triển khai Nhiều Tác nhân là một Vấn đề của Hệ thống Phân tán
Khi tác nhân đầu tiên hoạt động và quy trình làm việc trở nên lớn hơn, một kỹ sư AI ứng dụng mới thường có bản năng chia công việc thành các vai trò: một tác nhân nghiên cứu, một lập kế hoạch, một thực thi, một xem xét.
Nhưng tác nhân thứ hai thay đổi đơn vị thiết kế từ tác nhân sang hệ thống. Nhiều vòng lặp hiện hoạt động trong cùng một môi trường – một tác nhân có thể cập nhật trạng thái khách hàng trong khi một tác nhân khác đang giữa chừng viết dựa trên trạng thái đã lỗi thời. Cả hai đều đưa ra quyết định hợp lý, nhưng hệ thống đã để những quyết định đó tương tác theo sai thứ tự.
Đây là một vấn đề của hệ thống phân tán. Tin tốt là các kỹ sư hệ thống phân tán đã giải quyết những lỗi này từ nhiều thập kỷ trước. Công việc của bạn là áp dụng chúng vào các vòng lặp có chứa một LLM. Dưới đây là danh sách các giải pháp từ hệ thống phân tán áp dụng cho kỹ thuật AI:
Nguyên tắc một người ghi (Single-writer principle). Mọi phần trạng thái quan trọng có chính xác một tác nhân có thể ghi vào nó – các tác nhân khác đọc từ nó hoặc gửi yêu cầu thay đổi. Thực thi điều này ở cấp độ công cụ: nếu tác nhân thực thi là người duy nhất có thể ghi vào CRM, thì tác nhân nghiên cứu không thể làm hỏng CRM cho dù nó suy luận kém đến đâu.
Khóa tính chất lũy đẳng (Idempotency keys). Các tác nhân thử lại các lệnh gọi công cụ khi có thứ gì đó thất bại hoặc hết thời gian chờ, nhưng việc thử lại có thể nguy hiểm khi công cụ thay đổi thứ gì đó trong thế giới thực. Bạn không muốn một tác nhân gửi cùng một khoản thanh toán hai lần chỉ vì yêu cầu đầu tiên trông như đã thất bại. Giải pháp là đính kèm một khóa duy nhất vào mọi lệnh gọi công cụ làm thay đổi dữ liệu (mutating tool call) – nghĩa là bất kỳ hành động nào thay đổi dữ liệu trong một hệ thống bên ngoài. Nếu công cụ thấy cùng một khóa lần nữa, nó sẽ trả về kết quả ban đầu thay vì chạy hành động lần thứ hai. API của Stripe hoạt động theo cách này – và nó được áp dụng cho việc phát triển tác nhân khi xử lý thanh toán, email, v.v.
Điều kiện tiên quyết cho các thao tác ghi (Preconditions on writes). Các tác nhân thường hành động dựa trên một góc nhìn cũ về thế giới. Một thứ gì đó có thể đã thay đổi giữa lúc tác nhân lập kế hoạch và lúc nó cố gắng cập nhật một hệ thống bên ngoài. Để ngăn chặn các thao tác ghi dựa trên dữ liệu cũ (stale writes), các công cụ làm thay đổi dữ liệu nên yêu cầu một điều kiện trước khi thực hiện thay đổi. Ví dụ: "chỉ đặt trạng thái thành Đã phê duyệt nếu nó vẫn là Đang chờ xử lý." Nếu trạng thái đã thay đổi, công cụ sẽ thất bại rõ ràng thay vì âm thầm ghi đè lên trạng thái mới hơn.
Bàn giao rõ ràng (Explicit hand-offs). Chuyển công việc dưới dạng các thông điệp với một lược đồ xác định, được sắp xếp theo trình tự bởi một bộ điều phối (orchestrator). Một tác nhân sẽ nhận nhiệm vụ của nó, không phải tự khám phá ra nó.
Tóm tắt (TLDR)
Bài viết này đóng vai trò là tổng quan về các chủ đề quan trọng nhất mà tôi đã học được với tư cách là một kỹ sư AI Ứng dụng: đánh giá, kỹ thuật khung và thiết kế hệ thống nhiều tác nhân.
Nếu bạn rút ra được điều gì, hãy nhớ điều này – mô hình cung cấp trí thông minh, nhưng mọi thứ làm cho nó đáng tin cậy (lớp đo lường, môi trường hoạt động, các quy tắc phối hợp) đều do bạn thiết kế. Hiểu được những điều này và quá trình chuyển đổi từ kỹ thuật phần mềm trở thành một sự mở rộng các kỹ năng bạn đã có.
Nếu bạn quan tâm đến loại công việc này và muốn đến giải quyết một số vấn đề thú vị nhất trong lĩnh vực AI Ứng dụng cùng với một đội ngũ kỹ sư tài năng, chúng tôi luôn tuyển dụng. Hãy nộp đơn trên trang web của chúng tôi tại varickagents.com và chúng tôi có thể cho bạn bắt đầu sớm nhất có thể. Mặt khác, nếu bạn giới thiệu một ứng viên thành công, chúng tôi sẽ thưởng cho bạn 20.000 đô la tiền giới thiệu.
