LLM codegen fails and how to stop 'em — Danilo Campos, PostHog

• PostHog Wizard tự động hóa quy trình tích hợp PostHog, chuyển đổi hai giờ "đau khổ" thành tám phút trải nghiệm giải trí, được chứng minh qua 15.000 lượt tích hợp mỗi tháng và phản hồi tích cực từ người dùng.
• Thành công của Wizard đến từ việc xử lý các thách thức phổ biến của AI như "model rot" (mô hình lỗi thời), kiến trúc không tối ưu, và khả năng ứng biến không mong muốn của tác nhân.
• Các chiến lược chính bao gồm cung cấp ngữ cảnh cập nhật, sử dụng các dự án mẫu ('model airplanes') để hướng dẫn kiến trúc chuẩn, dẫn dắt tác nhân từng bước ('breadcrumbing'), và hỏi phản hồi trực tiếp từ AI để liên tục cải thiện hiệu suất.

• Chống "Model Rot" bằng RAG: Sử dụng phương pháp Retrieval-Augmented Generation (RAG) bằng cách đưa các tài liệu markdown cập nhật (như tài liệu posthog.com) trực tiếp vào cửa sổ ngữ cảnh của tác nhân, đảm bảo thông tin luôn chính xác và mới nhất.
• Hướng dẫn kiến trúc bằng "Model Airplanes": Xây dựng các dự án mẫu thu nhỏ và tối ưu ("model airplanes") với kiến trúc lý tưởng trên nhiều khung làm việc. Những mẫu này giúp tác nhân hiểu rõ hình dạng và vị trí tối ưu để đặt các sự kiện theo dõi, đồng thời tiết kiệm mã thông báo.
• Hạn chế ứng biến của tác nhân bằng "Breadcrumbing": Dẫn dắt tác nhân từng bước trong quá trình giải quyết vấn đề. Bắt đầu với các câu hỏi chung để xác định các tệp có giá trị kinh doanh, sau đó dần dần đưa ra các hướng dẫn cụ thể hơn, thay vì cung cấp quá nhiều thông tin chi tiết ngay từ đầu.
• Cải thiện thành công tác nhân qua "Inference Time Interrogation": Thêm một bước "tra vấn" vào cuối mỗi lần chạy của tác nhân, hỏi nó "Chúng tôi có thể làm gì tốt hơn để giúp bạn thành công?" Điều này giúp phát hiện các vấn đề như công cụ bị thiếu, hướng dẫn mâu thuẫn hoặc ngữ cảnh sai ngôn ngữ.
• Kiểm soát chi tiết và an toàn công cụ: Thiết lập quyền kiểm soát chi tiết đối với việc sử dụng công cụ của tác nhân, đặc biệt là với các tệp nhạy cảm như .env. Xây dựng các công cụ chuyên biệt, giới hạn (ví dụ: chỉ kiểm tra sự hiện diện của khóa, ghi giá trị mới) để ngăn chặn rò rỉ dữ liệu hoặc hành vi phá hoại.
• Giá trị chuyển dịch từ mã nguồn sang ngôn ngữ tự nhiên: Nhận ra rằng giá trị của ngôn ngữ tự nhiên (tài liệu markdown, văn xuôi) đang tăng lên so với mã nguồn truyền thống. Các mô hình AI tốt hơn có thể tận dụng văn xuôi chất lượng cao để tạo ra nhiều giá trị hơn.
• Thiết kế tác nhân như "con bạch tuộc": Cung cấp đủ thông tin và sắp xếp hợp lý, sau đó cho phép tác nhân sự linh hoạt để tự điều chỉnh và giải quyết vấn đề, thay vì ràng buộc quá chặt chẽ hành vi của chúng (ngoại trừ các biện pháp an toàn).
• Quản lý ngữ cảnh hiệu quả với "Skill Files": Sử dụng một dịch vụ ngữ cảnh để tổng hợp tất cả tài liệu, "model airplanes" và các thông tin liên quan thành một "skill file" duy nhất, đảm bảo tác nhân luôn có quyền truy cập vào ngữ cảnh đầy đủ và nhất quán.

