Một AI API dễ đánh giá nhất khi bạn ngừng coi nó như một tích hợp chung chung và bắt đầu gắn nó với một quyết định cụ thể trong phễu. Trường hợp sử dụng phù hợp cho nghiên cứu nhận biết không giống với trường hợp sử dụng phù hợp cho onboarding, chuyển đổi, giữ chân hay vận hành. Mỗi giai đoạn cần một đầu vào khác nhau, lựa chọn mô hình khác nhau, bề mặt công cụ khác nhau, giới hạn ngân sách khác nhau và chỉ số thành công khác nhau.
Hướng dẫn này cung cấp cho các đội ngũ một cách thực tiễn để chọn các quy trình làm việc AI API theo từng giai đoạn phễu. Hãy dùng nó khi bạn đang quyết định nên xây dựng gì trước, bề mặt API nào là quan trọng, và làm sao biết một nguyên mẫu có đáng để nhận lưu lượng truy cập sản xuất hay không.
Câu trả lời nhanh
Hãy dùng một AI API khi một quy trình làm việc cần hiểu ngôn ngữ, tạo nội dung, truy xuất, phân loại, trích xuất, tạo hình ảnh hoặc video, hoặc gọi công cụ bên trong một sản phẩm hay quy trình vận hành. Đừng bắt đầu với bảng xếp hạng mô hình. Hãy bắt đầu bằng câu hỏi của phễu:
| Giai đoạn phễu | Câu hỏi kinh doanh | Quy trình làm việc AI API hữu ích | Chỉ số quan trọng |
|---|---|---|---|
| Nhận biết | Chúng ta nên học được gì từ thị trường? | Tổng hợp nghiên cứu, phân cụm chủ đề, trích xuất tín hiệu cạnh tranh | Số phát hiện hữu ích trên mỗi nguồn được xem xét |
| Đánh giá | Chúng ta nên tin tưởng mô hình hay quy trình làm việc nào? | Kiểm thử prompt, so sánh mô hình, thử nghiệm đa phương thức | Tỷ lệ đầu ra được chấp nhận ở độ trễ và chi phí mục tiêu |
| Kích hoạt | Người dùng mới có thể đạt giá trị nhanh hơn không? | Copilot onboarding, Q&A tài liệu, trợ lý thiết lập | Thời gian đến tác vụ thành công đầu tiên |
| Chuyển đổi | Chúng ta có thể giảm ma sát mua hàng không? | Soạn thảo đề xuất, giải thích ROI, tóm tắt mức độ đủ điều kiện | Tỷ lệ hỗ trợ chuyển đổi đủ điều kiện |
| Giữ chân | Chúng ta có thể giúp khách hàng tiếp tục thành công không? | Phân loại hỗ trợ, tóm tắt tài khoản, phát hiện rủi ro sử dụng | Thời gian xử lý vấn đề và phạm vi phủ nhận diện rủi ro churn |
| Vận hành | Chúng ta có thể quản trị chi tiêu và độ tin cậy không? | Nhật ký sử dụng, kiểm tra hạn mức, rà soát phương án dự phòng, kiểm soát khóa | Chi phí trên mỗi tác vụ được chấp nhận và thời gian khôi phục sự cố |
Phần khan hiếm không phải là gọi một mô hình. Phần khan hiếm là kết nối lời gọi AI API với một quyết định có thể đo lường được và cụ thể theo từng giai đoạn.
Điều gì được tính là một trường hợp sử dụng AI API?
Một trường hợp sử dụng AI API có bốn phần:
- Một đầu vào có thể lặp lại, chẳng hạn như prompt, bản ghi hội thoại, ticket hỗ trợ, sự kiện sản phẩm, tệp, hình ảnh hoặc hồ sơ khách hàng.
- Một hành động mô hình hoặc công cụ, chẳng hạn như tạo sinh, trích xuất, phân loại, truy xuất, tìm kiếm web, làm giàu dữ liệu, tạo hình ảnh hoặc tạo video.
- Một đầu ra được kiểm soát, chẳng hạn như JSON, danh sách xếp hạng, bản nháp, bản tóm tắt, điểm số, tài sản media hoặc bước tiếp theo được đề xuất.
- Một chỉ số cho bạn biết kết quả có đủ hữu ích để tiếp tục hay không.
Định nghĩa đó quan trọng vì nó giúp các đội ngũ không triển khai tự động hóa mơ hồ. Một trường hợp sử dụng AI API tốt sẽ nói rằng: "ở giai đoạn phễu này, chúng tôi sẽ biến đầu vào này thành đầu ra này, và chúng tôi sẽ đánh giá nó bằng chỉ số này."
Nếu bạn vẫn đang chọn lớp truy cập, thì lựa chọn kiến trúc là một vấn đề riêng. Một API của nhà cung cấp trực tiếp có thể đủ cho một khối lượng công việc ổn định. Một AI API gateway trở nên hữu ích hơn khi bạn cần nhiều mô hình, một base URL tương thích OpenAI, định tuyến, thanh toán dùng chung, hoặc xem xét mức sử dụng theo từng yêu cầu.
Nhận biết: Biến tiếng ồn thị trường thành các tín hiệu có thể tìm kiếm
Các đội ở đầu phễu thường có quá nhiều thông tin thô và quá ít khả năng tổng hợp. Ra mắt sản phẩm, trang đối thủ, bài đăng mạng xã hội, đánh giá, thảo luận cộng đồng và ghi chú bán hàng đều có thể chứa những tín hiệu yếu. Một AI API có thể giúp biến những tài liệu đó thành các cụm và câu hỏi.
Các trường hợp sử dụng tốt ở giai đoạn nhận biết bao gồm:
- Phân cụm chủ đề từ phỏng vấn khách hàng, ghi chú cuộc gọi, đánh giá, thảo luận cộng đồng và các truy vấn tìm kiếm.
- Giám sát các đợt ra mắt của đối thủ, trích xuất các tuyên bố, định vị, đối tượng mục tiêu, gợi ý về giá và các điểm chứng minh.
- Tạo bản tóm tắt có dẫn nguồn cho GTM, nội dung, bán hàng hoặc nghiên cứu sản phẩm.
- Nhóm từ khóa và câu hỏi trước khi lịch nội dung được chốt.
Chỉ số không nên là "số từ được tạo ra." Các chỉ số tốt hơn ở giai đoạn nhận biết là độ phủ nguồn, số phát hiện hữu ích trên mỗi nguồn đã xem xét, tỷ lệ khử trùng lặp, mức độ chấp nhận trích dẫn và số quyết định mà bản tóm tắt thực sự thay đổi.
Ở giai đoạn này, bạn thường cần các công cụ AI API nhiều không kém gì khả năng tạo văn bản. Một mô hình có thể tóm tắt những gì bạn cung cấp, nhưng một quy trình làm việc cũng có thể cần các API tìm kiếm, trình duyệt, làm giàu dữ liệu hoặc dữ liệu trước khi mô hình có thể suy luận trên tập nguồn.
Đánh giá: So sánh mô hình với công việc thực tế, không phải demo
Đánh giá là nơi nhiều đội ngũ lãng phí thời gian. Họ so sánh các mô hình bằng các prompt chung chung, rồi phát hiện ra rằng lưu lượng thực tế trong sản xuất lại hoạt động khác. Một trường hợp sử dụng đánh giá AI API tốt hơn bắt đầu bằng một tập nhỏ các tác vụ thực của người dùng và một thang điểm chấm.
Các quy trình làm việc hữu ích ở giai đoạn đánh giá bao gồm:
- Chạy cùng một tập prompt trên các mô hình văn bản ứng viên.
- Kiểm thử độ tin cậy của đầu ra có cấu trúc cho JSON, function calls, thẻ và tóm tắt.
- So sánh các mô hình ảnh hoặc video theo nhu cầu về thương hiệu, tốc độ và khả năng chỉnh sửa.
- Đo hành vi dự phòng khi mô hình ưu tiên bị chậm, không khả dụng hoặc quá đắt cho tác vụ.
Các chỉ số quan trọng là tỷ lệ đầu ra được chấp nhận, tỷ lệ thử lại, độ trễ p90, chi phí trên mỗi đầu ra được chấp nhận, thời gian chỉnh sửa của con người và loại lỗi. Bài viết về các chỉ số API định tuyến AI thực sự quan trọng đi sâu hơn vào những chỉ số vận hành này.
Đây cũng là nơi một AI API hợp nhất có thể giảm công sức di chuyển. Tài liệu của Flatkey mô tả một OpenAI-compatible REST API tại https://router.flatkey.ai/v1, và hướng dẫn OpenAI SDK của nó cho thấy cùng một mã yêu cầu có thể được trỏ đến Flatkey bằng cách thay đổi base URL và API key. Điều đó giúp thử nghiệm lựa chọn mô hình dễ hơn mà không phải viết lại toàn bộ client.
Kích hoạt: Giúp người dùng hoàn thành tác vụ có giá trị đầu tiên
Các trường hợp sử dụng ở giai đoạn kích hoạt nên hẹp. Mục tiêu không phải là thêm một chatbot chỉ vì mọi người khác đều có. Mục tiêu là giúp người dùng mới hoàn thành tác vụ có giá trị đầu tiên với ít ma sát hơn.
Các ví dụ AI API mạnh ở giai đoạn kích hoạt bao gồm:
- Một trợ lý thiết lập đọc mục tiêu mà người dùng nêu ra và đề xuất cấu hình đầu tiên phù hợp.
- Một giao diện Hỏi & Đáp tài liệu trả lời các câu hỏi triển khai kèm liên kết đến tài liệu liên quan.
- Một trình tạo mã hoặc mẫu prompt sử dụng framework, mô hình hoặc môi trường mà người dùng đã chọn.
- Một danh sách kiểm tra cho lần chạy đầu tiên, biến một mục tiêu mơ hồ thành một chuỗi các bước.
Theo dõi thời gian đến tác vụ đầu tiên thành công, tỷ lệ hoàn thành, chất lượng giảm tải cho hỗ trợ, các báo cáo về ảo giác, và tỷ lệ người dùng tiếp tục sau kết quả được tạo đầu tiên. Nếu trợ lý tạo ra các câu trả lời trôi chảy nhưng không giúp người dùng tiến lên, đó không phải là một chiến thắng ở giai đoạn kích hoạt.
Tài liệu quickstart của Flatkey nêu một số điểm khởi đầu cho nhà phát triển: REST API thuần, OpenAI SDK, Flatkey CLI, và thiết lập coding-agent. Loại tài liệu nguồn như vậy rất hữu ích để làm nền cho một trợ lý kích hoạt vì nó cho phép trợ lý đề xuất một lộ trình mà không bịa ra các bước thiết lập không được hỗ trợ.
Chuyển đổi: Làm cho việc mua sắm kỹ thuật dễ giải thích hơn
Các trường hợp sử dụng AI API ở giai đoạn chuyển đổi nên giảm sự không chắc chắn, chứ không tạo ra cảm giác cấp bách giả tạo. Với các sản phẩm kỹ thuật, người mua thường cần được hỗ trợ chuyển một quy trình làm việc sang ngôn ngữ kinh doanh: mức sử dụng dự kiến, rủi ro vận hành, yêu cầu mua sắm, và công sức triển khai.
Các quy trình chuyển đổi thực tế bao gồm:
- Tóm tắt ghi chú khám phá thành các yêu cầu triển khai cụ thể cho từng trường hợp sử dụng.
- Soạn thảo một kế hoạch đánh giá kỹ thuật cho ngăn xếp mà khách hàng tiềm năng ưa thích.
- Tạo ra các tường thuật về ROI hoặc khối lượng công việc từ các đầu vào đã được phê duyệt và các giả định sử dụng hiện tại.
- Tạo ghi chú chuyển giao cho bộ phận sales engineering sau buổi demo, giai đoạn dùng thử hoặc chuỗi hỗ trợ.
Chỉ số nên là chất lượng chuyển đổi có hỗ trợ: các bước tiếp theo đủ điều kiện được tạo ra, thời gian của sales engineering được tiết kiệm, yêu cầu được làm rõ, tài sản chứng minh được tái sử dụng, và ít vòng qua lại hơn. Tránh để mô hình bịa ra giá cả, cam kết, tuyên bố tuân thủ hay tài liệu tham chiếu khách hàng. Hãy giữ các trường đó ở dạng mẫu, có nguồn, hoặc để trống.
Nếu chi phí là một phần của cuộc trò chuyện mua hàng, hãy ghép quy trình với một bộ tính toán thực tế hoặc dữ liệu sử dụng. Bộ tính chi phí LLM theo từng giai đoạn phễu là một tài liệu bổ trợ hữu ích để quyết định những giả định về chi phí nào thuộc về nhận biết, đánh giá, kích hoạt, chuyển đổi và giữ chân.
Giữ chân: Phát hiện ma sát trước khi nó trở thành churn
Các trường hợp sử dụng ở giai đoạn giữ chân cần các rào chắn mạnh hơn vì chúng thường chạm tới lịch sử khách hàng, dữ liệu hỗ trợ và mức sử dụng sản phẩm. AI API nên giúp đội ngũ nhận ra ma sát sớm hơn và phản hồi một cách nhất quán.
Các quy trình giữ chân hữu ích bao gồm:
- Phân loại ticket hỗ trợ và đề xuất tuyến xử lý.
- Tạo bản tóm tắt tài khoản từ sự kiện sản phẩm, ghi chú hỗ trợ và mức sử dụng gần đây.
- Giải thích rủi ro churn từ các tín hiệu đã được phê duyệt, không phải suy đoán ẩn.
- Cá nhân hóa ghi chú phát hành theo phân khúc khách hàng hoặc mô-đun sản phẩm.
- Phát hiện lỗ hổng trong cơ sở tri thức từ các câu hỏi lặp lại chưa được trả lời.
Chỉ số nên gắn với kết quả của khách hàng: thời gian đến phản hồi đầu tiên nhanh hơn, ít trường hợp leo thang hơn, thời gian giải quyết được cải thiện, mức độ áp dụng các tính năng chính cao hơn, và việc bàn giao chủ sở hữu tài khoản rõ ràng hơn. Nếu quy trình không thể giải thích vì sao nó gắn cờ một tài khoản hoặc vấn đề, thì nó có rủi ro đối với thành công khách hàng.
Đây cũng là nơi khả năng hiển thị mức sử dụng trở nên quan trọng. Tài liệu sử dụng của Flatkey cho biết các đội ngũ có thể xem nhật ký yêu cầu với tên mô hình, số lượng token, chi phí trên mỗi yêu cầu, dấu thời gian, bộ lọc theo khóa, và xuất dữ liệu. Đó chính là loại bằng chứng mà các đội ngũ lưu giữ và vận hành cần khi họ đang cố tách một vấn đề của sản phẩm khỏi vấn đề về mô hình, prompt, định tuyến, hoặc ngân sách.
Vận hành: Kiểm soát chi tiêu, khóa và độ tin cậy
Vận hành là giai đoạn quyết định liệu một thử nghiệm AI API có thể sống sót trước lưu lượng sản xuất hay không. Khi việc sử dụng lan rộng qua các tính năng, tác tử, môi trường hoặc đội ngũ, các nhà lãnh đạo cần câu trả lời cho những câu hỏi thực tế:
- Khóa, ứng dụng, hoặc môi trường nào đã tạo ra chi phí này?
- Mô hình nào đã được chọn, và nó có thành công không?
- Những yêu cầu nào đã thất bại, thử lại, hoặc chuyển sang phương án dự phòng?
- Các kiểm thử phát triển có đang tiêu tốn ngân sách sản xuất không?
- Bộ phận tài chính có thể đối soát mức sử dụng mà không cần yêu cầu kỹ thuật xuất nhật ký thủ công không?
Các trường hợp sử dụng tốt ở giai đoạn vận hành gồm xem lại nhật ký sử dụng, phân tách API key, danh sách cho phép mô hình, giới hạn hàng tháng, tóm tắt sự cố chuyển sang phương án dự phòng, và xuất sổ cái ở cấp độ yêu cầu. Tài liệu API key của Flatkey khuyến nghị dùng khóa riêng cho từng môi trường, đặt tên khóa mang tính mô tả, dùng biến môi trường, xoay vòng định kỳ, và thu hồi khi một khóa bị xâm phạm.
Chỉ số then chốt là chi phí trên mỗi tác vụ được chấp nhận, chứ không phải chi phí trên mỗi yêu cầu thô. Các lần thử lại thất bại, đầu ra chất lượng thấp, và việc dọn dẹp thủ công đều phải được tính vào mô hình chi phí thực tế. Để biết thêm chi tiết, hãy xem hướng dẫn về giới hạn hạn mức AI API.
Cách chọn quy trình AI API đầu tiên của bạn
Hãy dùng bộ lọc năm bước này trước khi viết mã:
- Chọn một giai đoạn phễu. Đừng trộn lẫn nghiên cứu nhận biết, onboarding, và giữ chân trong cùng một thử nghiệm.
- Đặt tên cho quyết định mà quy trình đó sẽ cải thiện. Nếu không có quyết định, thì không có trường hợp sử dụng.
- Chọn bề mặt API tối thiểu. Chỉ bắt đầu với chat, responses, embeddings, images, video, hoặc tools khi quy trình thực sự cần chúng.
- Xác định chỉ số chấp nhận trước khi thử nghiệm. Dùng tỷ lệ đầu ra được chấp nhận, thời gian tiết kiệm được, độ trễ, chi phí trên mỗi tác vụ được chấp nhận, hoặc chất lượng bàn giao đã được xác minh.
- Quyết định các rào chắn vận hành. Lập kế hoạch API key, môi trường, hạn mức, nhật ký, hành vi dự phòng, và rà soát của con người trước khi ra mắt.
Đây cũng là thời điểm thích hợp để quyết định giữa truy cập trực tiếp từ nhà cung cấp và một gateway. Truy cập trực tiếp đơn giản hơn khi chỉ cần một mô hình, một đội ngũ, và một hóa đơn. Một AI API hợp nhất sẽ thực tế hơn khi quy trình cần nhiều mô hình, rà soát mức sử dụng chung, một khóa cho nhiều môi trường, hoặc một lộ trình di chuyển rõ ràng hơn cho các client tương thích OpenAI.
Flatkey phù hợp ở đâu
Flatkey trở nên phù hợp khi trường hợp sử dụng AI API trải rộng trên nhiều hơn một mô hình, đội ngũ, công cụ, hoặc ràng buộc vận hành. Tài liệu Flatkey hiện tại mô tả:
- Một API tương thích OpenAI tại
https://router.flatkey.ai/v1. - Xác thực bằng bearer token với Flatkey API keys.
- Các endpoint chat, responses, embeddings, tạo ảnh, tạo video, và danh sách mô hình.
- Thiết lập OpenAI SDK bằng cách thay đổi base URL và API key.
- Nhật ký sử dụng cho tên mô hình, số lượng token, chi phí yêu cầu, dấu thời gian, và lọc ở cấp độ khóa.
- Quản lý API key cho các môi trường riêng biệt, thu hồi, và hạn mức thông qua nhóm.
Đối với một đội ngũ đang chọn quy trình làm việc AI API đầu tiên, những chi tiết đó rất quan trọng vì chúng nối quyết định xây dựng với vận hành. Bạn có thể bắt đầu với một giai đoạn duy nhất, kiểm thử các tác vụ thực tế, và xem xét liệu đầu ra, độ trễ, chi phí và quản trị có đủ tốt trước khi mở rộng hay không.
Câu hỏi thường gặp
Trường hợp sử dụng AI API đầu tiên tốt nhất là gì?
Trường hợp sử dụng AI API đầu tiên tốt nhất là trường hợp có đầu vào lặp lại được, đầu ra rõ ràng và một quyết định có thể đo lường. Với nhiều đội ngũ, điều đó có nghĩa là kiểm thử prompt ở giai đoạn đánh giá hoặc hỗ trợ thiết lập ở giai đoạn kích hoạt, vì cả hai đều có thể được phạm vi hóa chặt chẽ.
Nên bắt đầu một trường hợp sử dụng AI API với một mô hình hay nhiều mô hình?
Hãy bắt đầu với một mô hình nếu tác vụ hẹp và ổn định. So sánh nhiều mô hình khi chất lượng, độ trễ, phương thức hoặc chi phí có thể làm thay đổi quyết định. Sử dụng gateway khi chính quá trình đánh giá cần định tuyến sạch hơn, thanh toán dùng chung hoặc một client tương thích OpenAI.
Các công cụ AI API khác gì so với model API?
Model API tạo ra hoặc chuyển đổi nội dung. Các công cụ AI API thực hiện hành động hoặc lấy dữ liệu, chẳng hạn như tìm kiếm, duyệt web, làm giàu dữ liệu hoặc quy trình làm việc với media. Nhiều trường hợp sử dụng trong sản xuất cần cả hai: công cụ thu thập hoặc hành động dựa trên ngữ cảnh, còn mô hình thì suy luận trên đó.
Tôi nên đo lường gì trước khi mở rộng quy trình làm việc AI API?
Hãy đo tỷ lệ đầu ra được chấp nhận, độ trễ p90, tỷ lệ thử lại, chi phí trên mỗi tác vụ được chấp nhận, thời gian chỉnh sửa của con người, và các nhóm lỗi. Với các quy trình hướng tới khách hàng, cũng hãy đo tỷ lệ hoàn thành của người dùng, mức độ leo thang lên hỗ trợ, và các phàn nàn về chất lượng.
Khi nào một đội ngũ không nên dùng AI API?
Không nên dùng AI API khi các quy tắc xác định, nội dung tĩnh hoặc một truy vấn cơ sở dữ liệu thông thường sẽ giải quyết vấn đề một cách đáng tin cậy hơn. Cũng nên tạm dừng khi quy trình làm việc yêu cầu dữ liệu nhạy cảm nhưng thiếu các kiểm soát quan trọng, sự rõ ràng về chính sách lưu giữ, ghi log, hạn ngạch hoặc rà soát của con người.
Danh sách kiểm tra cuối cùng
Trước khi bạn triển khai một quy trình làm việc AI API, hãy xác nhận:
- Giai đoạn phễu là rõ ràng.
- Đầu vào và đầu ra có thể lặp lại được.
- Bề mặt API là nhỏ nhất có thể để giải quyết tác vụ.
- Chỉ số thành công mang tính đặc thù theo giai đoạn.
- Chỉ số chi phí bao gồm các lần thử lại, phương án dự phòng và thời gian dọn dẹp thủ công.
- Các khóa, hạn ngạch, nhật ký và quyền sở hữu đã được xác định.
- Các tuyên bố về giá, tuân thủ và hiệu năng không được hỗ trợ sẽ bị loại trừ khỏi đầu ra được tạo ra.
Một AI API không phải là một chiến lược tự thân. Nó trở nên hữu ích khi được gắn với một giai đoạn phễu, được đánh giá bằng một chỉ số thực tế, và được vận hành với đủ khả năng quan sát để tiếp tục cải thiện.
