Tôi đã chứng kiến một hóa đơn 200$ xuất hiện trên tài khoản AWS chỉ qua một đêm.
Không phải vì hệ thống bị sập.
Một agent chạy loop trong sáu tiếng đồng hồ mà không có điều kiện dừng, gọi OpenAI API ở mỗi lần lặp.
Mọi bảng điều khiển giám sát đều báo cáo nó đang hoạt động tốt.
Không ai để ý cho đến khi hóa đơn xuất hiện vào sáng hôm sau.
Đó là điều xảy ra khi bạn xây dựng các hệ thống AI mà không hiểu cách chúng thực sự hoạt động.
Hầu hết mọi người học kỹ thuật AI theo chiều ngược lại.
Cài một thư viện. Làm theo một hướng dẫn. Gọi một API. Làm cho nó chạy được. Cảm thấy như đang tiến bộ.
Rồi đột nhiên có thứ gì đó hỏng theo một cách vô lý.
Họ thay đổi các con số một cách ngẫu nhiên cho đến khi nó ngừng hỏng.
Đó không phải là kỹ thuật. Đó là hy vọng với một chiếc bàn phím.
Dưới đây là 6 khái niệm giúp giải quyết vấn đề này.
Một câu giải thích tất cả
Mọi hệ thống AI, dù phức tạp đến đâu, cũng chỉ là:
Bộ nhớ (RAG) + Suy nghĩ (LLM + Token) + Hành động (Agent) + Đo lường (Eval)
… được kết nối thông qua Kỹ thuật Context (Context Engineering).
Đó là toàn bộ lĩnh vực này.
Mọi thứ bên dưới chỉ là giải thích chi tiết từng phần thực sự có nghĩa là gì.
1. Token và Cửa sổ Ngữ cảnh (Context Window)
LLM không đọc chữ. Chúng đọc các khối gọi là token.
"kỹ thuật" → 1 token
"không thể tin nổi" → 2 token. Dấu cách và dấu câu cũng được tính.
Mỗi mô hình đều có một cửa sổ ngữ cảnh — một giới hạn cứng về số lượng token mà nó có thể giữ cùng lúc.
→ Claude: 200,000 token
→ GPT-5: 400,000 token
Hãy nghĩ về nó như một tấm bảng trắng trong phòng họp.
Mô hình chỉ làm việc với những gì hiện có trên bảng.
Khi bảng đầy, những ghi chú cũ sẽ bị xóa để nhường chỗ.
Mô hình không mất khả năng suy nghĩ.
Nó mất quyền truy cập vào thông tin cũ hơn.
Vì sao điều này phá vỡ hệ thống production:
→ Token tốn tiền — mỗi lần gọi API đều tính phí theo token đầu vào và đầu ra
→ Lịch sử trò chuyện dài nhanh chóng lấp đầy cửa sổ
→ Khi ngữ cảnh đầy, các hướng dẫn cũ hơn bị rơi ra một cách âm thầm
→ Việc đưa gì vào ngữ cảnh là một quyết định kỹ thuật, không phải mặc định
Thất bại chứng minh điều này:
Một nhóm đã xây dựng một agent hỗ trợ khách hàng với toàn bộ lịch sử trò chuyện 12 tháng làm ngữ cảnh cho mỗi yêu cầu.
Hoạt động hoàn hảo trong thử nghiệm với 5 lượt tương tác.
Trong production, sau 50 lượt tương tác, agent bắt đầu bỏ qua chính system prompt của nó.
Các hướng dẫn vẫn ở đó.
Nhưng chúng bị chôn vùi dưới 80,000 token nội dung hội thoại.
Mô hình đã thực sự ngừng chú ý đến chúng.
Giải pháp không phải là một mô hình tốt hơn.
Mà là tóm tắt lịch sử cũ hơn để giữ cho cửa sổ luôn tập trung.
Sự thật khó chịu:
Hầu hết các "thất bại prompt engineering" thực ra là thất bại về token và cửa sổ ngữ cảnh dưới một lớp ngụy trang.
Các kỹ sư đổ lỗi cho prompt khi vấn đề thực sự là hướng dẫn quan trọng nằm ở dòng thứ 3 của một ngữ cảnh dài 500 dòng và mô hình đã ngừng đánh trọng số cho nó.
2. Embedding và Tìm kiếm Vector
Embedding chuyển đổi ý nghĩa thành các con số để có thể tính toán "sự tương đồng" bằng toán học.
Vấn đề chúng giải quyết:
Bạn có 50,000 tài liệu. Một người dùng hỏi. Bạn cần 3 tài liệu liên quan nhất — mà không cần đọc tất cả 50,000 tài liệu mỗi lần.
Tìm kiếm từ khóa thất bại ở đây.
Nếu tài liệu nói "xe hơi" và người dùng hỏi về "ôtô", tìm kiếm từ khóa sẽ bỏ sót.
Không phải vì câu trả lời không có ở đó. Mà vì từ ngữ không khớp.
Embedding giải quyết vấn đề này theo một cách khác.
Một mô hình embedding chuyển đổi văn bản thành một vector — một danh sách các con số đại diện cho ý nghĩa trong không gian toán học.
Văn bản tương tự về mặt ngữ nghĩa → vector tương tự về mặt số học.
"xe hơi" và "ôtô" → ở gần nhau
"xe hơi" và "quang hợp" → ở xa nhau
Cách tìm kiếm vector thực sự hoạt động:
- Mỗi tài liệu được chuyển đổi thành một vector và được lưu trữ
- Câu hỏi của người dùng cũng trở thành một vector
- Hệ thống tìm các vector được lưu trữ nằm gần vector câu hỏi nhất
- Đó là những tài liệu phù hợp nhất của bạn
Đây không phải là phép thuật xấp xỉ. Đây là hình học.
Sự tương đồng là một tính chất toán học thực sự mà bạn có thể tính toán.
Nơi xuất hiện trong production:
→ Tìm kiếm ngữ nghĩa trong bất kỳ hệ thống tài liệu nào
→ Tìm sản phẩm, bài viết, hồ sơ người dùng tương tự
→ Bước truy xuất trong RAG (khái niệm tiếp theo)
→ Bộ nhớ trong AI agent
3. RAG (Retrieval-Augmented Generation - Sinh tăng cường truy xuất)
Thay vì huấn luyện mô hình trên dữ liệu của bạn, bạn sẽ truy xuất dữ liệu liên quan tại thời điểm truy vấn và cung cấp nó cho mô hình làm ngữ cảnh.
Vấn đề RAG giải quyết:
LLM biết rất nhiều. Nhưng chúng không biết dữ liệu của bạn.
Tài liệu nội bộ của công ty bạn. Cơ sở dữ liệu sản phẩm của bạn. Lịch sử hỗ trợ khách hàng của bạn.
Không có gì trong số đó nằm trong tập huấn luyện.
Hai lựa chọn: huấn luyện một mô hình trên dữ liệu của bạn (đắt, chậm, nhanh chóng lỗi thời) hoặc cung cấp dữ liệu của bạn cho mô hình đúng vào thời điểm nó cần.
RAG là lựa chọn thứ hai, được thực hiện một cách có hệ thống.
Quy trình 3 bước:
→ TRUY XUẤT:
Câu hỏi trở thành một vector → cơ sở dữ liệu vector tìm các tài liệu được lưu trữ tương tự nhất → lấy ra 3-5 đoạn (chunk) hàng đầu
→ TĂNG CƯỜNG:
Các tài liệu đã truy xuất được thêm vào ngữ cảnh của mô hình → prompt trở thành "sử dụng ngữ cảnh này, hãy trả lời câu hỏi"
→ SINH:
Mô hình trả lời dựa trên dữ liệu thực tế của bạn — không phải bịa đặt
Nơi RAG thất bại:
→ Truy xuất kém = trả lời kém. Mô hình chỉ có thể làm việc với những gì nó nhận được
→ Chunk kém sẽ tách câu trả lời khỏi ngữ cảnh của nó
→ Mô hình vẫn có thể bịa đặt nếu truy xuất không tìm thấy thứ gì hữu ích
Một thất bại RAG thực tế:
Một nhóm đã xây dựng một trợ lý kiến thức nội bộ cho một cuốn sách hướng dẫn kỹ thuật dày 500 trang.
Hoạt động hoàn hảo trong các buổi demo. Trong production, các câu trả lời mơ hồ và đôi khi sai.
Vấn đề: kích thước chunk.
Họ đã chia cuốn sách hướng dẫn thành các chunk 1,000 token dựa trên số ký tự thô.
Bảng bị chia đôi giữa dòng. Hướng dẫn từng bước bị chia đôi giữa bước.
Việc truy xuất đang tìm đúng khu vực tổng quan — nhưng bỏ lỡ câu trả lời thực sự.
Giảm một nửa kích thước chunk và thêm overlap (chồng lấn) đã khắc phục 80% vấn đề chỉ sau một đêm.
Ý kiến mạnh mẽ:
RAG bị đánh giá quá cao khi khả năng truy xuất của bạn kém.
LLM không thể sửa lỗi truy xuất kém. Nó chỉ có thể bịa đặt xung quanh nó.
Nếu bạn thấy các câu trả lời sai, hãy ngừng tinh chỉnh prompt của bạn.
Hãy bắt đầu đo lường độ chính xác truy xuất của bạn.
Câu trả lời nằm ở đó.
4. Vòng lặp Agent (Agentic Loop)
Agent hoạt động bằng cách liên tục chọn một hành động, thực thi nó, quan sát kết quả và quyết định việc cần làm tiếp theo — cho đến khi hoàn thành nhiệm vụ.
Một lệnh gọi LLM thông thường là không trạng thái (stateless). Bạn hỏi, nó trả lời, xong.
Một agent là có trạng thái (stateful). Nó hành động, quan sát, quyết định, lặp lại.
Vòng lặp bằng tiếng Việt dễ hiểu:
- Nhận một mục tiêu
- Quyết định hành động tiếp theo
- Thực thi nó — tìm kiếm, viết code, đọc file
- Quan sát kết quả
- Quyết định hành động tiếp theo dựa trên những gì đã học
- Lặp lại cho đến khi mục tiêu hoàn thành
- Trả về câu trả lời cuối cùng
Công cụ (Tools) là thứ mang lại sức mạnh cho agent.
Nếu không có công cụ, LLM chỉ phản hồi bằng văn bản.
Với công cụ, nó có thể tìm kiếm trên web, đọc file, viết code, gọi API, kích hoạt bất kỳ hành động nào bạn xác định.
Ba điều mà người mới bắt đầu luôn sai:
→ Agent không có điều kiện dừng sẽ chạy mãi mãi. Bạn phải xác định khi nào nên dừng — giới hạn bước, giới hạn thời gian hoặc điều kiện hoàn thành mục tiêu
→ Càng nhiều công cụ không đồng nghĩa với hiệu suất tốt hơn. Quá nhiều công cụ khiến mô hình bối rối về việc nên sử dụng cái nào
→ Lỗi công cụ cần được xử lý rõ ràng. Một thất bại âm thầm khiến agent tự tin tạo ra rác
Chi tiết về thất bại 200$ qua một đêm:
Agent không có giới hạn bước tối đa. Mục tiêu của nó: nghiên cứu một chủ đề và tạo ra một bản tóm tắt.
Một trong những công cụ tìm kiếm web của nó trả về kết quả rỗng.
Agent không biết cách dừng lại.
Nó tiếp tục tìm kiếm, thử lại, tạo ra các bản tóm tắt trung gian — mỗi cái lại kích hoạt một lần tìm kiếm khác.
Sáu giờ sau: 847 lần gọi LLM. 2.1 triệu token tiêu thụ. Một bản tóm tắt có vẻ mạch lạc nhưng hoàn toàn vòng quanh. Một hóa đơn 200$.
Sửa chữa chỉ là ba dòng: một bộ đếm bước tối đa, một trình xử lý rõ ràng cho kết quả rỗng, một đường leo thang khi độ tin cậy thấp.
Cùng một agent đó hiện hoàn thành trong trung bình dưới 12 lần gọi.
Ý kiến bạn cần nghe:
Hầu hết các agent thất bại không phải vì mô hình tệ — mà vì các kỹ sư coi vòng lặp như thể nó tự quản lý được.
Nó không phải vậy.
Lan can an toàn (Guardrails), điều kiện dừng, trình xử lý lỗi — hãy xây dựng chúng ngay từ đầu, không phải thêm vào sau sự cố đầu tiên.
5. Đánh giá (Eval - Evaluation)
Eval là cách bạn biết liệu hệ thống AI của mình có thực sự hoạt động hay không — và liệu một thay đổi có làm nó tốt hơn hay tệ hơn.
Đây là khái niệm mà hầu hết các hướng dẫn bỏ qua vì nó không hào nhoáng.
Nó cũng là thứ phân biệt các kỹ sư xây dựng demo với những người xây dựng hệ thống production.
Vấn đề khi không có eval:
Bạn thay đổi prompt. Cập nhật logic truy xuất. Chuyển sang mô hình mới hơn.
Nó có tốt hơn không?
Bạn không biết. Bạn có thể kiểm tra thủ công một vài ví dụ — nhưng đó là cảm giác, không phải bằng chứng.
Eval thực sự trông như thế nào:
→ Một bộ dữ liệu vàng (golden dataset): 25-50 đầu vào thực với đầu ra đúng đã biết, bao gồm các trường hợp sử dụng chính cộng với 5 trường hợp khó (edge case) đã biết
→ Các chỉ số nhị phân nếu có thể:
— Hệ thống RAG có truy xuất đúng tài liệu không? Có/Không
— Agent có hoàn thành mà không có lỗi không? Có/Không
— Phản hồi có chứa thông tin cần thiết không? Có/Không
→ Điểm tổng hợp được theo dõi theo thời gian:
— Độ chính xác truy xuất: 89% → sau khi thay đổi → 84%. Phát hiện suy giảm.
— Tỷ lệ hoàn thành nhiệm vụ: 76% → phiên bản agent mới → 81%. Xác nhận cải thiện.
Chu kỳ eval:
Triển khai → Đo lường bằng eval → Tìm thất bại → Thêm thất bại vào bộ dữ liệu vàng → Sửa → Chạy eval lại → So sánh điểm → Chỉ phát hành nếu các con số được cải thiện
Sự thật trung thực:
"Mức độ hữu ích: 3.7/5" không cho bạn biết điều gì có thể hành động được.
"Truy xuất đúng tài liệu: 84% thời gian" cho bạn biết chính xác vấn đề nằm ở đâu và mức độ cải thiện của một sửa chữa.
Một hệ thống AI không có eval không phải là một sản phẩm.
Nó là một bản demo mà bạn không thể tự tin thay đổi.
6. Kỹ thuật Context (Context Engineering)
Là kỷ luật quyết định chính xác thông tin nào được đưa vào cửa sổ ngữ cảnh của mô hình, cách nó được cấu trúc và những gì bị bỏ lại.
Đây là ý kiến khiến mọi người khó chịu:
Kỹ thuật context quan trọng hơn kỹ thuật prompt (prompt engineering).
Một prompt tầm thường trong một ngữ cảnh được quản lý tốt sẽ vượt trội hơn một prompt xuất sắc bị chôn vùi trong nhiễu — mọi lúc.
Hầu hết các nhóm dành 80% nỗ lực tối ưu hóa cho prompt và gần như không có gì cho context.
Kết quả phản ánh điều đó.
Cách tiếp cận ngây thơ thất bại:
Bao gồm mọi thứ. Tất cả lịch sử. Tất cả các tài liệu đã truy xuất. Mọi mô tả công cụ. System prompt. Tin nhắn người dùng. Tất cả.
Điều này thất bại vì một lý do nhất quán: mô hình bị nhầm lẫn về điều gì quan trọng nhất.
Có một hiệu ứng được ghi chép lại gọi là "lost in the middle" (lạc ở giữa) — thông tin bị chôn vùi sâu trong một ngữ cảnh dài có khả năng được sử dụng thấp hơn.
Kỹ thuật context thực sự bao gồm những gì:
→ Lựa chọn: quyết định này cụ thể cần tài liệu, dữ kiện hoặc lịch sử nào?
→ Nén: các phần cũ hơn của cuộc trò chuyện có thể được tóm tắt để tiết kiệm token không?
→ Sắp xếp thứ tự: các hướng dẫn quan trọng nên ở đầu và cuối — không phải ở giữa
→ Cắt tỉa: những gì có thể loại bỏ mà không ảnh hưởng đến chất lượng đầu ra?
→ Cấu trúc: tiêu đề, dấu phân cách, các phần được gắn nhãn ảnh hưởng đến độ tin cậy của việc mô hình sử dụng thông tin
Một ví dụ thực tế:
Một agent đã chạy trong 45 phút. Nó đã tích lũy 80,000 token lịch sử hội thoại. Cửa sổ của nó là 128,000.
Bạn không muốn mất mục tiêu và các ràng buộc ban đầu, ngay cả khi lịch sử lấp đầy cửa sổ.
Kỹ thuật context: nén các đầu ra công cụ cũ hơn, tóm tắt lý luận trước đó, giữ cho định nghĩa nhiệm vụ nổi bật trong suốt phiên.
Kỹ thuật prompt là viết các hướng dẫn tốt.
Kỹ thuật context là xây dựng môi trường mà trong đó các hướng dẫn đó thực sự được tuân theo.
Cách 6 khái niệm này tạo thành một hệ thống
BỘ NHỚ → RAG + Embedding (những gì hệ thống biết)
SUY NGHĨ → LLM + Token + Cửa sổ Ngữ cảnh (cách nó suy luận với những gì nó biết)
HÀNH ĐỘNG → Vòng lặp Agent + Công cụ (những gì nó có thể làm trong thế giới thực)
ĐO LƯỜNG → Eval (cách bạn biết nó đang hoạt động)
CHẤT KẾT DÍNH → Kỹ thuật Context (quyết định điều gì chảy giữa tất cả các thành phần trên)
Một chatbot đơn giản chỉ là Suy nghĩ.
Một agent hỗ trợ khách hàng là Bộ nhớ + Suy nghĩ + Hành động.
Một hệ thống production đáng tin cậy thêm Đo lường.
Sự tinh tế nằm ở cách các phần kết nối tốt với nhau.
Luồng cho bất kỳ yêu cầu đơn lẻ nào:
Câu hỏi người dùng
→ Kỹ thuật Context quyết định nên bao gồm gì
→ Embedding truy xuất Bộ nhớ liên quan (RAG)
→ Token xác định bao nhiêu vừa với cửa sổ
→ LLM suy luận dựa trên ngữ cảnh đã được tập hợp
→ Vòng lặp Agent quyết định liệu có cần thêm thông tin hay không
→ Eval đo lường xem đầu ra có thực sự chính xác không
Nên bắt đầu từ đâu
Bạn không cần phải thành thạo cả sáu cùng một lúc.
→ Bắt đầu với token và cửa sổ ngữ cảnh — chúng ảnh hưởng đến mọi thứ bạn xây dựng
→ Thêm embedding khi bạn cần tìm kiếm ngữ nghĩa hoặc bộ nhớ
→ Học RAG khi bạn cần neo một mô hình vào dữ liệu của riêng bạn
→ Học vòng lặp agent khi bạn cần tự động hóa
→ Thêm eval trước khi bạn phát hành bất cứ thứ gì lên production
→ Áp dụng kỹ thuật context khi mọi thứ khác trở nên trực quan
Trình tự đó không phải là ngẫu nhiên.
Mỗi khái niệm làm cho khái niệm tiếp theo trở nên dễ học hơn.
Kết luận trung thực cuối cùng
Hầu hết các nhóm gặp khó khăn với AI trong production không phải vì mô hình sai hay thư viện sai.
Họ gặp khó khăn vì họ đã bỏ qua một trong sáu khái niệm này.
Agent chạy vòng lặp vô tận vì không ai nghĩ về điều kiện dừng.
Câu trả lời RAG sai vì không ai đo lường khả năng truy xuất.
Prompt ngừng hoạt động trong các phiên dài vì không ai hiểu cách cửa sổ ngữ cảnh bị lấp đầy.
Đây không phải là những vấn đề phức tạp.
Chúng là những vấn đề cơ bản, được che đậy bằng từ ngữ kỹ thuật.
Các công cụ thay đổi sau mỗi sáu tháng.
Sáu khái niệm này là cách các công cụ hoạt động.
Hãy học các khái niệm, và bạn sẽ không bao giờ bối rối trước một công cụ mới nữa.
Quan trọng hơn — bạn sẽ không bao giờ tiêu 200$ để nhìn một agent chạy vòng lặp suốt đêm, tự hỏi điều gì đã sai.
Nếu bài viết này hữu ích:
→ Đăng lại (Repost) để chia sẻ với mọi kỹ sư AI bạn biết
→ Theo dõi @sairahul1 để biết thêm nhiều hệ thống và phân tích như thế này
→ Đánh dấu (Bookmark) trang này — bạn sẽ tham khảo nó vào lần tới khi có thứ gì đó hỏng trong production
Tôi viết về AI, xây dựng sản phẩm và các hệ thống hoạt động trong khi bạn ngủ.
