Sản xuất từ đầu đến cuối: Xác minh, giám sát và đạo đức

Lợi nhuận:

Có thể thiết kế kiến trúc end-to-end sử dụng tính năng LLM từ ý tưởng đến sản xuất
Thiết lập các lớp thực thi xác minh, phê duyệt của con người và theo dõi (ghi nhật ký/số liệu)
Ranh giới chuyển các nguyên tắc đạo đức và quyền riêng tư vào các quyết định sản xuất

Trong mười bài trước, chúng ta đã học từng phần một: cấu trúc yêu cầu, tính kinh tế của mã thông báo, luồng, lời nhắc hệ thống, lựa chọn mô hình, bộ đệm, lô, quản lý lỗi, khóa bảo mật và tự động hóa. Trong bài cuối cùng này, chúng tôi kết hợp các bộ phận và thiết lập kiến trúc tổng thể mang tính năng LLM từ ý tưởng đến sản xuất. Quá trình sản xuất khác với “bản demo hoạt động”: việc xác minh là bắt buộc, đầu ra phải được giám sát, các ranh giới và nguyên tắc đạo đức phải được đưa vào các quyết định. Đơn vị này là cột mang của mô-đun; Tất cả những cái trước đều tập hợp lại ở đây.

Các lớp kiến trúc sản xuất

Bằng cấp LLM vững chắc bao gồm khoảng năm lớp:

Lớp đầu vào: Thu thập dữ liệu, làm sạch nó, che giấu các khu vực nhạy cảm, chỉ truyền những gì cần thiết.
Lớp mô hình: Chọn đúng mô hình (đơn vị 5), đặt lời nhắc và thông số hệ thống (đơn vị 4), bộ đệm (đơn vị 6).
Lớp xác thực: Kiểm tra đầu ra dựa trên lược đồ/quy tắc, nguồn và sự chấp thuận của con người nếu cần.
Lớp hành động: Thực hiện hành động với đầu ra được xác thực; Ghi lại các hành động có tác động cao.
Lớp giám sát: Ghi lại và đo lường mọi cuộc gọi, chi phí, lỗi và chất lượng.

Các lớp này là một đường ống; mỗi cái kiểm tra đầu ra của cái trước.

Tại sao cần phải xác minh?

LLM có thể tạo ra âm thanh trôi chảy nhưng đôi khi không chính xác. Điều này được gọi là ảo giác: mô hình có thể bịa đặt thông tin có vẻ đúng nhưng thực tế không phải vậy. Trong trò chơi trò chuyện, điều này có thể chấp nhận được; không thể được dung thứ trong một hệ thống sản xuất (hóa đơn, sức khỏe, pháp lý, tài chính). Hóa ra là không đáng tin cậy một cách mù quáng; được xác nhận.

Các lớp xác minh (tăng theo tác động):

Xác thực định dạng/lược đồ: Đầu ra có phù hợp với lược đồ JSON dự kiến không? (Đầu ra có cấu trúc phần lớn đảm bảo điều này.)
Xác minh quy tắc/logic: Các giá trị có hợp lý không? (Số tiền có âm không, ngày trong tương lai, danh mục có hợp lệ không?)
Xác minh nguồn: Tuyên bố có dựa trên tài liệu được cung cấp không? Mô hình có nói điều gì đó không có trong tài liệu không?
Sự chấp thuận của con người: Một chuyên gia xem xét các quyết định có tác động lớn hoặc mơ hồ.

Thận trọng: “Mô hình đã quá tốt rồi, không cần xác minh thêm nữa” là sai lầm sản xuất nguy hiểm nhất. Cho dù mô hình có tốt đến đâu thì lớp xác minh vẫn là mạng lưới an toàn trong các quyết định có tác động lớn. Ngay cả một quyết định tự động sai lầm cũng có thể lấy đi toàn bộ thời gian tiết kiệm được.

Con người trong vòng lặp

Không phải mọi quyết định đều phải hoàn toàn tự động. Trong phương pháp tiếp cận con người trong vòng lặp, mô hình sẽ tăng tốc công việc và con người phê duyệt nó. Sự cân bằng phù hợp phụ thuộc vào tác động của quyết định và độ tin cậy của mô hình đối với nhiệm vụ đó.

