Dọn dữ liệu trước khi xây AI Agent: bài học từ 573 file rác

TL;DR: Trước khi gắn thêm một AI Agent vào hệ thống, tôi học một bài học đơn giản nhưng đắt giá: AI Agent không thông minh hơn kho tri thức bạn đưa cho nó đọc. Một lần kiểm kê định kỳ, tôi đếm được 573 file rác nằm rải rác trong kho tri thức cá nhân — và đó chính là 573 lý do khiến câu trả lời của AI từng lệch hướng.

Tháng trước tôi ngồi rà soát lại kho tri thức cá nhân (Obsidian vault) trước khi kết nối thêm một tầng AI Agent để hỗ trợ tra cứu và tổng hợp thông tin. Tôi từng nghĩ việc quan trọng nhất sẽ là chọn mô hình, viết prompt, dựng workflow. Hoá ra việc quan trọng nhất lại nằm ở một khâu tôi vẫn xem là phụ: dọn dẹp dữ liệu. Chạy một lượt kiểm kê thủ công, tôi đếm được 573 file rác — ghi chú trùng lặp, bản nháp bỏ dở, file mồ côi không còn liên kết với note nào khác. Bài viết này không nói về kỹ thuật AI Agent. Nó nói về kỷ luật vận hành hệ thống tri thức cá nhân — thứ quyết định AI Agent của bạn trả lời chính xác hay trả lời bừa.

Vì sao một Founder xây AI Agent lại phải quan tâm đến... dọn file rác?

Trả lời ngắn: Vì AI Agent lấy ngữ cảnh trực tiếp từ kho tri thức bạn cấp cho nó — kho đó lộn xộn thì câu trả lời của AI cũng lộn xộn theo, bất kể mô hình nền tảng mạnh đến đâu.

Tôi từng chia sẻ trong bài viết về triết lý biến Obsidian thành "IDE" cho AI Agent rằng nếu coi kho tri thức là codebase và AI là lập trình viên đọc codebase đó, thì mọi lỗi cú pháp, mọi file thừa trong codebase đều làm chậm hoặc làm sai quá trình suy luận. Vấn đề là phần lớn Founder — kể cả tôi ở giai đoạn đầu — chỉ nghĩ đến việc "cho AI Agent ăn dữ liệu", chứ không nghĩ đến việc dữ liệu đó có đang sạch hay không.

Một AI Agent truy xuất ngữ cảnh không phân biệt được đâu là ghi chú còn giá trị, đâu là bản nháp bạn đã bỏ dở ba tháng trước. Nó chỉ thấy văn bản, và nó trích dẫn theo mức độ liên quan bề mặt. Nếu trong kho có hai file gần giống nhau nhưng một file đã lỗi thời, AI hoàn toàn có thể chọn nhầm file cũ để trả lời — và bạn sẽ không biết vì sao câu trả lời "nghe có vẻ đúng" lại sai lệch với thực tế hiện tại.

Bài học: "Garbage In, Garbage Out" áp dụng cho cả AI Agent lẫn con người

Nguyên lý "Garbage In, Garbage Out" (rác vào, rác ra) không mới — dân kỹ thuật nào cũng thuộc lòng. Nhưng tôi từng nghĩ nó chỉ áp dụng cho code hoặc dữ liệu huấn luyện mô hình, không nghĩ nó áp dụng ngay cả với ghi chú cá nhân của chính mình.

Tuần đầu tiên vận hành AI Agent mới, tôi hỏi nó tổng hợp lại một quyết định chiến lược tôi từng ghi lại. Nó trả lời dựa trên một bản nháp tôi viết lúc còn phân vân, chưa phải bản kết luận cuối cùng. Câu trả lời không sai về mặt câu chữ — nó trích đúng nguyên văn — nhưng sai về mặt bối cảnh, vì tôi đã đổi quyết định sau đó mà không xoá file nháp cũ. Đây chính là khoảnh khắc tôi nhận ra: rác dữ liệu không chỉ làm chậm con người khi tìm kiếm, nó còn khiến AI Agent tự tin trình bày một thông tin đã hết hạn như thể đó là sự thật hiện tại.

