AI Engineering · Chip Huyen · Chương 10AI Engineering · Chip Huyen · Chương 10AI Engineering · Chip Huyen · Chapter 10
Chương 10 · Chương khép lạiChương 10 · Bài cuốiChapter 10 · The closing chapter

Ráp tất cả lại: kiến trúc và vòng phản hồiLắp mọi mảnh lại thành một cỗ máyPutting it together: architecture and the feedback loop

Chín chương trước mỗi chương lo một mảnh. Chương cuối ráp chúng lại. Huyen bắt đầu từ kiến trúc đơn giản nhất — truy vấn vào, mô hình trả lời, hết — rồi lần lượt chỉ ra chỗ hỏng của nó và thêm đúng một thành phần để vá: bối cảnh, rào chắn, bộ định tuyến và cổng mô hình, bộ nhớ đệm, rồi vòng lặp tác tử và hành động ghi.1 Nửa sau chương quay sang thứ không nằm trong sơ đồ nào: người dùng — nguồn dữ liệu riêng nuôi lại chính hệ thống ấy.

Chín bài trước, mỗi bài lo một việc nhỏ. Bài này lắp hết lại thành một cỗ máy hoàn chỉnh. Cách lắp rất hay: bắt đầu từ cỗ máy đơn giản nhất, thấy nó hỏng chỗ nào thì thêm đúng một mảnh vào chỗ đó. Rồi cuối cùng, hỏi chính người dùng xem máy chạy tốt không. Nhớ nhé: đừng lắp sẵn cả cỗ máy khổng lồ — thêm từng mảnh khi thật sự cần.

The previous nine chapters each handled one piece. The closing chapter assembles them. Huyen starts from the simplest possible architecture — query in, model answers, done — then names what breaks and adds exactly one component to fix it: context, guardrails, a model router and gateway, caches, then agentic loops and write actions.1 The second half turns to the thing no diagram contains: users — the proprietary data source that feeds the system back into itself.

∴
Luận đề của chương Ý chính của bài The chapter's thesis

Phần lớn thách thức của AI, theo Huyen, thực chất là bài toán hệ thống: để giải, phải lùi lại nhìn toàn bộ. Mỗi thành phần thêm vào có thể làm hệ thống mạnh hơn, an toàn hơn hoặc nhanh hơn, nhưng đồng thời làm nó phức tạp hơn và mở ra những kiểu hỏng mới.1 Vì vậy kiến trúc phải mọc dần theo nhu cầu, và phải quan sát được — còn phản hồi người dùng là thứ nói cho ta biết hệ thống có thật sự đạt mục tiêu hay không.

Nhiều vấn đề của AI không nằm ở một mảnh nào, mà ở chỗ cả cỗ máy chạy chung với nhau. Thêm một mảnh thì máy làm được nhiều hơn, nhưng cũng dễ hỏng theo kiểu mới. Nhớ nhé: chỉ thêm mảnh khi thật sự cần, và luôn nhìn được bên trong máy đang xảy ra gì.

Many AI challenges, Huyen argues, are at their core system problems: solving them means stepping back to consider the whole. Each added component can make a system more capable, safer or faster, but also more complex and exposed to new failure modes.1 So the architecture must grow with need, must be observable — and user feedback is what tells you whether the system actually achieves its goal.

Cụm 1 · Năm bướcPhần 1 · Lắp máyCluster 1 · Five steps

Kiến trúc mọc dần từ chỗ hỏngThêm mảnh khi máy hỏngAn architecture grown from its failures

Huyen mô tả kiến trúc đơn giản nhất: ứng dụng nhận truy vấn, gửi tới mô hình, mô hình sinh câu trả lời, trả về người dùng — không bối cảnh, không rào chắn, không tối ưu. “Model API” ở đây bao gồm cả API của bên thứ ba lẫn mô hình tự vận hành.1 Từ đó, bà thêm thành phần theo đúng thứ tự mà bà thường thấy trong sản xuất: bổ sung bối cảnh, dựng rào chắn, thêm bộ định tuyến và cổng mô hình, giảm độ trễ bằng bộ nhớ đệm, rồi thêm các mẫu hình tác tử.

Đầu tiên cỗ máy rất đơn giản: hỏi một câu, máy trả lời, xong. Nhưng rồi ta phát hiện nó thiếu tài liệu, nó nói bậy, nó chậm, nó đắt. Mỗi lần phát hiện một chỗ hỏng, ta lắp thêm đúng một mảnh để vá. Nhớ nhé: cỗ máy lớn không được vẽ ra từ đầu — nó lớn lên từ những chỗ hỏng.

Huyen describes the simplest architecture: the application receives a query, sends it to the model, the model generates a response, and it is returned to the user — no context augmentation, no guardrails, no optimisation. “Model API” here covers both third-party APIs and self-hosted models.1 From there she adds components in the order she commonly sees in production: enhance context, put in guardrails, add a model router and gateway, reduce latency with caches, then add agentic patterns.

Kiến trúc không phải bản vẽ có sẵn. Nó là một chuỗi câu trả lời cho những câu hỏi mà hệ thống tự đặt ra khi chạy thật.

Cỗ máy không được vẽ trước. Nó được vá dần, mỗi lần một chỗ.

An architecture is not a blueprint you start with. It is a sequence of answers to the questions a running system asks you.

Huyen nói rõ rằng bà theo thứ tự thường gặp trong sản xuất, nhưng “nhu cầu của mỗi người mỗi khác — bạn nên theo thứ tự hợp lý nhất cho ứng dụng của mình”. Vì vậy đừng đọc năm bước này như một danh sách bắt buộc; đọc chúng như năm loại vấn đề sẽ lần lượt xuất hiện.1

