- Cuộc thảo luận đang chuyển từ "prompt engineering" sang một bước phát triển cao hơn là "context engineering"
- Context không chỉ là một câu prompt đơn lẻ, mà là mọi thông tin mà LLM có thể nhìn thấy trước khi tạo câu trả lời (chỉ dẫn, lịch sử hội thoại, bộ nhớ dài hạn, thông tin bên ngoài, công cụ khả dụng, v.v.)
- Thành công hay thất bại của agent giờ đây phụ thuộc vào chất lượng của context hơn là hiệu năng của mô hình
- Các agent tiên tiến tích hợp nhiều ngữ cảnh như lịch của người dùng, email trước đây, danh bạ... để tạo ra phản hồi gần hơn với việc giải quyết vấn đề thực tế
- Context engineering là thiết kế hệ thống động được tùy biến theo từng tình huống, tức quá trình cung cấp đúng thông tin và công cụ cho LLM vào đúng thời điểm
Context Engineering là gì
- Gần đây, thuật ngữ "context engineering" đang lan rộng rất nhanh trong lĩnh vực AI
- Nếu "prompt engineering" trước đây tập trung vào việc thiết kế một câu hỏi hoặc mệnh lệnh đơn lẻ, thì context engineering là một cách tiếp cận rộng hơn và mạnh hơn
- Tobi Lutke định nghĩa đây là "nghệ thuật cung cấp toàn bộ context để LLM có thể giải quyết công việc một cách đáng tin cậy"
Những yếu tố chính của context
- Việc một hệ thống agent có hoạt động thành công hay không phụ thuộc rất lớn vào những thông tin nào được đưa vào working memory
- Phần lớn thất bại của agent không đến từ mô hình, mà từ sự thiếu hụt context phù hợp
Các thành phần của context
- System prompt/chỉ dẫn: Các chỉ dẫn cơ bản, ví dụ và quy tắc định nghĩa hành vi của mô hình
- User prompt: Yêu cầu hoặc câu hỏi trực tiếp từ người dùng
- Trạng thái/lịch sử hội thoại: Dòng chảy hội thoại hiện tại và thông tin ngữ cảnh liên quan
- Bộ nhớ dài hạn: Các cuộc hội thoại trước đó qua nhiều bước, sở thích của người dùng, tóm tắt dự án trước đây và tập hợp thông tin mà mô hình được học để ghi nhớ lâu dài
- RAG (truy hồi tăng cường): Thông tin mới nhất và có liên quan cao được lấy từ tài liệu bên ngoài, cơ sở dữ liệu, API...
- Công cụ khả dụng: Các hàm mà mô hình có thể gọi, định nghĩa của các công cụ tích hợp sẵn (ví dụ:
check_inventory, send_email)
- Đầu ra có cấu trúc: Định nghĩa định dạng phản hồi mà mô hình phải tuân theo (ví dụ:
JSON)
Vì sao context quan trọng
- Trên thực tế, yếu tố tạo nên một AI agent hiệu quả không phải là code phức tạp hay chất lượng mô hình, mà là bạn cung cấp context phù hợp đến mức nào
- Một agent đơn giản chỉ để demo thường chỉ nhận yêu cầu người dùng và đưa ra phản hồi cơ bản, trong khi một agent "kỳ diệu" sẽ cân nhắc context phong phú để tạo ra câu trả lời hữu ích hơn nhiều và gần với cách con người phản hồi
- So sánh
- Agent chất lượng thấp (demo): Chỉ nhìn vào yêu cầu đơn giản và tạo ra câu trả lời rập khuôn. Ví dụ: với email "Bạn có rảnh ngày mai không?", nó sẽ trả lời máy móc như "Ngày mai tôi rảnh. Mấy giờ thì phù hợp?"
- Agent chất lượng cao ("kỳ diệu"): Có thể tận dụng toàn bộ lịch cá nhân, lịch sử email trước đó, thông tin nhận dạng của đối phương, các tùy chọn gọi công cụ cần thiết... để tạo phản hồi tự nhiên và phù hợp với tình huống. Ví dụ: "Ngày mai lịch của tôi đã kín, nhưng sáng thứ Năm còn trống nên tôi đã gửi lời mời lịch. Nếu phù hợp, xin vui lòng cho tôi biết."
- Vì vậy, yếu tố quyết định thành công không phải là thuật toán hay bản thân mô hình, mà là việc cung cấp đúng context cho đúng công việc
- Phần lớn thất bại của AI agent là kết quả của thất bại trong thiết kế context, chứ không phải do mô hình
Sự tiến hóa từ prompt engineering sang context engineering
- Nếu prompt engineering tập trung vào việc tối ưu một dòng chỉ dẫn bằng văn bản, thì context engineering bao gồm phạm vi rộng hơn nhiều: thông tin, công cụ và thiết kế mang tính cấu trúc
- Context engineering là năng lực chuyên môn về thiết kế và xây dựng hệ thống để cung cấp một cách có hệ thống cho LLM những thông tin và công cụ cần thiết, ở đúng định dạng và đúng thời điểm, nhằm giúp nó hoàn thành nhiệm vụ
Đặc điểm của context engineering
- Thiết kế toàn hệ thống: Context không phải chỉ là một template prompt đơn giản, mà là đầu ra của toàn bộ hệ thống vận hành trước khi gọi LLM
- Tạo động: Lựa chọn và xử lý theo thời gian thực nhiều loại thông tin như lịch, email, tìm kiếm web... tùy theo từng tình huống của nhiệm vụ
- Cung cấp thông tin và công cụ đúng lúc đúng chỗ: Nguyên tắc "Garbage In, Garbage Out", vì vậy điều quan trọng là tránh để mô hình nhận thông tin thừa hoặc thiếu
- Tầm quan trọng của sự rõ ràng về định dạng: Khi nạp thông tin, cần tóm tắt và cấu trúc thay vì liệt kê rời rạc; cách sử dụng công cụ cũng phải được truyền đạt rõ ràng
Kết luận
- Bản chất của việc phát triển các AI agent mạnh mẽ và đáng tin cậy không nằm ở một "prompt kỳ diệu" hay mô hình mới nhất, mà nằm ở context engineering (thiết kế và cung cấp context)
- Đây không chỉ là một vấn đề kỹ thuật đơn thuần, mà còn đòi hỏi năng lực thiết kế hệ thống toàn diện phù hợp với yêu cầu và mục tiêu kinh doanh, bao gồm thông tin, công cụ và định nghĩa đầu ra có cấu trúc
- Điều cốt lõi là cung cấp đúng thông tin phù hợp, ở đúng thời điểm và theo đúng định dạng để LLM có thể hoàn thành nhiệm vụ
Tài liệu tham khảo
2 bình luận
Cảm giác như chỉ đổi mỗi cái tên thôi.
Ý kiến Hacker News
Gần đây tôi cũng đã viết một bài blog về chủ đề này, xem bài của tôi - Context Engineering
Tôi nghĩ các bài viết của Drew Breunig xử lý chủ đề này cực kỳ xuất sắc
Thời điểm có hơi trùng với lúc meme “context engineering” đang lan truyền, nhưng thực ra công việc đó không liên quan đến meme này
Bài How Long Contexts Fail - Vì sao ngữ cảnh dài thất bại giải thích theo nhiều cách khác nhau việc ngữ cảnh dài gây ra vấn đề như thế nào, và cái gọi là “context rot” phát sinh ra sao
Bài How to Fix Your Context - Cách sửa ngữ cảnh của bạn đặt tên cho nhiều kỹ thuật như Tool Loadout, Context Quarantine, Context Pruning, Context Summarization, Context Offloading để đưa ra cách giải quyết vấn đề
Tôi nghĩ các bài viết của Drew Breunig rất đáng đọc
Điều này cực kỳ quan trọng không chỉ khi tự xây agent, mà cả khi dùng agent coding ngay lúc này
Có vẻ những giới hạn và cách hành xử này sẽ còn tiếp diễn một thời gian
Tôi mong xem ai sẽ là người đầu tiên phát triển Logic Core để tự động hóa kỹ sư context
Tôi cũng cho rằng đây chỉ là “kỹ năng dùng trong một tháng”
Rồi nó cũng sẽ sớm biến mất như bao trào lưu khác
Trong giới nghiên cứu LLM, các vấn đề này được xem là sản phẩm của các LLM hiện tại
Đã có nghiên cứu về cách dùng hàng triệu công cụ cùng lúc và sử dụng long context ổn định
Trong tương lai, trừ các trường hợp đặc biệt cần kết nối với nhà cung cấp khác, có lẽ chỉ một agent là đủ cho hầu hết tình huống
Những người thiết kế hệ thống agent tương lai dựa trên LLM hiện tại có khả năng sẽ giống như LangChain
Cũng giống hiện tượng LangChain làm cho GPT-3 trở nên lỗi thời ngay khi GPT-3.5 xuất hiện
Với ai từng dùng LLM hoặc biết LLM hoạt động thế nào, điều này khá hiển nhiên
Cái “kỹ năng” gọi là prompt engineering vốn dĩ cũng rõ ràng là một hạt nhân tạm thời, không thể tồn tại lâu
Về cơ bản, đây là việc cung cấp đầu vào (context) và hành động (output) cho LLM, và cần rất nhiều công việc pipeline để làm được điều đó
Tôi đồng ý với kết luận rằng “việc xây dựng các AI agent mạnh mẽ và đáng tin cậy đang rời xa chuyện tìm prompt thần kỳ hay bản cập nhật mô hình”
Đúng là cần tập trung hơn vào “context engineering: cung cấp đúng thông tin và công cụ, ở đúng định dạng và đúng thời điểm”
Nhưng nếu “đúng định dạng” và “đúng thời điểm” đó về bản chất chưa được định nghĩa, thì chẳng phải vẫn đang theo đuổi một “giải pháp thần kỳ” sao
Nếu “đúng thông tin” nghĩa là “thông tin khiến LLM đưa ra câu trả lời đủ chính xác”, thì tôi cho rằng về bản chất nó không khác gì prompt engineering
Với những cỗ máy phi quyết định như thế này, tôi không thấy có nhiều heuristic đáng tin cậy ngoài cách “thử prompt rồi xem kết quả”
Cuối cùng thì vẫn là kiểu tư duy ma thuật bất tận
Giờ có đổi tên từ “prompt engineering” sang “context engineering” thì rốt cuộc vẫn là cứ loay hoay chỉnh cái này cái kia để tìm thứ gì đó hiệu quả trong một không gian đầy bất định
Về bản chất thì đó là overfitting
Prompt engineering cuối cùng chính là như vậy
Vấn đề là “đúng định dạng, đúng thời điểm” vốn dĩ chưa được định nghĩa rõ
Phần lớn lời khuyên về “cách dùng AI cho tốt” thực ra đều bắt đầu từ chính vấn đề này
Cuối cùng vẫn có cảm giác như gõ trống làm lễ cúng
Trong khung lý thuyết mới nhất, quá trình này được chia thành hai giai đoạn: thăm dò (Exploratory) và khám phá (Discovery)
Giai đoạn thăm dò có thể hình dung như một thiết bị phun vật chất vào không khí
Nhanh chóng đưa vào các chất đánh dấu dễ nhận biết, thường là một phép ví von với phân
Giai đoạn khám phá thì được khái niệm hóa là phân tích kiểu lan tỏa của chúng
Tóm lại, hai bước này có thể diễn đạt là “cứ thử đại” rồi “xem kết quả”
Giờ khi ai cũng nhận ra “prompt engineering” không phải kỹ năng ghê gớm gì, tôi có cảm giác ngành AI cứ liên tục dời cột mốc mục tiêu
Kỹ năng mới rốt cuộc vẫn là “lập trình”
Vẫn là kỹ năng cũ
Muốn hiểu những thứ này thì phải tự viết chương trình
Càng viết chương trình để huấn luyện LLM, chạy inference và phân tích hành vi của nó, bạn sẽ càng hiểu nhiều hơn
Ban đầu tôi có lý thuyết và kỳ vọng về kết quả, nhưng sau khi thực sự huấn luyện LLM theo nhiều cách khác nhau, tôi đi đến kết quả và niềm tin hoàn toàn khác
Quá trình trực tiếp triển khai công cụ thực sự tạo ra khác biệt mang tính quyết định
Tôi cũng chỉ có kinh nghiệm lập trình machine learning ở mức trung bình, nhưng tôi nghĩ việc từng tự làm một compiler ở mức trung bình là chìa khóa để có được kết quả tốt trong các hệ thống phức tạp
Bạn nghĩ Karpathy biết được điều này bằng cách nào?
Câu trả lời nằm ở blog của Karpathy
Giống như lời khuyên muốn hiểu compiler thì hãy tự viết compiler
Về mặt kỹ thuật thì đúng, nhưng đa số mọi người không muốn đi sâu đến thế
Tôi có cảm giác cuộc thảo luận này ngày càng giống các diễn đàn game như WoW, nơi game thủ thử nghiệm chiến thuật và tranh cãi với nhau bằng thứ ngôn ngữ tập thể kỳ quái
Cái gọi là chiến thuật gần như được tìm ra bằng thử-sai, rồi chỉ nói bằng thứ ngôn ngữ mà nhóm đó mới hiểu
Lập trình cũng đang dần thích nghi với thời đại bị game hóa
Hiện tượng power user bán các chiến lược giả cho người mới hoặc cho giới quản lý quá thiên về tư duy game
Thực ra ở các làn sóng phần mềm doanh nghiệp trước đây cũng lặp lại điều tương tự
Chỉ là lần này, cái “trào lưu do power user dẫn dắt” đã xâm nhập rất sâu vào phạm vi ảnh hưởng/kiểm soát/workflow vốn thuộc về developer, tức những người xây dựng
Cảm giác mà developer hiện nay trải qua có lẽ không khác cảm giác trước đây của các vị trí QA, SRE, CS khi bị ép áp dụng tool hay thông lệ chỉ vì “đó là xu hướng!”
Kết luận:
“Xây dựng AI agent mạnh mẽ và đáng tin cậy không nằm ở prompt thần kỳ hay cập nhật mô hình, mà ở context engineering: cung cấp đúng thông tin và công cụ cho đúng định dạng và đúng thời điểm, phù hợp với mục đích kinh doanh”
Thật ra đây cũng là nguyên lý áp dụng y hệt cho con người
Nếu được cung cấp đúng thông tin vào đúng lúc, con người cũng giải quyết tốt hơn
Tôi không thích xu hướng so sánh máy học với con người theo kiểu hời hợt như vậy
Nó không mang lại nhiều insight, mà cũng hiếm khi đúng
Cuối cùng thì đó vẫn là chuyện tìm và bấm đúng nút mục tiêu trong môi trường một cách hiệu quả
Không khác quá nhiều so với software engineering truyền thống
Chỉ là kết quả có tính phi quyết định hơn
Tôi luôn liên tục yêu cầu phía UX và product giải thích về “mockup, yêu cầu, tiêu chí nghiệm thu, mẫu input/output, vì sao tính năng này quan trọng” v.v.
Trừ khi có thể quét não để trích xuất điều họ muốn, còn không thì việc mô tả đúng cái mình muốn là điều bắt buộc
Đây không phải thứ có thể chỉ dựa vào ‘cảm giác’
Không phải nhiều context hơn, mà là context tốt hơn mới là chìa khóa
(ví dụ điển hình: X-Y problem)
Ngay cả khi đưa cho LLM hiện đại một context cực kỳ tốt, nó vẫn thất bại
Công ty chúng tôi đã đào rất sâu vào phần này hơn 2 năm nay
Mức độ niềm tin mù quáng vào quan điểm “context là câu trả lời” thật đáng kinh ngạc
Đến một lúc nào đó, tôi nghĩ tự làm trực tiếp còn nhanh hơn là dùng AI
Ít nhất cách đó còn để lại bài học hữu ích, chứ không phải đổ hàng giờ vào việc tạo context cho LLM
Tôi tò mò về những trường hợp LLM thất bại dù đã có đủ context
Sẽ rất tốt nếu bạn có thể chia sẻ ví dụ cụ thể
Việc đi tìm prompt thần kỳ thực ra chưa bao giờ đúng nghĩa là “prompt engineering”
Về bản chất, nó luôn là “context engineering”
Nhiều chuyên gia AI tự xưng đã bán nó như prompt engineering, nhưng thực ra họ không thật sự hiểu bản chất
RAG (retrieval-augmented generation) không phải khái niệm mới xuất hiện trong năm nay
Các công cụ bọc lại những bí quyết phức tạp như embedding, vector DB, graph DB cũng đang ngày càng phổ biến hơn
Các nền tảng lớn cũng đang cải thiện những công cụ liên quan để cung cấp hệ sinh thái phong phú hơn
Lúc nào cũng có cảm giác người ta lại tạo ra một khái niệm mới cho cùng một vấn đề rồi chỉ đổi tên
Cuối cùng vẫn là lặp đi lặp lại thứ giống nghi lễ shaman ngồi trước đống lửa, gõ trống và niệm chú
Cảm giác như triệu hồi quỷ, phải đọc đúng thần chú với đúng từ ngữ rồi hy vọng nó làm theo mệnh lệnh của mình
Trong đầu tôi luôn có sự giằng co giữa tâm thế của một kỹ sư muốn độ tin cậy, khả năng lặp lại, độ phủ test mạnh, với sự phức tạp mất kiểm soát hiện tại
Tôi thật sự nể những ai demo các hệ thống như vậy ở quy mô lớn
Nó làm tôi nhớ đến thời từng demo nghiên cứu lỗ hổng bảo mật
Dù chuẩn bị tốt đến đâu, kết quả tại hiện trường vẫn có thể lệch bất cứ lúc nào, và tôi từng đổ mồ hôi như tắm khi thuyết trình
Đây thực sự là góc nhìn rất giống với trải nghiệm của tôi
Khi đưa context vào LLM, tôi thường tự hỏi: “Chỉ với thông tin này thì con người có giải được không?”
Khi trước làm sản phẩm text2SQL, mỗi lần model thất bại thì ngay cả các nhà phân tích dữ liệu thật cũng thường nói kiểu “À, bảng đó là bảng cũ. Giờ phải dùng bảng này”
Cuối cùng thì nếu LLM thiếu context mà một ‘nhà phân tích con người’ cần, nó cũng sẽ mắc lỗi
Nếu có một thứ còn thiếu trong chủ đề này thì đó chính là “đánh giá (evaluations)”
Tôi vẫn ngạc nhiên khi thấy nhiều dự án AI không có đánh giá, hoặc làm rất hời hợt
Đánh giá còn quan trọng hơn cả test trong kỹ thuật truyền thống
Tập đánh giá không cần quá lớn, chỉ cần bao phủ tốt miền bài toán là đủ
Không có nó thì tất cả chỉ là “đoán mò”
Và tôi cũng thường tự hỏi “Liệu với thông tin này con người có giải được không?”
Đã có lúc tôi kỳ vọng LLM giải được những bài toán mà ngay cả con người cũng không giải nổi
Quy luật cổ điển của lập trình máy tính
“Nếu cố để lập trình viên có thể code bằng tiếng Anh, bạn sẽ phát hiện ra rằng thực ra họ cũng không viết tiếng Anh cho ra hồn”
Có phần đùa, nhưng cũng phần nào đúng
Phần lớn ngôn ngữ tự nhiên không rõ ràng đến vậy
Nếu bạn có thể diễn đạt cực kỳ chính xác điều mình muốn bằng tiếng Anh, thì có lẽ bạn cũng đã có thể viết thẳng nó bằng một ngôn ngữ để máy diễn giải
Nếu hỏi câu hỏi có/không
Thì có 50% khả năng nhận được câu trả lời sai
Nó có đặc tính như vậy
Tôi thường để model hỏi những câu như vậy trước khi thực sự bắt đầu làm việc
Ví dụ, nếu có điểm nào chưa chắc chắn thì hãy hỏi lại, và yêu cầu ví dụ về các pattern code đang được dùng
Để nó có thể lấy chính các template đang dùng làm ví dụ tham chiếu
Những người cosplay data scientist không muốn có đánh giá
Vì thế ngoài các sản phẩm thực sự kiếm tiền thì hầu như không có đánh giá
Nói “hoàng đế cởi truồng” thì không kiếm được tiền
Nhưng với các trường hợp thực sự cần cho công việc, thì nhất định phải có phần đánh giá