⚠️ Lưu ý: Báo cáo đánh giá Obsidian vs này là của kiến trúc v4.0. Quyết định cuối cùng (Context Loading, không dùng RAG/ChromaDB) đã được ghi nhận trong ADR tại 10_KIEN_TRUC_VA_KE_HOACH_TRIEN_KHAI.md.

Báo cáo Deep Research: Obsidian-Markdown Context Engineering vs. RAG Pipeline cho Dự án CXK

Ngày thực hiện: 25/09/2026
Dự án: Trợ lý AI (CXK)
Thực hiện bởi: AI Architecture Researcher
Độc giả: Nhóm phát triển (, , Đội kỹ thuật Vaga)

Tóm tắt Điều hành (Executive Summary)

Báo cáo này đánh giá tính khả thi của việc sử dụng Obsidian-Markdown Context Engineering (nạp trực tiếp thư mục Markdown vào context window lớn của ) để thay thế hoặc bổ sung cho RAG pipeline truyền thống (chunk → embed → vector DB).

Với quy mô dữ liệu MVP của dự án CXK (~2 MB text, tương đương ~500.000 tokens) và việc sử dụng Gemini 2.5 Pro/Flash (hỗ trợ 1M-2M tokens), phương pháp Obsidian-Markdown tỏ ra vượt trội về độ an toàn y khoa (medical safety), chi phí triển khai, và khả năng bảo toàn ngữ cảnh. Tuy nhiên, RAG vẫn cần thiết cho khả năng mở rộng dài hạn. Báo cáo đề xuất một mô hình Hybrid: Dùng Obsidian làm Source of Truth và nạp trực tiếp file nguyên bản (File-level routing) kết hợp fallback.

PHẦN A — Khảo sát và Định nghĩa hai Phương pháp

A1. Phương pháp RAG truyền thống (Retrieval-Augmented Generation)

  • Mô tả kiến trúc: Hệ thống chia nhỏ tài liệu thành các đoạn (chunks), biến đổi thành vector (), lưu vào Vector DB (như ChromaDB), và truy xuất bằng tìm kiếm ngữ nghĩa (semantic search) khi có câu hỏi.
  • Workflow: Ingest → Chunk → Embed → Store → Query → Retrieve → Augment → Generate.
  • Đặc điểm: Tối ưu chi phí token, hoạt động tốt với kho dữ liệu khổng lồ (hàng GBs) [1]. Tuy nhiên, dễ làm mất ngữ cảnh y khoa do cắt xén không khéo [CẦN XÁC MINH].

A2. Phương pháp Obsidian-Markdown (Context Engineering)

  • Định nghĩa: Sử dụng hệ thống file Markdown có cấu trúc, quản lý bằng Obsidian. Dựa vào context window siêu lớn (1M+ tokens của Gemini), AI đọc trực tiếp file Markdown hoặc toàn bộ Vault thay vì tìm kiếm vector.
  • Cơ chế: Tổ chức cấu trúc thư mục, wikilinks ([[link]]), tags, và frontmatter ( - knowledge card) làm xương sống. dùng hệ thống này như một "bộ nhớ ngoài" và đọc trực tiếp file phù hợp nhờ các Map of Content (MOC).
  • Tính năng Obsidian: Graph view giúp CVYK thấy liên kết bệnh lý, Templates chuẩn hóa định dạng, Local-first đảm bảo bảo mật y khoa.

A3. Các mô hình lai (Hybrid)

  • File-level Routing (Structured Retrieval): LLM phân loại câu hỏi → Chọn trực tiếp các file Markdown (Knowledge Cards) cần thiết nguyên vẹn → Nạp vào prompt. Không chunking.
  • Obsidian làm Source of Truth: Quản lý tri thức bằng Obsidian offline, nhưng khi deploy production thì vẫn index vào RAG để tối ưu tốc độ [2].

PHẦN B — Đánh giá So sánh Chi tiết (12 Tiêu chí)

Điểm từ 1 (Thấp/Kém) đến 5 (Cao/Tốt).