Tác động của quyết định

Cách tiếp cận

Thấp (gợi ý nhãn, bản nháp)

Tự động hóa hoàn toàn; lỗi là rẻ và có thể đảo ngược

Trung bình (định tuyến, ưu tiên)

Tự động hóa + kiểm soát lấy mẫu

Cao (tiền, hợp đồng, sức khỏe, xóa)

Sự đồng ý của con người là bắt buộc; mô hình chỉ gợi ý

Giám sát: Bạn không thể quản lý những gì bạn không thấy

Trong sản xuất, bạn phải theo dõi mọi cuộc gọi. Nếu không giám sát, bạn không thể cải thiện chi phí, chất lượng hoặc phát hiện sớm vấn đề. Các số liệu chính cần ghi lại:

Cách sử dụng/chi phí: Mỗi yêu cầu và tổng số token, phân phối mô hình, chi tiêu hàng ngày.
Độ trễ: Thời gian phản hồi trung bình và trường hợp xấu nhất.
Tỷ lệ lỗi: tỷ lệ 429/500, thử lại, bỏ qua.
Chất lượng: Tỷ lệ đầu ra bị từ chối ở lớp xác minh, tỷ lệ hiệu chỉnh khi được con người phê duyệt, phản hồi của người dùng.

Mẹo: Không ghi dữ liệu nhạy cảm (thông tin cá nhân, chìa khóa) vào nhật ký giám sát. Xem xét nhật ký trong phạm vi bảo mật; ghi lại bằng cách che nếu cần thiết (đơn vị 9).

Đạo đức và ranh giới

Trách nhiệm đạo đức là một phần của quyết định sản xuất cũng như độ chính xác về mặt kỹ thuật:

Tính minh bạch: Người dùng nên biết liệu họ đang nói chuyện với trí tuệ nhân tạo hay con người.
Tính công bằng và sai lệch: Mô hình có thể có sai lệch từ dữ liệu mà nó được đào tạo; Giám sát hậu quả phân biệt đối xử trong các quyết định có tác động lớn (tuyển dụng, tín dụng).
Trách nhiệm pháp lý: Nếu một quyết định tự động gây ra tổn hại, bạn phải chịu trách nhiệm; “Người mẫu nói vậy” không phải là lời bào chữa.
Chấp nhận các giới hạn: Mô hình không thể thực hiện một số nhiệm vụ một cách đáng tin cậy; không tự động hóa chúng cũng là một quyết định thiết kế.

Mẫu có thể sao chép

# Danh sách kiểm tra xác thực (sau khi tạo đầu ra)1) Lược đồ có hợp lệ không? (xác thực đầu ra có cấu trúc)2) Các giá trị có hợp lý không? (kiểm tra quy tắc: phạm vi, ngày tháng, enum)3) Tuyên bố có dựa trên nguồn không? (từ chối nếu không có trong tài liệu)4) Tác động có cao không? → gửi để con người phê duyệt5) Nếu tất cả đều được thông qua → cho phép hành động, hãy lưu

# Lời nhắc hệ thống buộc phải dựa vào nguồn Chỉ dựa vào thông tin trong tài liệu được cung cấp. Không thêm bất cứ điều gì không có trong tài liệu. Nếu thông tin không có trong tài liệu, hãy viết "Không tìm thấy trong tài liệu". Không bao giờ đoán hoặc bịa đặt mọi thứ.

# Ngưỡng phê duyệt của con người (quy tắc quyết định)NẾU quyết định_loại trong [tiền, hợp đồng, xóa, sức khỏe] → bắt buộc phê duyệt của con ngườiIF model_trust < ngưỡng HOẶC xác thực "không chắc chắn" → gửi đến sự chấp thuận của con ngườiOTHER → tự động áp dụng + kiểm soát lấy mẫu

# Mẫu nhật ký theo dõi (ghi dữ liệu nhạy cảm){ "time": "...", "model":...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...","authentication":passed|rejected|human", "cost_usd":... } // dữ liệu cá nhân và khóa KHÔNG BAO GIỜ được ghi