• wizard — trình hướng dẫn
• integration — tích hợp
• model rot — mô hình lỗi thời
• RAG (Retrieval-Augmented Generation) — Tạo sinh tăng cường truy xuất
• agent — tác nhân AI
• tool — công cụ
• model airplanes — mô hình máy bay (dự án mẫu thu nhỏ)
• breadcrumb — dẫn đường (bằng mẩu bánh mì)
• inference time interrogation — tra vấn thời gian suy luận
• LLM gateway — cổng LLM (Large Language Model)

Giới thiệu về PostHog Wizard

Chào buổi sáng. Ai sợ robot? Tôi không sợ robot, bởi vì chúng đã "làm mũi tôi chảy máu" quá nhiều lần đến nỗi chúng không thể gây thêm bất kỳ nỗi đau nào nữa. Và đó là điều tôi muốn kể cho bạn nghe vào buổi sáng tốt đẹp này. Cảm ơn bạn đã đến trò chuyện cùng tôi. Tên tôi là Danilo. Tôi làm việc tại PostHog và tạo ra PostHog Wizard. Điều rất đặc biệt mà PostHog Wizard làm được là nó bỏ qua hai giờ đồng hồ cực kỳ khó chịu mà bạn sẽ không bao giờ lấy lại được trong đời, và biến nó thành tám phút giải trí "giả tạo" cho bạn.

Làm thế nào chúng tôi làm được điều này? Chúng tôi có 15.000 người mỗi tháng chạy wizard này, và đổi lại, họ nhận được một hệ thống tích hợp (integration) PostHog hoạt động hiệu quả và họ thực sự yêu thích. Chúng tôi làm điều đó như thế nào? Tôi sẽ kể cho bạn nghe tất cả về nó hôm nay. Để nhấn mạnh rằng điều này thực sự hiệu quả, trong sáu giờ qua, chúng tôi đã nhận được hai bài đăng tự phát trên Blue Sky và Twitter, nơi mọi người thực sự hạnh phúc.

Bây giờ, điều này có vẻ đáng sợ. Tôi có một robot ở ngoài kia đang viết mã cho mọi người. Điều gì sẽ xảy ra nếu nó làm việc kém hiệu quả? Chà, chúng tôi đã học được tất cả các cách mà nó có thể làm việc kém hiệu quả. Tôi sẽ kể cho bạn nghe về những cách mà những công việc tồi tệ đó xảy ra. Tôi sẽ kể cho bạn một số chiến lược mà bạn có thể sử dụng để các tác nhân viết mã tự động của bạn cũng làm đúng việc.

Xử lý "Model Rot" (Mô hình lỗi thời)

Được rồi, hãy bắt đầu với vấn đề dễ nhất: model rot (mô hình lỗi thời). Việc huấn luyện một mô hình mất rất nhiều thời gian, nhưng không chỉ là thời gian, mà còn là tiền bạc. Bạn không thể "chơi đùa" như Anthropic, huấn luyện một mô hình vào cuối tuần cho vui. Đây là một khoản chi phí vốn nghiêm túc. Hậu quả của việc này là các mô hình sau khi huấn luyện sẽ không còn phản ánh thực tế nữa. Chúng là một "ảnh chụp nhanh" của thế giới và web như nó đã từng cách đây sáu, tám, mười hai, hoặc mười tám tháng.

Điều này hữu ích cho nhiều thứ, nhưng nếu bạn là một dự án phần mềm phát triển nhanh – và có rất nhiều dự án phần mềm như vậy – thì hậu quả là mô hình không còn biết chuyện gì đang xảy ra nữa. Vì vậy, bạn phải đối phó với model rot. Đây là những vấn đề khá đơn giản. Có lẽ bạn đã từng giải quyết những vấn đề tương tự trước đây. Có ai ở đây có ý kiến về cách bạn giải quyết model rot không? Tôi thấy một số người lắc đầu. Gì vậy? RAG (Retrieval-Augmented Generation) là tốt. Mặc dù tôi sẽ nói cho bạn biết điều này: với cửa sổ ngữ cảnh (context window) như hiện tại, bạn không thể đánh bại việc chỉ cần đưa một loạt các tệp markdown vào ngữ cảnh và vá lại các lỗ hổng.