Bước 1Step 1Bổ sung bối cảnh — truy xuất và công cụEnhance context — retrieval and tools
Bước 2Step 2Rào chắn — bảo vệ hệ thống và người dùngGuardrails — protect the system and its users
Bước 3Step 3Định tuyến và cổng mô hìnhModel router and gateway
Bước 4Step 4Bộ nhớ đệm — giảm độ trễ và chi phíCaches — reduce latency and cost
Bước 5Step 5Mẫu hình tác tử và hành động ghiAgent patterns and write actions
  1. 01
    Context construction

    Context construction — dựng bối cảnhĐưa thêm tài liệu cho máy đọcContext construction

    Bước mở rộng đầu tiên gần như luôn là cho hệ thống khả năng tự dựng bối cảnh cần thiết cho mỗi truy vấn — qua các cơ chế truy xuất văn bản, hình ảnh, dữ liệu bảng, hoặc qua công cụ gọi API như tìm kiếm web, tin tức, thời tiết. Huyen gọi đây là feature engineering của mô hình nền tảng: nó cấp cho mô hình thông tin cần thiết để tạo ra đầu ra.1

    Máy chỉ biết những gì nó từng học. Muốn nó trả lời đúng về công ty bạn, phải đưa tài liệu của công ty cho nó đọc ngay lúc hỏi — như đặt cuốn sổ tay lên bàn trước khi hỏi. Nhớ nhé: câu trả lời tốt thường bắt đầu từ tài liệu tốt, không phải từ mô hình xịn hơn.

    The first expansion is almost always giving the system a way to construct the context each query needs — through text, image or tabular retrieval, or through tools that gather information via APIs such as web search, news or weather. Huyen calls this the feature engineering of foundation models: it gives the model the information it needs to produce an output.1

    Thấy ở đâuWhere you see it Vì vai trò trung tâm của nó với chất lượng đầu ra, dựng bối cảnh được hầu hết nhà cung cấp API hỗ trợ sẵn: OpenAI, Claude và Gemini đều cho tải tệp lên và cho mô hình dùng công cụ.1 Mấy ứng dụng chat lớn đều có nút “đính kèm tệp” — đó chính là bước này. Because it is so central to output quality, context construction is near-universally supported by model API providers: OpenAI, Claude and Gemini all let users upload files and let their models use tools.1

    Khác biệt giữa các nhà cung cấp

    Họ khác nhau ở loại và số lượng tài liệu cho phép tải lên. Một giải pháp RAG chuyên dụng có thể nhận bao nhiêu tài liệu tùy sức chứa của cơ sở dữ liệu vector, còn một API mô hình phổ thông có thể chỉ cho vài tệp.1

    Khác biệt ở công cụ

    Các giải pháp cũng khác nhau ở loại công cụ hỗ trợ và chế độ thực thi — có cho gọi hàm song song không, có chạy được tác vụ dài không.1

  2. 02
    Input & output guardrails

    Guardrails — rào chắn hai đầuHàng rào chặn hai chiềuGuardrails — at both ends

    Rào chắn đặt ở bất cứ đâu có phơi nhiễm rủi ro, và chia thành hai nhóm. Rào chắn đầu vào chống hai loại rủi ro: rò rỉ thông tin riêng tư ra API bên ngoài, và các prompt độc hại tấn công hệ thống. Rào chắn đầu ra có hai việc: bắt các lỗi đầu ra, và quy định chính sách xử lý từng kiểu lỗi — lỗi chất lượng (định dạng sai, ảo giác, câu trả lời dở) và lỗi an toàn (độc hại, lộ thông tin nhạy cảm, kích hoạt thực thi mã từ xa, gây rủi ro thương hiệu).1

    Hãy tưởng tượng hai người gác cổng: một người đứng ở cửa vào, kiểm tra xem ta có lỡ đưa bí mật ra ngoài không; một người đứng ở cửa ra, kiểm tra xem máy có nói bậy không. Nhớ nhé: gác cổng hai chiều, vào cũng canh mà ra cũng canh.

    Guardrails belong wherever there is exposure to risk, and split in two. Input guardrails protect against two kinds: leaking private information to external APIs, and bad prompts that compromise your system. Output guardrails have two jobs: catch output failures, and specify the policy for handling each failure mode — quality failures (malformatted responses, hallucinations, generally bad answers) and security failures (toxicity, leaked sensitive data, triggered remote tool or code execution, brand risk).1

    Thấy ở đâuWhere you see it Rò rỉ không phải giả thuyết: Huyen dẫn trường hợp một nhân viên Samsung đưa thông tin độc quyền của công ty vào ChatGPT và vô tình làm lộ bí mật.1 Cách giảm thiểu quen thuộc là che thông tin nhạy cảm bằng chỗ giữ chỗ như [PHONE NUMBER], rồi dùng từ điển ngược để khôi phục khi trả lời.1 Có thật chuyện nhân viên dán bí mật công ty vào ô chat rồi lộ ra ngoài. Nên trước khi gửi đi, ta thay số điện thoại bằng một cái nhãn giả, lúc trả về mới đổi lại. The leak is not hypothetical: Huyen cites a Samsung employee who put the company's proprietary information into ChatGPT and accidentally leaked its secrets.1 The familiar mitigation is masking sensitive data with a placeholder such as [PHONE NUMBER] and using a reverse PII dictionary to unmask it in the response.1

    Đánh đổi: độ tin cậy và độ trễ

    Huyen kể có đội nói thẳng rằng độ trễ quan trọng hơn, nên họ quyết định không cài rào chắn vì nó làm ứng dụng chậm đi đáng kể — và bà ghi chú rằng ý tưởng ấy khiến vài độc giả bản thảo gặp ác mộng. Rào chắn đầu ra cũng khó hoạt động ở chế độ phát trực tiếp, vì khó đánh giá một câu trả lời còn dang dở.1

    Thử lại, song song, và con người

    Nhiều lỗi vá được bằng logic thử lại — nhưng mỗi lần thử lại là thêm một vòng gọi API, và nếu thử sau khi hỏng thì độ trễ người dùng cảm nhận sẽ gấp đôi; gọi song song rồi chọn câu tốt hơn giữ được độ trễ. Với ca khó, nhiều đội chuyển cho người thật: một đội chuyển khi mô hình phân tích cảm xúc phát hiện người dùng đang giận, một đội khác chuyển sau một số lượt nhất định.1

    Đừng quên tỉ lệ từ chối sai

    Với phép đo an toàn, phải theo dõi không chỉ lỗi an toàn mà cả false refusal rate: một hệ thống quá an toàn sẽ chặn cả yêu cầu chính đáng, làm gián đoạn công việc và gây bực bội.1

    Giải pháp dùng sẵn

    Huyen liệt kê Purple Llama của Meta, NeMo Guardrails của NVIDIA, PyRIT và bộ lọc nội dung AI của Azure, Perspective API, và API kiểm duyệt nội dung của OpenAI. Vì rủi ro ở đầu vào và đầu ra chồng lấn nhau, một giải pháp thường bảo vệ cả hai phía.1

  3. 03
    Model router & gateway

    Router và gateway — chia đường, gom cửaNgười chỉ đường và một cửa chungRouter and gateway — split the path, unify the door

    Thay vì dùng một mô hình cho mọi truy vấn, bộ định tuyến gửi mỗi loại truy vấn tới giải pháp phù hợp. Lợi ích kép: mô hình chuyên biệt thường làm tốt hơn mô hình đa dụng trên đúng mảng của nó, và truy vấn đơn giản có thể đẩy sang mô hình rẻ hơn. Bộ định tuyến thường gồm một bộ phân loại ý định dự đoán người dùng đang muốn gì.1 Cổng mô hình thì ngược lại: nó gom mọi mô hình — tự vận hành lẫn thương mại — về một giao diện thống nhất.

    Ở quầy tiếp tân có một người chỉ đường: nghe bạn hỏi gì rồi chỉ đúng phòng — hỏi về hóa đơn thì sang phòng kế toán, hỏi về máy hỏng thì sang phòng kỹ thuật. Còn cổng mô hình giống một cánh cửa chung: bên trong có nhiều phòng, nhưng ai cũng chỉ cần đi qua một cửa. Nhớ nhé: chỉ đúng đường thì vừa nhanh vừa rẻ.

    Instead of one model for every query, a router sends each type of query to the right solution. The benefit is double: specialised models can outperform a general-purpose one on their own slice, and simpler queries can go to cheaper models. A router typically consists of an intent classifier that predicts what the user is trying to do.1 A model gateway does the opposite: it gathers every model — self-hosted and commercial — behind one unified interface.

    Thấy ở đâuWhere you see it Huyen lấy ví dụ một chatbot hỗ trợ khách hàng: muốn đặt lại mật khẩu thì chỉ sang trang hỏi đáp, muốn sửa sai sót hóa đơn thì chuyển cho người thật, còn trục trặc kỹ thuật thì chuyển cho chatbot chuyên khắc phục sự cố.1 Chatbot của ngân hàng hay tổng đài đều có người chỉ đường như thế: câu nào máy trả lời được thì máy trả lời, câu nào khó thì chuyển cho người. Huyen's example is a customer support chatbot: password resets are routed to the FAQ page, billing corrections to a human operator, and technical troubleshooting to a chatbot specialised in it.1

    Bộ định tuyến phải nhỏ và rẻ

    Nhiều đội thích ứng các mô hình ngôn ngữ nhỏ như GPT-2, BERT hay Llama 7B làm bộ phân loại ý định; nhiều đội huấn luyện hẳn bộ phân loại nhỏ hơn từ đầu. Bộ định tuyến phải nhanh và rẻ để dùng nhiều cái mà không phát sinh độ trễ và chi phí đáng kể.1

    Không chỉ phân loại ý định

    Bộ định tuyến còn có thể là bộ dự đoán hành động kế tiếp cho tác tử — nên dùng trình thông dịch mã hay API tìm kiếm — hoặc quyết định lấy thông tin từ tầng nào trong hệ thống bộ nhớ. Huyen minh họa bằng một tài liệu đính kèm nhắc tới Melbourne: khi người dùng hỏi “con vật đáng yêu nhất ở Melbourne là gì”, mô hình phải quyết định dựa vào tài liệu hay tra internet.1

    Gateway làm được nhiều hơn là bọc API

    Vì mọi yêu cầu và phản hồi đã chảy qua nó, cổng mô hình là chỗ tốt để đặt kiểm soát truy cập, quản lý chi phí, chính sách dự phòng khi API chính hỏng hoặc chạm giới hạn tần suất, cân bằng tải, ghi nhật ký và phân tích — một số cổng còn cung cấp cả bộ nhớ đệm và rào chắn.1

    Cổng dùng sẵn

    Huyen kể tên AI Gateway của Portkey, MLflow AI Gateway, LLM Gateway của Wealthsimple, TrueFoundry, Kong và Cloudflare — vì cổng tương đối dễ dựng nên có sẵn khá nhiều.1

  4. 04
    Exact & semantic caching

    Bộ nhớ đệm — chính xác và ngữ nghĩaNhớ lại câu đã trả lờiCaches — exact and semantic

    Đệm chính xác chỉ dùng lại mục đã lưu khi đúng mục ấy được yêu cầu: hỏi tóm tắt một sản phẩm, hệ thống xem trong đệm đã có bản tóm tắt của đúng sản phẩm đó chưa. Đệm ngữ nghĩa nới lỏng điều kiện — dùng lại cả khi câu hỏi chỉ tương tự. Huyen minh họa: một người hỏi “thủ đô của Việt Nam là gì”, mô hình trả lời “Hà Nội”; người sau hỏi “thành phố thủ đô của Việt Nam là gì” — cùng ý, khác chữ — và hệ thống dùng lại câu trả lời cũ.1

    Nếu ai đó vừa hỏi một câu và ta đã trả lời, lần sau có người hỏi y hệt thì cứ lấy câu cũ ra dùng, khỏi nghĩ lại. Có loại đệm khó hơn: câu hỏi chỉ na ná cũng dùng lại. Nhớ nhé: nhớ lại thì nhanh và rẻ, nhưng nhớ nhầm thì trả lời sai.

    With exact caching, a cached item is reused only when that exact item is requested: ask for a product summary, and the system checks whether a summary of that exact product exists. Semantic caching loosens the condition — items are reused even when the query is merely similar. Huyen's example: one user asks “What's the capital of Vietnam?” and gets “Hanoi”; a later user asks “What's the capital city of Vietnam?” — the same question, different wording — and the system reuses the answer.1

    Thấy ở đâuWhere you see it Đệm đặc biệt hấp dẫn với truy vấn nhiều bước như chuỗi suy luận, hoặc các hành động tốn thời gian như truy xuất, chạy SQL, tìm kiếm web.1 Việc càng lâu — phải tra nhiều chỗ, chạy nhiều bước — thì nhớ lại càng đáng giá. Caching is especially appealing for multi-step queries such as chain-of-thought, and for time-consuming actions such as retrieval, SQL execution or web search.1

    Chính sách loại bỏ

    Đệm phải có chính sách loại bỏ để giữ kích thước và hiệu năng; thường dùng là LRU (ít dùng gần đây nhất), LFU (ít dùng nhất) và FIFO (vào trước ra trước). Truy vấn riêng của từng người — “đơn hàng gần nhất của tôi đến đâu rồi” — hay truy vấn nhạy thời gian như “thời tiết thế nào” thì không nên đệm; nhiều đội huấn luyện hẳn một bộ phân loại để đoán câu nào đáng đệm.1

    Đệm làm rò rỉ dữ liệu

    Huyen cảnh báo bằng một ví dụ thương mại điện tử: người X hỏi “chính sách đổi trả với đồ điện tử là gì” — câu nghe rất chung — nhưng chính sách lại phụ thuộc hạng thành viên, nên câu trả lời chứa thông tin của X. Hệ thống tưởng đây là câu chung và đệm lại; sau đó người Y hỏi y hệt và nhận về thông tin của X.1

    Vì sao đệm ngữ nghĩa đáng ngờ hơn

    Giá trị của nó bấp bênh vì nhiều bộ phận dễ hỏng: nó cần nhúng chất lượng cao, tìm kiếm vector hoạt động tốt và một thước đo tương đồng đáng tin. Đặt ngưỡng tương đồng cũng khó, phải thử đi thử lại; đặt sai thì hệ thống nhầm hai câu khác nhau là một và trả về câu sai.1

    Và nó không miễn phí

    Đệm ngữ nghĩa tốn thời gian và tính toán vì phải tìm kiếm vector; tốc độ và chi phí phụ thuộc kích thước tập nhúng đã đệm. Nó chỉ đáng khi tỉ lệ trúng đệm cao — và nên đánh giá rủi ro về hiệu quả, chi phí, chất lượng trước khi rước thêm phức tạp.1

  5. 05
    Agent patterns & write actions

    Vòng lặp tác tử và hành động ghiMáy tự làm thêm một vòngAgentic loops and write actions

    Tới đây mỗi truy vấn vẫn chạy tuần tự. Mẫu hình tác tử phá vỡ điều đó: sau khi sinh ra đầu ra, hệ thống có thể tự xác định rằng nó chưa hoàn thành nhiệm vụ và cần truy xuất thêm; câu trả lời cũ cùng bối cảnh mới được đưa lại vào chính mô hình đó hoặc một mô hình khác, tạo thành vòng lặp. Đầu ra cũng có thể kích hoạt hành động ghi: soạn email, đặt đơn hàng, khởi tạo một lệnh chuyển tiền.1

    Đến đây máy mới chỉ trả lời. Bước này cho nó quyền tự làm thêm vòng nữa nếu thấy chưa xong — và thậm chí quyền làm thật: gửi thư, đặt hàng, chuyển tiền. Nhớ nhé: cho máy quyền làm thật thì phải hết sức cẩn thận, vì nó sửa được cả thế giới bên ngoài.

    Until now each query has followed a sequential flow. Agentic patterns break that: after generating an output, the system may determine it has not accomplished the task and needs another retrieval; the original response plus the new context is passed back into the same model or a different one, creating a loop. Outputs can also invoke write actions: composing an email, placing an order, initialising a bank transfer.1

    Thấy ở đâuWhere you see it Hành động ghi cho phép hệ thống thay đổi trực tiếp môi trường của nó — điều này làm hệ thống mạnh hơn rất nhiều nhưng cũng phơi nó ra rủi ro lớn hơn nhiều; Huyen viết rằng trao quyền ấy cho mô hình phải làm với sự cẩn trọng tối đa.1 Trợ lý biết đặt vé, gửi thư thay bạn — tiện, nhưng nếu nó hiểu sai thì hậu quả là thật. Write actions let a system change its environment directly — which makes it vastly more capable but also exposes it to significantly more risk; Huyen writes that giving a model access to write actions should be done with the utmost care.1

    Cái giá của sự phức tạp

    Huyen chốt lại bước này bằng một nhận xét: nếu đã đi hết các bước, kiến trúc của bạn giờ hẳn đã khá phức tạp — hệ thống phức tạp giải được nhiều việc hơn nhưng cũng sinh thêm nhiều kiểu hỏng, khó gỡ lỗi hơn vì có quá nhiều điểm có thể hỏng.1

    Ranh giới giữa các thành phần là mềm

    Trong phần tổng kết, bà nhấn mạnh rằng tách thành phần là để giữ hệ thống mô-đun, nhưng ranh giới ấy linh động: rào chắn có thể nằm trong dịch vụ suy luận, trong cổng mô hình, hoặc đứng riêng thành một thành phần.1