Dấu nhắc yếu / Dấu nhắc mạnh (độ tin cậy sản xuất)

# YẾU (không xác minh, không nguồn, áp dụng tự động) Đánh giá yêu cầu này, đưa ra quyết định hoàn tiền và áp dụng.

# MẠNH (dựa trên nguồn, tạo đề xuất, để con người phê duyệt) Đánh giá yêu cầu hoàn trả này chỉ dựa trên tài liệu chính sách hoàn trả. Đề xuất quyết định có căn cứ nhưng không thực hiện: {"recommendation:"approve|reject","reason":...","policy_clause:"..."}. Nếu văn bản chính sách không có cơ sở rõ ràng, hãy đưa ra "không rõ ràng". Một đại diện sẽ phê duyệt quyết định cuối cùng.

Phiên bản mạnh mẽ; Nó gán quyết định cho nguồn, định vị mô hình như một “người gợi ý” chứ không phải là “người thực hiện” và đặt bước có tác động cao sau sự chấp thuận của con người. Đây là bản chất của độ tin cậy sản xuất.

Ba hộp nhỏ

Trường hợp 1 - Ngày lớp xác minh được lưu. Một công ty fintech đang có mô hình phân loại mô tả giao dịch và tạo hồ sơ kế toán tự động. Họ đã thêm xác thực quy tắc: khi mô hình xuất ra số tiền không chính xác (12.500 thay vì 1.250 trong tài liệu), quy tắc "số tiền không khớp với tài liệu" sẽ từ chối đầu ra và bản ghi rơi vào tay con người. Nếu không có xác minh, bản ghi không chính xác sẽ âm thầm xâm nhập vào hệ thống.

Trường hợp 2 - Kẻ chạy trốn bị giám sát bắt giữ. Nhóm SaaS đã thành lập một ban giám sát; Một buổi sáng, chi phí hàng ngày tăng gấp ba lần. Từ nhật ký, người ta thấy rằng một khách hàng đã vào một vòng lặp và gửi cùng một yêu cầu hàng nghìn lần. Họ đã thêm hạn ngạch và loại bỏ trùng lặp; Vấn đề đã được giải quyết trong vòng vài giờ. Nếu không theo dõi, hóa đơn sẽ gây bất ngờ vào cuối tháng.

Trường hợp 3 - Chấp nhận giới hạn. Một công ty khởi nghiệp về chăm sóc sức khỏe đang lên kế hoạch đưa ra khuyến nghị chẩn đoán hoàn toàn tự động và hiển thị cho bệnh nhân. Trong quá trình xem xét đạo đức và trách nhiệm pháp lý, họ quyết định điều này nằm ngoài giới hạn: mô hình chỉ cung cấp bản tóm tắt và các điểm có thể có cho bác sĩ, bác sĩ đưa ra chẩn đoán. Không tự động hóa công việc cũng là một quyết định thiết kế chín chắn.

Những lỗi thường gặp

Bỏ qua xác thực: Áp dụng đầu ra một cách mù quáng, nói rằng "mô hình tốt".
Tự động hóa quyết định có tác động cao: Sự chấp thuận của con người là điều cần thiết trong tiền bạc/sức khỏe/luật.
Không giám sát: Các vấn đề về chi phí và chất lượng được phát hiện muộn.
Ghi dữ liệu nhạy cảm vào nhật ký: Vi phạm quyền riêng tư; Lưu nó bằng cách che nó.
Không cố gắng dựa vào nguồn: Mô hình có thể tạo nên những gì không có trong tài liệu.
Bỏ qua các giới hạn: Không tự động hóa một số nhiệm vụ là quyết định đúng đắn; Sự minh bạch và trách nhiệm là của bạn.

Sâu hơn: Quản lý phát hành, khôi phục và triển khai gia tăng

Đưa tính năng LLM vào sản xuất không phải là thiết lập nó rồi quên nó đi; là sửa đổi một hệ thống trực tiếp một cách an toàn theo thời gian. Nó có ba trụ cột.