Và đây chính xác là những gì chúng tôi làm với PostHog Wizard. Chúng tôi có tài liệu mới nhất, nóng hổi trên posthog.com. Và chúng tôi cho phép tác nhân đưa ra lựa chọn. Chúng tôi hỏi: "Bạn đang làm gì? Bạn đang tích hợp gì ở đây? Chúng tôi đã phát hiện ra điều gì?" Và tác nhân có thể sử dụng công cụ (tool) để truy cập, chọn từ một danh sách các tài liệu markdown mới nhất mà nó có thể đưa thẳng vào ngữ cảnh của mình, hoàn thành công việc và thực hiện mọi thứ một cách chính xác. Điều đã thúc đẩy tất cả điều này là một năm trước, mọi người bắt đầu hỏi các tác nhân rất nguyên thủy của họ, kiểu như: "Được rồi, Cursor. Tôi muốn bạn tích hợp PostHog cho tôi." Và nó đã làm một công việc khủng khiếp. Phải không? Nó chỉ đơn giản là tự tạo ra các khóa (key), tự tạo ra các mẫu (pattern), tự phát minh ra các API không tồn tại. Và đó không phải lỗi của chúng tôi – chúng tôi không làm gì cả – nhưng đó lại là vấn đề của chúng tôi. Vì vậy, việc tìm ra cách chúng tôi có thể cung cấp ngữ cảnh chính xác, cập nhật cho tác nhân để nó thực hiện công việc đúng đắn là một phần lý do khiến mọi người vui vẻ đăng bài về những gì wizard đã làm cho họ.

Giải quyết kiến trúc không tối ưu bằng "Mô hình Máy bay"

Được rồi. Các mô hình này, rõ ràng là chúng đã thu thập dữ liệu từ mọi loại dự án ngoài kia. Và tôi không cần phải đoán rằng không phải tất cả các dự án đó đều có kiến trúc tuyệt vời, bởi vì một số quyết định mà các tác nhân này đưa ra khi xây dựng một dự án rất kỳ lạ. Vậy bạn làm gì? Làm thế nào để bạn giải quyết việc một tác nhân hình dung cách kết hợp mọi thứ, có thể về mặt kỹ thuật là khả thi, nhưng không hoàn toàn lý tưởng?

Chà, tôi và những người bạn trong nhóm PostHog Wizard, chúng tôi duy trì một "đội bay" mà chúng tôi gọi là "mô hình máy bay" (model airplanes). Đây là những dự án đã triển khai PostHog. Chúng có mặt trên nhiều khung làm việc (framework), nhiều ngôn ngữ khác nhau. Nhưng điều khiến chúng trở thành "mô hình máy bay" là chúng tôi không có một ứng dụng sản xuất hoàn chỉnh thực sự ở đó. Điều chúng tôi có là một thứ mỏng hơn nhiều, một thứ tương tự như một "mảnh vụn" của một ứng dụng thực tế. Ví dụ, phần xác thực (auth) không hoạt động. Hay đúng hơn, auth hoạt động cho bất cứ thứ gì. Bạn có thể nhập bất cứ điều gì bạn muốn vào trường mật khẩu và bạn sẽ có thể đăng nhập. Nhưng auth có "hình dạng" của auth, có nghĩa là chúng tôi có thể cung cấp những "mô hình máy bay" này cho tác nhân. Và sau đó tác nhân biết, "Ồ, tuyệt. Vậy khi auth xuất hiện, đây là một nơi tuyệt vời để đặt việc theo dõi sự kiện cụ thể." Một việc theo dõi sự kiện khác mà người ta muốn sử dụng khi họ muốn theo dõi đăng nhập và danh tính trong PostHog.

