Smart Project Search là use case phù hợp nhất để VDL-VN khởi động hành trình AI vì nó giải quyết đúng điểm nghẽn lớn nhất: tìm lại hồ sơ dự án, spec, báo giá và tài liệu kỹ thuật cũ trong kho NAS phân tán. Một thiết kế end-to-end tốt không chỉ cần mô hình mạnh, mà còn phải có dữ liệu sạch, truy xuất đúng quyền, thời gian phản hồi nhanh và câu trả lời có thể kiểm chứng nguồn.
Mục tiêu của Smart Project Search
Mục tiêu nghiệp vụ của hệ thống là rút ngắn thời gian tra cứu từ hàng chục phút hoặc hàng giờ xuống còn vài giây cho mỗi truy vấn. Người dùng chính là kỹ sư, mua hàng và quản lý dự án, những người thường xuyên phải hỏi lại hồ sơ cũ để kiểm tra thông số thiết bị, revision, báo giá nhà cung cấp hoặc lịch sử quyết định kỹ thuật.
Khác với một công cụ tìm file truyền thống, Smart Search cần hiểu ngôn ngữ tự nhiên. Người dùng có thể hỏi theo cách quen thuộc như “Thiết bị X trong dự án Y năm 2022 dùng spec nào?” hoặc “Có báo giá vendor nào cho tủ điện tương tự ở dự án trước không?”. Điều này yêu cầu hệ thống chuyển từ keyword search sang semantic retrieval có ngữ cảnh.
Phạm vi dữ liệu và ưu tiên pilot
Trong giai đoạn đầu, hệ thống nên tập trung vào các nguồn dữ liệu tạo giá trị cao nhất: thư mục dự án trên NAS, PDF kỹ thuật, file scan, báo giá cũ và email đính kèm liên quan đến dự án. Không nên cố gắng số hóa toàn bộ dữ liệu lịch sử ngay từ ngày đầu. Cách tiếp cận thực tế là chọn khoảng 5.000 tài liệu đại diện cho 2–3 năm gần nhất, thuộc hai phòng ban có nhu cầu mạnh nhất là Engineering và Procurement.
Mỗi tài liệu sau khi nạp vào hệ thống cần được gắn metadata tối thiểu gồm mã dự án, loại tài liệu, nhà cung cấp, ngày tài liệu, revision, phòng ban sở hữu và phạm vi quyền truy cập. Đây là lớp dữ liệu sống còn để truy xuất chính xác và lọc quyền sau này.
- Project ID: gắn tài liệu với đúng dự án hoặc gói thầu
- Document type: phân biệt datasheet, báo giá, biên bản, email, bản vẽ
- Revision code: giúp ưu tiên bản mới nhất hoặc đối chiếu thay đổi
- Access scope: xác định ai được quyền thấy tài liệu
Pipeline ingest và tiền xử lý tài liệu
Pipeline ingest nên hoạt động theo hai cơ chế: quét lô định kỳ cho giai đoạn pilot và theo dõi thay đổi thư mục cho giai đoạn vận hành. File watcher nhận diện file mới hoặc file cập nhật. Sau đó hệ thống đưa tài liệu qua OCR pipeline đối với file scan, qua PDF parser đối với tài liệu text-based và qua metadata extractor để bóc tách các trường quan trọng như mã dự án, số revision, tên vendor hoặc loại thiết bị.
Sau bước parser, tài liệu cần được chia thành các semantic chunk. Mỗi chunk phải đủ ngắn để tìm kiếm chính xác nhưng đủ dài để giữ ngữ cảnh kỹ thuật. Với tài liệu engineering, chunk theo heading, section, bảng thông số hoặc block text thường hiệu quả hơn chia cứng theo số ký tự. Những bảng quan trọng như thông số điện, model, part number hoặc phạm vi cung cấp nên được ưu tiên trích xuất riêng.
Kiến trúc RAG có phân quyền
Trung tâm của Smart Search là kiến trúc RAG. Sau khi chunk được tạo, embedding model mã hóa từng đoạn và lưu vào vector database. Song song, metadata store lưu toàn bộ thuộc tính tài liệu và quyền truy cập. Khi người dùng đặt câu hỏi, hệ thống không gửi ngay cho mô hình sinh văn bản. Thay vào đó, query sẽ được rewrite, nhận diện ý định, sau đó dùng hybrid search để kết hợp semantic search với keyword search, đặc biệt hữu ích với mã thiết bị, mã dự án và revision.
Sau khi lấy kết quả sơ bộ, access filter loại bỏ toàn bộ tài liệu mà người dùng không có quyền xem. Chỉ những chunk hợp lệ mới được đưa vào top-k context. Từ đó, prompt template gói ngữ cảnh và chuyển cho Private LLM để tổng hợp câu trả lời. Cách làm này vừa tăng độ chính xác vừa giảm nguy cơ rò rỉ dữ liệu.
Với Smart Search trong môi trường doanh nghiệp kỹ thuật, tìm đúng tài liệu là quan trọng; nhưng tìm đúng tài liệu mà người dùng có quyền xem còn quan trọng hơn.
Thiết kế câu trả lời và kiểm soát ảo giác
Smart Search không nên trả lời theo kiểu “AI biết mọi thứ”. Hệ thống cần bị ràng buộc bởi quy tắc grounded answer: chỉ được trả lời dựa trên ngữ cảnh truy xuất được. Nếu dữ liệu không đủ rõ hoặc không có kết quả đạt ngưỡng tin cậy, hệ thống phải kích hoạt no-answer rule và trả về thông báo an toàn, ví dụ: “Chưa tìm thấy đủ dữ liệu trong phạm vi quyền truy cập hiện tại”.
Mỗi câu trả lời nên đi kèm danh sách nguồn, gồm tên file, thư mục, revision, đoạn trích và liên kết mở file. Confidence score có thể hiển thị nội bộ để hỗ trợ người dùng đánh giá mức độ chắc chắn. Ở giai đoạn sau, hệ thống có thể bổ sung khả năng so sánh giữa nhiều nguồn hoặc tóm tắt sự khác biệt giữa các revision.
Thiết kế API và service layer
Để triển khai linh hoạt, Smart Search nên được đóng gói dưới dạng một tập dịch vụ nhẹ. Search API nhận truy vấn từ giao diện chat hoặc portal nội bộ. Ingestion API xử lý nạp dữ liệu và cập nhật chỉ mục. Metadata service quản lý schema, Auth service xác thực người dùng và quyền, Reranker service xếp hạng lại kết quả, còn Cache service giúp tăng tốc các truy vấn lặp lại.
Mô hình microservice nhẹ là đủ cho giai đoạn đầu, miễn là toàn bộ dịch vụ cùng dùng chung một service gateway và logging thống nhất. Điều này giúp đội triển khai dễ theo dõi lỗi, đo latency và tối ưu dần mà không cần một hạ tầng quá phức tạp ngay từ đầu.
Giao diện người dùng và trải nghiệm tìm kiếm
Về mặt giao diện, người dùng nên có một ô chat làm điểm tương tác chính. Bên cạnh đó là các bộ lọc dự án, loại tài liệu, thời gian và vendor. Mỗi câu trả lời cần có phần “nguồn tham khảo” hiển thị 3–5 kết quả liên quan nhất, cho phép preview đoạn trích và mở file gốc.
Feedback button như “đúng”, “chưa đủ”, “sai nguồn” hoặc “không thấy tài liệu cần thiết” sẽ tạo ra dữ liệu phản hồi rất quý cho quá trình cải tiến. Đây là cách thực tế nhất để nâng retrieval precision và answer accuracy theo thời gian.
KPI và tiêu chí thành công
Thành công của Smart Search không nên đo bằng số lượng mô hình hay độ phức tạp kỹ thuật, mà bằng chỉ số vận hành rõ ràng. Bốn KPI quan trọng nhất là thời gian phản hồi, độ chính xác truy xuất, mức độ chấp nhận sử dụng và số giờ tiết kiệm được. Ngoài ra cần theo dõi failed query để biết người dùng đang hỏi gì mà hệ thống chưa trả lời tốt.
Đối với pilot 8 tuần, VDL-VN có thể đặt mục tiêu khả thi: 80% truy vấn trả lời dưới 5 giây, 70% truy vấn có nguồn liên quan cao, giảm ít nhất 30–40% thời gian tìm tài liệu ở nhóm người dùng thí điểm và đạt tỷ lệ sử dụng lặp lại đủ cao để chứng minh nhu cầu thực.
Lộ trình triển khai 8 tuần
Trong hai tuần đầu, đội dự án cần chốt phạm vi dữ liệu, chuẩn metadata và quyền truy cập, đồng thời dựng pipeline ingest cơ bản. Tuần 3–4 tập trung vào parsing, chunking, vector hóa và giao diện search tối thiểu. Tuần 5–6 triển khai RAG, citation, cache và logging. Tuần 7 dành cho UAT với Engineering và Procurement. Tuần 8 tối ưu prompt, cải thiện ranking và tổng kết KPI pilot.
Cách tiếp cận này giữ đúng tinh thần pilot-first: nhỏ, đo được, an toàn và có thể mở rộng. Khi pilot chứng minh được hiệu quả, cùng một nền tảng có thể phát triển tiếp sang Quote Analyzer, Knowledge Hub và các use case AI khác.
Kết luận
Smart Project Search không chỉ là một ô chat trên dữ liệu nội bộ. Đây là hạt nhân của lớp truy xuất tri thức doanh nghiệp tại VDL-VN. Nếu được thiết kế đúng với ingestion tốt, metadata rõ, RAG có phân quyền, prompt guardrail và KPI chặt chẽ, hệ thống này sẽ tạo ra ROI nhanh nhất và đặt nền móng cho toàn bộ kiến trúc AI phía sau.