Phiên bản. Lời nhắc hệ thống, lựa chọn mô hình và quy tắc xác minh của bạn thay đổi theo thời gian. Phiên bản từng thay đổi đáng kể và ghi lại phiên bản nào đang hoạt động. Nếu một ngày chất lượng giảm xuống, "chúng ta đã thay đổi điều gì?" Bạn sẽ có thể trả lời câu hỏi trong vòng vài phút. Trong một hệ thống không có phiên bản, việc tìm ra nguyên nhân gốc rễ của sự hồi quy phải mất nhiều ngày.

Quay lại. Nếu lời nhắc hoặc mô hình mới hoạt động kém hơn mong đợi khi đang hoạt động, bạn có thể nhanh chóng quay lại phiên bản phổ biến trước đó. Một sự thay đổi không có kế hoạch khôi phục là chấp nhận rủi ro trực tiếp một cách mù quáng. "Tôi đã thay đổi một số thứ, nó trở nên tồi tệ, tôi không thể quay lại" là kịch bản sản xuất tốn kém nhất.

Triển khai dần dần. Thay vì áp dụng thay đổi cho tất cả lưu lượng truy cập cùng một lúc, trước tiên bạn triển khai thay đổi đó thành một tỷ lệ phần trăm nhỏ (ví dụ: 5%) và theo dõi các số liệu (chất lượng, chi phí, lỗi). Nếu tốt thì bạn tăng tỷ lệ lên; Nếu nó xấu, bạn sẽ lấy lại được chỉ một phần nhỏ bị ảnh hưởng. Điều này hạn chế rất nhiều rủi ro.

Ba phương pháp thực hành này kết hợp các kỹ thuật từ tất cả các đơn vị trước đó: eval (đơn vị 5) đo lường sự thay đổi trước, giám sát (đơn vị này) đưa ra cảnh báo sớm trong quá trình lan truyền, lớp xác minh phát hiện các kết quả đầu ra sai trước khi chúng có thể áp dụng được. Sản xuất không phải là một thiết lập chính xác duy nhất; Đó là một kỷ luật liên tục để đo lường, giám sát và có thể thay đổi một cách tự tin. Toàn bộ mô-đun là để bạn thiết lập nguyên tắc này.

Tóm lại

Sản xuất không chỉ là một bản demo hoạt động: nó là một hệ thống gồm các lớp đầu vào, mô hình, xác minh, hành động và giám sát. Đầu ra không đáng tin cậy nếu không được xác minh; các quyết định có tác động cao gắn liền với sự chấp thuận của con người; Mọi cuộc gọi đều được theo dõi về chi phí, lỗi và chất lượng. Đạo đức, tính minh bạch, kiểm soát thiên vị, trách nhiệm giải trình và chấp nhận các giới hạn là không thể thiếu trong các quyết định kỹ thuật. Mọi phần học được trong mô-đun này đều kết hợp với nhau trong thiết kế tổng thể này.

Nhiệm vụ ứng dụng

Thiết kế một tính năng LLM từ đầu đến cuối. (1) Điền vào năm lớp (đầu vào, mô hình, xác minh, hành động, giám sát) cho nhiệm vụ cụ thể của bạn. (2) Đánh dấu bằng tác động những quyết định nào sẽ cần sự chấp thuận của con người. (3) Viết ít nhất ba lần kiểm tra xác thực (lược đồ, quy tắc, nguồn). (4) Xác định các số liệu chính bạn sẽ theo dõi và những số liệu bạn sẽ không ghi lại. (5) Viết giới hạn và nguyên tắc đạo đức mà bạn chấp nhận ở tính năng này.

danh sách kiểm tra

[ ] Tôi có thể thiết kế năm lớp của đường ống sản xuất.
[ ] Tôi có thể xác thực kết quả đầu ra dựa trên lược đồ, quy tắc và nguồn.
[ ] Tôi có thể đặt ngưỡng phê duyệt của con người dựa trên tác động của quyết định.
[ ] Tôi giám sát chi phí, lỗi và chất lượng, đồng thời thực hành không ghi dữ liệu nhạy cảm vào nhật ký.
[ ] Tôi có thể biến đạo đức, trách nhiệm và ranh giới thành các quyết định sản xuất.

