Vẽ ngay pipeline RAG là bỏ lỡ điều Cohere muốn xem ở vòng thiết kế FDE

Thử hình dung người phỏng vấn chỉ nói một câu: “Thiết kế guardrail cho knowledge cutoff của một LLM.” Đây là một đề thiết kế mà ứng viên kể lại trên Lodely sau khi phỏng vấn ở Cohere. Đề không cho schema, không nói có bao nhiêu người dùng, cũng không nói hệ thống chạy trên cloud nào.

Phản xạ dễ mắc nhất là vẽ ngay một pipeline RAG. Vẽ được, nhưng như thế là bỏ qua đúng phần người phỏng vấn muốn xem.

Tin tuyển FDE cho nhóm Agentic Platform của Cohere ghi rằng người làm vị trí này dẫn dắt việc thiết kế, xây dựng và bàn giao các agent dùng LLM, những agent biết suy luận, lập kế hoạch và hành động qua nhiều công cụ và API.

Cũng tin tuyển đó yêu cầu FDE chịu trách nhiệm scope và định hình use case từ đầu đến cuối, chứ không chỉ viết code. Vì thế vòng thiết kế là một buổi customer discovery thu nhỏ. Nếu bạn đang nhắm vị trí FDE ở bất kỳ công ty LLM nào cho doanh nghiệp, đây là kỹ năng đáng luyện trước tiên.

Các vòng trông như thế nào?

Một hướng dẫn trên techinterview.org mô tả quy trình phỏng vấn chung của Cohere là một loop 4-5 vòng, kéo dài khoảng 4-7 tuần. Hướng dẫn này không nói riêng về FDE.

Với các vị trí forward-deployed, ứng viên kể lại trên Lodely một thứ tự cụ thể hơn. Đó là lời kể của ứng viên, Cohere chưa xác nhận, nên hãy coi nó là bản đồ tham khảo chứ không phải đề cương chính thức.

Vòng (theo lời ứng viên)	Thực chất kiểm tra gì	Chuẩn bị gì
Gọi với recruiter	Bạn có hiểu FDE là vai trò gắn với khách hàng không	Một câu chuyện về lần bạn tự scope bài toán cho người dùng
AI system design	Kiến trúc LLM cho doanh nghiệp và các đánh đổi	Khung 5 bước bên dưới, luyện thật nhiều về RAG
Debugging	Bình tĩnh đọc lỗi trong hệ thống người khác viết	Tập debug một pipeline retrieval trả kết quả sai
Coding (đôi khi có AI hỗ trợ)	Python dùng được trong production, và khả năng phán đoán khi có trợ lý AI	Viết code sạch, có test, giải thích được từng dòng AI gợi ý

Người phỏng vấn thực sự chấm điều gì?

Tin tuyển của Cohere nêu ba thứ đáng đọc kỹ. Trước hết là Python production, kèm khả năng xây eval framework chặt chẽ, không dừng ở kiểu thử rồi sửa.

Ở mục điểm cộng, tin tuyển nhắc tới kinh nghiệm trong các ngành bị quản lý chặt hoặc nhạy cảm như tài chính, y tế, viễn thông, cùng hiểu biết về bảo mật và tuân thủ cho AI trong doanh nghiệp.

Hướng dẫn trên techinterview.org nói thẳng hơn nữa. Theo đó, phỏng vấn ở Cohere hỏi về kiến trúc retrieval kỹ hơn các công ty cùng ngành, nên lời khuyên số một là học RAG thật sâu. Tiếp theo là làm quen với các mối lo của doanh nghiệp: data sovereignty, audit log, triển khai on-premise.

Mối lo về triển khai không phải chuyện lý thuyết. Tài liệu của Cohere liệt kê bốn phương án triển khai, trong đó có private deployment trên cloud, tức doanh nghiệp tự chạy toàn bộ stack Cohere trên nền tảng cloud của mình.

Nói với TechCrunch về nền tảng agent North, một đồng sáng lập Cohere cho biết họ có thể triển khai trên “một GPU đặt trong tủ” mà khách hàng có sẵn ở đâu đó.

Giải mẫu: guardrail cho knowledge cutoff

Bước 1: hỏi lại. Giả sử người phỏng vấn trả lời rằng khách hàng là một ngân hàng và trợ lý nội bộ phục vụ nhân viên tư vấn. Câu đầu tiên bạn cần hỏi là hệ thống sẽ chạy ở đâu và dữ liệu có được rời khỏi hạ tầng của ngân hàng không. Sau đó mới hỏi loại câu hỏi nào phụ thuộc vào thời gian, và trả lời sai thì hậu quả là gì.

Bước 2: chốt ràng buộc deployment. Giả sử ngân hàng chạy on-premise hoặc private cloud. Khi đó bạn không thể gọi web search bên ngoài để lấy tin mới: nguồn “mới” chỉ còn là kho tài liệu nội bộ, vì thế quy trình cập nhật kho đó trở thành một phần của guardrail. Mỗi lần guardrail can thiệp cũng phải được ghi vào audit log để bộ phận tuân thủ kiểm tra lại được.

