AI·20K Demo Day ZineĐang in số mới...
№ 23
Legolas AI là trợ lý pháp chế giúp trường học xử lý văn bản pháp luật và tài liệu nội bộ dựa trên căn cứ có thể kiểm chứng. Tra cứu đúng nguồn, rà soát rủi ro và soạn nháp nhanh hơn — tất cả với trích dẫn rõ ràng.
№ 23
Demo Day Zine
Trong môi trường đại học, phòng pháp chế thường phải xử lý nhiều nhóm công việc liên quan đến văn bản, bao gồm tra cứu văn bản pháp luật, đối chiếu quy định nội bộ, rà soát hợp đồng/văn bản hành chính và hỗ trợ soạn thảo các loại văn bản như công văn, tờ trình, biên bản hoặc thông báo. Đây là các công việc có tính lặp lại cao nhưng đòi hỏi độ chính xác, tính minh bạch và khả năng kiểm chứng nguồn rất lớn.
Người dùng mục tiêu của MVP là cán bộ phòng pháp chế trong trường đại học — nhóm người dùng thường xuyên làm việc với văn bản pháp luật, quy chế nội bộ, hợp đồng, biểu mẫu và các văn bản hành chính. Với nhóm người dùng này, vấn đề lớn nhất không chỉ là “tìm được thông tin”, mà là tìm đúng căn cứ, đúng ngữ cảnh, đúng văn bản còn phù hợp và có thể chứng minh câu trả lời dựa trên nguồn nào.
Trên thực tế, dữ liệu phục vụ công việc pháp chế thường bị phân tán. Văn bản pháp luật nằm ở các nguồn công khai, trong khi tài liệu nội bộ của trường như quy chế, quy định, hợp đồng, biểu mẫu hoặc văn bản hướng dẫn lại nằm trong các hệ thống riêng, file PDF, tài liệu scan, email hoặc thư mục lưu trữ khác nhau. Điều này khiến quá trình tra cứu, đối chiếu và tổng hợp thông tin mất nhiều thời gian, đồng thời phụ thuộc lớn vào kinh nghiệm cá nhân.
Bên cạnh đó, việc kiểm chứng căn cứ vẫn còn thủ công. Khi cần trả lời một vấn đề pháp chế, người dùng không chỉ cần một câu trả lời nhanh, mà còn cần biết câu trả lời đó dựa trên văn bản nào, điều khoản nào hoặc đoạn trích nào. Các công cụ LLM thông thường có thể phản hồi nhanh nhưng không đảm bảo minh bạch về nguồn, dễ tạo ra câu trả lời nghe hợp lý nhưng khó kiểm chứng. Trong nghiệp vụ pháp chế, điều này có thể dẫn đến rủi ro trong tham mưu, ban hành văn bản hoặc xử lý hồ sơ.
Ngoài tra cứu, cán bộ pháp chế còn phải rà soát nhiều loại tài liệu như hợp đồng, công văn, quy chế hoặc văn bản nội bộ. Đây là công việc tốn thời gian vì người dùng cần đọc toàn văn, phát hiện rủi ro, kiểm tra căn cứ, đánh giá câu chữ chưa rõ và đề xuất chỉnh sửa phù hợp. Tương tự, việc soạn nháp văn bản hành chính/pháp chế cũng cần đúng mẫu, đúng ngữ cảnh và bám vào căn cứ pháp lý hoặc thông tin nội bộ liên quan.
Từ các pain point trên, nhóm xác định Legolas AI không nên được định vị như một chatbot pháp lý trả lời tự do, mà là một trợ lý pháp chế có kiểm soát, tập trung vào ba nhu cầu lõi của MVP:
MVP của Legolas AI vì vậy được thu hẹp vào ba luồng chính: tra cứu, rà soát và soạn nháp. Hệ thống không thay thế chuyên gia pháp lý, không tự động đưa ra quyết định pháp lý cuối cùng và không cam kết bao phủ toàn bộ hệ thống văn bản. Vai trò của sản phẩm là hỗ trợ cán bộ pháp chế làm việc nhanh hơn, có căn cứ hơn và dễ kiểm chứng hơn, trong khi con người vẫn giữ vai trò kiểm duyệt và ra quyết định cuối cùng.
Legolas AI được thiết kế như một nền tảng trợ lý pháp chế dành cho môi trường trường học, gồm ba lớp trải nghiệm chính.
Lớp đầu tiên là giao diện hỏi đáp và tra cứu. Người dùng đặt câu hỏi bằng ngôn ngữ tự nhiên. Câu trả lời không chỉ hiển thị nội dung tổng hợp, mà còn có danh sách nguồn trích dẫn, đoạn trích liên quan và thông tin văn bản. Đây là điểm khác biệt quan trọng so với chatbot thông thường, vì người dùng pháp chế cần khả năng kiểm chứng.
Lớp thứ hai là thư viện tài liệu. Hệ thống chia nguồn dữ liệu thành các phạm vi rõ ràng: thư viện văn bản pháp luật công khai, thư viện nội bộ của tổ chức và tài liệu tải lên theo phiên làm việc. Cách chia này giúp kiểm soát quyền truy cập, tránh trộn lẫn tài liệu cá nhân, tài liệu nội bộ và nguồn pháp luật chung.
Lớp thứ ba là công cụ rà soát và soạn nháp. Với rà soát văn bản, hệ thống hiển thị kết quả dưới dạng các phát hiện có phân loại rủi ro, trích dẫn và gợi ý sửa. Với soạn nháp, hệ thống hỗ trợ người dùng tạo bản nháp có cấu trúc, sau đó người dùng vẫn là người kiểm duyệt cuối cùng.
Về trải nghiệm người dùng, nhóm ưu tiên sự rõ ràng và tin cậy thay vì tạo cảm giác “AI thần kỳ”. Các yếu tố như citation, đoạn trích, trạng thái xử lý, quyền truy cập tài liệu, onboarding và giới hạn guest user đều được thiết kế để người dùng hiểu hệ thống đang làm gì và câu trả lời đến từ đâu.
Kiến trúc kỹ thuật của sản phẩm được xây dựng theo hướng web app hiện đại, tách lớp rõ ràng giữa giao diện người dùng, backend nghiệp vụ, cơ sở dữ liệu và tầng truy xuất tài liệu bằng AI, có khả năng triển khai cloud và mở rộng dần.
Frontend sử dụng React, Vite và Tailwind CSS để xây dựng giao diện web. Phần giao diện hỗ trợ các luồng chính của sản phẩm như tra cứu văn bản, quản lý thư viện tài liệu, rà soát văn bản, soạn nháp, onboarding và dark mode. Vite được dùng để tối ưu trải nghiệm phát triển frontend và build ứng dụng tĩnh để triển khai lên Vercel.
Backend sử dụng FastAPI để cung cấp API cho xác thực, quản lý tổ chức, quản lý tài liệu, tra cứu, rà soát và sinh nội dung bằng AI. Backend được thiết kế theo hướng tách service để dễ kiểm thử, dễ mở rộng và dễ triển khai, đóng vai trò trung gian giữa frontend, database và retrieval service.
Cơ sở dữ liệu quan hệ sử dụng PostgreSQL để lưu người dùng, tổ chức, vai trò, metadata tài liệu, lịch sử sử dụng và các thông tin nghiệp vụ khác.
Vector database sử dụng ChromaDB để lưu embedding của các chunk văn bản phục vụ truy xuất ngữ nghĩa. Embedding sử dụng BGE-M3, phù hợp với nhu cầu tìm kiếm ngữ nghĩa đa ngôn ngữ và xử lý văn bản tiếng Việt.
Retrieval layer sử dụng hướng Hybrid Search, kết hợp tìm kiếm từ khóa và tìm kiếm ngữ nghĩa. Cụ thể, hệ thống có thể kết hợp BM25, dense vector search và cơ chế hợp nhất kết quả như RRF để tăng khả năng tìm đúng văn bản trong cả hai trường hợp: người dùng hỏi bằng từ khóa chính xác hoặc hỏi bằng ngôn ngữ tự nhiên.
Pipeline RAG của hệ thống gồm các bước chính: người dùng gửi truy vấn từ frontend, backend kiểm tra quyền truy cập và phạm vi tài liệu, retrieval service truy xuất các đoạn liên quan từ ChromaDB/BM25, sau đó backend sử dụng các đoạn nguồn này để gọi LLM tạo câu trả lời có trích dẫn. Với các trường hợp nguồn không đủ rõ, hệ thống ưu tiên phản hồi theo hướng cảnh báo thiếu căn cứ thay vì để LLM tự suy diễn.
Deployment được thiết kế theo hướng tách frontend và backend. Frontend triển khai trên Vercel, backend triển khai bằng Docker trên cloud service như Render, cơ sở dữ liệu dùng PostgreSQL cloud, retrieval service có thể tách riêng và triển khai qua Hugging Face hoặc một cloud service độc lập. Hệ thống cũng tích hợp logging/tracing AI bằng Langfuse để theo dõi chất lượng câu trả lời, latency, lỗi retrieval và hành vi sử dụng thực tế.
Một trong những khó khăn đầu tiên là dữ liệu pháp lý có cấu trúc phức tạp. Văn bản pháp luật không giống tài liệu văn bản thông thường, vì nội dung được tổ chức theo chương, mục, điều, khoản, điểm và thường có quan hệ tham chiếu lẫn nhau. Nếu chỉ cắt văn bản theo số ký tự hoặc theo đoạn cố định, hệ thống dễ tạo ra các chunk bị đứt giữa câu, mất ngữ cảnh hoặc không đủ thông tin để trích dẫn chính xác.
Để giải quyết, nhóm thử nghiệm nhiều chiến lược chunking. Baseline ban đầu dùng overlap chunking để có kết quả nhanh. Sau đó nhóm phát triển hướng legal-aware chunking, ưu tiên cắt theo cấu trúc pháp lý như Điều, Khoản, Điểm, đồng thời lưu metadata như document_id, chunk_id, tiêu đề văn bản, số ký hiệu, loại văn bản, ngày ban hành, ngày hiệu lực và path pháp lý của đoạn trích. Cách này giúp retrieval không chỉ tìm được đoạn liên quan mà còn hiển thị citation rõ hơn.
Ngoài ra, dữ liệu nội bộ của trường thường không public, có thể nằm ở PDF, file scan hoặc tài liệu không chuẩn hóa. Vì vậy, MVP chọn hướng cho phép tổ chức tự upload tài liệu nội bộ, thay vì cố gắng thu thập toàn bộ dữ liệu nội bộ ngay từ đầu. Đây là quyết định giúp sản phẩm khả thi hơn trong giai đoạn đầu.
Với bài toán pháp chế, hallucination là rủi ro lớn. Một câu trả lời sai nhưng nghe hợp lý có thể gây hại nhiều hơn là không trả lời. Vì vậy, hệ thống được thiết kế theo hướng Retrieval-Augmented Generation, trong đó LLM không trả lời dựa hoàn toàn vào kiến thức nội tại, mà phải dựa trên các nguồn được truy xuất.
Pipeline cơ bản gồm các bước: phân tích câu hỏi, truy xuất nguồn liên quan, chọn và xếp hạng các đoạn phù hợp, sau đó sinh câu trả lời có trích dẫn. Khi nguồn không đủ, hệ thống cần có khả năng cảnh báo hoặc trả lời rằng chưa đủ căn cứ, thay vì bịa ra nội dung.
Nhóm cũng xử lý các vấn đề như tìm kiếm theo số hiệu văn bản, lọc metadata, deduplicate kết quả, cho phép nhiều chunk từ cùng một văn bản khi cần, và sửa các lỗi liên quan đến filter trong vector database. Những xử lý này giúp hệ thống phù hợp hơn với cách người dùng pháp chế thực sự tra cứu: đôi khi họ nhớ số văn bản, đôi khi chỉ nhớ nội dung, đôi khi cần đối chiếu nhiều nguồn cùng lúc.
Citation không chỉ là phần trang trí giao diện, mà là cơ chế tạo niềm tin. Nhóm đã gặp các vấn đề như citation bị trùng lặp, đoạn trích không khớp với nhãn nguồn, hoặc nhiều chunk cùng văn bản bị hiển thị rời rạc gây khó đọc.
Giải pháp là thiết kế lại cách gom citation theo tài liệu, gắn anchor cho từng đoạn trích, hiển thị excerpt tương ứng và loại bỏ các metadata debug khỏi giao diện người dùng. Mục tiêu là để người dùng có thể đọc câu trả lời, bấm vào nguồn, xem đoạn trích và tự kiểm chứng.
Rà soát văn bản khó hơn hỏi đáp vì hệ thống phải đọc toàn văn, phát hiện vị trí có vấn đề, phân loại mức độ rủi ro và đưa ra gợi ý sửa. Nhóm lựa chọn thiết kế review flow theo hướng human-in-the-loop: AI chỉ đưa ra phát hiện và đề xuất, còn người dùng quyết định chấp nhận, từ chối hoặc chỉnh sửa.
Các rủi ro kỹ thuật trong luồng này gồm prompt injection từ nội dung văn bản tải lên, JSON output từ LLM không ổn định, hiệu năng khi tìm vị trí đoạn trích trong văn bản dài và quyền truy cập tài liệu review. Nhóm đã đưa ra hướng hardening như tách phần văn bản người dùng khỏi instruction hệ thống, xử lý JSON robust hơn, tối ưu việc mapping đoạn trích và tách quyền upload tài liệu review khỏi thư viện tài liệu chính.
Vì sản phẩm phục vụ môi trường trường học, dữ liệu nội bộ cần được kiểm soát theo tổ chức. Nhóm quyết định mô hình role đơn giản cho MVP gồm owner, member và viewer. Owner có quyền quản lý tổ chức và tài liệu nội bộ; member có thể sử dụng các chức năng được cấp quyền; viewer có quyền hạn chế hơn. Một tài khoản chỉ thuộc một tổ chức trong phạm vi MVP để giảm độ phức tạp.
Nhóm cũng loại bỏ personal library để tránh làm luồng sản phẩm rối và giảm nguy cơ trộn lẫn tài liệu cá nhân với tài liệu tổ chức. Thay vào đó, dữ liệu được chia thành thư viện văn bản pháp luật, thư viện tổ chức và session uploads.
Từ đầu, nhóm xác định sản phẩm không chỉ là notebook hoặc demo localhost, mà cần có web app deploy được để người dùng thử. Điều này tạo thêm các bài toán về xác thực, OAuth callback, biến môi trường, database migration, CORS, quota cho guest user, logging AI và đặc biệt là cách triển khai tầng retrieval vốn cần embedding model, vector database và BM25 index.
Nếu đặt toàn bộ backend, embedding model và ChromaDB vào cùng một service, hệ thống sẽ nặng, khó deploy và khó mở rộng. Vì vậy, nhóm tách kiến trúc thành các phần độc lập: frontend deploy trên Vercel, backend FastAPI deploy bằng Docker trên Render, PostgreSQL lưu dữ liệu nghiệp vụ, còn Hugging Face Space được dùng làm retrieval service riêng cho BGE-M3, ChromaDB, BM25 cache và Hybrid Search.
Cách tách này giúp backend nhẹ hơn và tập trung vào nghiệp vụ như xác thực, phân quyền, upload, quản lý tổ chức và điều phối request. Trong khi đó, retrieval service có thể được tối ưu riêng cho tác vụ tìm kiếm tài liệu, build index, load embedding model và truy vấn ChromaDB. Đây cũng là hướng phù hợp với MVP vì nhóm có thể cập nhật hoặc scale retrieval service mà không ảnh hưởng trực tiếp đến frontend và backend chính.
Ngoài ra, nhóm tích hợp Langfuse để quan sát các request AI, theo dõi lỗi retrieval, latency, chất lượng câu trả lời và hành vi sử dụng thực tế. Các cơ chế như guest quota, phân quyền theo tổ chức, logging và benchmark giúp sản phẩm tiến gần hơn đến môi trường dùng thử thật thay vì chỉ là demo cục bộ.
Về mặt kỹ thuật, sản phẩm khả thi vì các thành phần cốt lõi đều có thể xây dựng bằng công nghệ hiện có: web app, API backend, PostgreSQL, vector database, embedding model, hybrid retrieval và LLM. Nhóm đã chia nhỏ hệ thống thành các module rõ ràng nên có thể phát triển, kiểm thử và thay thế từng phần mà không phải viết lại toàn bộ.
Quan trọng hơn, hiệu quả kỹ thuật đã được đo lường trên corpus thực tế. Trên bộ benchmark công khai Legal Zalo AI 2021 (788 câu hỏi, 61.425 điều khoản), hệ thống hybrid retrieval của nhóm đạt Recall@10 = 97,14%, nDCG@10 = 89,55% và MRR@10 = 87,03% — vượt top-1 leaderboard HuggingFace MTEB (AITeamVN) +3,05 điểm phần trăm nDCG@10 và +3,69 điểm MRR@10, với latency chỉ 56ms mỗi câu truy vấn. Trên pipeline end-to-end với corpus VBPL nội bộ (202.526 chunks), 30 câu hỏi pháp lý đa văn bản cho kết quả: citation hit rate 83,33%, context keyword recall 96,50%, legal number recall 90,00% và multi-source fact score 90,00%. Thử nghiệm ở quy mô lớn hơn với 4.837 câu hỏi ghi nhận error rate 0% và latency trung bình 31ms mỗi truy vấn.
Lý do chọn kiến trúc hybrid retrieval (dense + BM25 + Reciprocal Rank Fusion) cũng được xác nhận qua ablation test so sánh trực tiếp các phương pháp. Trên tập câu hỏi thông thường, cả dense và hybrid đều đạt hit rate 100%, trong khi BM25 đơn thuần giảm xuống 96,67%. Trên tập câu hỏi khó có nhiều văn bản giao thoa từ khóa — tình huống đặc trưng của corpus pháp lý Việt Nam — BM25 sụp xuống 56,67% hit rate và MRR 0,38, trong khi hybrid giữ được 93,33% hit rate. Điều này cho thấy sự kết hợp là cần thiết: BM25 bắt dính số hiệu văn bản chính xác, dense xử lý ngữ nghĩa câu hỏi.
Về mặt dữ liệu, MVP không phụ thuộc hoàn toàn vào việc sở hữu ngay toàn bộ dữ liệu nội bộ của một tổ chức. Sản phẩm có thể bắt đầu từ văn bản pháp luật công khai và cho phép tổ chức tự tải lên tài liệu nội bộ. Đây là hướng khả thi hơn so với việc cố gắng crawl toàn bộ dữ liệu từ đầu, vì dữ liệu nội bộ thường không public, không đồng nhất và có yêu cầu bảo mật. Corpus công khai đã được index ở quy mô production với 202.526 chunks và BM25 cache xây dựng song song, không cần thêm hạ tầng khi tổ chức bổ sung tài liệu nội bộ.
Về mặt nghiệp vụ, sản phẩm chọn đúng phạm vi hỗ trợ thay vì thay thế con người. Các quyết định pháp lý cuối cùng vẫn thuộc về cán bộ pháp chế. AI đóng vai trò tăng tốc tra cứu, gợi ý rủi ro, chuẩn bị bản nháp và minh bạch hóa căn cứ. Cách tiếp cận này phù hợp với mức độ tin cậy hiện tại của LLM và giảm rủi ro pháp lý.
Về mặt triển khai, sản phẩm có thể vận hành với chi phí hợp lý ở giai đoạn MVP nhờ sử dụng các dịch vụ cloud phổ biến và kiến trúc tách phần. Frontend, backend, database, vector store và retrieval service có thể được scale riêng khi nhu cầu tăng. Các tính năng như guest quota, logging, benchmark và role-based access control giúp sản phẩm tiến gần hơn đến môi trường dùng thử thực tế.
Tuy vậy, sản phẩm vẫn có một số rủi ro cần tiếp tục xử lý. Rủi ro thứ nhất là độ đầy đủ và cập nhật của nguồn dữ liệu — corpus hiện tại phủ văn bản công khai nhưng chưa có cơ chế cập nhật tự động khi luật mới ban hành. Rủi ro thứ hai là chất lượng extraction với tài liệu phức tạp — đo lường thực tế cho thấy chunking theo cấu trúc pháp lý giảm tỷ lệ chunk cắt giữa câu từ 78% xuống còn 56% và giảm tỷ lệ chunk chứa nhiều điều khoản trộn lẫn từ 54% xuống 17% so với phương pháp overlap thông thường, nhưng vẫn còn dư địa cải thiện. Rủi ro thứ ba là hallucination ở các câu hỏi phức tạp — kết quả đo lường cho thấy answer groundedness đạt 70%; 30% còn lại chủ yếu do LLM timeout ở câu hỏi multi-hop, là rủi ro đã định lượng được và có hướng xử lý cụ thể (tách query, tăng timeout). Rủi ro thứ tư là bảo mật dữ liệu nội bộ khi nhiều tổ chức cùng sử dụng hệ thống — hiện đã có scope phân tách (guest, user private, org private) nhưng cần kiểm tra kỹ hơn ở quy mô nhiều tenant. Những rủi ro này không làm sản phẩm mất tính khả thi, nhưng cần được đưa vào roadmap phát triển.
Trong giai đoạn tiếp theo, sản phẩm có thể phát triển theo bốn hướng chính.
Hướng thứ nhất là nâng cấp retrieval. Hệ thống có thể bổ sung temporal filter để ưu tiên văn bản còn hiệu lực, graph retrieval để xử lý quan hệ tham chiếu giữa các văn bản, recursive cross-reference để lần theo các điều khoản được dẫn chiếu và evaluation pipeline để đo citation hit rate, grounding score, latency và mức độ đầy đủ của câu trả lời.
Hướng thứ hai là hoàn thiện review flow. Công cụ rà soát có thể hỗ trợ highlight trực tiếp trên văn bản, phân loại rủi ro chi tiết hơn, cho phép người dùng thêm nhận xét thủ công, re-check sau khi chỉnh sửa và export báo cáo rà soát. Đây là hướng có giá trị thực tế cao vì gắn trực tiếp với workflow pháp chế.
Hướng thứ ba là mở rộng drafting workflow. Hệ thống có thể bổ sung thư viện mẫu văn bản, template theo loại nghiệp vụ, tự động gợi ý căn cứ pháp lý cho từng phần, lưu lịch sử bản nháp và hỗ trợ so sánh các phiên bản chỉnh sửa.
Hướng thứ tư là production hardening. Sản phẩm cần tiếp tục hoàn thiện bảo mật, audit log, rate limit, phân quyền theo tổ chức, logging AI, benchmark định kỳ, feedback button và dashboard theo dõi chất lượng. Đây là các yếu tố cần thiết nếu muốn chuyển từ MVP demo sang sản phẩm có thể pilot với người dùng thật.
Về dài hạn, Legolas AI có thể trở thành một nền tảng trợ lý pháp chế chuyên biệt cho khối trường học, nơi mỗi trường có kho văn bản nội bộ riêng nhưng vẫn dùng chung nền tảng tra cứu văn bản pháp luật, rà soát và soạn thảo. Lợi thế của sản phẩm không nằm ở việc “có chatbot AI”, mà nằm ở khả năng kết hợp dữ liệu pháp lý, dữ liệu nội bộ, retrieval có kiểm chứng, citation minh bạch và quy trình human-in-the-loop phù hợp với nghiệp vụ pháp chế.