Thi học phần

1. Vai trò 'hệ thống' làm gì trong API trò chuyện LLM?

A) Cung cấp cho người mẫu những hướng dẫn thường xuyên và các quy tắc ứng xử áp dụng trong toàn bộ cuộc trò chuyện ✔
B) Giữ câu hỏi cuối cùng do người dùng viết
C) Lưu trữ phản hồi do mô hình tạo ra
D) Mã hóa khóa API

Mô tả: Vai trò hệ thống cung cấp cho mô hình những hướng dẫn, tính cách và quy tắc liên tục áp dụng trong toàn bộ cuộc trò chuyện; Đó là một chuyển hướng cấp cao, tách biệt với tin nhắn của người dùng.

2. Tại sao lịch sử hội thoại (tin nhắn trước đó) lại được gửi lại mỗi lần trong yêu cầu API?

A) Cần sao lưu khi máy chủ xóa lịch sử
B) Các lệnh gọi API không có trạng thái; ✔ Ngữ cảnh bị gửi lại theo mọi yêu cầu vì mô hình không ghi nhớ lịch sử
C) Chỉ cần thiết cho việc lập hóa đơn, không ảnh hưởng đến mô hình
D) Lịch sử gửi là bắt buộc để tránh làm chậm phản hồi

Giải thích: Lệnh gọi API LLM không có trạng thái; Mô hình không nhớ các vòng trước đó nên tất cả lịch sử liên quan sẽ được gửi lại theo mọi yêu cầu để duy trì bối cảnh.

3. 'Mã thông báo' trong định giá LLM là gì?

A) Mật khẩu dùng một lần để đăng nhập vào API
B) Một khoản phí cố định được trả cho mỗi yêu cầu
C) Đơn vị nhỏ nhất trong đó mô hình xử lý văn bản; thường tương ứng với phần từ ✔
D) Đơn vị chỉ đo độ dài của đầu ra

Mô tả: Mã thông báo là đơn vị nhỏ nhất trong đó mô hình xử lý văn bản; Nó thường tương ứng với một đoạn của từ và cả đầu vào và đầu ra đều được tính phí dựa trên số lượng mã thông báo.

4. Tại sao mã thông báo đầu ra đắt hơn mã thông báo đầu vào ở hầu hết các nhà cung cấp LLM?

A) Mã thông báo đầu ra luôn dài hơn đầu vào
B) Mã thông báo đầu vào là miễn phí
C) Mã thông báo đầu ra được gửi hai lần qua internet
D) Đơn giá cao hơn vì việc tạo đầu ra yêu cầu tính toán bổ sung cho mỗi mã thông báo ✔

Mô tả: Mỗi mã thông báo đầu ra yêu cầu mô hình thực hiện tạo từng bước (tính toán); Chi phí sản xuất này cao hơn so với việc xử lý toàn bộ đầu vào cùng một lúc nên đơn giá đầu ra thường cao hơn.

5. Sử dụng tính năng phát trực tuyến có lợi nhất trong tình huống nào?

A) Trong câu trả lời dài; Giảm độ trễ nhận thấy và ngăn chặn thời gian chờ ✔
B) Chỉ trong những câu trả lời rất ngắn, một từ
C) Để giảm chi phí xuống bằng không
D) Để ẩn khóa API

Mô tả: Trong các phản hồi dài, tính năng phát trực tuyến giúp giảm độ trễ nhận thấy bằng cách làm cho các từ đầu tiên xuất hiện ngay lập tức và ngăn thời gian chờ HTTP ở giá trị max_tokens lớn.

6. Việc tăng thông số “nỗ lực” trong các mô hình hiện đại thường có tác dụng gì?

A) Luôn rút ngắn câu trả lời
B) Tự động xoay khóa API
C) Nó chỉ làm giảm giá token đầu vào
D) Tăng chiều sâu tư duy và chi tiêu mã thông báo; Nó có thể cải thiện chất lượng nhưng cũng làm tăng độ trễ và chi phí ✔

