№ 41
TraVy là trợ lý du lịch AI trò chuyện bằng tiếng Việt lẫn tiếng Anh, biến một cuộc hội thoại vài phút thành lịch trình Việt Nam chi tiết theo từng ngày - được xây dựng trên nền dữ liệu RAG có nguồn xác thực thay vì suy đoán từ mô hình ngôn ngữ chung. Thay vì lặp lại top 10 điểm đến quen thuộc, TraVy hiểu đúng sở thích, ngân sách và nhịp độ của từng người để gợi ý cả những trải nghiệm địa phương mà các nền tảng du lịch phổ biến thường bỏ sót.
Việt Nam có 34 tỉnh thành, hàng nghìn di tích, hàng trăm nền ẩm thực vùng miền - nhưng khách du lịch, dù trong hay ngoài nước, gần như luôn kết thúc với cùng một danh sách lặp lại: Hồ Hoàn Kiếm, Phố cổ, Vịnh Hạ Long, Hội An Ancient Town. Không phải vì Việt Nam thiếu điều để khám phá, mà vì quy trình tìm kiếm thông tin đang bị vỡ vụn. Một chuyến đi trung bình đòi hỏi 4-10 giờ lục lọi qua Google, TripAdvisor, Reddit, hội nhóm Facebook, video TikTok, rồi tự tay ghép các mảnh rời rạc đó thành một lịch trình có logic. Khách quốc tế thì bị chặn bởi rào cản ngôn ngữ vì phần lớn thông tin bản địa sâu chỉ tồn tại bằng tiếng Việt; khách nội địa thì biết các điểm lớn nhưng không chạm được tới lớp trải nghiệm địa phương, quán ăn không lên app, con đường mòn dân bản địa mới biết, vì lớp thông tin đó chỉ sống trong các nhóm chat, không hề được cấu trúc hóa. Các công cụ hiện có, từ Google Travel đến ChatGPT, hoặc là quá chung chung, hoặc đòi hỏi kỹ năng prompt để không bị "ảo giác" ra những địa điểm không tồn tại.
Giải pháp kỹ thuật: TraVy giải quyết bài toán này bằng một pipeline hội thoại có kiểm soát chặt, không phải một wrapper mỏng quanh LLM. Khi người dùng nhắn tin, hệ thống trước tiên phân tích mức độ sẵn sàng của yêu cầu (điểm đến, thời gian, số ngày, sở thích, ngân sách) - nếu thiếu thông tin trọng yếu, TraVy chủ động hỏi lại thay vì bịa ra một lịch trình cho có. Khi đủ dữ kiện, hệ thống phân giải đúng vùng địa lý rồi truy vấn song song một cơ sở tri thức RAG lai (hybrid: vector search kết hợp keyword search trên Postgres/pgvector, có lọc theo vùng) cùng dữ liệu thời tiết thời gian thực, trước khi đưa toàn bộ ngữ cảnh đó cho một tầng lập kế hoạch LLM chuyên biệt để sinh lịch trình từng ngày, và cuối cùng định dạng lại thành câu trả lời tự nhiên.
Điều làm nên khác biệt nằm ở lớp dữ liệu phía sau: một data pipeline có quản trị (governed), chỉ crawl từ danh sách nguồn được duyệt trước - Wikipedia tiếng Việt/tiếng Anh, Wikivoyage, OpenStreetMap, Overture Places, Foursquare Open Places, Wikidata, vietnam.travel — đi qua đầy đủ các bước chuẩn hóa, trích xuất thực thể, chấm điểm chất lượng, và một "gazetteer" xác thực rằng nội dung được gắn nhãn vùng thực sự nói về đúng vùng đó, trước khi được publish nguyên tử vào môi trường production. Dữ liệu cộng đồng và nguy cơ ảo giác được kiểm soát bằng một tầng guardrail độc lập: chặn prompt injection (kể cả biến thể tiếng Việt và dịch ngôn ngữ chéo), giới hạn phạm vi chỉ trả lời về du lịch Việt Nam, và từ chối nội dung nhạy cảm. Hệ thống hiện phủ 15 vùng địa lý trọng điểm từ Bắc vào Nam, vượt mục tiêu 10 tỉnh thành đề ra cho bản release.
Tính khả thi: TraVy không còn là một ý tưởng trên giấy - đây là một hệ thống end-to-end đang chạy thật: frontend React/Vite, backend NestJS, AI-service Python với pipeline RAG hoàn chỉnh, toàn bộ nối với Supabase Postgres (pgvector cho vector search, PostGIS cho dữ liệu địa lý). Quan trọng hơn, chất lượng của hệ thống không dừng ở cảm nhận chủ quan mà được đo bằng một bộ 100 test case trải trên 8 nhóm hành vi khác nhau - từ lập lịch trình cơ bản, hỏi lại khi thiếu thông tin, chặn nội dung độc hại, chỉnh sửa lịch trình đa lượt, độ nhạy cá nhân hóa theo sở thích/ngân sách, cho tới độ bền với input phi chuẩn. Lần chạy gần nhất ghi nhận độ chính xác lập lịch trình đạt 91%, tỷ lệ chặn an toàn tuyệt đối 100% trên mọi kịch bản tấn công guardrail được thử nghiệm, và tỷ lệ truy vấn không tìm được dữ liệu (zero-result) chỉ 9% dù đã thử cả những câu hỏi ở vùng ít dữ liệu. Nhóm đã phát hiện và vá 5 lỗi thực sự thông qua chính quy trình eval này. Toàn bộ được team hoàn thiện trong khuôn khổ vài tuần, cho thấy kiến trúc modular monolith và việc tận dụng dịch vụ managed (Supabase, các API LLM) là lựa chọn đúng đắn cho quy mô đội ngũ hiện tại.
Hướng phát triển: Chặng tiếp theo của TraVy đi theo ba trục. Thứ nhất là làm sâu lớp trải nghiệm: bổ sung tầng bối cảnh văn hóa - lịch sử, truyền thuyết, ý nghĩa của từng địa điểm và một lớp dữ liệu cộng đồng được gắn nhãn minh bạch để đưa những khám phá địa phương thực sự tiếp cận được người dùng. Thứ hai là hoàn thiện vòng đời sản phẩm: tài khoản người dùng, lưu và quay lại chuyến đi (đã có nền tảng, vừa được củng cố ổn định), lịch trình đầy đủ hơn với gợi ý phương tiện, chi phí ước tính và chỗ ở, cùng cơ chế người dùng gắn cờ thông tin sai để đội ngũ dữ liệu xử lý trong vòng 7 ngày. Thứ ba, và bền vững nhất, là mở rộng độ phủ dữ liệu ra ngoài 15 vùng hiện tại và tiếp tục siết chặt độ tin cậy ở những điểm eval đã chỉ ra còn yếu, biến chính bộ eval 100 case này thành một cơ chế hồi quy liên tục mỗi khi hệ thống thay đổi, thay vì một lần kiểm thử duy nhất trước khi nộp bài.