Cụm 2 · Nhìn vào trongPhần 2 · Nhìn vào trongCluster 2 · Looking inside

Quan sát được, rồi mới sửa đượcNhìn được thì mới sửa đượcYou can only fix what you can see

Mục tiêu của giám sát, Huyen viết, giống hệt mục tiêu của đánh giá: giảm thiểu rủi ro và phát hiện cơ hội. Rủi ro cần chặn gồm lỗi ứng dụng, tấn công bảo mật và trôi lệch; cơ hội thì nằm ở cải thiện ứng dụng và tiết kiệm chi phí. Giám sát còn giữ ta có trách nhiệm, bằng cách làm hiệu năng hệ thống trở nên nhìn thấy được.1

Muốn sửa một cỗ máy, trước hết phải nhìn được nó đang làm gì bên trong. Phần này nói về cách gắn “đèn báo” và “sổ ghi chép” vào máy, để khi hỏng ta biết hỏng ở đâu. Nhớ nhé: cái gì không nhìn thấy thì không sửa được.

The goal of monitoring, Huyen writes, is the same as the goal of evaluation: mitigate risks and discover opportunities. The risks are application failures, security attacks and drifts; the opportunities are improvement and cost savings. Monitoring also keeps you accountable by giving visibility into your system's performance.1

Giám sát chỉ nhìn đầu ra bên ngoài. Khả năng quan sát đòi hỏi nhiều hơn: rằng trạng thái bên trong của hệ thống có thể suy ra được từ chính những đầu ra ấy.

Giám sát là nhìn máy từ bên ngoài. Quan sát là nhìn được cả bên trong mà không phải mở máy ra.

Monitoring only watches external outputs. Observability assumes something stronger: that a system's internal states can be inferred from those outputs.

Từ giữa thập niên 2010, ngành công nghiệp đã chuyển sang dùng từ “khả năng quan sát” thay cho “giám sát”. Trong sách này, Huyen dùng “giám sát” cho hành vi theo dõi thông tin của hệ thống, và “khả năng quan sát” cho toàn bộ quá trình gắn thiết bị đo, theo dõi và gỡ lỗi.1