Và như vậy, thông qua việc duy trì một thứ không phức tạp như ứng dụng sản xuất thực tế – điều này cũng có nghĩa là, tất nhiên, nó hiệu quả về mã thông báo (token) hơn – bạn sẽ có được hình dạng chính xác của một tích hợp như một mẫu (pattern) mà mô hình và tác nhân có thể hoàn thành một cách nhất quán mỗi lần.

Hạn chế sự ứng biến của Tác nhân bằng "Breadcrumbing"

Vì vậy, ngoài kiến trúc kỳ lạ, tác nhân có thể tìm thấy một con đường kỳ lạ xuyên qua không gian vấn đề. Và với 15.000 tích hợp mỗi tháng, nó có thể tìm ra 15.000 cách để hoàn thành một tích hợp PostHog. Và mặc dù điều này sẽ đáp ứng yêu cầu "chúng tôi đã tự động hóa việc tích hợp", nhưng nó sẽ tạo ra một gánh nặng hỗ trợ rất kỳ lạ cho chúng tôi vì chúng tôi sẽ có quá nhiều cách khác nhau để thiết lập PostHog. Chẳng hạn, "Cái quái gì thế này? Làm thế nào tôi hiểu được điều này?" Đây sẽ là một vấn đề ở quy mô lớn. Điều này sẽ giống như câu chuyện về chàng học việc của phù thủy.

Vì vậy, để hạn chế sự ứng biến (improvisation), điều chúng tôi làm là "dẫn đường" cho tác nhân bằng "những mẩu bánh mì" (breadcrumb). Chúng tôi không nói trước cho tác nhân chính xác những gì chúng tôi sẽ làm. Bạn có thể đã thấy điều này trước đây ngay cả khi bạn đang sử dụng Clawed code: nếu bạn nói cho nó chính xác nơi bạn muốn đến, nó có thể tạo ra một "lỗ hổng" hình dạng Clawed code xuyên qua bốn tác vụ đầu tiên và sau đó trở nên rất "làm màu" ở tác vụ thứ năm. Và đây không phải là điều chúng tôi muốn.

Vì vậy, một trong những điều chúng tôi làm là bắt đầu mà hầu như không nói cho tác nhân biết chúng tôi đang làm gì. Chúng tôi thậm chí không thực sự đề cập rằng chúng tôi đang thực hiện một tích hợp PostHog. Chúng tôi bắt đầu bằng một câu hỏi kiểu như: "Đâu là những tệp có giá trị kinh doanh thú vị trong dự án này? Bạn có thể tìm thấy thứ gì đó giống như giao diện đăng nhập hay giao diện Stripe, hoặc thứ gì đó có thể chỉ ra rằng ai đó sắp thực hiện giao dịch không?" Chúng tôi đi tìm những tệp có thể phản ứng với tác động trong hoạt động kinh doanh của ai đó. Và điều buồn cười là những thứ liên quan đến kinh doanh thường tạo ra một "cái bóng" rất lớn trong mã. Và vì vậy, chúng tôi có thể phát hiện loại này một cách rất đáng tin cậy.

Sau đó, chúng tôi nói: "Được rồi, đây là một số tệp thú vị. Những sự kiện thú vị nào đang diễn ra trong các tệp đó? Đừng viết mã ngay bây giờ. Hãy cùng suy nghĩ về một số sự kiện thú vị mà chúng ta có thể thêm vào đây. Chúng có thể là gì?" Vì vậy, chúng tôi lập danh sách các sự kiện này, lấy tên sự kiện, mô tả cho các sự kiện đó và chúng tôi chỉ đơn giản là đặt chúng vào một tệp nhỏ. Và đây là sự khởi đầu của mọi thứ. Chúng tôi thậm chí không nhất thiết phải biết chúng tôi đang đi đâu.