Mô tả: Tham số nỗ lực điều chỉnh mức độ suy nghĩ sâu sắc của mô hình về một nhiệm vụ và số lượng mã thông báo sẽ chi tiêu; Việc nâng cấp có thể cải thiện chất lượng nhưng cũng làm tăng độ trễ và chi phí. Đối với các nhiệm vụ đơn giản, nỗ lực thấp là đủ.

7. Cách tiếp cận hiệu quả nhất về mặt chi phí đối với một nhiệm vụ phân loại khối lượng lớn, đơn giản là gì?

A) Luôn sử dụng model đắt nhất và mạnh nhất
B) Gọi tất cả các mô hình cùng lúc cho mỗi yêu cầu
C) Chọn mô hình nhẹ nhất/rẻ nhất để hoàn thành nhiệm vụ bằng cách xác minh nó bằng một đánh giá nhỏ ✔
D) giữ giá trị max_tokens quá cao một cách không cần thiết

Giải thích: Nếu nhiệm vụ không phức tạp, việc chọn mô hình nhanh hơn và rẻ hơn, dễ dàng hoàn thành nhiệm vụ (ví dụ: lớp Haiku) thay vì sử dụng mô hình đắt tiền và mạnh mẽ nhất sẽ giảm đáng kể chi phí.

8. Bộ nhớ đệm nhanh chóng giảm chi phí nhiều nhất trong trường hợp nào?

A) Khi bối cảnh lớn và cố định được sử dụng nhiều lần trong nhiều yêu cầu ✔
B) Khi một văn bản hoàn toàn khác được gửi cùng với mỗi yêu cầu
C) Khi chỉ có một yêu cầu duy nhất được thực hiện
D) Để giảm mã thông báo đầu ra

Mô tả: Bộ nhớ đệm là kết quả khớp tiền tố; Trong trường hợp một ngữ cảnh lớn, không thể thay đổi (lời nhắc hệ thống, tài liệu) được sử dụng lại trong nhiều yêu cầu, việc đọc từ bộ đệm chỉ là một phần nhỏ (~0,1 lần) so với toàn bộ giá.

9. Tôi nên chỉnh sửa lời nhắc như thế nào để bộ đệm nhắc nhở truy cập?

A) Đặt nội dung thay đổi ở đầu và nội dung cố định ở cuối
B) Nhúng ngày giờ hiện tại vào lời nhắc hệ thống cho mỗi yêu cầu
C) Đặt nội dung cố định (lời nhắc hệ thống, tài liệu) ở đầu và nội dung thay đổi ở cuối ✔
D) Thay đổi thứ tự danh sách công cụ theo từng yêu cầu

Giải thích: Vì bộ nhớ đệm khớp với tiền tố nên nội dung cố định/không thay đổi (lời nhắc hệ thống, tài liệu) sẽ được khởi tạo; nội dung thay đổi (ngày, câu hỏi của người dùng, ID yêu cầu) được đặt ở cuối. Ngay cả một byte đơn được thay đổi lúc đầu cũng sẽ làm mất hiệu lực bộ đệm.

10. Xử lý hàng loạt phù hợp nhất với loại khối lượng công việc nào?

A) Trò chuyện trực tiếp nơi người dùng mong đợi phản hồi tức thì trên màn hình
B) Chỉ một câu hỏi ngắn
C) Tạo khóa API
D) Những công việc có khả năng chịu trì hoãn, khối lượng lớn và không yêu cầu kết quả ngay lập tức ✔

Mô tả: Xử lý hàng loạt phù hợp với khối lượng lớn công việc không yêu cầu phản hồi ngay lập tức và có khả năng chịu được độ trễ; kết quả được cung cấp sau một thời gian, nhưng đơn giá thường thấp hơn.

11. Dùng gì để tự tin khớp kết quả thuộc về yêu cầu nào trong một đợt?

A) Gửi thứ tự (vị trí) của yêu cầu
B) Độ dài của câu trả lời
C) 4 chữ số cuối của khóa API
D) Một custom_id duy nhất được cung cấp cho mỗi yêu cầu ✔