MTTDMTTDKhi có chuyện xấu, mất bao lâu để phát hiện?When something bad happens, how long to detect it?
MTTRMTTRSau khi phát hiện, mất bao lâu để xử lý xong?After detection, how long to resolve it?
CFRCFRBao nhiêu phần trăm lần triển khai gây hỏng phải sửa hoặc quay lui?What share of deployments cause failures needing fixes or rollbacks?
Không biết CFRCFR unknownĐã đến lúc thiết kế lại nền tảng cho dễ quan sát hơnTime to redesign the platform to make it more observable
  1. 06
    Metrics designed around failures

    Chỉ số thiết kế quanh kiểu hỏngĐo cái gì, và vì sao đoMetrics designed around failure modes

    Huyen viết thẳng rằng bản thân chỉ số không phải mục tiêu: hầu như không công ty nào quan tâm điểm liên quan của đầu ra là bao nhiêu, trừ khi nó phục vụ một mục đích. Mục đích của một chỉ số là báo cho ta biết có gì đó sai, và chỉ ra cơ hội cải thiện. Vì thế thứ tự đúng là: xác định kiểu hỏng muốn bắt trước, rồi mới thiết kế chỉ số quanh những kiểu hỏng ấy.1

    Đừng đo bừa. Trước hết hãy hỏi: mình sợ máy hỏng kiểu gì nhất? Sợ nó bịa chuyện thì đo xem câu trả lời có bám vào tài liệu không. Sợ tốn tiền thì đo số chữ mỗi lần hỏi. Nhớ nhé: cứ hỏi “mình sợ gì” trước, rồi mới nghĩ cách đo.

    Metrics are not the goal, Huyen writes bluntly: almost no company cares what your output relevancy score is unless it serves a purpose. A metric's purpose is to tell you when something is wrong and to identify opportunities. So the right order is: understand the failure modes you want to catch first, then design metrics around them.1

    Thấy ở đâuWhere you see it Dễ theo dõi nhất là lỗi định dạng, vì dễ nhận ra và dễ kiểm chứng: nếu mong đợi JSON, hãy đếm xem mô hình sinh JSON không hợp lệ bao nhiêu lần, và trong số đó bao nhiêu dễ vá — thiếu dấu ngoặc đóng thì dễ, thiếu khóa mong đợi thì khó.1 Lỗi dễ bắt nhất là lỗi hình thức — máy phải trả về đúng khuôn mà lại trả sai khuôn. Cái đó đếm được ngay. The easiest failures to track are format failures, because they are easy to notice and verify: if you expect JSON, track how often the model outputs invalid JSON and how much of it is easily fixable — a missing closing bracket is easy, a missing expected key is harder.1

    Chỉ số suy ra từ hành vi

    Chất lượng mô hình còn suy ra được từ tín hiệu hội thoại: bao nhiêu lần người dùng dừng sinh giữa chừng, trung bình một cuộc hội thoại mấy lượt, trung bình mỗi đầu vào bao nhiêu token — người dùng đang giao việc phức tạp hơn hay đang học cách viết prompt ngắn gọn hơn — và phân bố token đầu ra thay đổi thế nào theo thời gian.1

    Độ trễ và chi phí

    Các chỉ số độ trễ quen thuộc từ Chương 9 vẫn được dùng: TTFT (thời gian tới token đầu tiên), TPOT (thời gian mỗi token đầu ra) và tổng độ trễ — nên theo dõi theo từng người dùng để biết hệ thống co giãn ra sao. Chỉ số chi phí gồm số truy vấn và khối lượng token vào/ra; nếu API có giới hạn tần suất thì phải theo dõi số yêu cầu mỗi giây.1

    Tương quan với ngôi sao Bắc Đẩu

    Khi đã có nhiều chỉ số, nên đo xem chúng tương quan với nhau và với chỉ số ngôi sao Bắc Đẩu của doanh nghiệp ra sao — DAU, thời lượng phiên, hay số thuê bao. Chỉ số tương quan mạnh gợi ý cách cải thiện; chỉ số không tương quan chút nào cũng hữu ích, vì nó gợi ý thứ không nên tối ưu.1

    Kiểm điểm hay kiểm toàn bộ

    Có thể chọn kiểm mẫu — lấy một tập con để phát hiện nhanh vấn đề — hoặc kiểm toàn bộ mọi yêu cầu để có bức tranh đầy đủ; kết hợp cả hai thường là chiến lược cân bằng. Và chỉ số phải tách được theo các trục liên quan: người dùng, bản phát hành, phiên bản prompt hoặc chuỗi, loại prompt, và thời gian.1

  2. 07
    Logs and traces

    Nhật ký và vết truy vấnSổ ghi chép và đường điLogs and traces

    Chỉ số là số liệu tổng hợp; chúng cô đặc thông tin từ các sự kiện và cho ta thấy tình hình trong một cái liếc. Nhưng có những câu hỏi chúng không trả lời được. Nhật ký thì ngược lại: một bản ghi chỉ-thêm về các sự kiện. Quy trình gỡ lỗi điển hình là chỉ số báo có chuyện xấu năm phút trước, ta mở nhật ký quanh thời điểm ấy để biết chuyện gì, rồi đối chiếu lỗi trong nhật ký với chỉ số để chắc đã nhận diện đúng vấn đề.1

    Đèn báo trên máy chỉ nói “có gì đó sai”. Muốn biết sai gì thì phải mở sổ ghi chép ra đọc. Còn “vết” là cả đường đi của một câu hỏi qua từng phòng trong nhà máy. Nhớ nhé: ghi lại mọi thứ, vì hôm nay ta chưa biết mai mình sẽ cần đọc gì.

    Metrics are aggregated; they condense events and show you at a glance how the system is doing. But there are questions they cannot answer. Logs are the opposite: an append-only record of events. The typical debugging flow is that metrics tell you something went wrong five minutes ago, you read the logs from around then to find out what happened, then correlate the errors with the metrics to confirm you identified the right issue.1

    Thấy ở đâuWhere you see it Vết truy vấn cho thấy toàn bộ quá trình từ lúc người dùng gửi câu hỏi tới lúc nhận câu trả lời: hệ thống đã làm gì, lấy về tài liệu nào, gửi prompt cuối cùng nào cho mô hình, mỗi bước mất bao lâu và tốn bao nhiêu. Huyen minh họa bằng một vết được LangSmith trực quan hóa.1 Nhiều công cụ vẽ được cả hành trình của một câu hỏi, từng chặng mất mấy giây — nhìn vào là biết tắc ở đâu. A trace shows the whole process from a user's query to the final response: what actions the system took, which documents it retrieved, the final prompt sent to the model, and how long and how much each step cost. Huyen illustrates it with a request trace visualised in LangSmith.1

    Quy tắc: ghi hết

    Vì không thể biết trước mai sẽ cần đọc nhật ký nào, quy tắc chung là ghi mọi thứ: toàn bộ cấu hình (điểm cuối API, tên mô hình, thiết lập lấy mẫu như nhiệt độ, top-p, top-k, điều kiện dừng, mẫu prompt), truy vấn người dùng, prompt cuối cùng, đầu ra và các đầu ra trung gian, việc gọi công cụ và kết quả công cụ, cùng thời điểm một thành phần bắt đầu, kết thúc hay sập — kèm thẻ và mã định danh để biết nhật ký đến từ đâu.1

    Đọc dữ liệu sản xuất bằng mắt

    Dù không thể xử lý nhật ký thủ công, Huyen khuyên vẫn nên tự xem dữ liệu sản xuất hằng ngày. Shankar và cộng sự (2024) phát hiện rằng cảm nhận của lập trình viên về thế nào là đầu ra tốt hay xấu thay đổi khi họ tiếp xúc nhiều dữ liệu hơn — cho phép họ vừa viết lại prompt để tăng cơ hội có câu trả lời tốt, vừa cập nhật quy trình đánh giá để bắt được câu xấu.15

  3. 08
    Drift detection

    Phát hiện trôi — ba thứ tự đổiBa thứ đổi mà ta không hayDrift detection — three things that change

    Hệ thống càng nhiều bộ phận thì càng nhiều thứ có thể đổi. Huyen kể ba thứ. Một là prompt hệ thống: nó có thể dựng trên một mẫu prompt và mẫu ấy được cập nhật, hoặc một đồng nghiệp thấy lỗi chính tả rồi sửa — một logic đơn giản đủ để bắt được thay đổi này. Hai là hành vi người dùng. Ba là chính mô hình bên dưới.1

    Có ba thứ âm thầm đổi mà ta không để ý: lời dặn ta viết cho máy, thói quen của người dùng, và chính cái máy ở phía nhà cung cấp. Nhớ nhé: máy hôm nay trả lời khác hôm qua, chưa chắc tại bạn.

    The more parts a system has, the more things can change. Huyen names three. First, the system prompt: it may have been built on a prompt template that was updated, or a coworker may have fixed a typo — simple logic is enough to catch this. Second, user behaviour. Third, the underlying model itself.1

    Thấy ở đâuWhere you see it Khi dùng mô hình qua API, API có thể giữ nguyên trong khi mô hình bên dưới được cập nhật — và nhà cung cấp không phải lúc nào cũng công bố. Chen và cộng sự (2023) ghi nhận khác biệt đáng kể về điểm chuẩn giữa phiên bản tháng 3 và tháng 6 năm 2023 của GPT-4 và GPT-3.5; Voiceflow báo cáo hiệu năng giảm 10% khi chuyển từ GPT-3.5-turbo-0301 cũ sang GPT-3.5-turbo-1106 mới.14 Cùng một cái nút bấm, nhưng cái máy phía sau có thể đã được thay mà không ai báo — và kết quả khác đi. When using a model through an API, the API can stay the same while the underlying model is updated — and providers do not always disclose it. Chen et al. (2023) observed notable benchmark differences between the March 2023 and June 2023 versions of GPT-4 and GPT-3.5; Voiceflow reported a 10% performance drop moving from the older GPT-3.5-turbo-0301 to the newer GPT-3.5-turbo-1106.14

    Người dùng thích nghi với công nghệ

    Theo thời gian, người dùng đổi hành vi để lấy kết quả tốt hơn — như người ta đã học cách đặt câu hỏi trên Google Search, hay cách viết bài để lên hạng tìm kiếm. Huyen còn dẫn một ví dụ lạ: dân sống ở vùng có xe tự lái đã học được cách “bắt nạt” xe tự lái để giành quyền đi trước (Liu và cộng sự, 2020).1

    Vì sao chỉ nhìn chỉ số là không đủ

    Nếu người dùng học cách yêu cầu câu trả lời ngắn gọn hơn, độ dài phản hồi sẽ giảm dần theo thời gian. Nhìn riêng chỉ số thì không rõ vì sao — phải điều tra mới hiểu nguyên nhân gốc.1

  4. 09
    AI pipeline orchestration

    Điều phối — định nghĩa và xâu chuỗiNgười nhạc trưởng của cỗ máyOrchestration — define, then chain

    Bộ điều phối cho ta chỉ định các thành phần làm việc với nhau thế nào để thành một đường ống đầu-cuối, và bảo đảm dữ liệu chảy trơn tru giữa chúng. Ở mức cao nó làm hai việc: định nghĩa thành phần — khai báo các mô hình, nguồn dữ liệu truy xuất, công cụ, và cả công cụ đánh giá, giám sát nếu có — và xâu chuỗi, về bản chất là hợp thành hàm: ta nói cho nó các bước hệ thống đi từ lúc nhận truy vấn tới lúc xong việc.1

    Khi trong nhà máy có nhiều phòng, cần một người nhạc trưởng nói rõ: câu hỏi vào thì đi phòng nào trước, rồi phòng nào sau, và ai đưa gì cho ai. Nhớ nhé: lúc mới bắt đầu, đừng vội thuê nhạc trưởng — hãy tự xếp trước cho hiểu máy mình.

    An orchestrator lets you specify how components work together into an end-to-end pipeline and ensures data flows between them. At a high level it does two things: components definition — telling it which models, retrieval data sources and tools your system uses, plus any evaluation and monitoring tools — and chaining, which is essentially function composition: you tell it the steps your system takes from receiving the query to completing the task.1

    Thấy ở đâuWhere you see it Huyen kể tên LangChain, LlamaIndex, Flowise, Langflow và Haystack; vì truy xuất và dùng công cụ là mẫu hình phổ biến, nhiều khung RAG và tác tử cũng chính là công cụ điều phối. Bà lưu ý riêng: bộ điều phối đường ống AI khác với bộ điều phối luồng công việc tổng quát như Airflow hay Metaflow.1 Có sẵn nhiều bộ khung làm việc này — nhưng chúng khác với mấy công cụ lập lịch công việc thông thường. Huyen names LangChain, LlamaIndex, Flowise, Langflow and Haystack; because retrieval and tool use are common patterns, many RAG and agent frameworks are orchestration tools too. She flags separately that an AI pipeline orchestrator is different from a general workflow orchestrator like Airflow or Metaflow.1

    Vì sao nên bắt đầu mà không có nó

    Huyen khuyên đừng nhảy ngay vào một công cụ điều phối khi khởi động dự án: mọi công cụ ngoài đều mang thêm phức tạp, và bộ điều phối có thể che mất những chi tiết then chốt về cách hệ thống hoạt động, khiến nó khó hiểu và khó gỡ lỗi.1

    Ba tiêu chí khi chọn

    Tích hợp và khả năng mở rộng (nó có hỗ trợ thành phần bạn đang dùng hoặc sẽ dùng không, và nếu không thì sửa khó tới đâu); hỗ trợ đường ống phức tạp (rẽ nhánh, xử lý song song, xử lý lỗi); và tính dễ dùng, hiệu năng, khả năng mở rộng quy mô — tránh những bộ điều phối tự ý gọi API ngầm hoặc thêm độ trễ.1

    Song song hóa khi cần độ trễ thấp

    Với ứng dụng có yêu cầu độ trễ khắt khe, hãy làm song song nhiều nhất có thể. Ví dụ của Huyen: thành phần định tuyến (quyết định gửi truy vấn đi đâu) và thành phần loại bỏ PII có thể chạy cùng lúc.1

    Đánh giá và giám sát phải đi đôi

    CFR cao không nhất thiết có nghĩa hệ thống giám sát tệ, nhưng nên xem lại quy trình đánh giá để bắt được thay đổi xấu trước khi triển khai. Chỉ số đánh giá phải chuyển hóa tốt thành chỉ số giám sát, và vấn đề phát hiện lúc giám sát phải được đưa ngược về quy trình đánh giá.1

