Nebius tuyển FDE để đưa Tavily vào production

Ngày 10/2/2026, Nebius công bố thỏa thuận mua Tavily, một nhà cung cấp agentic search đang phục vụ các doanh nghiệp trong Fortune 500 và nhiều công ty AI hàng đầu. Bảy tháng sau, ở New York, Nebius đăng tuyển vị trí Forward Deployed Engineer, Enterprise – Tavily. Việc chính của vị trí này là thiết kế và triển khai các tích hợp chạy production trên API của Tavily.

Với người làm FDE, tin tuyển dụng này đáng chú ý hơn cả thương vụ. Search cho agent đang thành một mảnh hạ tầng mà doanh nghiệp mua về, và họ cần người nối nó vào hệ thống thật của mình. Nếu bạn muốn vào mảng applied AI, công cụ này là cách rẻ để luyện đúng kỹ năng mà job description đang đòi.

Tavily thực ra làm được gì?

Tài liệu của Tavily tự mô tả sản phẩm là “lớp web cho AI agent”. API có bốn khả năng. Search tìm trên web những nguồn mới và liên quan. Extract lấy nội dung sạch từ một hoặc nhiều URL. Crawl đọc nhiều trang của cùng một website. Research trả về một báo cáo có trích dẫn, tổng hợp từ nhiều nguồn.

Theo SiliconANGLE, Tavily gom ba việc vào chung một API cho lập trình viên: tìm kiếm nhanh, crawl website và tách nội dung trang web thành dạng có cấu trúc. Khách hàng được nêu tên gồm IBM, Cohere và Groq. Theo Nebius, Tavily giữ nguyên thương hiệu và tiếp tục phục vụ khách cũ. Đội ngũ của Tavily, gồm cả nhà sáng lập kiêm CEO Rotem Weiss, chuyển sang Nebius.

Khi nào FDE cần đến nó?

Mô hình ngôn ngữ không biết những gì xảy ra sau thời điểm huấn luyện. Một hệ RAG nội bộ thì chỉ biết tài liệu của chính khách hàng.

Vì thế, mỗi khi use case cần thông tin đang thay đổi ngoài tường lửa, chẳng hạn quy định mới, giá của đối thủ hay tin về nhà cung cấp, agent cần một lớp truy cập web.

Bạn có thể tự viết lớp đó hoặc dùng một API như Tavily. Tự viết nghĩa là bạn phải tự lo phần tìm kiếm, phần tải trang và phần lọc bỏ HTML rác. Khi làm việc tại chỗ khách hàng, thời gian của FDE nên dồn vào bài toán nghiệp vụ, nên một API gom sẵn search, crawl và extract giúp bạn khỏi phải tự dựng lại phần việc ấy.

Một ví dụ tối thiểu, làm từ đầu đến cuối

Thử hình dung đội phân tích của một công ty bảo hiểm muốn mỗi sáng thứ Hai có một agent tóm tắt các thay đổi quy định trong tuần. Phần dưới đây là một kịch bản giả định để bạn chép lại cấu trúc, không phải output thật của API.

Bước một: agent biến yêu cầu thành truy vấn, chẳng hạn “thay đổi quy định bảo hiểm nhân thọ tuần này”, rồi gọi Search. Thứ nhận về là một danh sách nguồn kèm URL. Giả sử trong đó có thông cáo của cơ quan quản lý A, một bài báo tài chính và một bài blog của công ty luật.

Bước hai: agent chỉ giữ các URL thuộc tên miền của cơ quan quản lý, rồi gọi Extract. Thay vì HTML thô lẫn menu và chân trang, bạn nhận phần văn bản của thông cáo, ví dụ đoạn nêu điều khoản được sửa và ngày có hiệu lực.

Bước ba chỉ cần khi cơ quan đó đăng nhiều văn bản rải rác trên cùng một website. Lúc ấy bạn dùng Crawl để đọc nhiều trang của site đó.

Bước bốn: mô hình viết bản tóm tắt theo một khuôn cố định. Một dòng mẫu: “Cơ quan quản lý A sửa yêu cầu công bố phí, hiệu lực từ [ngày] — nguồn: [URL thông cáo].” Quy tắc đơn giản: ý nào không gắn được URL đã Extract thì không được vào bản tóm tắt, để chuyên viên tuân thủ bấm vào kiểm tra lại từng ý.

Research có thể thay cả bốn bước bằng một lần gọi, vì nó trả về luôn một báo cáo có trích dẫn. Trước khi chọn cách này, hãy kiểm tra xem kết quả Research có cho bạn thấy đủ rõ những nguồn đã được dùng hay không.

Lời khuyên: khi làm prototype, hãy bắt đầu bằng Search cộng Extract và ghi log mọi URL. Khi đã hiểu chất lượng nguồn, hãy so với Research rồi mới chọn. Tên tham số cụ thể thì đọc trong tài liệu chính thức, đừng đoán.

Prototype chạy rồi, production cần thêm gì?

Tin tuyển dụng của Nebius mô tả FDE làm việc cùng các đội engineering, data, product và AI của khách để đưa use case từ prototype lên production. Một lần gọi API chạy được trên laptop mới chỉ là prototype. Production phải trả lời được ba câu: API chậm thì sao, nguồn sai thì ai phát hiện, và ai chịu trách nhiệm khi bản tóm tắt dẫn nhầm văn bản.

Với độ trễ, hãy đặt timeout cho từng lần gọi Search và Extract. Quá hạn thì agent không treo mà chuyển sang phương án dự phòng: dùng bản kết quả đã lưu của lần chạy trước kèm dòng “chưa cập nhật”, hoặc báo thẳng là chưa lấy được nguồn.

Với nguồn sai, hãy ngồi cùng đội tuân thủ của khách để chốt một allowlist tên miền đáng tin, rồi lọc URL bằng code của bạn trước bước Extract. Danh sách này nên nằm trong file cấu hình, có một người phía khách đứng tên chịu trách nhiệm, để thêm hay bớt nguồn không cần sửa code.

Với trách nhiệm, hãy đưa vào eval một bước kiểm tra trích dẫn: với mỗi ý trong bản tóm tắt, xác nhận đoạn văn Extract từ URL được dẫn thực sự chứa thông tin đó. Tỷ lệ ý khớp nguồn trên một bộ câu hỏi mẫu có đáp án là con số cần theo dõi hằng ngày, và phải có người cụ thể nhận cảnh báo khi nó tụt.

Nên học gì trước?

Tin tuyển dụng ghi rõ yêu cầu năng lực engineering thực hành vững, nhất là Python, API và hệ thống backend, cộng với kinh nghiệm về RAG và agent. Thứ tự học vì thế khá rõ.

Đầu tiên là viết client gọi API có timeout, xử lý lỗi và retry. Tiếp theo là dựng pipeline lấy nguồn, lọc theo allowlist rồi đưa vào ngữ cảnh mô hình. Sau cùng là viết eval kiểm tra trích dẫn có khớp nguồn.

Về hồ sơ, khi đọc job description, hãy chú ý những cụm như “production-ready integrations” hay “prototype to production”. Trong CV, một dòng như “đưa agent có web search lên production, đo tỷ lệ trích dẫn đúng trên bộ 20 câu hỏi” có sức nặng hơn hẳn một dòng liệt kê thư viện. Kèm theo một repo nhỏ có log URL và bảng chấm điểm thì càng thuyết phục.

Agent sẽ ngày càng phải đọc web trước khi trả lời. Người được trả tiền là người làm cho việc đọc ấy đáng tin, chứ không phải người viết dòng gọi API đầu tiên.