Bước 3: định nghĩa lỗi. Knowledge cutoff gây ra hai kiểu lỗi. Kiểu thứ nhất là mô hình tự tin trả lời về một sự kiện xảy ra sau ngày cutoff. Kiểu thứ hai nguy hiểm hơn với ngân hàng: mô hình đưa ra một thông tin từng đúng nhưng đã cũ, ví dụ một quy định đã bị thay, dù kho đã có bản mới.

Bước 4: kiến trúc. Chỉ đến lúc này mới vẽ, và vẽ trong giới hạn của bước 2. Một bộ phân loại gắn nhãn câu hỏi có phụ thuộc thời gian hay không. Câu phụ thuộc thời gian được đưa sang retrieval trên kho nội bộ có gắn ngày hiệu lực, ưu tiên bản mới nhất.

Nếu tài liệu mới nhất cũ hơn ngưỡng cho phép, hoặc không tìm thấy tài liệu nào, hệ thống trả lời có điều kiện và ghi rõ dữ liệu tính đến ngày nào. Nếu không thể trả lời có điều kiện thì hệ thống từ chối.

Bước 5: eval. Đây là chỗ phân biệt ứng viên mạnh với ứng viên trung bình. Bạn có thể phác ra trên bảng một đoạn như sau:

EVAL_SET = [
    {"q": "Định nghĩa tỷ lệ an toàn vốn là gì?", "time_sensitive": False},
    {"q": "Quy định hạn mức mới nhất áp dụng ra sao?", "time_sensitive": True, "has_fresh_doc": True},
    {"q": "Chính sách công bố tuần trước nói gì?", "time_sensitive": True, "has_fresh_doc": False},
]

# results: mỗi mục của EVAL_SET sau khi chạy qua hệ thống, có thêm
# answered_confidently, refused, cited_latest_doc (hệ thống có dùng bản mới nhất không)
def score(results):
    post_cutoff = sum(r["time_sensitive"] and not r.get("has_fresh_doc")
                      and r["answered_confidently"] for r in results)
    stale_doc = sum(r["time_sensitive"] and r.get("has_fresh_doc")
                    and r["answered_confidently"] and not r["cited_latest_doc"] for r in results)
    over_refusal = sum(not r["time_sensitive"] and r["refused"] for r in results)
    return {"post_cutoff": post_cutoff, "stale_doc": stale_doc, "over_refusal": over_refusal}

Hai số đo đầu ứng với hai kiểu lỗi ở bước 3, và chúng kéo ngược chiều với số thứ ba. Siết guardrail thì câu trả lời tự tin nhưng lỗi thời giảm, nhưng số lần từ chối thừa tăng.

Tin tuyển đòi eval phải hơn hẳn kiểu thử rồi sửa. Trong đề này, cách thể hiện điều đó là gọi tên sự đánh đổi và đề nghị ngân hàng tự chọn ngưỡng theo hậu quả của từng loại lỗi.

Tự luyện thế nào?

Bắt đầu bằng việc đọc kỹ tin tuyển và gạch chân mọi động từ: design, scope, deliver, evaluate. Mỗi động từ nên ứng với một câu chuyện có thật trong kinh nghiệm của bạn. Sau đó chọn ba đề thiết kế LLM cho doanh nghiệp và giải từng đề theo 5 bước, nói to như đang ngồi trong phòng phỏng vấn.

Song song, hãy tự xây một hệ RAG nhỏ có eval đi kèm. Nó không cần đẹp, nhưng cần có bộ test và số đo trước/sau. Trong CV, đừng viết “có kinh nghiệm với RAG”.

Hãy viết rằng bạn đã xây eval cho hệ thống nào và nó giảm loại lỗi nào. Nếu từng làm cho khách hàng trong tài chính, y tế hay viễn thông, hãy đưa điều đó lên đầu, vì đó chính là điểm cộng tin tuyển nêu.

Những lỗi khiến ứng viên mất điểm

Lỗi phổ biến nhất là đưa ra giải pháp trước khi hỏi lại. Lỗi thứ hai là xử lý knowledge cutoff bằng một dòng prompt kiểu “đừng bịa”. Prompt như vậy không đo được và không kiểm tra lại được. Lỗi thứ ba là quên deployment: một kiến trúc cần gọi API bên ngoài sẽ đổ vỡ ngay khi khách hàng nói họ chạy trên hạ tầng riêng.

Ở vòng coding có AI hỗ trợ, cái bẫy nằm ở chỗ khác: dán nguyên code được gợi ý mà không giải thích được nó. Hãy coi trợ lý AI như một đồng nghiệp junior. Bạn được nhờ nó viết nháp, nhưng chịu trách nhiệm về từng dòng.

Đề “guardrail cho knowledge cutoff” nghe như một câu đố kỹ thuật. Thực chất nó hỏi xem bạn có phải là người mà một ngân hàng sẽ tin giao cho chiếc GPU trong tủ của họ hay không.