Điểm khác biệt duy nhất giữa con người và AI ở đây là: con người còn có trực giác để nghi ngờ ("cái này hình như cũ rồi"), còn AI Agent thì không — trừ khi bạn dọn dẹp trước để nó không có cơ hội đọc nhầm.

Quy trình "Janitor Scan" định kỳ tôi đang áp dụng cho kho tri thức

Sau lần phát hiện 573 file rác đó, tôi không coi việc dọn dẹp là một lần làm rồi thôi. Tôi biến nó thành một quy trình định kỳ, tự đặt tên vui là "Janitor Scan" — một lượt quét dọn có nhịp, không phải dọn khi nào rảnh thì dọn.

Quy trình tôi đang áp dụng gồm bốn bước:

• Kiểm kê theo nhịp cố định, không phải theo cảm hứng — đặt lịch quét định kỳ thay vì chờ đến khi kho tri thức quá tải mới xử lý.
• Đánh dấu file mồ côi — ghi chú không còn liên kết (backlink) tới hoặc từ bất kỳ note nào khác, dấu hiệu rõ nhất cho thấy nó đã tách rời khỏi mạch tư duy hiện tại.
• Đưa vào khu vực cách ly trước khi xoá hẳn — không xoá ngay lập tức, mà chuyển vào một thư mục tạm để rà lại lần cuối, tránh mất dữ liệu còn giá trị do quét nhầm.
• Ghi lại số liệu mỗi lần quét — con số file rác phát hiện được (như 573 lần đó) là một tín hiệu sức khoẻ của hệ thống, không phải một con số để khoe, mà để theo dõi xu hướng: kho tri thức đang gọn lại hay đang phình ra nhanh hơn tốc độ tôi dọn.

Nhịp quét dọn này quan trọng không kém nhịp bạn viết ghi chú mới. Một kho tri thức chỉ có đầu vào mà không có đầu ra (loại bỏ) sẽ luôn tích rác nhanh hơn bạn tưởng — đặc biệt khi bạn dùng AI để hỗ trợ ghi chú nhanh hơn, tức là tốc độ tạo file cũng tăng theo.

Bắt đầu từ đâu nếu bạn chưa từng dọn dẹp hệ thống của mình

Trả lời ngắn: Bắt đầu bằng một lượt kiểm kê thủ công quy mô nhỏ — không cần công cụ phức tạp, chỉ cần liệt kê toàn bộ file và tự hỏi từng file một: "cái này còn phục vụ AI Agent hoặc chính mình không?"

Nếu bạn chưa từng dọn dẹp hệ thống ghi chú của mình, đừng bắt đầu bằng việc đi tìm công cụ tự động hoá. Bắt đầu bằng việc tự tay lướt qua một phần nhỏ của kho — ví dụ một thư mục dự án cũ — và phân loại thủ công theo ba nhóm: còn dùng, không chắc, và rõ ràng đã lỗi thời. Chỉ riêng bước phân loại này thôi cũng đã lộ ra phần lớn vấn đề, vì phần lớn founder không thiếu kỷ luật ghi chép, mà thiếu kỷ luật dọn dẹp.

Sau khi có cảm nhận về quy mô vấn đề, mới nên tính đến việc đặt lịch quét định kỳ như tôi mô tả ở trên. Công cụ chỉ giúp lặp lại quy trình nhanh hơn — nó không thay được lần đầu tiên bạn tự tay nhìn lại toàn bộ kho tri thức của mình.

Kết luận

573 file rác không phải là một con số đáng xấu hổ — nó là bằng chứng cho thấy tôi đã chịu ngồi đếm. Phần lớn hệ thống tri thức cá nhân chưa bao giờ được đếm, nên vấn đề vẫn nằm im ở đó, âm thầm làm sai lệch mọi AI Agent được kết nối vào sau này. Nếu bạn đang cân nhắc thêm AI Agent vào quy trình làm việc, có lẽ câu hỏi cần đặt ra trước không phải là "chọn mô hình nào", mà là "kho dữ liệu tôi sắp cho AI đọc có đang sạch không". Tôi có viết riêng một bộ tiêu chí đánh giá mức độ sẵn sàng dùng AI cho SME mà phần dữ liệu và quy trình nội bộ cũng là một trong những chiều đánh giá — bạn có thể đối chiếu thêm nếu đang ở giai đoạn chuẩn bị.