Vì vậy, "mẩu bánh mì" tiếp theo là: "Được rồi, hãy bắt đầu thực sự triển khai PostHog." Giờ đây chúng tôi biết rất nhiều sự kiện. Chúng tôi đã suy nghĩ rất kỹ về những sự kiện đó có thể là gì. Và giờ đây chúng tôi có tài liệu và mọi thứ mà chúng tôi có thể tải theo khung làm việc và ngôn ngữ mà chúng tôi quan tâm ở đây. Và vì vậy, chúng tôi có thể đáng tin cậy đi vào đó và bắt đầu thực hiện các sửa đổi đối với các tệp của mọi người. Và các sửa đổi một lần nữa không ngu ngốc và không điên rồ.

Tăng cường thành công của Tác nhân thông qua "Tra vấn"

Được rồi. Bây giờ chúng ta có thể làm tất cả những việc chu đáo để giúp tác nhân thành công. Nhưng mối đe dọa lớn nhất đối với kết quả của tác nhân lại chính là chúng ta. Chúng ta là những sinh vật yếu ớt, nhỏ bé. Chúng ta có một chút thịt ở đây, bị nhốt trong đầu mình. Và chúng ta cũng có một giới hạn ngữ cảnh. Chúng ta không thể thực sự định lượng nó, và nó thay đổi tùy thuộc vào việc chúng ta uống cà phê từ bao lâu rồi, và liệu chúng ta có ăn sáng vào buổi sáng hôm đó không. Ngữ cảnh của chúng ta không chỉ bị giới hạn mà còn rời rạc. Có những thứ chúng ta nhớ đã triển khai tuần trước và có những thứ chúng ta đã quên từ tháng trước. Và vì vậy, chúng ta đang thực hiện các thay đổi và chỉnh sửa mã, và phát triển những thứ mà tác nhân của chúng ta đang làm việc xung quanh. Và đôi khi chúng ta bỏ sót những thứ thực sự quan trọng.

Và vì vậy, có một lúc chúng tôi có một hướng dẫn công cụ của MCP mâu thuẫn với một công cụ khác. Và tác nhân kiểu như, "Ôi trời, tôi không biết phải làm gì ở đây. Bạn đặt tôi vào một tình huống bất khả thi." Chúng tôi đã có một tình huống mà chúng tôi nói với nó, "Này, có một công cụ mà bạn chắc chắn cần phải sử dụng để hoàn tất thiết lập này." Và tác nhân đang đến đó, "Được rồi, tuyệt. Hãy sử dụng công cụ." Đợi đã, MCP không có công cụ nào tên này. Tôi muốn chạy hàng trăm lần với công cụ bị thiếu này. Và điều gì đang xảy ra ở đó?

Vì vậy, nếu chúng tôi không hỏi, chúng tôi sẽ không biết. Và vì vậy, một trong những điều bạn có thể làm rất hữu ích và khá rẻ tiền là một chút "tra vấn thời gian suy luận" (inference time interrogation) về những gì vừa xảy ra với tác nhân của bạn. Vào cuối mỗi lần chạy, ngay tại stop hook, chúng tôi hỏi một câu hỏi rất đơn giản. Chúng tôi đang thực hiện một chút nghiên cứu người dùng, nhưng người dùng trong trường hợp này là một robot. Chúng tôi hỏi tác nhân robot, "Này, chúng tôi có thể làm gì tốt hơn để giúp bạn thành công trong lần chạy này?" Và sau đó nó nói cho chúng tôi biết. Và đó là cách chúng tôi phát hiện ra: "Này, chúng tôi không cấp cho bạn quyền truy cập vào công cụ." Và vì vậy không có công cụ. Vì vậy, chúng tôi phải sử dụng những chỉ thị mâu thuẫn này mà không có sự "tra vấn" liên tục. Ồ, một ví dụ hay là chúng tôi cứ tiếp tục cung cấp cho nó các hướng dẫn cho JavaScript, và đó lại là một dự án Python mà nó đang làm việc. Tất nhiên, điều này không gây khó chịu, nhưng chúng tôi sẽ xác định nó theo cách đó. Vấn đề lớn là bạn phải hỏi để tìm ra.

Đảm bảo an toàn và kiểm soát Công cụ