Cụm 3 · Vòng phản hồiPhần 3 · Người dùng nói gìCluster 3 · The feedback loop

Phản hồi người dùng là dữ liệu riêngNgười dùng dạy máy mà không biếtUser feedback is proprietary data

Phản hồi người dùng xưa nay luôn giữ hai vai trò trong phần mềm: đánh giá hiệu năng và định hướng phát triển. Với ứng dụng AI, nó còn thêm một vai trò lớn hơn — nó là dữ liệu riêng, và dữ liệu là lợi thế cạnh tranh. Một hệ thống phản hồi được thiết kế tốt là điều kiện cần để tạo ra bánh đà dữ liệu đã bàn ở Chương 8: sản phẩm ra mắt sớm, hút người dùng sớm, thu dữ liệu để liên tục cải thiện mô hình, khiến đối thủ khó đuổi kịp.1

Mỗi lần bạn bấm “thích”, sửa lại câu máy viết, hay hỏi lại vì máy hiểu sai — bạn đang dạy nó. Cái kho “người dùng đã dạy gì” ấy là của riêng công ty, đối thủ không mua được. Nhớ nhé: người dùng là thầy giáo mà không ai trả lương.

User feedback has always played two roles in software: evaluating performance and informing development. In AI applications it takes on a bigger one — it is proprietary data, and data is a competitive advantage. A well-designed feedback system is necessary to create the data flywheel of Chapter 8: a product that launches quickly and attracts users early gathers the data to keep improving its models, making it hard for competitors to catch up.1

Giao diện hội thoại khiến người dùng dễ đưa phản hồi hơn — và khiến người làm sản phẩm khó rút ra tín hiệu hơn.

Nói chuyện thì dễ góp ý, nhưng góp ý lẫn trong câu chuyện thì khó nhặt ra.

The conversational interface makes it easier for users to give feedback and harder for developers to extract signals.

Huyen nhắc rằng phản hồi người dùng là dữ liệu người dùng: khai thác nó đòi hỏi đúng những thận trọng như với mọi dữ liệu khác. Quyền riêng tư phải được tôn trọng, và người dùng có quyền biết dữ liệu của họ đang được dùng thế nào.1

