Từ Obsidian đến GraphRAG: bài học sau một tháng

TL;DR: Trong một tháng, tôi đi từ việc dọn dẹp một kho tri thức cá nhân lộn xộn đến việc tự xây một lớp điều phối cho nhiều AI Agent, rồi đặt lại câu hỏi khi nào một Agent được tự quyết. Bài học lớn nhất rút ra sau cả chặng đường không nằm ở bất kỳ công nghệ nào trong số đó — mà ở việc tôi học được cách đặt câu hỏi đúng trước khi thêm bất kỳ lớp tự động hóa nào vào hệ thống.

Tháng 9 này tôi không đặt mục tiêu viết một chuỗi bài liên quan đến nhau. Nó xảy ra một cách tự nhiên — mỗi lần giải quyết xong một bài toán vận hành thật, tôi lại phát hiện ra bài toán tiếp theo đang chờ sẵn. Dọn dữ liệu dẫn tới câu hỏi bộ nhớ nên tổ chức ra sao. Bộ nhớ dẫn tới câu hỏi ai điều phối nhiều Agent cùng lúc. Điều phối dẫn tới câu hỏi khi nào Agent được tự quyết, khi nào phải dừng lại chờ tôi duyệt. Bài này là lúc tôi lùi lại, nhìn cả bốn mảnh ghép cùng một lúc, và tìm bài học chung đang ẩn bên dưới quá trình xây hệ thống AI Agent suốt một tháng qua.

Nhìn lại một tháng: từ dọn dẹp dữ liệu đến điều phối nhiều AI Agent

Tháng này bắt đầu bằng một việc chẳng liên quan gì đến AI trên bề mặt: dọn file rác. Trước khi cho bất kỳ Agent nào chạm vào kho tri thức cá nhân, tôi buộc mình xóa sạch những gì không còn giá trị — kết quả là gần sáu trăm tệp bị loại bỏ. Lúc đó tôi chỉ nghĩ đơn giản là dọn dẹp cho gọn. Chỉ sau này tôi mới nhận ra đó là bước chuẩn bị bắt buộc cho mọi thứ diễn ra sau đó.

Bước tiếp theo là câu hỏi kiến trúc: một khi kho tri thức đã sạch, nó nên được tổ chức thế nào để cả tôi và AI Agent cùng dùng được? Đây là lúc tôi đối chiếu hai mô hình lưu trữ hoàn toàn khác nhau trong GraphRAG vs Obsidian: bộ nhớ AI Agent khác bộ não bạn — Obsidian phục vụ tư duy con người, còn một lớp đồ thị tri thức phục vụ khả năng suy luận đa bước của AI Agent. Hai bộ nhớ tách biệt, đồng bộ có kiểm soát, không trộn lẫn vai trò của nhau.

Có bộ nhớ đúng rồi, bài toán tiếp theo lộ ra ngay: dữ liệu sạch, tổ chức tốt vẫn vô nghĩa nếu kênh giao tiếp với khách hàng không được thiết kế đúng cách hành vi thật. Đó là lý do một Agent chăm sóc khách hàng cần hiểu rằng khách Việt nhắn tin qua Zalo chứ không mở email — một bài học kiến trúc buộc tôi phải thiết kế lại từ cửa sổ phản hồi đến đồng bộ định danh khách hàng xuyên kênh. Và khi có nhiều Agent chuyên biệt cùng chạy — một xử lý nội dung, một xử lý dữ liệu, một xử lý phản hồi khách hàng — tôi phát hiện mình đang tự làm cái việc lẽ ra hệ thống phải làm: giữ ngữ cảnh chung và quyết định ai nói tiếp. Đó là lúc tôi chọn tự xây một lớp điều phối, thay vì lắp ráp một framework có sẵn.

Bốn mảnh ghép đó — dữ liệu, bộ nhớ, kênh giao tiếp, điều phối — không phải bốn dự án rời rạc. Chúng là bốn lớp của cùng một hệ thống, mỗi lớp chỉ lộ diện sau khi lớp trước đã đủ ổn định để tôi nhìn thấy giới hạn của nó.

Bài học lớn nhất: hệ thống tốt không phải hệ thống phức tạp nhất

Nếu chỉ được giữ lại một bài học từ cả tháng, đây là bài học đó: mỗi lần tôi thêm một lớp mới vào hệ thống, cám dỗ lớn nhất không phải là làm nó phức tạp hơn — mà là nghĩ rằng phức tạp hơn đồng nghĩa với tốt hơn. Thực tế ngược lại hoàn toàn.