Bây giờ, cũng có những trò gian lận (shenanigans) mà bạn phải lo lắng ở đây, bởi vì việc chạy một tác nhân trên máy của người khác đòi hỏi một lượng lớn sự tin tưởng, đúng không? Chúng tôi có một robot có thể làm bất cứ điều gì tiềm năng. Và chúng tôi không muốn làm điều gì đó phá hoại hoặc gây hại cho dự án của người dùng. Chúng tôi không muốn đặt họ vào tình thế tồi tệ hơn.

Và một trong những phiên bản đầu tiên của wizard của chúng tôi thực sự sẽ đọc các tệp .env, điều này cần thiết để thực hiện ghi (write). Đúng không? Bạn không thể ghi mù quáng vào một tệp. Đó chỉ là một trong những cơ chế mà các tác nhân này hoạt động. Và cũng không lý tưởng khi gửi nội dung tệp .env của mọi người lên đám mây. Và kiểu như, "Được rồi, tuyệt. Thứ đó đang nằm trong nhật ký chết tiệt của ai đó mà bạn không biết." Vì vậy, đây rõ ràng là tin xấu.

Nhưng khi bạn thiết kế những thứ này, bạn có quyền kiểm soát chi tiết (fine grain control) đối với việc sử dụng công cụ. Đúng không? Bạn có thể quyết định: "Được rồi, những công cụ này ổn. Những kiểu đọc này ổn. Những kiểu đọc này thì không ổn." Vì vậy, chúng tôi thực sự đã khóa chặt những gì tác nhân được phép làm xung quanh bất kỳ thứ gì là tệp .env. Và sau đó chúng tôi có thể xây dựng cho nó một công cụ có thể làm hai việc: nó có thể kiểm tra sự hiện diện của một khóa (key) - liệu khóa này có tồn tại không? Và nó có thể ghi một giá trị mới vào một khóa. Và đó là tất cả. Không có gì được gửi lên về mặt suy luận (inference) cho tệp .env này. Và vì vậy, kết quả là chúng tôi không còn chạm vào những thứ này nữa. Nhưng một lần nữa, bạn đang thả lỏng những robot này trên máy tính của bất kỳ ai, bạn phải để mắt đến những trò gian lận này, bởi vì ngay cả khi bạn đang giải quyết vấn đề bạn đã hứa sẽ giải quyết, việc làm theo cách đó có thể khiến bạn trông như một kẻ tồi.

Tư duy Lập trình truyền thống

Bây giờ, đây là vấn đề lớn. Đây là vấn đề kỳ lạ, bởi vì trong suốt sự nghiệp của chúng ta, chúng ta đã được khen thưởng bằng việc viết mã, viết mã. Chúng ta viết mã thông minh. "Ồ, tôi có một cấu trúc ở đây. Thứ này hoạt động. Thứ này đáng tin cậy. Thứ này phức tạp. Nhưng hiệu suất thực sự tốt." Và chúng ta chỉ cần viết mã thật nhiều ra khỏi thứ này. Nếu chúng ta viết mã để thoát khỏi vấn đề này, mọi thứ sẽ ổn. Được rồi.

Giá trị của Mã nguồn và Ngôn ngữ Tự nhiên

Trong thế giới hiện tại, giá trị của mã nguồn không còn như trước. Một điều khá thú vị về mã nguồn là: nếu hôm nay bạn viết một đoạn mã mà bạn cho là tốt, nhưng ngày mai một mô hình mới ra mắt, đoạn mã bạn viết vẫn giữ nguyên giá trị. Thậm chí, giá trị đó có thể giảm đi một chút. Mã nguồn luôn là một tài sản giảm giá trị. Bạn viết nó, có thể ship nó ra thế giới khi nó đã hơi "mục rữa" một chút. Bạn có thể nghĩ rằng có một số tech debt và bạn sẽ phải giải quyết nó vào một lúc nào đó. Nhưng trong lúc đó, bạn đã ship đúng hạn, bạn đã hoàn thành những gì cần làm.