# Tiêu chí RAG truyền thống Obsidian-Markdown Giải thích & Phân tích
B1 Chất lượng truy xuất 4 5 RAG có thể truy xuất sai do nhiễu vector. Obsidian-Markdown (nhồi toàn bộ file) không bỏ sót thông tin.
B2 Bảo toàn ngữ cảnh 2 5 RAG cắt nhỏ file (chunking) dễ làm đứt gãy mối quan hệ y khoa. Obsidian nạp file nguyên bản.
B3 Độ phức tạp triển khai 2 5 RAG cần pipeline phức tạp (embedding, ChromaDB). Obsidian chỉ cần đọc file text. Rất hợp cho 1 NCS.
B4 Chi phí vận hành 4 2 Obsidian nạp token lớn gây tốn kém phí trên mỗi lượt gọi, RAG rẻ hơn nhiều [3].
B5 Khả năng mở rộng 5 2 Khi dữ liệu lên hàng chục nghìn file, context window sẽ bị tràn. RAG scale vô hạn.
B6 Tính minh bạch (Transparency) 3 5 NCS và CVYK có thể mở Obsidian đọc y hệt những gì AI đọc. RAG là hộp đen vector.
B7 Khả năng cập nhật 3 5 Sửa file trong Obsidian là xong. RAG cần re-index, re-embed, xóa vector cũ.
B8 (truy vết nguồn (provenance)) 4 5 File Markdown có sẵn meta data rõ ràng. RAG đôi khi ghép nhầm chunk của nguồn khác.
B9 An toàn y khoa (Medical Safety) 3 5 Ngữ cảnh toàn vẹn giúp AI tránh hallucinate các nằm ngoài chunk.
B10 Phù hợp nguồn lực 2 5 Đội 1 NCS + AI agents rất khó duy trì 1 pipeline RAG ổn định. Quản lý folder là tối ưu.
B11 Tính offline/local-first 2 5 Obsidian hoàn toàn offline, bảo mật dữ liệu tuyệt đối trong khâu biên soạn.
B12 Tương thích hạ tầng 4 5 Cả 2 đều chạy được trên Windows Server + , nhưng đọc file text trực tiếp dễ cài đặt hơn ChromaDB.

PHẦN C — Phân tích SWOT

C1. RAG truyền thống

  • Điểm mạnh (Strengths): Chi phí query rẻ, mở rộng không giới hạn, tốc độ phản hồi nhanh.
  • Điểm yếu (Weaknesses): Mất ngữ cảnh khi chunk, triển khai phức tạp, khó debug cho người không chuyên.
  • Cơ hội (Opportunities): Chuẩn bị tốt cho giai đoạn scale-up sau này.
  • Thách thức (Threats): Nguy cơ an toàn y khoa do lấy nhầm/thiếu chunk.

C2. Obsidian-Markdown (Context Engineering)

  • Điểm mạnh: Giữ 100% ngữ cảnh y khoa, dễ setup, cực kỳ minh bạch cho CVYK review.
  • Điểm yếu: Phụ thuộc vào context window của LLM, chi phí API cao nếu nhồi 1M token/query.
  • Cơ hội: Phù hợp hoàn hảo cho MVP (dữ liệu chỉ ~2MB).
  • Thách thức: API limits (Rate limit của Gemini) và độ trễ (latency) khi xử lý 1M tokens.

C3. Mô hình Hybrid (Structured Retrieval)

  • Điểm mạnh: Cân bằng giữa bảo toàn ngữ cảnh và chi phí. Định tuyến file thay vì chunk.
  • Điểm yếu: Cần logic code định tuyến (Router) phức tạp hơn một chút.

PHẦN D — Khuyến nghị và Quyết định

D1. Ma trận quyết định (Decision Matrix)

Trọng số: 3 = rất quan trọng cho CXK, 2 = quan trọng, 1 = cần xét nhưng không quyết định.
Điểm: Lấy từ bảng B (1–5), nhân trọng số.

# Tiêu chí Trọng số RAG (điểm × w) Obsidian (điểm × w) Hybrid (điểm × w)
B1 Chất lượng truy xuất 2 4×2 = 8 5×2 = 10 5×2 = 10
B2 Bảo toàn ngữ cảnh 3 2×3 = 6 5×3 = 15 5×3 = 15
B3 Độ phức tạp triển khai 2 2×2 = 4 5×2 = 10 4×2 = 8
B4 Chi phí vận hành 2 4×2 = 8 2×2 = 4 3×2 = 6
B5 Khả năng mở rộng 1 5×1 = 5 2×1 = 2 4×1 = 4
B6 Tính minh bạch & kiểm soát 2 3×2 = 6 5×2 = 10 5×2 = 10
B7 Khả năng cập nhật 2 3×2 = 6 5×2 = 10 5×2 = 10
B8 Truy vết nguồn (truy vết nguồn (provenance)) 3 4×3 = 12 5×3 = 15 5×3 = 15
B9 An toàn y khoa 3 3×3 = 9 5×3 = 15 5×3 = 15
B10 Phù hợp nguồn lực 3 2×3 = 6 5×3 = 15 4×3 = 12
B11 Tính offline/local-first 1 2×1 = 2 5×1 = 5 4×1 = 4
B12 Tương thích hạ tầng 1 4×1 = 4 5×1 = 5 5×1 = 5
Tá»"NG 25 76 116 114