Khi dọn dữ liệu, cách dễ nhất để "làm cho xong" là viết một quy tắc phân loại tự động phức tạp, xử lý được mọi trường hợp ngoại lệ. Tôi đã thử, và nó thất bại — không phải vì kỹ thuật sai, mà vì tôi không còn hiểu chính hệ thống phân loại của mình sau vài tuần. Khi thiết kế bộ nhớ cho AI Agent, cám dỗ tương tự lặp lại: đồ thị tri thức nghe hấp dẫn hơn nhiều so với ghi chú Markdown thông thường, nhưng phần lớn câu hỏi tôi thực sự cần trả lời chưa bao giờ đòi hỏi mức độ phức tạp đó. Khi xây lớp điều phối, tôi cũng từng cân nhắc một kiến trúc cho phép các Agent tự gọi nhau linh hoạt — và nó tạo ra một mớ phụ thuộc chéo mà chỉ mình tôi gỡ được mỗi khi có lỗi.

Điểm chung của cả ba lần vấp: hệ thống tốt không phải hệ thống xử lý được nhiều tình huống nhất trên giấy. Nó là hệ thống mà tôi — người chịu trách nhiệm vận hành nó — vẫn còn hiểu rõ từng phần sau vài tháng, khi có sự cố xảy ra lúc nửa đêm và không ai khác giải thích được thay tôi.

Câu hỏi tôi tự đặt ra trước khi thêm bất kỳ lớp tự động hóa nào

Sau bốn lần lặp lại cùng một kiểu vấp trong một tháng, tôi bắt đầu tự áp một bộ câu hỏi trước khi cho phép mình thêm bất kỳ lớp tự động hóa mới nào vào hệ thống — không phải để làm chậm tiến độ, mà để tránh phải tháo dỡ lại những gì vừa dựng lên tuần trước:

• Tôi có đang giải quyết một bài toán thật đang xảy ra, hay chỉ đang thêm một khả năng "cho chắc"? Cả 573 file rác lẫn lớp điều phối tôi tự xây đều bắt đầu từ một va chạm thật, không phải từ việc đọc thấy một xu hướng hay ho.
• Nếu lớp này lỗi lúc 2 giờ sáng, tôi có tự tin đọc lại và hiểu ngay vấn đề nằm ở đâu không? Nếu câu trả lời là "phải mất một lúc mới nhớ ra", đó là dấu hiệu lớp đó đã phức tạp hơn mức tôi thực sự kiểm soát được.
• Hành động này có dễ đảo ngược nếu sai không? Đây chính là ranh giới tôi dùng để quyết định phần nào Agent được tự xử lý, phần nào phải dừng lại chờ tôi duyệt — nguyên tắc mà tôi sẽ đào sâu hơn ở phần cuối bài này.
• Tôi có đang thêm lớp này vì nó thực sự cần thiết, hay vì tôi muốn hệ thống "trông" chuyên nghiệp hơn? Câu hỏi khó trả lời thành thật nhất trong bốn câu — nhưng cũng là câu giữ tôi khỏi việc tự làm phức tạp hóa những thứ vốn dĩ đơn giản.

Bốn câu hỏi này không có gì mới mẻ về mặt kỹ thuật. Giá trị của chúng nằm ở việc tôi bắt buộc phải trả lời trước khi viết một dòng code, không phải sau khi hệ thống đã chạy và tôi mới nhận ra mình không hiểu nó nữa.

Điều tôi sẽ thử nghiệm tiếp trong tháng 10

Tháng 10 tôi chưa có một kế hoạch chi tiết theo từng tuần — điều tôi có là một hướng thử nghiệm rõ ràng: xem cả bốn lớp của tháng 9 vận hành cùng nhau trong điều kiện thật, thay vì đánh giá từng lớp riêng lẻ như tôi đã làm suốt tháng vừa qua. Dữ liệu sạch, bộ nhớ đúng kiến trúc, kênh giao tiếp đúng hành vi khách hàng, lớp điều phối rõ ranh giới — bốn thứ đó nghe hợp lý trên giấy, nhưng tôi chưa thực sự để chúng chạy đủ lâu cùng lúc để biết điểm ma sát nằm ở đâu.

Tôi cũng dự định siết lại phần ranh giới tự chủ của từng Agent một cách có hệ thống hơn, thay vì quyết định theo cảm tính như một số trường hợp trong tháng này. Đây là phần tôi cố tình chưa vội kết luận — vì nó cần được kiểm chứng qua vận hành thật, không phải qua một bài viết tổng kết.

Kết luận

Nhìn lại, một tháng này không phải là một tháng học thêm công nghệ mới. Nó là một tháng học lại cùng một bài học bốn lần, ở bốn tầng khác nhau của cùng một hệ thống: đơn giản và có ranh giới rõ ràng luôn thắng phức tạp và đầy đủ tính năng, miễn là tôi còn là người phải hiểu và chịu trách nhiệm cho từng phần của nó.

Câu hỏi về ranh giới tự chủ mà tôi nhắc ở trên — phần nào Agent được tự quyết, phần nào bắt buộc phải có con người duyệt — là chủ đề tôi đã đào sâu hơn ở Zero Trust cho AI Agent: khi nào cần người duyệt. Nếu tháng 9 là tháng dựng nền, có lẽ tháng 10 sẽ là tháng kiểm chứng xem cái nền đó có thực sự đứng vững hay không.