Lưu ý: Kết quả hàng loạt có thể được trả về theo thứ tự khác với thứ tự gửi; vì vậy, cần phải khớp kết quả theo ID chứ không phải vị trí với custom_id duy nhất được cung cấp cho mỗi yêu cầu.

12. Bạn nên làm gì khi gặp lỗi 429 (giới hạn tỷ lệ) từ API?

A) Buộc bằng cách gửi nhiều yêu cầu hơn cùng một lúc
B) Thử lại với thời gian chờ theo cấp số nhân, theo tiêu đề thử lại sau ✔
C) Hủy hoàn toàn yêu cầu và hiển thị lỗi là sự cố cho người dùng
D) Thay đổi khóa API

Giải thích: 429 là lỗi có thể thử lại; Cách tiếp cận đúng là thử lại với thời gian chờ theo cấp số nhân, tôn trọng tiêu đề thử lại sau. Hầu hết các SDK chính thức đều tự động thực hiện việc này.

13. Mã lỗi HTTP nào sau đây thường được coi là có thể thử lại được?

A) 400 (yêu cầu không hợp lệ)
B) 401 (lỗi xác thực)
C) 529 (máy chủ quá tải) ✔
D) 404 (không tìm thấy)

Giải thích: 429 (giới hạn tốc độ), 500 (lỗi máy chủ) và 529 (quá tải) là lỗi tạm thời và có thể thử lại bằng cách lùi lại. Các lỗi như 400 và 401 là vấn đề về yêu cầu/danh tính; Thử lại sẽ không giải quyết được.

14. Cách nào sau đây là cách an toàn để quản lý khóa API?

A) Lưu trữ trong biến môi trường/trình quản lý ẩn, không nhúng vào mã và luân chuyển thường xuyên ✔
B) Viết key trực tiếp vào mã nguồn và gửi vào kho lưu trữ
C) Đưa khóa vào JavaScript phía máy khách (trình duyệt)
D) Chia sẻ một khóa duy nhất với toàn bộ nhóm qua email

Mô tả: Khóa không bao giờ được ghi vào mã nguồn hoặc kho lưu trữ; Nó được lưu trữ trong một biến môi trường hoặc công cụ quản lý ẩn, được cấp các đặc quyền tối thiểu và được luân chuyển thường xuyên.

15. Cách tiếp cận tốt nhất để tích hợp LLM với công cụ tự động hóa (n8n, Zapier, Make) về mặt quyền riêng tư là gì?

A) Gửi tất cả dữ liệu thô đến mô hình, ngay cả khi không cần thiết
B) Viết khóa API bằng văn bản thuần túy trong bước quy trình
C) Giảm thiểu và che giấu dữ liệu nhạy cảm cũng như lưu trữ khóa dưới dạng thông tin xác thực bí mật ✔
D) Giữ dữ liệu cá nhân vĩnh viễn trong lịch sử luồng

Mô tả: Khi quá trình tự động nhập dữ liệu đi qua các hệ thống và mô hình của bên thứ ba, dữ liệu nhạy cảm/cá nhân cần được giảm thiểu, che giấu và chỉ gửi các trường bắt buộc; Khóa API cũng được lưu trữ dưới dạng thông tin xác thực bí mật trong công cụ.

16. Tại sao việc xác thực đầu ra là bắt buộc trong tính năng sản xuất dựa trên LLM?

A) Chỉ cần định dạng vì mô hình không bao giờ mắc lỗi
B) Vì mô hình có thể sản xuất trôi chảy nhưng đôi khi không chính xác; Lược đồ/quy tắc phải được kiểm tra với sự phê duyệt của nguồn lực và con người ✔
C) Nên tránh việc xác nhận vì nó chỉ làm tăng chi phí
D) Việc xác minh chỉ nhằm mục đích giảm số lượng token

Mô tả: LLM có thể tạo ra âm thanh trôi chảy nhưng đôi khi không chính xác (gây ảo giác); vì vậy nó được đưa ra trong các quyết định có tác động lớn; Nó cần được kiểm tra bằng cách kiểm tra lược đồ/quy tắc, xác thực nguồn và phê duyệt của con người khi cần thiết.