Kết luận: Obsidian-Markdown thuần túy (116) và Hybrid (114) gần bằng nhau, cả hai đều vượt xa RAG (76). Hybrid được ưu tiên vì cân bằng tốt hơn ở B4 (chi phí) và B5 (mở rộng) — hai yếu tố sẽ quan trọng hơn khi dự án scale lên sau MVP.

D2. Khuyến nghị rõ ràng

Khuyến nghị: CHỌN MÔ HÌNH HYBRID (Structured Retrieval / File-level Routing) kết hợp Obsidian làm hệ thống quản lý nội dung.

Lý do:
1. An toàn y khoa là số 1. Việc cắt nhỏ thẻ tri thức (knowledge card) y khoa có cấu trúc thành các chunk rời rạc trong RAG là vô cùng nguy hiểm.
2. Dữ liệu MVP hiện tại (~2MB) hoàn toàn vừa vặn trong 1M token của Gemini 2.5.
3. Đội ngũ (1 NCS + CVYK) chỉ cần dùng Obsidian để soạn thảo, liên kết và quản lý thẻ tri thức. Không cần quản trị ChromaDB trong giai đoạn MVP.

D3. Điều kiện tiên quyết

  • Tổng dung lượng file Markdown nạp vào prompt ≤ 1M tokens (khoảng 3MB text).
  • Sử dụng mô hình có khả năng recall tốt ở long context (như Gemini 1.5/2.5 Pro).

D4. Kịch bản áp dụng

  • RAG tốt hơn: Khi dữ liệu phình to lên > 10MB hoặc khi chi phí API trở thành gánh nặng tài chính.
  • Obsidian-Markdown tốt hơn: Dùng làm hệ thống back-office cho CVYK và NCS soạn thảo, duyệt bài offline, quản lý red flag.

PHẦN E — Kế hoạch Triển khai Cụ thể (Mô hình Hybrid)

E1. Kiến trúc hệ thống chi tiết

flowchart TD
    subgraph Offline Vault (Obsidian)
        A[NCS & CVYK] -->|Viết & Duyệt| B(Knowledge Cards YAML/MD)
        B --> C(Tags & bảng phân loại (taxonomy))
    end

    subgraph Windows Server (IIS)
        B -->|Sync/Copy| D[Local File System]
        E[User Query] --> F[FastAPI Router]
        F -->|Step 1: LLM Router Agent| G[Xác định Category/File cần thiết]
        G -->|Step 2| H[Nạp toàn bộ 3-5 Knowledge Cards nguyên bản]
        H --> I[Bộ lọc an toàn - Pre-check]
        I --> J{Gemini 2.5 Pro}
        J --> K[Bộ lọc an toàn - Post-check]
        K --> L[Trả lời User]
    end

E2. Cấu trúc thư mục Obsidian vault (Ánh xạ Tầng 2 CXK)

CXK-Vault/
├── 01_Taxonomy/               (Các bảng phân loại, MOCs)
├── 02_Knowledge_Cards/        (Thẻ tri thức - chia theo nhóm bệnh)
│   ├── Knee_OA/
│   ├── Low_Back_Pain/
├── 03_Safety_Rules/           (Cờ đỏ, ranh giới y khoa)
├── 04_Clinical_Cases/         (FAQ, tình huống lâm sàng)
└── 99_Templates/              (Mẫu tạo thẻ tri thức)

E3. Quy ước file

  • Naming: KC_{NhómBệnh}_{Số}_{MôTảNgắn}.md (VD: KC_KneeOA_001_BaiTap.md)
  • Frontmatter :
---
id: KC-OA-001
type: knowledge_card
disease: Knee Osteoarthritis
status: approved
reviewer: CVYK_VuTheSy
last_updated: 2026-09-25
tags: [osteoarthritis, exercise, knee]
---