Tường minhExplicitThích/không thích, sao, “chúng tôi đã giải quyết được vấn đề chưa?”Thumbs up/down, star ratings, “Did we solve your problem?”
NgầmImplicitSuy ra từ hành động: mua, sửa, dừng, hỏi lạiInferred from actions: buying, editing, stopping, rephrasing
Dùng để làm gìUsed forĐánh giá · phát triển · cá nhân hóaEvaluation · development · personalisation
Cảnh giácCautionThiên lệch, và vòng lặp phản hồi thoái hóaBiases, and degenerate feedback loops
  1. 10
    Explicit vs implicit feedback

    Tường minh và ngầm — hai loại tín hiệuNói thẳng và nói bằng hành độngExplicit and implicit — two kinds of signal

    Phản hồi tường minh là thông tin người dùng cung cấp khi ứng dụng hỏi thẳng. Nó khá chuẩn hóa giữa các ứng dụng — có bao nhiêu cách để hỏi một người rằng họ có thích thứ gì đó đâu — nên nó được hiểu rõ hơn. Phản hồi ngầm thì suy ra từ hành động, và phụ thuộc hoàn toàn vào việc ứng dụng cho người dùng làm được gì; mô hình nền tảng mở ra cả một thế giới ứng dụng mới, kéo theo nhiều thể loại phản hồi ngầm mới.1

    Có hai cách người ta khen chê. Một là nói thẳng: bấm nút thích hay không thích. Hai là nói bằng việc làm: mua món được gợi ý, sửa lại câu máy viết, hoặc bỏ đi giữa chừng. Nhớ nhé: việc làm nói nhiều hơn lời nói, nhưng cũng khó hiểu hơn.

    Explicit feedback is what users provide when the application asks. It is fairly standard across applications — there are only so many ways to ask someone whether they like something — so it is better understood. Implicit feedback is inferred from actions, and depends entirely on what a user can do inside the application; foundation models enable a new world of applications and, with them, many new genres of implicit feedback.1

    Thấy ở đâuWhere you see it Huyen minh họa bằng một trợ lý lên kế hoạch du lịch: nó gợi ý ba khách sạn ở Sydney, và chính cách bạn đáp lại đã hé lộ sở thích. “Đặt cho tôi cái gần phòng tranh” cho thấy bạn quan tâm nghệ thuật; “Không có cái nào dưới 200 đô à?” cho thấy bạn nhạy giá — và rằng trợ lý chưa hiểu bạn lắm.1 Trợ lý gợi ý ba khách sạn. Bạn chọn cái gần bảo tàng, hay hỏi “có cái nào rẻ hơn không” — chỉ một câu ấy thôi, nó đã biết bạn thích gì. Huyen's illustration is a trip-planning assistant: it suggests three hotels in Sydney, and how you reply reveals your preference. “Yes book me the one close to galleries” shows an interest in art; “Is there nothing under $200?” reveals a price-conscious user — and that the assistant doesn't quite get you yet.1

    Ưu và nhược của từng loại

    Tường minh dễ diễn giải nhưng đòi thêm công sức từ người dùng, nên thường thưa thớt — nhất là với ứng dụng ít người dùng — và chịu thiên lệch phản hồi: người không hài lòng dễ lên tiếng hơn, làm bức tranh trông tiêu cực hơn thực tế. Ngầm thì dồi dào — “giới hạn duy nhất là trí tưởng tượng của bạn” — nhưng nhiễu.1

    Vì sao tín hiệu ngầm khó đọc

    Chia sẻ một cuộc hội thoại có thể là khen hoặc chê. Huyen kể một người bạn của bà chủ yếu chia sẻ khi mô hình phạm lỗi lộ liễu, còn một người bạn khác chủ yếu chia sẻ những hội thoại hữu ích cho đồng nghiệp — phải nghiên cứu người dùng của chính mình mới hiểu vì sao họ làm mỗi hành động. Thêm tín hiệu có thể làm rõ ý định: nếu người dùng diễn đạt lại câu hỏi sau khi chia sẻ một liên kết, có lẽ cuộc hội thoại đã không như họ mong.1

    Ba mục đích sử dụng

    Phản hồi rút ra từ hội thoại dùng cho ba việc: đánh giá (rút ra chỉ số để giám sát ứng dụng), phát triển (huấn luyện mô hình tương lai hoặc dẫn hướng phát triển chúng), và cá nhân hóa (làm ứng dụng hợp với từng người).1

    Không phải chủ đề mới

    Huyen ghi rằng phản hồi hội thoại được chú ý nhiều nhờ chatbot, nhưng nó đã là hướng nghiên cứu tích cực nhiều năm trước ChatGPT — cộng đồng học tăng cường đã thử cho thuật toán học từ phản hồi ngôn ngữ tự nhiên từ cuối thập niên 2010, và nó cũng được quan tâm ở các ứng dụng hội thoại sớm như Amazon Alexa, tính năng điều khiển giọng nói của Spotify và Yahoo! Voice.1

  2. 11
    Natural language feedback

    Phản hồi ngôn ngữ tự nhiênGóp ý giấu trong câu nóiNatural language feedback

    Phản hồi rút ra từ nội dung tin nhắn được gọi là phản hồi ngôn ngữ tự nhiên, và Huyen liệt kê vài tín hiệu đáng theo dõi trong sản xuất. Dừng sớm: người dùng ngắt giữa chừng, thoát ứng dụng, bảo mô hình dừng, hay đơn giản là bỏ mặc tác tử đang chờ — nhiều khả năng cuộc hội thoại không ổn. Sửa lỗi: nếu câu tiếp theo bắt đầu bằng “Không, …” hay “Ý tôi là …”, câu trả lời có lẽ đã trật.1

    Khi máy trả lời trật, ta ít khi bấm nút chê — ta chỉ nói “Không, ý tôi là…” rồi hỏi lại. Chính câu ấy là lời chê. Nhớ nhé: lời chê thật thường nấp trong câu nói tiếp theo, không nằm ở nút bấm.

    Feedback extracted from the content of messages is called natural language feedback, and Huyen lists signals worth tracking in production. Early termination: the user stops a generation halfway, exits the app, tells the model to stop, or simply leaves the agent hanging — the conversation likely isn't going well. Error correction: if a follow-up starts with “No, …” or “I meant, …”, the response was probably off the mark.1

    Thấy ở đâuWhere you see it Khi người dùng tự sửa câu trả lời — ví dụ sửa lại đoạn mã mô hình vừa sinh — đó là tín hiệu rất mạnh rằng phần bị sửa chưa đúng. Mỗi lần sửa còn là một mẫu dữ liệu ưu tiên: câu gốc là bản thua, câu đã sửa là bản thắng.1 Bạn sửa lại đoạn mã máy viết — đó là cách chê rõ ràng nhất, và cũng là bài học tốt nhất cho nó. When a user edits a response directly — correcting generated code, say — that is a very strong signal that the edited part wasn't right. Each edit is also a preference example: the original is the losing response, the edit is the winning one.1

    Tám nhóm than phiền

    Huyen dẫn Bảng 10-1: tám nhóm phản hồi ngôn ngữ tự nhiên thu được từ phân cụm tự động bộ dữ liệu FITS (Xu và cộng sự, 2022), kết quả từ Yuan và cộng sự (2023). Nhóm lớn nhất là “làm rõ lại yêu cầu” với 3.702 mẫu (26,54%); kế đó là than phiền rằng bot không trả lời câu hỏi, đưa thông tin không liên quan, hoặc bảo người dùng tự đi tìm — 2.260 mẫu (16,20%). Nhóm nhỏ nhất, than phiền bot lặp lại hoặc thô lỗ, chỉ 137 mẫu (0,99%).167

    Hiểu kiểu hỏng để vá đúng chỗ

    Biết bot hỏng kiểu gì là chìa khóa để làm nó tốt lên: nếu người dùng không thích câu dài dòng, đổi prompt cho bot cô đọng hơn; nếu họ không hài lòng vì câu thiếu chi tiết, nhắc bot cụ thể hơn.1

    Cảm xúc và tỉ lệ từ chối

    Than phiền cũng có thể chỉ là biểu lộ cảm xúc tiêu cực không nêu lý do — kiểu “Ugh”. Một số tổng đài theo dõi giọng người gọi suốt cuộc: nếu càng lúc càng to tiếng thì có chuyện; ngược lại, bắt đầu giận mà kết thúc vui thì có lẽ vấn đề đã được giải quyết. Phản hồi còn suy ra được từ chính câu của mô hình: tỉ lệ từ chối cao — “Xin lỗi, tôi không biết điều đó” — thường đi kèm người dùng không hài lòng.1

    Tín hiệu từ hành động, không phải lời

    Sinh lại có thể vì không hài lòng, nhưng cũng có thể vì muốn có lựa chọn để so — và Huyen nói bà hay sinh lại với yêu cầu phức tạp để kiểm tra tính nhất quán: nếu hai câu trả lời mâu thuẫn nhau thì bà không tin câu nào. Việc tổ chức hội thoại cũng là tín hiệu: xóa là chê khá mạnh, còn đổi tên lại gợi ý rằng hội thoại tốt nhưng tiêu đề tự sinh thì dở. Độ dài hội thoại thì tùy ứng dụng — với bạn đồng hành AI, dài là thích; với bot hỗ trợ khách hàng, dài có thể là kém hiệu quả — và nên đọc cùng độ đa dạng lời thoại, vì hội thoại dài mà bot cứ lặp vài câu nghĩa là người dùng đang mắc kẹt trong vòng lặp.1

  3. 12
    Feedback design

    Thiết kế phản hồi — khi nào và bằng cách nàoHỏi lúc nào, hỏi thế nàoFeedback design — when and how

    Phản hồi nên được thu suốt hành trình người dùng, nhưng phải không xâm phạm và không cản trở luồng làm việc. Huyen nêu ba thời điểm đặc biệt đáng giá: lúc mới bắt đầu, để hiệu chỉnh ứng dụng cho người mới đăng ký; khi có chuyện xấu, để người dùng báo lỗi; và khi mô hình thiếu tự tin, để hỏi người dùng nhằm tăng độ chắc chắn.1

    Hỏi ý kiến cũng phải đúng lúc: lúc mới làm quen, lúc máy làm sai, và lúc máy phân vân giữa hai cách. Hỏi đúng lúc thì người ta vui lòng trả lời. Nhớ nhé: đừng bắt người dùng làm thêm việc chỉ để khen chê.

    Feedback should be collected throughout the user journey, but nonintrusively and without interfering with the workflow. Huyen names three especially valuable moments: in the beginning, to calibrate the application for a new user; when something bad happens, so users can report failures; and when the model has low confidence, so asking the user raises its certainty.1

    Thấy ở đâuWhere you see it Huyen coi Midjourney là ví dụ hay được nhắc tới về thiết kế phản hồi tốt: mỗi prompt sinh ra bốn ảnh, và người dùng có ba lựa chọn — phóng to một ảnh, sinh biến thể từ một ảnh, hoặc sinh lại. Lựa chọn 1 là tín hiệu tích cực mạnh nhất về ảnh được chọn, lựa chọn 2 yếu hơn, lựa chọn 3 báo rằng không ảnh nào đủ tốt.1 Midjourney đưa bốn bức ảnh và ba nút bấm. Bạn bấm nút nào cũng là đang chấm điểm cho nó mà không hay. Huyen cites Midjourney as a frequently praised example of good feedback design: each prompt generates a set of four images, with three options — upscale one, generate variations of one, or regenerate. Option 1 is the strongest positive signal about the chosen image, option 2 a weaker one, option 3 says none was good enough.1

    Khi sản phẩm sai, người dùng vẫn phải xong việc

    Lý tưởng là khi mô hình sai, người dùng vẫn hoàn thành được việc của họ: phân loại sai thì cho họ sửa nhãn. Hãy để người dùng cộng tác với AI; nếu không được thì để họ cộng tác với người. Ví dụ đẹp của cộng tác người–AI là tính năng vẽ đè (inpainting) trong sinh ảnh — chọn một vùng ảnh và mô tả cách sửa — vừa cho người dùng kết quả tốt hơn vừa cho lập trình viên phản hồi chất lượng cao.1

    So sánh cạnh nhau: đầy đủ hay một phần?

    Khi mô hình phân vân giữa bản tóm tắt ngắn và bản chi tiết, nó có thể đưa cả hai ra cạnh nhau cho người dùng chọn — tín hiệu so sánh ấy dùng được cho tinh chỉnh theo ưu tiên. Nhưng bày hai câu trả lời đầy đủ là đòi hỏi phản hồi tường minh, mà người dùng có thể không có thời gian đọc hết, dẫn tới phiếu nhiễu. Google Gemini chỉ bày phần đầu mỗi câu và để người dùng bấm mở cái họ muốn đọc; Huyen ghi rõ rằng chưa rõ cách nào cho phản hồi đáng tin hơn.1

    Có nên hỏi cả khi mọi thứ tốt?

    Hướng dẫn giao diện người dùng của Apple cảnh báo không nên hỏi cả phản hồi tích cực lẫn tiêu cực: ứng dụng vốn phải cho kết quả tốt, hỏi về kết quả tốt có thể khiến người dùng nghĩ rằng kết quả tốt là ngoại lệ. Nhưng nhiều người Huyen trò chuyện lại nghĩ ngược lại — một quản lý sản phẩm nói đội của họ cần phản hồi tích cực vì nó chỉ ra đúng những tính năng người dùng yêu thích, để đội tập trung mài giũa một nhóm nhỏ thay vì dàn trải. Rủi ro làm rối giao diện có thể quản lý bằng cách hạn chế tần suất: với tập người dùng lớn, chỉ hiện lời mời cho 1% người dùng mỗi lần cũng đủ dữ liệu.1

    Đừng bắt người ta làm điều bất khả

    Huyen kể bà từng chưng hửng khi ChatGPT bắt chọn giữa hai câu trả lời cho một câu hỏi thống kê — với câu hỏi toán, đáp án đúng đâu phải chuyện sở thích, và bà ước có nút “Tôi không biết”. Thiết kế mập mờ cũng sinh phản hồi nhiễu: khi bà tổ chức một buổi tập huấn tối ưu GPU và dùng Luma để thu phản hồi, bà thấy nhiều đánh giá 1/5 kèm lời khen — hóa ra Luma đặt biểu tượng mặt giận, tương ứng một sao, vào đúng chỗ đáng lẽ là năm sao.1

    Công khai hay riêng tư

    Độ hiển thị của một tín hiệu ảnh hưởng sâu tới hành vi, trải nghiệm và chất lượng phản hồi. Người ta thẳng thắn hơn khi riêng tư, nên tín hiệu thường chất lượng hơn: năm 2024, X (trước là Twitter) chuyển lượt “thích” thành riêng tư, và Elon Musk — chủ sở hữu X — tuyên bố số lượt thích tăng đáng kể sau thay đổi ấy. Nhưng tín hiệu riêng tư làm giảm khả năng khám phá và giải thích: giấu lượt thích thì người dùng không tìm được bài mà bạn bè đã thích, và có thể bối rối vì sao bài nọ hiện trên bảng tin.1

    Bối cảnh quanh phản hồi, và sự đồng ý

    Chỉ riêng con số thích/không thích đã hữu ích cho phân tích sản phẩm, nhưng muốn phân tích sâu thì cần bối cảnh — chẳng hạn 5 tới 10 lượt hội thoại trước đó — mà bối cảnh ấy có thể chứa thông tin định danh cá nhân, nên không lấy được nếu không có sự đồng ý rõ ràng. Vì thế một số sản phẩm đưa điều khoản cho phép dùng dữ liệu để phân tích và cải thiện, hoặc gắn phản hồi với một luồng “hiến tặng dữ liệu”: khi gửi góp ý, người dùng tích một ô để chia sẻ dữ liệu tương tác gần đây làm bối cảnh.1

  4. 13
    Feedback limitations

    Giới hạn — thiên lệch và vòng lặp thoái hóaNghe theo người dùng cũng có thể hỏngLimitations — biases and degenerate loops

    Phản hồi không phải bữa trưa miễn phí. Giống mọi dữ liệu khác, nó có thiên lệch — và mỗi ứng dụng có thiên lệch riêng. Huyen nêu bốn nhóm: thiên lệch khoan dung (chấm cao hơn mức đáng, để tránh va chạm hoặc vì đó là lựa chọn dễ nhất), tính ngẫu nhiên (chọn bừa vì thiếu động lực đọc kỹ), thiên lệch vị trí (dễ bấm vào gợi ý đầu tiên hơn), và thiên lệch ưu tiên (thích câu dài hơn dù kém chính xác hơn; hoặc thiên lệch gần đây, thiên về câu nhìn thấy sau cùng).1

    Người ta hay chấm điểm dễ dãi, hay bấm bừa, hay chọn cái nằm trên đầu, hay thích câu dài. Nên đừng tin phản hồi một cách mù quáng. Nhớ nhé: nghe người dùng thì tốt, nhưng nghe mà không suy nghĩ thì hỏng sản phẩm.

    Feedback isn't a free lunch. Like any data it carries biases, and each application has its own. Huyen names four: leniency bias (rating more positively than warranted, to avoid conflict or because it is easiest), randomness (clicking at random for lack of motivation), position bias (users are more likely to click the first suggestion), and preference bias (preferring the longer response even when it is less accurate; or recency bias, favouring the answer seen last).1

    Thấy ở đâuWhere you see it Trên thang năm sao, bốn và năm sao đáng lẽ đều nghĩa là trải nghiệm tốt, nhưng người dùng thường thấy sức ép phải cho năm sao, để dành bốn sao cho lúc có chuyện. Theo Uber, năm 2015 điểm trung bình của tài xế là 4,8, và dưới 4,6 thì tài xế có nguy cơ bị ngừng hoạt động.1 Đi xe công nghệ, ai cũng cho 5 sao cho xong — nên 4 sao lại thành điểm xấu. Thang điểm bị lệch cả cụm như thế. On a five-star scale, four and five stars should both mean a good experience, but users often feel pressured to give five, reserving four for when something goes wrong. According to Uber, in 2015 the average driver rating was 4.8, with scores below 4.6 putting drivers at risk of deactivation.1

    Thiên lệch không nhất thiết là dấu chấm hết

    Mục tiêu của Uber là phân biệt tài xế tốt với tài xế kém, và ngay cả với thiên lệch ấy, hệ thống đánh giá của họ vẫn có vẻ đạt mục tiêu. Điều thiết yếu là nhìn vào phân bố điểm để phát hiện thiên lệch. Muốn phản hồi mịn hơn, có thể gỡ bỏ hàm ý tiêu cực nặng nề của điểm thấp — thay vì hiện số 1 tới 5, hiện các câu như “Chuyến đi tuyệt, tài xế tuyệt”, “Khá ổn”, “Không có gì để phàn nàn nhưng cũng không có gì xuất sắc”, “Đáng lẽ có thể tốt hơn”, “Đừng ghép tôi với tài xế này nữa”.1

    Vòng lặp phản hồi thoái hóa

    Phản hồi là không đầy đủ: ta chỉ nhận được phản hồi về những gì ta đã bày ra cho người dùng thấy. Khi phản hồi được dùng để đổi hành vi mô hình, vòng lặp thoái hóa có thể xuất hiện — dự đoán ảnh hưởng tới phản hồi, phản hồi ảnh hưởng tới vòng huấn luyện sau, khuếch đại thiên lệch ban đầu. Huyen minh họa bằng hệ gợi ý video: video A xếp trên B chỉ vì chênh lệch nhỏ ban đầu, nên được bấm nhiều hơn, nên càng được đẩy lên — vấn đề này được biết tới với các tên “thiên lệch phơi bày”, “thiên lệch phổ biến” hay “bong bóng lọc”.1

    Khi sản phẩm biến thành xứ sở mèo

    Vòng lặp thoái hóa còn đổi cả trọng tâm sản phẩm lẫn tập người dùng. Ban đầu một nhóm nhỏ phản hồi rằng họ thích ảnh mèo; hệ thống bắt được và sinh thêm ảnh mèo; điều đó hút người yêu mèo tới, họ lại phản hồi rằng ảnh mèo tốt — chẳng mấy chốc ứng dụng thành xứ sở mèo. Huyen nhấn mạnh rằng cùng cơ chế ấy khuếch đại được cả những thiên lệch khác: phân biệt chủng tộc, phân biệt giới, hay thiên về nội dung khiêu dâm.1

    Và biến trợ lý thành kẻ nịnh

    Hành động theo phản hồi người dùng có thể biến một tác tử hội thoại thành — theo cách nói của Huyen, vì không có từ nào khá hơn — kẻ nói dối. Nhiều nghiên cứu cho thấy huấn luyện mô hình trên phản hồi người dùng dạy nó đưa ra thứ nó nghĩ người dùng muốn nghe, kể cả khi đó không phải thứ chính xác hay có lợi nhất (Stray, 2023); Sharma và cộng sự (2023) chỉ ra rằng mô hình huấn luyện trên phản hồi con người có xu hướng sycophancy — nịnh hót, thiên về những câu trả lời khớp với quan điểm sẵn có của người dùng.18