Wizard mà khiến mọi người hài lòng được tạo thành từ 90% markdown files, 8% công cụ để phân phối và xử lý các markdown files, và phần còn lại là những thứ liên quan đến Agent Harness. Ngôn ngữ tự nhiên (dạng văn xuôi) chính là nơi chứa đựng phần lớn giá trị của chúng ta hiện nay. Khi bạn viết văn xuôi xuất sắc hôm nay, và ngày mai một mô hình thậm chí còn tốt hơn ra mắt, nó sẽ có thể tận dụng văn xuôi đó để làm được nhiều điều hơn nữa.

Thiết kế Tác nhân như một "Con bạch tuộc"

Một tác nhân giống như một con bạch tuộc. Nó có thể luồn lách, chui vào những góc hẹp, và tự điều khiển để vượt qua các vấn đề. Bạn không nên hạn chế quá mức khả năng giải quyết vấn đề của tác nhân, ngoài những hành vi phá phách mà chúng ta đã thảo luận. Thay vì suy nghĩ "làm thế nào để ràng buộc chặt chẽ hành vi của tác nhân này?", chúng ta nên đặt câu hỏi: "Làm thế nào để tôi lùi lại, cung cấp đủ thông tin cho nó, và sắp xếp thông tin đó theo trình tự hợp lý để nó thực hiện điều tôi muốn, đồng thời khiến mọi người hài lòng trong quá trình đó?"

Chia sẻ Kinh nghiệm Xây dựng Robot

Đây là những gì tôi học được từ việc xây dựng robot, với nhiều trải nghiệm "đau thương". Tôi còn vài phút nữa. Có ai có câu hỏi nào về hành trình kỳ lạ khi xây dựng robot này, thứ khiến mọi người hạnh phúc không? Mời đặt câu hỏi.

Quản lý Ngữ cảnh và Tệp Kỹ năng

Chắc chắn rồi. Cách chúng tôi cung cấp ngữ cảnh cho wizard là chúng tôi sử dụng các skill file (tệp kỹ năng) được tạo ra từ context service của chúng tôi. Context service này sẽ lấy tất cả các model airplane đó, làm phẳng chúng thành một markdown file duy nhất, và sau đó đưa vào như một tham chiếu trong skill file. Nhờ đó, chúng tôi luôn có quyền truy cập vào model airplane đầy đủ, mà mô hình có thể nắm bắt và xử lý.

Đúng vậy, đây chỉ là một phần của nội dung bổ sung được đưa vào skill. Chúng tôi nhận thấy có nhiều loại đầu vào hữu ích có thể đưa vào skill file. Chúng tôi có tài liệu (documentation) ở dạng văn xuôi thuần túy, nhưng sau đó chúng tôi cũng đưa vào các model airplane để nó có thể hình dung được hình dạng của một tích hợp thành công. Và tác nhân tham chiếu tất cả những điều đó để hoàn thành công việc. Mời đặt câu hỏi.

Triển khai và Cổng API LLM

Chắc chắn rồi. Cái này sử dụng Claude agent SDK, mà chúng tôi sau đó đóng gói lại trong một CLI. Vì vậy, bạn chỉ cần chạy một lệnh duy nhất. Và sau đó, chúng tôi cung cấp inference miễn phí bằng cách ghi nhật ký vào post logs. Chúng tôi có LLM gateway này, nơi chúng tôi có thể chi trả tất cả các mã thông báo thay cho bạn. Đây là một quy trình khá phức tạp (như một "vườn bách thú") bởi vì đôi khi Claude sẽ lưu trữ thông tin ở một nơi mà chúng tôi không mong đợi, và sau đó nó sẽ gây lỗi cho người dùng. Đây vẫn là những ngày đầu cho việc thực hiện điều này như một dạng dịch vụ.

Còn gì nữa tôi có thể nói với bạn không? Sau đó tôi sẽ nhường chỗ cho diễn giả tiếp theo. Cảm ơn vì đã tham gia. Rất vui được gặp bạn. Chúc bạn có một ngày tuyệt vời!