Cách DoorDash, Instacart và Uber Eats tích hợp LLM vào hệ thống tìm kiếm

Người dùng mong đợi các ứng dụng và tác nhân (agents) có thể kết nối với những công cụ mà họ đang sử dụng hàng ngày. Mỗi tích hợp để đạt được điều đó lại đòi hỏi một quy trình OAuth khác nhau, một vòng đời token khác nhau, và mất hàng tuần để xây dựng cơ sở hạ tầng trước khi bạn kịp viết một dòng mã sản phẩm nào.

WorkOS Pipes giải quyết vấn đề này chỉ với một lệnh gọi API. Với các bộ kết nối (connectors) được xây dựng sẵn cho GitHub, Slack, Salesforce, Google Drive và nhiều nền tảng khác, Pipes xử lý toàn bộ các khâu OAuth, làm mới token và lưu trữ thông tin xác thực. Bạn chỉ cần gọi API của nhà cung cấp thực tế với một token mới mỗi lần.

Kết nối với hơn 100 nhà cung cấp →

Trong vài năm qua, ba trong số những công ty giao đồ ăn lớn nhất đã tái cấu trúc hệ thống tìm kiếm của họ dựa trên LLM. DoorDash, Instacart và Uber Eats đều đang giải quyết cùng một bài toán: cố gắng hiểu ý định của người dùng khi họ nhập nội dung vào ô tìm kiếm. Họ cũng tiếp cận các cơ sở nghiên cứu gần như tương đồng nhau. Tuy nhiên, kiến trúc mà họ triển khai lại trông rất khác biệt.

Sự khác biệt đó là một trong những khía cạnh thú vị nhất của quá trình phát triển hiện đại sử dụng LLM. Một khi hiểu được lý do tại sao mỗi công ty lại chọn hướng đi đó, chúng ta sẽ có một mô hình tư duy để hình dung cách tích hợp AI vào bất kỳ hệ thống sản xuất nào.

Việc thêm một LLM vào ngăn xếp (stack) hiện có chỉ xoay quanh một câu hỏi: LLM nên can thiệp sâu đến mức nào vào thời gian chạy (runtime)?

Cuối cùng, DoorDash, Instacart và Uber Eats đều trả lời câu hỏi đó theo những cách khác nhau, và việc chọn LLM cụ thể nào chỉ là yếu tố phụ. Cơ sở hạ tầng mà họ đã có sẵn mới là thứ quyết định câu trả lời.

Trong bài viết này, chúng ta sẽ xem xét các giải pháp khác biệt của họ, cố gắng thấu hiểu những lựa chọn đó và tìm ra mô hình đằng sau chúng.

Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các thông tin được chia sẻ công khai từ nhiều nguồn khác nhau. Các tài liệu tham khảo được liệt kê ở cuối bài. Vui lòng để lại bình luận nếu bạn phát hiện bất kỳ điểm nào không chính xác.

Hãy thử nhập “thứ gì đó tốt cho sức khỏe vào một buổi tối mưa” vào một ứng dụng giao đồ ăn và xem kết quả trả về. Kết quả chúng ta nhận được ngày nay nằm ở mức hữu ích và ấn tượng. Năm năm trước, truy vấn tương tự có thể chỉ trả về một danh sách các mặt hàng ngẫu nhiên, bởi vì tìm kiếm theo từ khóa coi các từ ngữ là một tập hợp các token thay vì là một ý định, và truy vấn đó không cung cấp nhiều dữ liệu để khớp từ khóa.

Mô hình này lặp lại trên một số dạng lỗi phổ biến trong tìm kiếm thực phẩm. Ví dụ:

Từ đồng nghĩa: “Soda” và “soft drink” mô tả cùng một sản phẩm, nhưng công cụ tìm kiếm theo từ khóa coi chúng là các token khác nhau.

Lỗi chính tả: “Mozzarela” lẽ ra phải truy xuất được kết quả cho “mozzarella”, nhưng sự sai lệch về chính tả khiến việc tra cứu thất bại.

Viết tắt: “Gf pizza” có nghĩa là pizza không chứa gluten (gluten-free), đòi hỏi hệ thống phải nhận diện được từ viết tắt là từ đồng nghĩa của cụm từ đầy đủ.

Trộn lẫn ngôn ngữ: Từ “pan” trong tiếng Tây Ban Nha có nghĩa là bánh mì, trong khi từ “pan” trong tiếng Anh có nghĩa là cái chảo, vì vậy thanh tìm kiếm song ngữ phải phân biệt được ngữ cảnh.