E4. Workflow con người

  1. NCS tạo file nháp bằng Template trong Obsidian.
  2. Dùng Obsidian Graph View để kiểm tra liên kết bệnh lý.
  3. CVYK đọc, chỉnh sửa và chuyển status: approved trong frontmatter.
  4. Chỉ các file approved mới được đồng bộ lên Windows Server.

E5. Workflow AI (File-level Routing)

  1. Routing: Khi user hỏi "Tôi bị Ä'au gối có nên tập gym không?", AI đọc lướt bảng phân loại (taxonomy) và xác định cần các file thuá»™c tag knee và exercise.
  2. Retrieval: Backend () đọc nội dung nguyên bản của các file Markdown tương ứng.
  3. Generation: Đẩy toàn bộ nội dung file (cùng red flag rules) vào context window của Gemini để tạo câu trả lời.

E6. Migration plan (từ RAG hiện tại sang thiết kế mới)

  • Bỏ: Các script chunking (02_create_chunks.py), embedding (03_generate_embeddings.py), và ChromaDB.
  • Thêm: Hệ thống file reader đơn giản trong FastAPI để load toàn bộ thư mục knowledge-cards/ theo thẻ tag.
  • Đồng bộ: Dùng git hoặc công cụ sync để đẩy vault từ máy NCS lên server IIS.

E7. Sprint plan điều chỉnh (so sánh với 8 sprint hiện có)

Kế hoạch RAG cũ Kế hoạch Hybrid mới Thay đổi
1: Nền móng Tái cấu trúc + source registry + Giữ nguyên + thêm setup Obsidian vault +1 (setup vault)
2: Knowledge Base Trích xuất KC dạng YAML Trích xuất KC dạng Markdown + YAML frontmatter trong Obsidian Đổi format, thêm wikilinks
3: Chunk → Embed → ChromaDB → Retrieval API Semantic Router (phân loại câu hỏi → chọn file) + File Reader API Tiết kiệm ~1 tuần — bỏ embed/VectorDB
4: Safety + Backend Safety engine + LLM + FastAPI behind IIS Giữ nguyên — safety engine đọc file YAML trực tiếp Không đổi
5: Frontend + Voice Website MVP + Voice Giữ nguyên Không đổi
6: Testing 100-case + Giữ nguyên + thêm test long-context recall +1 test suite
7: Telegram + Pilot Telegram bot + Pilot 20–30 NCT Giữ nguyên Không đổi
8: Báo cáo Phân tích + Báo cáo cuối Giữ nguyên + đánh giá khi nào cần chuyển sang RAG +1 section báo cáo

Lợi ích chính: Sprint 3 tiết kiệm được ~1 tuần (không cần cài đặt/cấu hình ChromaDB, viết embedding pipeline). Thời gian này dùng để hoàn thiện Semantic Router và test long-context quality.

E8. Rủi ro và giảm thiểu

# Rủi ro Mức độ Chiến lược giảm thiểu
R1 Rate limit API Gemini khi nạp 500K+ tokens liên tục Cao Cache FAQ phổ biến; giảm token bằng File-level Routing (chỉ nạp 3–5 file thay vì toàn bộ vault); dùng Gemini Flash cho câu đơn giản
R2 Chi phí token cao khi production scale Trung bình Theo dõi cost/query; đặt ngưỡng chuyển sang RAG khi cost > \$X/tháng; cache response cho FAQ
R3 Long-context recall suy giảm ("Lost in the Middle" problem) Trung bình Đặt thông tin quan trọng (cờ đỏ, ) ở đầu và cuối context; test recall thường xuyên
R4 Dữ liệu vượt quá context window khi mở rộng sau MVP Thấp (MVP) Thiết kế File-level Routing từ đầu; khi >3MB → chuyển sang RAG cho phần mở rộng, giữ Obsidian làm source of truth
R5 CVYK không quen Obsidian Thấp Obsidian có giao diện thân thiện; chuẩn bị video hướng dẫn 10 phút; CVYK chỉ cần đọc/sửa Markdown
R6 Sync vault lên server bị lỗi Thấp Dùng git hoặc rsync; có backup tự động trên metadata

Kết luận