Ba hiểu lầm khi đọc chương nàyThree misconceptions this chapter corrects

Chương cuối dễ bị đọc như một bản vẽ thi công hoặc một danh sách tính năng. Nó không phải cả hai.

A closing chapter is easily misread as a blueprint or a feature checklist. It is neither.

“Kiến trúc đầy đủ là đích đến”“The full architecture is the destination”

Huyen dựng kiến trúc theo lối tăng dần chính là để chống lại cách đọc này: thêm thành phần “khi nhu cầu phát sinh”, và bà nói rõ thứ tự của bà chỉ là thứ tự bà thường thấy, mỗi người nên theo thứ tự hợp với ứng dụng của mình. Mỗi thành phần thêm vào đều làm hệ thống phức tạp hơn và phơi nó ra những kiểu hỏng mới.1

The incremental construction is precisely the argument against this reading: components are added “as needs arise”, and Huyen says explicitly that her order is just the one she commonly sees — you should follow the order that makes sense for your application. Every added component increases complexity and exposes new failure modes.1

“Nút thích/không thích là đủ”“Thumbs up/down is enough”

Phản hồi tường minh đòi thêm công sức nên thường thưa thớt, và chịu thiên lệch phản hồi. Phần lớn tín hiệu thật nằm ở hành vi: dừng sớm, hỏi lại, sửa câu trả lời, xóa hội thoại — dồi dào hơn nhiều nhưng cũng nhiễu hơn nhiều, và cùng một hành động có thể mang hai nghĩa trái ngược tùy người.1

