Đang chạy mực qua máy in — từng lớp màu một, kiên nhẫn nhé!
№ 01
№ 02
№ 03
№ 04
№ 05
№ 06
MedPay AI · AI·20K Demo Day Zine
№ 37
MedPay AI
MediPayAI là nền tảng trợ lý AI chuyên sâu hỗ trợ người bệnh tra cứu chính xác quyền lợi Bảo hiểm Y tế (BHYT) và giải thích chi phí viện phí theo thời gian thực. Hệ thống ứng dụng kiến trúc GraphRAG / RAG lai đa tầng kết hợp suy luận quan hệ pháp lý, bảo đảm mọi câu trả lời đều có trích dẫn điều khoản chính thức còn hiệu lực và loại bỏ hoàn toàn hiện tượng ảo giác.
Fig. 01 · Ảnh dự án
MediPay AI — Mô tả dự án
1. Tổng quan
MediPay AI là trợ lý AI hỗ trợ tra cứu thông tin Bảo hiểm Y tế (BHYT) và các quy định hành chính y tế tại Việt Nam.
Người dùng có thể đặt câu hỏi bằng ngôn ngữ tự nhiên để tìm hiểu:
Quyền lợi và mức hưởng BHYT.
Điều kiện tham gia BHYT liên tục.
Quy trình chuyển tuyến, khám trái tuyến và điều trị cấp cứu.
Mức đóng BHYT theo từng nhóm đối tượng.
Hiệu lực, sửa đổi và thay thế của văn bản pháp luật.
So sánh các kịch bản chi phí và mức quỹ BHYT chi trả.
Các dữ kiện cần chuẩn bị trước khi hỏi về một tình huống cụ thể.
Điểm khác biệt của MediPay AI là câu trả lời không chỉ dựa trên khả năng sinh ngôn ngữ của mô hình AI, mà phải được đối chiếu với nguồn pháp lý có kiểm chứng, kèm trích dẫn để người dùng có thể kiểm tra lại.
MediPay AI là công cụ hỗ trợ tra cứu và giải thích thông tin, không thay thế tư vấn pháp lý, quyết định của cơ quan BHXH, cơ sở khám chữa bệnh hoặc nhân viên y tế.
2. Bài toán cần giải quyết
2.1. Khó khăn của người dân khi tra cứu BHYT
Thông tin về BHYT thường nằm rải rác trong nhiều loại văn bản:
Luật và luật sửa đổi, bổ sung.
Nghị định, thông tư, nghị quyết.
Văn bản hướng dẫn của cơ quan quản lý.
Quy định riêng theo nhóm đối tượng hoặc tuyến khám chữa bệnh.
Các văn bản có quan hệ sửa đổi, thay thế hoặc dẫn chiếu lẫn nhau.
Người dùng phổ thông thường gặp các vấn đề:
Khó tìm đúng văn bản áp dụng
Một câu hỏi đơn giản có thể liên quan đến nhiều văn bản khác nhau. Người dùng thường không biết nên bắt đầu tra cứu từ luật, nghị định hay thông tư nào.
Khó hiểu ngôn ngữ pháp lý
Văn bản pháp luật có nhiều thuật ngữ, điều kiện, ngoại lệ và cách diễn đạt phức tạp. Việc đọc đúng một điều khoản không đồng nghĩa với việc hiểu đúng phạm vi áp dụng.
Khó xác định hiệu lực của văn bản
Một văn bản có thể đã được sửa đổi, thay thế hoặc hết hiệu lực. Nếu chỉ tìm kiếm theo từ khóa mà không kiểm tra thời điểm áp dụng, người dùng có thể nhận được thông tin đã cũ.
Khó tổng hợp nhiều điều kiện trong cùng một tình huống
Mức hưởng BHYT có thể phụ thuộc vào:
Nhóm đối tượng tham gia.
Nơi đăng ký khám chữa bệnh ban đầu.
§
Phụ lục — Demo & Slides
Video demo
Bản demo trực tiếp
Slide trình bày
Hình thức đúng tuyến, trái tuyến hoặc cấp cứu.
Thời gian tham gia liên tục.
Loại dịch vụ và chi phí thuộc phạm vi hưởng.
Thời điểm phát sinh quyền lợi.
Rủi ro nhận câu trả lời thiếu căn cứ
Các chatbot thông thường có thể tạo ra câu trả lời trôi chảy nhưng:
Dẫn sai văn bản.
Trộn lẫn quy định cũ và mới.
Bỏ qua điều kiện hoặc ngoại lệ.
Tự suy đoán con số.
Không đưa ra nguồn để kiểm chứng.
2.2. Bài toán kỹ thuật
MediPay AI cần giải quyết đồng thời bốn yêu cầu:
Tìm đúng nguồn: truy xuất đúng văn bản, điều, khoản hoặc đoạn nội dung liên quan.
Tìm đúng phiên bản: bảo đảm nguồn được áp dụng đúng theo thời điểm và trạng thái hiệu lực.
Hiểu đúng ngữ cảnh: phân biệt câu hỏi tra cứu văn bản, câu hỏi chính sách, câu hỏi tính toán và câu hỏi cần bổ sung dữ kiện.
Trả lời an toàn: chỉ đưa ra thông tin có căn cứ, không để dữ liệu nội bộ hoặc nội dung chưa được kiểm chứng đi tới người dùng.
3. Giải pháp kỹ thuật
3.1. Giải pháp tổng thể
MediPay AI sử dụng kiến trúc Evidence-first GraphRAG kết hợp:
Tìm kiếm chính xác theo số hiệu văn bản.
Tìm kiếm từ khóa trên PostgreSQL.
Tìm kiếm ngữ nghĩa bằng vector trên Qdrant.
Điều hướng quan hệ văn bản bằng Neo4j.
Kiểm tra hiệu lực và provenance.
Sinh câu trả lời theo schema có cấu trúc.
Kiểm tra claim và citation trước khi trả kết quả.
Nguyên tắc cốt lõi:
Vector database và knowledge graph chỉ dùng để tìm kiếm hoặc điều hướng. Văn bản pháp luật canonical trong PostgreSQL mới là nguồn cuối cùng để tạo căn cứ và trích dẫn.
Tra cứu BHYT: đặt câu hỏi và nhận câu trả lời theo thời gian thực.
Nguồn trích dẫn: xem các đoạn văn bản được sử dụng.
Trình xem văn bản: mở toàn văn đã được làm sạch.
So sánh kịch bản: so sánh nhiều phương án chi phí BHYT.
Checklist điều kiện: xác định các dữ kiện còn thiếu.
Dòng thời gian pháp lý: xem trạng thái hiệu lực và quan hệ văn bản.
Admin dashboard: kiểm duyệt dữ liệu, theo dõi ingestion và quan sát hệ thống.
Frontend không truy cập trực tiếp database hoặc model provider. Mọi request đi qua API backend và được xác thực bằng Firebase ID token.
Backend
Backend sử dụng:
Python 3.11.
FastAPI.
Pydantic.
Uvicorn.
LangGraph.
SQLAlchemy async.
Các lớp chính:
src/api/ HTTP routes, authentication, SSE, serialization
src/application/ Use cases và orchestration
src/domain/ Legal evidence, claims, calculator, contracts
src/services/ Retrieval, rerank, guardrail, chat, timeline
src/integrations/ PostgreSQL, Qdrant, Neo4j, Firebase, LLM, telemetry
src/db/ Session, models, repositories
src/agents/ LangGraph state và processing nodes
PostgreSQL / Supabase
PostgreSQL là nguồn dữ liệu chuẩn của hệ thống, lưu:
Văn bản pháp luật.
Nội dung HTML và text canonical.
Điều, khoản, điểm và legal unit.
Passage/chunk phục vụ lexical search.
Metadata và trạng thái hiệu lực.
Table cells phục vụ các trường hợp có bảng.
Conversation và conversation turns.
Release registry và idempotency records.
Mọi nội dung cuối cùng được dùng để trả lời phải được hydrate trở lại từ PostgreSQL nhằm xác nhận:
release_id.
Content hash.
Source span.
Document identity.
Trạng thái hiệu lực.
Qdrant
Qdrant lưu semantic projection của các passage:
Vector embedding.
dataset_id.
document_id.
unit_id.
Source offsets.
Input hash.
Trạng thái có thể dùng để trả lời.
Qdrant giúp tìm những đoạn văn bản có ý nghĩa tương đồng ngay cả khi câu hỏi không sử dụng đúng từ khóa trong văn bản gốc.
Qdrant không được xem là nguồn citation cuối cùng. Mọi vector hit đều phải được kiểm tra và lấy lại nội dung canonical từ PostgreSQL.
Neo4j
Neo4j lưu các quan hệ giữa văn bản:
Sửa đổi, bổ sung.
Thay thế.
Bãi bỏ.
Dẫn chiếu.
Căn cứ.
Quan hệ hiệu lực theo thời gian.
GraphRAG chỉ được mở cho các câu hỏi temporal hoặc relational. Quy trình xử lý:
Seed document
→ Bounded graph expansion
→ Lấy document ID liên quan
→ Truy vấn lại passage canonical
→ Kiểm tra hiệu lực và provenance
→ Hợp nhất với evidence trực tiếp
Graph không được trả trực tiếp node, edge, score hoặc graph label cho người dùng.
LLM và structured generation
Mô hình ngôn ngữ chỉ đảm nhiệm việc tổng hợp câu trả lời từ evidence đã được kiểm chứng.
Output của model phải tuân thủ schema gồm các nhóm thông tin như:
Xác thực người dùng
→ Kiểm tra input và giới hạn request
→ Phân loại ý định và mức độ rủi ro
→ Chọn route phù hợp
→ Exact/lexical/semantic/graph retrieval
→ Hydrate passage canonical
→ Dedupe, fusion, rerank
→ Kiểm tra hiệu lực, authority và provenance
→ Calculator/table processing nếu cần
→ Structured LLM generation
→ Claim and citation guard
→ Public renderer
→ Trả JSON hoặc SSE
→ Lưu conversation/idempotency record
3.5. Các tính năng sản phẩm
Tra cứu hội thoại
Người dùng nhập câu hỏi bằng tiếng Việt. Hệ thống trả:
Kết luận ngắn gọn.
Điều kiện và quy định liên quan.
Ngoại lệ nếu có.
Danh sách căn cứ pháp lý.
Liên kết tới văn bản nguồn.
API hỗ trợ cả trả JSON đầy đủ và streaming thông qua SSE.
Checklist điều kiện
Checklist không tự kết luận quyền lợi. Tính năng này chỉ xác định các dữ kiện còn thiếu, ví dụ:
Nhóm đối tượng.
Thời gian tham gia liên tục.
Tình trạng chuyển tuyến.
Trường hợp cấp cứu.
Cơ sở khám chữa bệnh.
Thời điểm phát sinh sự kiện.
Sau khi hoàn tất checklist, người dùng có thể chuyển sang màn hình chat với cùng conversation context.
Calculator
Calculator sử dụng Decimal để thực hiện phép tính chính xác:
Chi phí trong phạm vi hưởng.
Tỷ lệ được hưởng.
Phần quỹ BHYT chi trả.
Phần người bệnh cùng chi trả.
Ngưỡng cùng chi trả.
Điều kiện BHYT 5 năm liên tục.
Calculator không tự chọn tỷ lệ pháp lý. Tỷ lệ và điều kiện phải được người dùng hoặc reviewer xác nhận từ nguồn trước khi tính.
Timeline pháp lý
Tính năng timeline cho phép người dùng:
Nhập số hoặc ký hiệu văn bản.
Chọn ngày cần đối chiếu.
Xem trạng thái chưa có hiệu lực, đang có hiệu lực, đã hết hiệu lực hoặc chưa đủ dữ liệu.
Xem văn bản sửa đổi, thay thế, bãi bỏ hoặc dẫn chiếu.
Document viewer
Document viewer hiển thị HTML canonical đã được sanitize ở backend:
Loại bỏ script và event handler.
Chặn URL scheme nguy hiểm.
Chặn frame, form và nội dung active.
Áp dụng CSP và X-Content-Type-Options.
Không công khai database ID hoặc internal chunk ID.
4. Tính khả thi
4.1. Tính khả thi về kỹ thuật
Dự án có tính khả thi cao vì các thành phần chính đều sử dụng công nghệ phổ biến và có hệ sinh thái ổn định:
FastAPI phù hợp với API bất đồng bộ và SSE.
Next.js phù hợp để xây dựng giao diện web hiện đại.
PostgreSQL phù hợp với dữ liệu văn bản, metadata, transaction và RLS.
Qdrant đáp ứng semantic retrieval.
Neo4j phù hợp với quan hệ giữa các văn bản.
Firebase hỗ trợ xác thực nhanh và phổ biến.
Docker Compose giúp chạy môi trường local nhất quán.
LangGraph hỗ trợ điều phối workflow AI có trạng thái.
Kiến trúc modular monolith hiện tại cũng phù hợp với quy mô nhóm nhỏ, tránh chi phí vận hành microservices quá sớm.
4.2. Tính khả thi về dữ liệu
Dữ liệu được tổ chức thành nhiều lớp:
Raw source
→ Canonical corpus
→ PostgreSQL release
→ Qdrant semantic projection
→ Neo4j relation projection
→ Release parity verification
Mỗi release có thể gắn với:
Source manifest.
Content hash.
Dataset ID.
Embedding model.
Collection name.
Graph version.
Migration head.
Thời điểm tạo và kích hoạt.
Cách quản lý theo release giúp:
Tái lập kết quả.
Phát hiện dữ liệu lệch giữa các database.
Hỗ trợ rollback.
Không trộn dữ liệu giữa các phiên bản.
4.3. Tính khả thi về vận hành
Môi trường local có thể chạy bằng Docker Compose với các service:
API.
Web.
PostgreSQL.
Qdrant.
Neo4j.
Redis.
Migration job.
Các lớp bảo vệ đã được thiết kế gồm:
Firebase authentication.
Rate limit.
Cost quota.
Request body limit.
Idempotency key.
Timeout và circuit breaker.
Sanitized HTML viewer.
Structured output.
Secret redaction.
Health/readiness check.
Prometheus metrics.
Langfuse/OpenTelemetry telemetry.
4.4. Tính khả thi về chi phí
Trong giai đoạn MVP, hệ thống có thể sử dụng:
Một backend container.
Một frontend deployment.
PostgreSQL managed.
Qdrant managed hoặc local trong môi trường phát triển.
Neo4j managed hoặc local cho testing.
Redis/Valkey cho cache và rate limit.
Docker Compose trên một EC2 cho backend production ban đầu.
Vercel cho frontend.
Mô hình này giúp giảm chi phí vận hành so với việc triển khai Kubernetes hoặc nhiều microservice ngay từ đầu.
4.5. Các rủi ro còn tồn tại
MediPay AI có thể chạy ở mức MVP/pilot có giám sát, nhưng chưa nên mặc định xem là hệ thống production pháp lý hoàn toàn tự động nếu chưa hoàn tất:
Human-adjudicated legal evaluation.
Kiểm tra đầy đủ citation correctness.
Benchmark end-to-end trên bộ câu hỏi độc lập.
Đánh giá latency p95/p99 với provider thật.
Parity giữa PostgreSQL, Qdrant và Neo4j.
Rollback và restore drill thực tế.
Browser smoke test trên môi trường triển khai thật.
Cấu hình và xoay vòng credential production.
Xác minh collector, tracing và redaction live.
Vì vậy, hướng triển khai phù hợp là:
Internal demo
→ Controlled pilot
→ Human-reviewed beta
→ Production có giám sát
→ Mở rộng sau khi quality gate đạt
5. Hướng phát triển
5.1. Giai đoạn 1 — Hoàn thiện MVP
Mục tiêu:
Ổn định chat BHYT.
Hoàn thiện citation và document viewer.
Hoàn thiện calculator, checklist và timeline.
Hoàn thiện Firebase authentication.
Hoàn thiện local Docker workflow.
Đóng băng API/SSE contract.
Công việc chính:
Chuẩn hóa release manifest.
Hoàn thiện active release pointer.
Kiểm tra parity giữa ba data store.
Bổ sung test cho các tình huống thiếu dữ kiện.
Kiểm thử các trường hợp văn bản hết hiệu lực, sửa đổi và thay thế.
5.2. Giai đoạn 2 — Nâng cao chất lượng retrieval
Mục tiêu:
Tăng recall và precision.
Giảm citation sai.
Giảm tỷ lệ fallback.
Giảm latency của retrieval.
Công việc:
Tối ưu lexical search và semantic search.
Cải thiện reranking.
Bổ sung authority/currentness filtering.
Tối ưu passage segmentation.
Tạo bộ benchmark độc lập có reviewer pháp lý.
So sánh ablation giữa lexical, semantic, graph và reranker.
Đo riêng thời gian PostgreSQL, embedding, Qdrant, Neo4j và generation.
5.3. Giai đoạn 3 — Mở rộng dữ liệu và nghiệp vụ
Có thể bổ sung:
Phân tích bảng kê viện phí.
OCR hóa đơn hoặc giấy tờ y tế.
Trích xuất các khoản phí từ ảnh hoặc PDF.
Đối chiếu chi phí với phạm vi BHYT.
Hỗ trợ nhiều loại hồ sơ hành chính.
Tra cứu quy trình thanh toán theo từng cơ sở.
Hỗ trợ thêm các lĩnh vực bảo hiểm và chính sách y tế khác.
Các tính năng OCR và phân tích hóa đơn chỉ nên được đưa vào production sau khi có:
Chính sách bảo vệ dữ liệu cá nhân.
Cơ chế xóa dữ liệu.
Kiểm soát quyền truy cập.
Kiểm thử độ chính xác OCR.
Cơ chế không lưu ảnh hoặc thông tin nhạy cảm ngoài thời gian cần thiết.
Hiểu tham chiếu như “văn bản này”, “trường hợp trên”, “khoản 2”.
Giữ context theo người dùng.
Không sử dụng câu trả lời cũ làm căn cứ pháp lý.
Công việc:
Lưu conversation và turn ở server.
Bổ sung conversation anchors.
Resolution tham chiếu theo citation của turn trước.
Tự động hỏi lại khi có nhiều văn bản có thể được nhắc tới.
Đánh giá cross-user isolation.
Hỗ trợ xóa hội thoại và chính sách retention.
5.5. Giai đoạn 5 — Production hardening
Mục tiêu:
Đảm bảo hệ thống có thể vận hành ổn định và khôi phục được.
Công việc:
Thiết lập AWS single-host production.
Cấu hình Nginx, TLS và domain.
Hoàn thiện Prometheus/Grafana.
Hoàn thiện OpenTelemetry và Langfuse.
Thiết lập backup và restore định kỳ.
Kiểm thử rollback active release.
Pin image bằng digest.
Tích hợp Gitleaks, Trivy và SBOM vào CI.
Thiết lập alert cho latency, error rate, provider outage và release drift.
5.6. Giai đoạn 6 — Đo lường và mở rộng
Khi có số liệu traffic thực tế, có thể xem xét:
Tách research worker khỏi API.
Tăng số replica API.
Bổ sung distributed queue.
Tối ưu cache theo route.
Tối ưu model routing.
Sử dụng model nhỏ cho query rewrite hoặc classification.
Dùng batch processing cho embedding/evaluation offline.
Mở rộng sang nhiều tỉnh, cơ sở y tế hoặc domain pháp lý khác.
Không nên thêm Kubernetes, microservices hoặc framework graph mới chỉ vì lý do mở rộng trên lý thuyết. Mọi thay đổi kiến trúc cần dựa trên số liệu về:
QPS.
Latency p95/p99.
Chi phí trên mỗi câu trả lời được chấp nhận.
Tỷ lệ lỗi.
Khả năng vận hành và rollback.
6. Tiêu chí đánh giá thành công
MediPay AI được xem là đạt mục tiêu khi đáp ứng được các nhóm tiêu chí sau:
Chất lượng câu trả lời
Câu trả lời có căn cứ pháp lý phù hợp.
Citation trỏ đúng văn bản và đoạn nội dung.
Không trộn văn bản đã hết hiệu lực với văn bản hiện hành.
Không tự bịa tỷ lệ, số tiền hoặc điều kiện.
Biết hỏi lại khi thiếu dữ kiện quan trọng.
Biết từ chối hoặc nêu uncertainty khi không đủ evidence.
An toàn và bảo mật
Không lộ secret, token, database ID hoặc internal chunk.
Conversation được tách biệt theo người dùng.
HTML nguồn được sanitize.
Request có giới hạn kích thước, tốc độ và chi phí.
Có idempotency khi retry.
Có audit trail cho thao tác quản trị.
Hiệu năng
Chat phản hồi trong thời gian chấp nhận được.
SSE phát lifecycle event đúng schema.
Dependency timeout không làm treo toàn bộ request.
Có fallback khi Qdrant, Neo4j, Redis hoặc provider gặp sự cố.
Không để cache thay thế dữ liệu canonical.
Khả năng vận hành
Có thể dựng môi trường từ repository sạch.
Có migration one-shot và migration checksum.
Có health/readiness endpoint.
Có backup, restore và rollback.
Có telemetry và metrics đủ để điều tra lỗi.
Có benchmark tái lập theo release, model và prompt version.
7. Kết luận
MediPay AI giải quyết một nhu cầu thực tế: giúp người dân tiếp cận và hiểu thông tin BHYT dễ dàng hơn, đồng thời giảm rủi ro do tra cứu nhầm văn bản hoặc diễn giải thiếu điều kiện.
Giải pháp sử dụng kiến trúc kết hợp giữa:
Tìm kiếm chính xác.
Tìm kiếm từ khóa.
Tìm kiếm ngữ nghĩa.
GraphRAG có giới hạn.
Dữ liệu canonical có provenance.
Sinh câu trả lời theo schema.
Kiểm tra claim và citation.
Authentication, observability và release management.
Kiến trúc hiện tại đủ phù hợp để phát triển MVP và triển khai pilot có kiểm soát. Hướng ưu tiên tiếp theo không phải là bổ sung thêm framework, mà là nâng cao:
Độ chính xác của retrieval và citation.
Chất lượng đánh giá bởi reviewer độc lập.
Độ ổn định và latency trên môi trường thật.
Khả năng backup, rollback và khôi phục.
Chính sách bảo vệ dữ liệu người dùng.
Khi các quality gate và operational gate được hoàn thiện, MediPay AI có thể mở rộng từ trợ lý tra cứu BHYT thành một nền tảng hỗ trợ quyết định hành chính y tế có kiểm chứng.# MediPay AI — Mô tả dự án
1. Tổng quan
MediPay AI là trợ lý AI hỗ trợ tra cứu thông tin Bảo hiểm Y tế (BHYT) và các quy định hành chính y tế tại Việt Nam.
Người dùng có thể đặt câu hỏi bằng ngôn ngữ tự nhiên để tìm hiểu:
Quyền lợi và mức hưởng BHYT.
Điều kiện tham gia BHYT liên tục.
Quy trình chuyển tuyến, khám trái tuyến và điều trị cấp cứu.
Mức đóng BHYT theo từng nhóm đối tượng.
Hiệu lực, sửa đổi và thay thế của văn bản pháp luật.
So sánh các kịch bản chi phí và mức quỹ BHYT chi trả.
Các dữ kiện cần chuẩn bị trước khi hỏi về một tình huống cụ thể.
Điểm khác biệt của MediPay AI là câu trả lời không chỉ dựa trên khả năng sinh ngôn ngữ của mô hình AI, mà phải được đối chiếu với nguồn pháp lý có kiểm chứng, kèm trích dẫn để người dùng có thể kiểm tra lại.
MediPay AI là công cụ hỗ trợ tra cứu và giải thích thông tin, không thay thế tư vấn pháp lý, quyết định của cơ quan BHXH, cơ sở khám chữa bệnh hoặc nhân viên y tế.
2. Bài toán cần giải quyết
2.1. Khó khăn của người dân khi tra cứu BHYT
Thông tin về BHYT thường nằm rải rác trong nhiều loại văn bản:
Luật và luật sửa đổi, bổ sung.
Nghị định, thông tư, nghị quyết.
Văn bản hướng dẫn của cơ quan quản lý.
Quy định riêng theo nhóm đối tượng hoặc tuyến khám chữa bệnh.
Các văn bản có quan hệ sửa đổi, thay thế hoặc dẫn chiếu lẫn nhau.
Người dùng phổ thông thường gặp các vấn đề:
Khó tìm đúng văn bản áp dụng
Một câu hỏi đơn giản có thể liên quan đến nhiều văn bản khác nhau. Người dùng thường không biết nên bắt đầu tra cứu từ luật, nghị định hay thông tư nào.
Khó hiểu ngôn ngữ pháp lý
Văn bản pháp luật có nhiều thuật ngữ, điều kiện, ngoại lệ và cách diễn đạt phức tạp. Việc đọc đúng một điều khoản không đồng nghĩa với việc hiểu đúng phạm vi áp dụng.
Khó xác định hiệu lực của văn bản
Một văn bản có thể đã được sửa đổi, thay thế hoặc hết hiệu lực. Nếu chỉ tìm kiếm theo từ khóa mà không kiểm tra thời điểm áp dụng, người dùng có thể nhận được thông tin đã cũ.
Khó tổng hợp nhiều điều kiện trong cùng một tình huống
Mức hưởng BHYT có thể phụ thuộc vào:
Nhóm đối tượng tham gia.
Nơi đăng ký khám chữa bệnh ban đầu.
Hình thức đúng tuyến, trái tuyến hoặc cấp cứu.
Thời gian tham gia liên tục.
Loại dịch vụ và chi phí thuộc phạm vi hưởng.
Thời điểm phát sinh quyền lợi.
Rủi ro nhận câu trả lời thiếu căn cứ
Các chatbot thông thường có thể tạo ra câu trả lời trôi chảy nhưng:
Dẫn sai văn bản.
Trộn lẫn quy định cũ và mới.
Bỏ qua điều kiện hoặc ngoại lệ.
Tự suy đoán con số.
Không đưa ra nguồn để kiểm chứng.
2.2. Bài toán kỹ thuật
MediPay AI cần giải quyết đồng thời bốn yêu cầu:
Tìm đúng nguồn: truy xuất đúng văn bản, điều, khoản hoặc đoạn nội dung liên quan.
Tìm đúng phiên bản: bảo đảm nguồn được áp dụng đúng theo thời điểm và trạng thái hiệu lực.
Hiểu đúng ngữ cảnh: phân biệt câu hỏi tra cứu văn bản, câu hỏi chính sách, câu hỏi tính toán và câu hỏi cần bổ sung dữ kiện.
Trả lời an toàn: chỉ đưa ra thông tin có căn cứ, không để dữ liệu nội bộ hoặc nội dung chưa được kiểm chứng đi tới người dùng.
3. Giải pháp kỹ thuật
3.1. Giải pháp tổng thể
MediPay AI sử dụng kiến trúc Evidence-first GraphRAG kết hợp:
Tìm kiếm chính xác theo số hiệu văn bản.
Tìm kiếm từ khóa trên PostgreSQL.
Tìm kiếm ngữ nghĩa bằng vector trên Qdrant.
Điều hướng quan hệ văn bản bằng Neo4j.
Kiểm tra hiệu lực và provenance.
Sinh câu trả lời theo schema có cấu trúc.
Kiểm tra claim và citation trước khi trả kết quả.
Nguyên tắc cốt lõi:
Vector database và knowledge graph chỉ dùng để tìm kiếm hoặc điều hướng. Văn bản pháp luật canonical trong PostgreSQL mới là nguồn cuối cùng để tạo căn cứ và trích dẫn.
Tra cứu BHYT: đặt câu hỏi và nhận câu trả lời theo thời gian thực.
Nguồn trích dẫn: xem các đoạn văn bản được sử dụng.
Trình xem văn bản: mở toàn văn đã được làm sạch.
So sánh kịch bản: so sánh nhiều phương án chi phí BHYT.
Checklist điều kiện: xác định các dữ kiện còn thiếu.
Dòng thời gian pháp lý: xem trạng thái hiệu lực và quan hệ văn bản.
Admin dashboard: kiểm duyệt dữ liệu, theo dõi ingestion và quan sát hệ thống.
Frontend không truy cập trực tiếp database hoặc model provider. Mọi request đi qua API backend và được xác thực bằng Firebase ID token.
Backend
Backend sử dụng:
Python 3.11.
FastAPI.
Pydantic.
Uvicorn.
LangGraph.
SQLAlchemy async.
Các lớp chính:
src/api/ HTTP routes, authentication, SSE, serialization
src/application/ Use cases và orchestration
src/domain/ Legal evidence, claims, calculator, contracts
src/services/ Retrieval, rerank, guardrail, chat, timeline
src/integrations/ PostgreSQL, Qdrant, Neo4j, Firebase, LLM, telemetry
src/db/ Session, models, repositories
src/agents/ LangGraph state và processing nodes
PostgreSQL / Supabase
PostgreSQL là nguồn dữ liệu chuẩn của hệ thống, lưu:
Văn bản pháp luật.
Nội dung HTML và text canonical.
Điều, khoản, điểm và legal unit.
Passage/chunk phục vụ lexical search.
Metadata và trạng thái hiệu lực.
Table cells phục vụ các trường hợp có bảng.
Conversation và conversation turns.
Release registry và idempotency records.
Mọi nội dung cuối cùng được dùng để trả lời phải được hydrate trở lại từ PostgreSQL nhằm xác nhận:
release_id.
Content hash.
Source span.
Document identity.
Trạng thái hiệu lực.
Qdrant
Qdrant lưu semantic projection của các passage:
Vector embedding.
dataset_id.
document_id.
unit_id.
Source offsets.
Input hash.
Trạng thái có thể dùng để trả lời.
Qdrant giúp tìm những đoạn văn bản có ý nghĩa tương đồng ngay cả khi câu hỏi không sử dụng đúng từ khóa trong văn bản gốc.
Qdrant không được xem là nguồn citation cuối cùng. Mọi vector hit đều phải được kiểm tra và lấy lại nội dung canonical từ PostgreSQL.
Neo4j
Neo4j lưu các quan hệ giữa văn bản:
Sửa đổi, bổ sung.
Thay thế.
Bãi bỏ.
Dẫn chiếu.
Căn cứ.
Quan hệ hiệu lực theo thời gian.
GraphRAG chỉ được mở cho các câu hỏi temporal hoặc relational. Quy trình xử lý:
Seed document
→ Bounded graph expansion
→ Lấy document ID liên quan
→ Truy vấn lại passage canonical
→ Kiểm tra hiệu lực và provenance
→ Hợp nhất với evidence trực tiếp
Graph không được trả trực tiếp node, edge, score hoặc graph label cho người dùng.
LLM và structured generation
Mô hình ngôn ngữ chỉ đảm nhiệm việc tổng hợp câu trả lời từ evidence đã được kiểm chứng.
Output của model phải tuân thủ schema gồm các nhóm thông tin như:
Xác thực người dùng
→ Kiểm tra input và giới hạn request
→ Phân loại ý định và mức độ rủi ro
→ Chọn route phù hợp
→ Exact/lexical/semantic/graph retrieval
→ Hydrate passage canonical
→ Dedupe, fusion, rerank
→ Kiểm tra hiệu lực, authority và provenance
→ Calculator/table processing nếu cần
→ Structured LLM generation
→ Claim and citation guard
→ Public renderer
→ Trả JSON hoặc SSE
→ Lưu conversation/idempotency record
3.5. Các tính năng sản phẩm
Tra cứu hội thoại
Người dùng nhập câu hỏi bằng tiếng Việt. Hệ thống trả:
Kết luận ngắn gọn.
Điều kiện và quy định liên quan.
Ngoại lệ nếu có.
Danh sách căn cứ pháp lý.
Liên kết tới văn bản nguồn.
API hỗ trợ cả trả JSON đầy đủ và streaming thông qua SSE.
Checklist điều kiện
Checklist không tự kết luận quyền lợi. Tính năng này chỉ xác định các dữ kiện còn thiếu, ví dụ:
Nhóm đối tượng.
Thời gian tham gia liên tục.
Tình trạng chuyển tuyến.
Trường hợp cấp cứu.
Cơ sở khám chữa bệnh.
Thời điểm phát sinh sự kiện.
Sau khi hoàn tất checklist, người dùng có thể chuyển sang màn hình chat với cùng conversation context.
Calculator
Calculator sử dụng Decimal để thực hiện phép tính chính xác:
Chi phí trong phạm vi hưởng.
Tỷ lệ được hưởng.
Phần quỹ BHYT chi trả.
Phần người bệnh cùng chi trả.
Ngưỡng cùng chi trả.
Điều kiện BHYT 5 năm liên tục.
Calculator không tự chọn tỷ lệ pháp lý. Tỷ lệ và điều kiện phải được người dùng hoặc reviewer xác nhận từ nguồn trước khi tính.
Timeline pháp lý
Tính năng timeline cho phép người dùng:
Nhập số hoặc ký hiệu văn bản.
Chọn ngày cần đối chiếu.
Xem trạng thái chưa có hiệu lực, đang có hiệu lực, đã hết hiệu lực hoặc chưa đủ dữ liệu.
Xem văn bản sửa đổi, thay thế, bãi bỏ hoặc dẫn chiếu.
Document viewer
Document viewer hiển thị HTML canonical đã được sanitize ở backend:
Loại bỏ script và event handler.
Chặn URL scheme nguy hiểm.
Chặn frame, form và nội dung active.
Áp dụng CSP và X-Content-Type-Options.
Không công khai database ID hoặc internal chunk ID.
4. Tính khả thi
4.1. Tính khả thi về kỹ thuật
Dự án có tính khả thi cao vì các thành phần chính đều sử dụng công nghệ phổ biến và có hệ sinh thái ổn định:
FastAPI phù hợp với API bất đồng bộ và SSE.
Next.js phù hợp để xây dựng giao diện web hiện đại.
PostgreSQL phù hợp với dữ liệu văn bản, metadata, transaction và RLS.
Qdrant đáp ứng semantic retrieval.
Neo4j phù hợp với quan hệ giữa các văn bản.
Firebase hỗ trợ xác thực nhanh và phổ biến.
Docker Compose giúp chạy môi trường local nhất quán.
LangGraph hỗ trợ điều phối workflow AI có trạng thái.
Kiến trúc modular monolith hiện tại cũng phù hợp với quy mô nhóm nhỏ, tránh chi phí vận hành microservices quá sớm.
4.2. Tính khả thi về dữ liệu
Dữ liệu được tổ chức thành nhiều lớp:
Raw source
→ Canonical corpus
→ PostgreSQL release
→ Qdrant semantic projection
→ Neo4j relation projection
→ Release parity verification
Mỗi release có thể gắn với:
Source manifest.
Content hash.
Dataset ID.
Embedding model.
Collection name.
Graph version.
Migration head.
Thời điểm tạo và kích hoạt.
Cách quản lý theo release giúp:
Tái lập kết quả.
Phát hiện dữ liệu lệch giữa các database.
Hỗ trợ rollback.
Không trộn dữ liệu giữa các phiên bản.
4.3. Tính khả thi về vận hành
Môi trường local có thể chạy bằng Docker Compose với các service:
API.
Web.
PostgreSQL.
Qdrant.
Neo4j.
Redis.
Migration job.
Các lớp bảo vệ đã được thiết kế gồm:
Firebase authentication.
Rate limit.
Cost quota.
Request body limit.
Idempotency key.
Timeout và circuit breaker.
Sanitized HTML viewer.
Structured output.
Secret redaction.
Health/readiness check.
Prometheus metrics.
Langfuse/OpenTelemetry telemetry.
4.4. Tính khả thi về chi phí
Trong giai đoạn MVP, hệ thống có thể sử dụng:
Một backend container.
Một frontend deployment.
PostgreSQL managed.
Qdrant managed hoặc local trong môi trường phát triển.
Neo4j managed hoặc local cho testing.
Redis/Valkey cho cache và rate limit.
Docker Compose trên một EC2 cho backend production ban đầu.
Vercel cho frontend.
Mô hình này giúp giảm chi phí vận hành so với việc triển khai Kubernetes hoặc nhiều microservice ngay từ đầu.
4.5. Các rủi ro còn tồn tại
MediPay AI có thể chạy ở mức MVP/pilot có giám sát, nhưng chưa nên mặc định xem là hệ thống production pháp lý hoàn toàn tự động nếu chưa hoàn tất:
Human-adjudicated legal evaluation.
Kiểm tra đầy đủ citation correctness.
Benchmark end-to-end trên bộ câu hỏi độc lập.
Đánh giá latency p95/p99 với provider thật.
Parity giữa PostgreSQL, Qdrant và Neo4j.
Rollback và restore drill thực tế.
Browser smoke test trên môi trường triển khai thật.
Cấu hình và xoay vòng credential production.
Xác minh collector, tracing và redaction live.
Vì vậy, hướng triển khai phù hợp là:
Internal demo
→ Controlled pilot
→ Human-reviewed beta
→ Production có giám sát
→ Mở rộng sau khi quality gate đạt
5. Hướng phát triển
5.1. Giai đoạn 1 — Hoàn thiện MVP
Mục tiêu:
Ổn định chat BHYT.
Hoàn thiện citation và document viewer.
Hoàn thiện calculator, checklist và timeline.
Hoàn thiện Firebase authentication.
Hoàn thiện local Docker workflow.
Đóng băng API/SSE contract.
Công việc chính:
Chuẩn hóa release manifest.
Hoàn thiện active release pointer.
Kiểm tra parity giữa ba data store.
Bổ sung test cho các tình huống thiếu dữ kiện.
Kiểm thử các trường hợp văn bản hết hiệu lực, sửa đổi và thay thế.
5.2. Giai đoạn 2 — Nâng cao chất lượng retrieval
Mục tiêu:
Tăng recall và precision.
Giảm citation sai.
Giảm tỷ lệ fallback.
Giảm latency của retrieval.
Công việc:
Tối ưu lexical search và semantic search.
Cải thiện reranking.
Bổ sung authority/currentness filtering.
Tối ưu passage segmentation.
Tạo bộ benchmark độc lập có reviewer pháp lý.
So sánh ablation giữa lexical, semantic, graph và reranker.
Đo riêng thời gian PostgreSQL, embedding, Qdrant, Neo4j và generation.
5.3. Giai đoạn 3 — Mở rộng dữ liệu và nghiệp vụ
Có thể bổ sung:
Phân tích bảng kê viện phí.
OCR hóa đơn hoặc giấy tờ y tế.
Trích xuất các khoản phí từ ảnh hoặc PDF.
Đối chiếu chi phí với phạm vi BHYT.
Hỗ trợ nhiều loại hồ sơ hành chính.
Tra cứu quy trình thanh toán theo từng cơ sở.
Hỗ trợ thêm các lĩnh vực bảo hiểm và chính sách y tế khác.
Các tính năng OCR và phân tích hóa đơn chỉ nên được đưa vào production sau khi có:
Chính sách bảo vệ dữ liệu cá nhân.
Cơ chế xóa dữ liệu.
Kiểm soát quyền truy cập.
Kiểm thử độ chính xác OCR.
Cơ chế không lưu ảnh hoặc thông tin nhạy cảm ngoài thời gian cần thiết.
Hiểu tham chiếu như “văn bản này”, “trường hợp trên”, “khoản 2”.
Giữ context theo người dùng.
Không sử dụng câu trả lời cũ làm căn cứ pháp lý.
Công việc:
Lưu conversation và turn ở server.
Bổ sung conversation anchors.
Resolution tham chiếu theo citation của turn trước.
Tự động hỏi lại khi có nhiều văn bản có thể được nhắc tới.
Đánh giá cross-user isolation.
Hỗ trợ xóa hội thoại và chính sách retention.
5.5. Giai đoạn 5 — Production hardening
Mục tiêu:
Đảm bảo hệ thống có thể vận hành ổn định và khôi phục được.
Công việc:
Thiết lập AWS single-host production.
Cấu hình Nginx, TLS và domain.
Hoàn thiện Prometheus/Grafana.
Hoàn thiện OpenTelemetry và Langfuse.
Thiết lập backup và restore định kỳ.
Kiểm thử rollback active release.
Pin image bằng digest.
Tích hợp Gitleaks, Trivy và SBOM vào CI.
Thiết lập alert cho latency, error rate, provider outage và release drift.
5.6. Giai đoạn 6 — Đo lường và mở rộng
Khi có số liệu traffic thực tế, có thể xem xét:
Tách research worker khỏi API.
Tăng số replica API.
Bổ sung distributed queue.
Tối ưu cache theo route.
Tối ưu model routing.
Sử dụng model nhỏ cho query rewrite hoặc classification.
Dùng batch processing cho embedding/evaluation offline.
Mở rộng sang nhiều tỉnh, cơ sở y tế hoặc domain pháp lý khác.
Không nên thêm Kubernetes, microservices hoặc framework graph mới chỉ vì lý do mở rộng trên lý thuyết. Mọi thay đổi kiến trúc cần dựa trên số liệu về:
QPS.
Latency p95/p99.
Chi phí trên mỗi câu trả lời được chấp nhận.
Tỷ lệ lỗi.
Khả năng vận hành và rollback.
6. Tiêu chí đánh giá thành công
MediPay AI được xem là đạt mục tiêu khi đáp ứng được các nhóm tiêu chí sau:
Chất lượng câu trả lời
Câu trả lời có căn cứ pháp lý phù hợp.
Citation trỏ đúng văn bản và đoạn nội dung.
Không trộn văn bản đã hết hiệu lực với văn bản hiện hành.
Không tự bịa tỷ lệ, số tiền hoặc điều kiện.
Biết hỏi lại khi thiếu dữ kiện quan trọng.
Biết từ chối hoặc nêu uncertainty khi không đủ evidence.
An toàn và bảo mật
Không lộ secret, token, database ID hoặc internal chunk.
Conversation được tách biệt theo người dùng.
HTML nguồn được sanitize.
Request có giới hạn kích thước, tốc độ và chi phí.
Có idempotency khi retry.
Có audit trail cho thao tác quản trị.
Hiệu năng
Chat phản hồi trong thời gian chấp nhận được.
SSE phát lifecycle event đúng schema.
Dependency timeout không làm treo toàn bộ request.
Có fallback khi Qdrant, Neo4j, Redis hoặc provider gặp sự cố.
Không để cache thay thế dữ liệu canonical.
Khả năng vận hành
Có thể dựng môi trường từ repository sạch.
Có migration one-shot và migration checksum.
Có health/readiness endpoint.
Có backup, restore và rollback.
Có telemetry và metrics đủ để điều tra lỗi.
Có benchmark tái lập theo release, model và prompt version.
7. Kết luận
MediPay AI giải quyết một nhu cầu thực tế: giúp người dân tiếp cận và hiểu thông tin BHYT dễ dàng hơn, đồng thời giảm rủi ro do tra cứu nhầm văn bản hoặc diễn giải thiếu điều kiện.
Giải pháp sử dụng kiến trúc kết hợp giữa:
Tìm kiếm chính xác.
Tìm kiếm từ khóa.
Tìm kiếm ngữ nghĩa.
GraphRAG có giới hạn.
Dữ liệu canonical có provenance.
Sinh câu trả lời theo schema.
Kiểm tra claim và citation.
Authentication, observability và release management.
Kiến trúc hiện tại đủ phù hợp để phát triển MVP và triển khai pilot có kiểm soát. Hướng ưu tiên tiếp theo không phải là bổ sung thêm framework, mà là nâng cao:
Độ chính xác của retrieval và citation.
Chất lượng đánh giá bởi reviewer độc lập.
Độ ổn định và latency trên môi trường thật.
Khả năng backup, rollback và khôi phục.
Chính sách bảo vệ dữ liệu người dùng.
Khi các quality gate và operational gate được hoàn thiện, MediPay AI có thể mở rộng từ trợ lý tra cứu BHYT thành một nền tảng hỗ trợ quyết định hành chính y tế có kiểm chứng.