Đa nghĩa: “Apple” (quả táo) và “Apple” (công ty công nghệ) có cùng cách viết nhưng mang ý nghĩa khác nhau, và câu trả lời đúng phụ thuộc vào ngữ cảnh.

Mỗi trường hợp trên đều là khoảnh khắc mà ý định của người dùng và các từ ngữ trong danh mục sản phẩm không khớp nhau.

Hai vấn đề khó khăn hơn nằm bên dưới điều này:

Đuôi dài (The long tail): Các nền tảng tạp hóa và nhà hàng chứng kiến một lượng truy vấn độc nhất khổng lồ. Bất kỳ mô hình chuyên biệt nào được huấn luyện trên dữ liệu chuyển đổi đều gặp khó khăn với các truy vấn chỉ xuất hiện vài lần, vì theo định nghĩa, các truy vấn hiếm gặp thì luôn hiếm.

Vấn đề ràng buộc: Một truy vấn như “bánh mì kẹp gà thuần chay” chứa một ràng buộc cứng bên trong, và việc truy xuất dựa trên độ tương đồng có thể trả về một chiếc bánh mì kẹp gà vi phạm ràng buộc đó, vì điểm số tương đồng vẫn trông có vẻ gần đúng. Các hạn chế về chế độ ăn uống, chất gây dị ứng và bộ lọc số lượng đều nằm trong nhóm này.

Tìm kiếm thực phẩm là lĩnh vực phù hợp để quan sát điều này, vì tất cả các dạng lỗi trên đều xuất hiện cùng lúc. Trong các phần tiếp theo, chúng ta sẽ xem xét cách các công ty khác nhau xử lý những tình huống này theo những cách khác nhau.

Làm thế nào để các kỹ sư nền tảng bắt kịp tốc độ của một đội ngũ phát triển đang tăng trưởng tại một công ty AI trị giá 2 tỷ USD? Hãy tham gia cùng Lawrence Aiello, Trưởng bộ phận Kỹ thuật Nền tảng tại Rogo, vào ngày 11 tháng 8 để tìm hiểu cách đội ngũ của anh ấy đánh giá và triển khai một nền tảng IaC hiện đại. Anh ấy sẽ đề cập đến:

Các tiêu chí đánh giá quan trọng khi Rogo chọn một nền tảng IaC hiện đại, đánh giá các giải pháp như Pulumi, OpenTofu, Crossplane và nhiều giải pháp khác.

“Nó chỉ đơn giản là hoạt động” (it just works) trông như thế nào trong thực tế đối với các hoạt động vận hành cơ sở hạ tầng.

Tại sao một nền tảng đáng tin cậy lại là nền tảng cho các quy trình làm việc cơ sở hạ tầng dựa trên AI.

Nếu nền tảng cơ sở hạ tầng của bạn đã trở thành một hệ thống khác cần phải bảo trì, thì phiên thảo luận này dành cho bạn.

Đăng ký ngay →

DoorDash đã có sẵn một đồ thị tri thức (knowledge graph) cho các mặt hàng và nhà hàng khi LLM trở nên khả thi cho sản xuất. Đồ thị này lưu trữ các thuộc tính có cấu trúc cho mọi mặt hàng, bao gồm loại món ăn, sở thích ăn uống, ẩm thực, thương hiệu và hương vị.

Cách tiếp cận của họ là sử dụng LLM để làm giàu đồ thị này ngoại tuyến (offline) bằng cách trích xuất các thuộc tính từ dữ liệu SKU, và chỉ sử dụng LLM tại thời điểm chạy (runtime) để phân tích các truy vấn thành các đoạn có thể liên kết ngược lại với đồ thị. Bản thân việc truy xuất vẫn dựa trên từ khóa và đồ thị.

Hãy xem xét truy vấn “bánh kem vani nhỏ không sữa”. LLM phân đoạn nó thành ba phần.

“nhỏ” là một thuộc tính về số lượng.

“không sữa” là một thuộc tính về sở thích ăn uống, ánh xạ tới nhãn chuẩn là “không chứa sữa” (dairy-free).

“bánh kem vani” được chia nhỏ hơn thành loại món ăn (“bánh kem”) và hương vị (“vani”).

Mỗi đoạn sau đó được liên kết với một trường cụ thể trong đồ thị tri thức. Sở thích ăn uống trở thành một bộ lọc cứng, vì vậy chỉ các mặt hàng không chứa sữa mới được truy xuất. Hương vị trở thành một sở thích mềm để xếp hạng. Loại món ăn giúp thu hẹp nhóm ứng viên.

Xem sơ đồ dưới đây: