Đơn vị nào cũng trả lời câu hỏi này bằng một khoảng giá rộng đến mức vô dụng, vì câu trả lời trung thực còn phụ thuộc vào những điều họ chưa biết. Vì vậy, đây là cơ sở đằng sau con số: bốn dạng công việc AI phổ biến bao gồm những gì, bạn đang cần dạng nào và những yếu tố nào khiến chi phí tăng lên.
Chi phí bên dưới được tính bằng tuần công kỹ sư thay vì tiền. Mức giá khác nhau tùy thị trường và người thực hiện; một trang báo giá bằng đô la sẽ không phù hợp với phần lớn độc giả vào ngày họ đọc. Hãy nhân với mức giá bạn thực sự đang so sánh. Đây là ước tính của chúng tôi dựa trên kinh nghiệm xây dựng những sản phẩm tương tự, không phải khảo sát ngành.
Bốn dạng công việc AI
Gần như mọi yêu cầu chúng tôi nhận được đều thuộc một trong các dạng này, hoặc kết hợp hai dạng. Xác định bạn muốn dạng nào là bước quan trọng nhất để có được con số thực tế, và bạn có thể làm việc đó trước khi nói chuyện với bất kỳ ai.
| Dạng | Chức năng | Đến phiên bản đầu tiên đưa vào vận hành |
|---|---|---|
| Trả lời dựa trên nội dung của bạn | Nhân viên hoặc khách hàng đặt câu hỏi; hệ thống trả lời dựa trên tài liệu của bạn và dẫn nguồn | 4–8 tuần công kỹ sư |
| Trích xuất và phân loại | Chuyển hóa hóa đơn, email, phiếu yêu cầu hoặc biểu mẫu thành các trường dữ liệu có cấu trúc hoặc danh mục | 3–6 tuần công kỹ sư |
| Tác tử thực hiện một tác vụ | Thực hiện hành động trên các hệ thống của bạn, chứ không chỉ tạo văn bản | 8–16 tuần công kỹ sư |
| Mô hình tích hợp trong sản phẩm của bạn | Chạy trên thiết bị của người dùng hoặc máy chủ riêng của bạn, không dùng API bên thứ ba | 10–20 tuần công kỹ sư |
Hai khoảng ước tính cuối rộng hơn vì cùng một lý do: cả hai đều phụ thuộc vào những yếu tố bên ngoài AI. Khả năng xây dựng tác tử chỉ tốt bằng các API mà nó cần dùng để thực hiện hành động; còn mô hình chạy trên thiết bị bị giới hạn bởi phần cứng bạn quyết định hỗ trợ.
Yếu tố thực sự quyết định chi phí
Để xem một quy trình trích xuất cụ thể, hãy tìm hiểu dịch vụ trích xuất dữ liệu hóa đơn và tự động hóa xử lý hóa đơn theo yêu cầucủa chúng tôi: tiếp nhận, xác thực, nhân viên rà soát và xuất dữ liệu sang hệ thống kế toán.
Không yếu tố nào trong số này là mô hình. Việc chọn mô hình chỉ cần một tuần đánh giá rồi được ghi thành một dòng trong tệp cấu hình; nếu đề xuất xem đó là câu hỏi trọng tâm, thì đó là dấu hiệu đáng lưu ý về chính đề xuất ấy.
- Tình trạng dữ liệu của bạn. Đây là yếu tố biến động lớn nhất. Trường hợp ít tốn kém là tài liệu sạch, cập nhật, có cấu trúc tốt và tập trung ở một nơi. Trường hợp tốn kém là bốn hệ thống lưu trữ dữ liệu không thống nhất, các tệp PDF được quét và một wiki chưa ai cập nhật từ năm 2023 — công việc lúc này là xử lý dữ liệu, việc mà dù sao bạn cũng cần làm.
- Mức độ chính xác cần đạt. Có sự khác biệt lớn giữa “soạn bản nháp để người khác kiểm tra” và “tự thực hiện mà không cần giám sát”. Trường hợp thứ hai cần đo lường, xử lý lỗi và có cách để mắc lỗi một cách an toàn; ngân sách sẽ được dành cho những việc đó.
- Số lượng hệ thống mà giải pháp kết nối. Mỗi tích hợp có cơ chế xác thực, giới hạn tốc độ và trường hợp lỗi riêng. Hai hệ thống là việc thường lệ. Sáu hệ thống thì thành một dự án khác hẳn.
- Có ai chịu trách nhiệm đánh giá hay không. Nếu không ai trong nhóm của bạn có thể xác định câu trả lời có tốt hay không, trước tiên chúng tôi phải xây dựng bộ công cụ đánh giá. Việc này đáng làm nhưng không miễn phí.
- Dữ liệu được phép chuyển đến đâu. “Không có gì rời khỏi hạ tầng của chúng tôi” là một ràng buộc hợp lý và cũng là yếu tố đầu vào của thiết kế. Điều đó thường có nghĩa là bạn tự lưu trữ các mô hình có trọng số mở, đánh đổi một phần năng lực để lấy quyền kiểm soát và chuyển chi phí lưu trữ sang phía bạn.
Chi phí vận hành mọi người hay quên
Ước tính chi phí xây dựng không phải là ngân sách. Sau khi ra mắt vẫn còn ba khoản chi phí, nhưng thường chỉ khoản đầu tiên có trong kế hoạch.
- Mức sử dụng. Tính theo từng yêu cầu và tăng theo khối lượng sử dụng. Chi phí thấp khi chạy thử, nên đến lúc triển khai thực tế nhiều người mới bất ngờ. Hãy ước tính ở mức gấp 10 lần khối lượng chạy thử trước khi quyết định kiến trúc.
- Đánh giá và giám sát. Chất lượng sẽ giảm sút khi nội dung của bạn thay đổi và khi nhà cung cấp cập nhật các mô hình đang được sử dụng. Cần có thứ gì đó theo dõi những thay đổi này.
- Thay đổi từ nhà cung cấp. Nhà cung cấp ngừng hỗ trợ mô hình theo lịch của họ. Hãy dự trù vài ngày công mỗi năm để chuyển đổi và tránh thiết kế khiến việc chuyển đổi trở nên khó khăn.
Bản thử nghiệm khả thi nên tốn bao nhiêu và chứng minh điều gì
Từ hai đến bốn tuần. Lâu hơn thế thì đó không còn là bản thử nghiệm khả thi nữa mà là một dự án không có kế hoạch.
Điều quan trọng là mục đích của bản thử nghiệm. Bản thử nghiệm nên kết thúc bằng một quyết định, không phải một bản demo — và cách đảm bảo điều đó là ghi rõ trước khi bắt đầu con số nào được xem là thành công, cũng như bạn sẽ làm gì nếu không đạt con số ấy. “Hệ thống cần phân loại đúng ít nhất 85% phiếu yêu cầu; nếu không đạt thì chúng ta dừng lại” là một bản thử nghiệm khả thi. “Xem AI có thể giúp gì cho chúng ta” là một buổi hội thảo.
Bản thử nghiệm cũng nên tạo ra thứ bạn vẫn cần dùng sau này: một tập hợp nhỏ gồm các ví dụ thực tế đã được gắn nhãn và có đáp án đúng. Tập dữ liệu kiểm thử này vẫn hữu ích dù mô hình hiện tại có thay đổi, đồng thời giúp quyết định tiếp theo ít tốn kém hơn.
Những câu hỏi đáng hỏi mọi nhà cung cấp
- 1. Điều gì có thể khiến chi phí cao gấp đôi ước tính của bạn?
- 2. Làm sao biết hệ thống đang hoạt động tốt, có thể đo bằng con số nào và ai sẽ đo?
- 3. Chi phí mỗi tháng là bao nhiêu nếu khối lượng sử dụng gấp mười lần khi chạy thử?
- 4. Điều gì xảy ra khi mô hình bạn chọn ngừng được hỗ trợ?
- 5. Dữ liệu của chúng tôi được chuyển đi đâu và những gì được lưu lại?
- 6. Hệ thống làm gì khi không biết câu trả lời?
- 7. Khi kết thúc, ai sở hữu mã nguồn, prompt và tập dữ liệu đánh giá?
Câu hỏi thứ sáu giúp hé lộ nhiều nhất. Hệ thống không có câu trả lời cho câu hỏi này sẽ tự tin bịa ra điều gì đó; đó là cách các dự án này đánh mất lòng tin của những người đáng lẽ sẽ sử dụng chúng.
Khi nào không nên xây dựng
Ba trường hợp chúng tôi sẽ khuyên bạn không nên xây dựng, vì nói sớm sẽ giúp cả hai bên tiết kiệm chi phí.
- Quy trình chưa được ghi lại ở đâu cả. Nếu không ai có thể mô tả các quy tắc, dự án cần bắt đầu bằng công việc cải thiện quy trình vận hành chứ không phải AI.
- Việc đó chỉ xảy ra mười lần mỗi tháng. Tự động hóa một tác vụ hiếm khi xảy ra thường không bù được chi phí duy trì hệ thống tự động hóa.
- Đã có sản phẩm hiện hữu làm được việc đó. Nếu dữ liệu của bạn không phải là lợi thế khác biệt, hãy mua sản phẩm có sẵn. Chúng tôi thà nói với bạn điều đó còn hơn thu phí để xây dựng lại.
Cách chúng tôi làm việc
Chúng tôi là một nhóm kỹ sư nhỏ, không phải công ty dịch vụ: bạn trao đổi trực tiếp với những người viết mã, không có quản lý khách hàng ở giữa, và chúng tôi chọn lọc dự án nhận làm. Trong lĩnh vực AI, chúng tôi làm tích hợp LLM, truy xuất thông tin từ nội dung riêng của bạn, tác tử và triển khai mô hình do chính bạn lưu trữ — bên cạnh công việc về .NET, Python, TypeScript và điện toán đám mây mà các thành viên khác trong studio thực hiện.
Chúng tôi cũng phát hành phần mềm Windows của riêng mình, trong đó có một trợ lý văn bản chạy mô hình ngôn ngữ hoàn toàn trên PC của người dùng, vì vậy chúng tôi có kinh nghiệm thực tế với mô hình chạy trên thiết bị và các yêu cầu nghiêm ngặt về quyền riêng tư.
Hãy cho chúng tôi biết bạn muốn xây dựng gì
Hãy mô tả vấn đề thay vì giải pháp — hiện tại mọi người làm gì, việc đó xảy ra thường xuyên thế nào và sai sót sẽ tốn kém ra sao. Bạn sẽ nhận được phản hồi trong vòng một ngày làm việc, kèm phạm vi công việc và chi phí ước tính, hoặc lý do chúng tôi cho rằng bạn không nên xây dựng giải pháp đó.