Với bối cảnh cụ thể của dự án CXK — dữ liệu MVP ~2 MB, context window 1M tokens, đội ngũ 1 NCS + AI agents, yêu cầu an toàn y khoa cao nhất — mô hình Hybrid (Obsidian-Markdown + File-level Routing) là lựa chọn tối ưu:

  1. An toàn hơn RAG: Không chunking = không mất ngữ cảnh y khoa
  2. Đơn giản hơn RAG: Không cần embedding pipeline, vector DB
  3. Minh bạch hơn RAG: CVYK đọc chính xác những gì AI đọc
  4. Có đường lùi: Khi dữ liệu phình to, chuyển sang RAG mà không mất source of truth

Hành động tiếp theo: Bắt đầu setup Obsidian vault theo cấu trúc E2, tạo template knowledge card theo E3, và điều chỉnh Sprint 1 để bao gồm Obsidian setup.

Nguồn tham khảo

# Nguồn Tóm tắt
1 Lewis, P. et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS. Paper gốc định nghĩa RAG — chia tài liệu thành passage, dùng DPR retriever + BART generator.
2 Google (2024). "Gemini 1.5: Unlocking multimodal understanding across millions of tokens." arXiv:2403.05530. Gemini 1.5 Pro xử lý 1M tokens với recall >99% trên Needle-in-a-Haystack test.
3 Karpathy, A. (2025). " & Context Engineering." Blog & talks. Đặt tên "Context Engineering" — nghệ thuật cung cấp đúng thông tin cho LLM thay vì chỉ prompt.
4 Willison, S. (2025). "RAG is not the only way." simonwillison.net. Phân tích khi nào RAG thừa — dữ liệu nhỏ + context window lớn = nạp trực tiếp hiệu quả hơn.
5 Liu, N. F. et al. (2024). "Lost in the Middle: How Language Models Use Long Contexts." TACL. LLM hay bỏ sót thông tin ở giữa context dài — cần đặt thông tin quan trọng ở đầu/cuối.
6 Microsoft Research (2024). "GraphRAG: Unlocking LLM discovery on narrative private datasets." Graph RAG dùng knowledge graph thay vector — tốt cho câu hỏi tổng hợp nhưng phức tạp triển khai.
7 Obsidian Community (2024–2025). "Using Obsidian as AI Knowledge Base." Obsidian Forum & Discord. Nhiều use case dùng Obsidian vault làm context cho AI agents — đặc biệt với Dataview + frontmatter.
8 Google Cloud (2025). "Gemini 2.5 Pro pricing & context caching." cloud.google.com. Context caching giảm cost 75% cho repeated prefixes — rất phù hợp knowledge base ít thay đổi.
9 Anthropic (2025). "Contextual Retrieval." anthropic.com. Kỹ thuật thêm context vào mỗi chunk trước khi embed — giải quyết một phần vấn đề mất ngữ cảnh.
10 WHO (2023). "Ethics and governance of AI for health." Hướng dẫn đạo đức AI y khoa — yêu cầu transparency, explainability, truy vết nguồn.
11 Barnett, S. et al. (2024). "Seven Failure Points When Engineering a RAG System." arXiv. 7 điểm thất bại RAG: chunking sai, embed kém, retrieval thiếu, hallucination, v.v.
12 Kamradt, G. (2024). "Needle in a Haystack — LLM Testing." GitHub. Framework test khả năng recall thông tin trong context dài — Gemini 2.5 đạt >99.7%.
13 Langchain (2025). "Semantic Router Documentation." python.langchain.com. Thư viện phân loại intent bằng embedding — dùng làm router chọn file thay vì RAG toàn phần.
14 Obsidian (2026). "Obsidian Dataview Plugin Documentation." blacksmithgu.github.io. Plugin query metadata YAML frontmatter — có thể tự động list/filter knowledge cards.
15 Bộ Y tế Việt Nam (2014). "Hướng dẫn chẩn đoán và điều trị các bệnh cơ xương khớp." . Nguồn y khoa chính thống cho dự án CXK — đã số hóa Markdown.
16 NICE (2022). "NG226: in over 16s." nice.org.uk. Guideline quốc tế về thoái hóa khớp — nguồn red flag rules.

Ghi chú: Các nguồn [3], [4], [7] dựa trên blog và cộng đồng thực hành, không phải peer-reviewed paper. Các số liệu chi phí token [8] phụ thuộc bảng giá Google Cloud tại thời điểm triển khai — [CẦN XÁC MINH] trước khi đưa vào ngân sách.