Explicit feedback demands extra work, so it is sparse and subject to response biases. Most of the real signal is behavioural: early termination, rephrasing, editing a response, deleting a conversation — far more abundant and far noisier, and the same action can mean opposite things for different users.1

“Càng nghe người dùng càng tốt”“The more you listen to users, the better”

Phản hồi dùng bừa bãi có thể kéo dài thiên lệch và phá hỏng sản phẩm: vòng lặp thoái hóa khuếch đại thiên lệch ban đầu, và huấn luyện trên phản hồi có thể dạy mô hình nịnh hót thay vì nói đúng.18 Phải hiểu giới hạn của phản hồi trước khi đưa nó vào sản phẩm.

Used indiscriminately, feedback can perpetuate biases and destroy your product: degenerate loops amplify initial biases, and training on feedback can teach a model sycophancy rather than accuracy.18 Understand the limitations before you build feedback into the product.

Tự kiểmTự hỏi mìnhSelf-check

Hệ thống của bạn đang ở bước nào?Cỗ máy của bạn đã có gì?Where is your system on this path?

Sáu câu hỏi bám theo mạch chương — kiến trúc, khả năng quan sát, vòng phản hồi. Trả lời thành thật thường lộ ra bước tiếp theo nên làm.

Sáu câu hỏi để soi lại cỗ máy của bạn. Trả lời thật lòng thì sẽ biết nên lắp thêm mảnh nào.

Six questions following the chapter's arc — architecture, observability, the feedback loop. Answering honestly usually reveals which step comes next.

Bạn thêm thành phần vì nhu cầu, hay vì nó đang thời thượng?Kiến trúc trong chương mọc lên từ những chỗ hỏng cụ thể. Nếu không nêu được chỗ hỏng mà một thành phần đang vá, có lẽ nó chưa cần. Huyen lưu ý rằng mỗi thành phần thêm vào đều mở ra kiểu hỏng mới và làm hệ thống khó gỡ lỗi hơn.
Rào chắn của bạn canh cả hai đầu chưa?Đầu vào chống rò rỉ dữ liệu và prompt độc hại; đầu ra bắt lỗi chất lượng lẫn lỗi an toàn — và có chính sách rõ cho từng kiểu lỗi. Đừng quên đo cả tỉ lệ từ chối sai: một hệ thống quá an toàn cũng là một hệ thống hỏng.
Bạn có biết MTTD, MTTR và CFR của mình không?Ba con số này đo chất lượng khả năng quan sát chứ không đo chất lượng mô hình. Huyen viết rằng nếu bạn không biết CFR của mình, đã đến lúc thiết kế lại nền tảng cho dễ quan sát hơn.
Một truy vấn hỏng — bạn chỉ ra được đúng bước hỏng không?Đó là phép thử của vết truy vấn: xử lý sai, bối cảnh lấy về không liên quan, hay mô hình sinh sai? Vết phải cho thấy cả thời gian và chi phí của từng bước, nếu đo được.
Bạn đang đọc tín hiệu ngầm nào?Dừng sớm, hỏi lại, sửa câu trả lời, xóa hội thoại — những tín hiệu này có mặt sẵn, chỉ là có được ghi lại và diễn giải hay không. Mỗi lần người dùng sửa câu trả lời là một cặp dữ liệu ưu tiên: bản gốc thua, bản sửa thắng.
Bạn đã tìm thiên lệch trong phản hồi của chính mình chưa?Nhìn phân bố điểm, vị trí lựa chọn, độ dài câu được chọn. Phản hồi chưa soi kỹ có thể dẫn tới quyết định sản phẩm sai lệch. Và hãy hỏi liệu hệ thống của bạn có đang tự nuôi lại chính thiên lệch của nó — vòng lặp thoái hóa hiếm khi tự lộ ra trong chỉ số.
Bạn lắp thêm mảnh vì máy hỏng, hay vì thấy người ta lắp?Nếu không chỉ ra được chỗ hỏng, thì chưa cần lắp.
Có người gác ở cả cửa vào lẫn cửa ra chưa?Cửa vào canh bí mật đi ra; cửa ra canh máy nói bậy.
Máy hỏng thì bao lâu bạn biết?Biết chậm thì sửa chậm.
Bạn có xem được đường đi của một câu hỏi không?Đi qua phòng nào, tắc ở đâu.
Bạn có để ý lúc người dùng bỏ đi giữa chừng không?Đó là lời chê rõ nhất mà không ai nói ra.
Bạn có tin phản hồi một cách mù quáng không?Nhớ nhé: nghe người dùng, nhưng phải suy nghĩ.
Do you add components out of need, or out of fashion?The chapter's architecture grows from concrete failures. If you can't name the failure a component fixes, you probably don't need it yet.
Do your guardrails cover both ends?Inputs against data leaks and prompt attacks; outputs against both quality and security failures — with an explicit policy per failure mode.
Do you know your MTTD, MTTR and CFR?These three measure the quality of your observability, not the quality of your model.
When a query fails, can you pinpoint the step?That is the test of tracing: was it processed wrong, was the retrieved context irrelevant, or did the model generate a wrong response?
Which implicit signals are you reading?Early termination, rephrasing, edits, deleted conversations — they are already there; the question is whether you log and interpret them.
Have you looked for the biases in your own feedback?Inspect the rating distribution, the position of chosen options, the length of preferred answers. Uninspected feedback leads to misleading product decisions.
Khép lại cả bộKhép lại cả bộClosing the series
Mười chương đi từ một câu hỏi — việc này có cần AI không — tới một cỗ máy biết tự nhìn mình. Điều còn lại sau tất cả là lời Huyen: nhiều thách thức của AI, ở cốt lõi, là bài toán hệ thống; muốn giải, phải lùi lại và nhìn toàn bộ.1 Mười bài, từ câu hỏi “có cần AI không” tới một cỗ máy biết tự soi mình. Nhớ nhé: đừng chỉ sửa từng mảnh — hãy lùi lại nhìn cả cỗ máy. Ten chapters, from one question — does this need AI at all — to a machine that can watch itself. What remains is Huyen's own line: many AI challenges are, at their core, system problems; to solve them you must step back and consider the whole.1