Lời gọi hàm của LLM không mở rộng tốt; điều phối bằng mã đơn giản và hiệu quả hơn

• Cách để LLM xử lý toàn bộ kết quả trả về từ lời gọi công cụ là chậm, tốn kém và bất lợi cho khả năng mở rộng
• Thay vào đó, đề xuất để LLM điều phối theo cách xử lý dữ liệu có cấu trúc bằng mã dựa trên output schema
• Cách tiếp cận này phù hợp để xử lý khối lượng dữ liệu lớn nhờ chuỗi hàm bằng mã và quản lý bộ nhớ dựa trên biến
• Phương thức xử lý dữ liệu dựa trên thực thi mã có độ chính xác và khả năng mở rộng cao vì LLM không trực tiếp tái tạo dữ liệu
• Việc xây dựng môi trường runtime AI an toàn đang nổi lên như một bài toán mới, đòi hỏi môi trường thực thi bền vững và có khả năng duy trì trạng thái

---

Lời gọi hàm của LLM không mở rộng tốt; điều phối bằng mã đơn giản và hiệu quả hơn.

Giới hạn của cách làm truyền thống là đưa kết quả gọi công cụ trở lại cho LLM

• Khi dùng công cụ MCP(Machine Context Protocol), thông thường người ta gửi kết quả đầu ra của công cụ cho LLM dưới dạng message rồi dẫn dắt hành động tiếp theo
• Trong các trường hợp sử dụng thực tế, máy chủ MCP của Linear và Intercom trả về các phản hồi JSON rất lớn
• JSON tương tự API nhưng không có output schema được định nghĩa, khiến LLM phải gánh việc phân tích toàn bộ văn bản
• Ví dụ, kết quả truy vấn danh sách issue của Linear có 50 mục, 70.000 ký tự, khoảng 25.000 token, là cực kỳ lớn
• Nhiều trường id không mang nhiều ý nghĩa nhưng vẫn tiêu tốn token, và nếu LLM phải tái hiện nguyên trạng chúng thì chi phí và lỗi sẽ tăng cao

Cần tách riêng xử lý dữ liệu và điều phối

• Cách làm hiện tại đang trộn xử lý dữ liệu và điều phối vào cùng một phiên chat
• Một số nơi tạo thêm thread khác như một "agent" cho việc này, nhưng nếu JSON đã có cấu trúc thì đó là cách làm kém hiệu quả
• Cách tốt hơn là xử lý trực tiếp dữ liệu có cấu trúc bằng mã
  • Ví dụ: thay vì để LLM tạo đầu ra cho việc sắp xếp issue, chạy sort bằng mã rồi chỉ trả về mảng kết quả

Xử lý dữ liệu dựa trên thực thi mã

• Tính toán AI thông qua thực thi mã đã được dùng trong nhiều AI interpreter khác nhau
• Cách này cho phép một cấu trúc gọn hơn, trong đó LLM không trực tiếp xuất dữ liệu mà chỉ cần quyết định cách sử dụng công cụ

Các khái niệm chính

• Dùng biến như bộ nhớ: gán giá trị = lưu trữ, output = truy xuất, khi gọi hàm thì truyền làm đối số
• Hỗ trợ chuỗi hàm: kết hợp nhiều lời gọi hàm song song/tuần tự, và biểu diễn phụ thuộc bằng luồng tự nhiên trong mã
• Xử lý dữ liệu lớn có thể mở rộng: kết hợp với NumPy, pandas... để xử lý dễ dàng từ hàng nghìn đến hàng chục nghìn bản ghi
• Cũng có thể gọi LLM khác: trong đoạn mã do LLM viết, có thể gọi một LLM khác để xử lý dữ liệu phi cấu trúc

MCP đã sẵn sàng chưa?

• Đặc tả MCP đã định nghĩa input schema, và gần đây cũng đã có PR cho output schema được gửi lên
• Khi output schema trở nên phổ biến, có thể dùng theo các cách như sau:
  • Dashboard tình trạng issue
  • Báo cáo ticket hoàn thành hằng tuần
  • AI giám sát các ticket bị đình trệ và chủ động đẩy thông báo

Thách thức của môi trường thực thi mã

• Bảo mật là vấn đề cốt lõi: vì chạy mã do AI/người dùng tạo ra nên cần thiết kế để ngăn lộ API key và dữ liệu
• Với Lutra, môi trường thực thi được cấu thành theo mô hình sandbox, và chỉ cung cấp cho model tài liệu gọi API
• Môi trường thực thi có trạng thái (như Jupyter) có chi phí cao, nên để phục vụ các phiên dài hạn cần các đặc tính stateless + persistent
• Điều này đang hình thành một danh mục mới là AI runtime, và việc thiết kế vẫn đang được thúc đẩy mạnh mẽ

Kết luận

• Cách làm truyền thống là đưa kết quả gọi công cụ vào LLM để xử lý có giới hạn về chi phí và độ chính xác
• Điều phối dựa trên mã cho phép xử lý gọn hơn, chính xác hơn và có thể mở rộng
• Môi trường thực thi mã AI đang được chú ý như runtime thế hệ tiếp theo với bảo mật, tính bền vững và khả năng mở rộng

[GN⁺]

Ý kiến Hacker News

• Chia sẻ trải nghiệm trong 2 năm qua khi lập luận rằng "một agent đủ tiên tiến thì không thể phân biệt với DSL". Thay vì yêu cầu agent nội hóa thuật toán, ý kiến cho rằng sẽ phù hợp hơn nhiều nếu dạy nó API rồi yêu cầu thiết kế thuật toán tận dụng API đó và chạy trong user space. Việc nhét thuật toán vào bên trong LLM bị xem là rất kém hiệu quả, trừ một số tình huống rất hẹp liên quan đến chi phí hoặc độ chính xác. Một phép so sánh được đưa ra là điều đó cũng giống như yêu cầu lập trình viên phải tự thực thi lời gọi hàm trong đầu
  • Đây được diễn giải như bằng chứng cho thấy con đường tiến tới ASI không nằm ở việc mở rộng năng lực của LLM, mà ở quá trình trích xuất và biên dịch các thuật toán tự cải thiện từ bên ngoài dưới dạng ứng dụng symbolic
  • Có người đề nghị chia sẻ căn cứ hoặc ví dụ cho việc đã dùng rộng rãi thuật ngữ 'agent' trong ngữ cảnh này từ 2 năm trước
• Chia sẻ kinh nghiệm tự xây dựng hệ thống agentic cho doanh nghiệp e-commerce của mình. Đã đánh giá smolagents và thấy nó thanh lịch, hấp dẫn nhưng có nhược điểm là làm tăng đáng kể độ phức tạp hệ thống. Nó hoàn hảo cho những môi trường như báo cáo động, nơi dữ liệu được sắp xếp và tổng hợp mà không có schema, nhưng với đa số công việc thì là overkill. Gemini và OpenAI hiện cung cấp tính năng Python interpreter nên có thể bao phủ phần lớn công việc của code agent. Cách tiếp cận liên tục chồng các thông điệp gọi công cụ lên stack là không có khả năng mở rộng nên không được khuyến nghị. Workflow agentic thực tế có vòng đời ngắn và kiểm soát độ phức tạp bằng cấu trúc cùng kỷ luật. Bài học từ phát triển phần mềm truyền thống vẫn giữ nguyên: quản lý quy mô của lời gọi hàm và ngăn hỗn loạn trước đây thế nào thì bây giờ cũng vậy. Cốt lõi của việc xây dựng hệ thống tốt là quản lý gánh nặng nhận thức của lập trình viên, và giải pháp đơn giản nhưng hoạt động đủ tốt thường vượt trội hơn cách làm cầu kỳ có hiệu năng cao. Tổ hợp lời gọi hàm là một ví dụ của kiểu giải pháp đơn giản đó, còn xử lý dữ liệu có cấu trúc cũng hoàn toàn có thể làm bằng các phương pháp parsing và biến đổi truyền thống. Khi cấu trúc chưa biết trước, ngay cả model giá rẻ cũng cho hiệu năng parsing rất tốt. Việc quản lý độ phức tạp của hệ thống agentic rốt cuộc có thể quy về bài toán quản lý trạng thái ứng dụng một cách chặt chẽ. Bằng cách thao tác message stack, có thể linh hoạt cấu hình active context đầu vào cho model, tương tự như quản lý bộ nhớ trong môi trường bị ràng buộc
  • Đây là phần tóm tắt chỉ ra rất chính xác các trade-off của hệ thống agentic. Nhóm chúng tôi cũng từng cân nhắc vấn đề tương tự khi xây dựng giải pháp tìm kiếm sản phẩm hội thoại cho e-commerce (IsarTech). Tổ hợp hàm và dữ liệu có cấu trúc là trọng tâm để kiểm soát độ phức tạp. Theo kinh nghiệm, đầu ra dựa trên type schema rõ ràng thực sự giúp nâng khả năng mở rộng của tool calling. Nhờ type schema, có thể quản lý cả cognitive load lẫn độ phức tạp hệ thống. Nên dựa vào hành vi mang tính quyết định ở mức cao nhất có thể, và chỉ dùng LLM khi gặp dữ liệu không schema hoặc có mơ hồ. LLM rất hiệu quả trong việc ánh xạ yêu cầu mơ hồ sang hệ thống mang tính quyết định. Tuy vậy, cần cân bằng giữa việc loại bỏ độ phức tạp từ đầu vào entropy cao, phi cấu trúc và việc làm tăng độ phức tạp thông qua chuỗi tool calling. Trong môi trường commerce thực tế, rất khó chỉ dùng một cách tiếp cận, và đầu ra có cấu trúc cũng có giới hạn với ý định mơ hồ nên cần chiến lược bổ sung
• Có ý kiến cho rằng vấn đề không nằm ở bản thân function calling mà ở thiết kế và cách dùng MCP. Phần lớn MCP chỉ là bản sao API và có vấn đề phát tán dữ liệu vô nghĩa. Việc lặp đi lặp lại các định dạng JSON lồng nhau tiêu tốn quá nhiều context đầu vào một cách không cần thiết và chứa nhiều thông tin không liên quan. Cần tối ưu như làm phẳng dữ liệu và loại bỏ các trường không cần thiết. MCP SaaS rốt cuộc chỉ đóng vai trò API gateway. MCP hiện tại bị xem là nguồn gây nhiễu chính và chưa được tối ưu đủ tốt
  • GraphQL chính là công nghệ tối ưu cho mục đích này. Nó được thiết kế để có thể chọn đúng các field cần thiết. Có người đã phát triển một Gateway mã nguồn mở chuyển nhiều truy vấn GraphQL thành một MCP server duy nhất
  • Có người đặt câu hỏi liệu vấn đề có phải là model không tuân thủ đúng các JSON schema phức tạp hay không
  • MCP không hữu ích, nhưng lọc bỏ mọi thứ cũng chưa chắc là phương án tốt nhất. Đôi khi agent cần xử lý lượng dữ liệu lớn. Trong trường hợp đó, thực thi code kèm đánh giá dữ liệu đơn giản và mô tả schema là cách tiếp cận có khả năng mở rộng tốt hơn. Dĩ nhiên, nếu hệ thống trở nên quá lớn thì các vấn đề tương tự lại xuất hiện. Giải pháp cuối cùng là tái hiện độ chính xác ở mức tư duy quyết định của con người bằng code, rồi để LLM gọi hệ thống quyết định đó. Về lý thuyết thì dễ nhưng nhấn mạnh rằng triển khai thực tế cực kỳ khó
  • Khi thử nghiệm đảo ngược chuỗi bằng ChatGPT, có người cảm thấy rất khó buộc LLM chỉ trả về một kết quả đơn giản và mức độ tin cậy cũng thấp. Từ trải nghiệm này, họ có thói quen luôn để nhiều LLM kiểm chứng lẫn nhau. Nếu tốc độ này tiếp diễn, đùa rằng có lẽ phải chuẩn bị trung tâm dữ liệu GPU riêng chỉ để đếm số ký tự trong một chuỗi đơn giản
• Gần đây đội ngũ Shopify đã open source Roast. Đây là công cụ cho phép chèn các tác vụ LLM phi quyết định vào workflow để tự động hóa những codebase khổng lồ. Nó được xem là thiết yếu cho tự động hóa công việc phức tạp
  • Có người rất ấn tượng với Roast. Sự kết hợp giữa tính quyết định và phi quyết định đặc biệt nổi bật. Tuy nhiên vẫn hơi bối rối về cách LLM điều phối nhiều tool calling và quyết định thứ tự gọi. Có vẻ nó hoạt động khi ra lệnh refactor, nhưng vẫn thắc mắc liệu có phù hợp với các tác vụ phức hợp như "cải thiện → kiểm thử lặp lại" hay không
  • Có cảm giác mới mẻ khi thấy Ruby vẫn tiếp tục hoạt động có ý nghĩa trong kỷ nguyên AI
  • Đây là một cách tiếp cận rất xuất sắc, chỉ cần đọc tài liệu cũng đã thấy kích thích trí tuệ. Việc đóng gói khả năng của LLM theo kiểu khai báo rất ấn tượng
  • Có người muốn biết cụ thể các workflow như vậy đang được dùng thực tế bên trong Shopify ra sao
  • Có người từng làm crash cả Claude Code Research Preview lẫn ChatGPT 4.5 Pro Deep Research (và có bằng chứng), nên đang tìm một công cụ thực sự hoạt động ổn định
• Câu trả lời tối ưu nằm ở mô hình hybrid chứ không phải một cực đoan nào. Ý kiến cho rằng tốt nhất là giải quyết được càng nhiều càng tốt bằng cách tiếp cận quyết định, còn LLM thì dùng cho các phần phức tạp khó đặc tả hoặc khó xử lý bằng kỹ thuật quyết định
  • Tập trung dùng LLM để tạo ra giải pháp mang tính quyết định (code), rồi khi đoạn code đó đã được kiểm chứng thì về sau tái sử dụng nó như code quyết định là một hướng tiếp cận thú vị
  • Có ý kiến cho rằng mục tiêu là giảm thiểu tối đa việc dùng LLM trong workflow
• Có người ngạc nhiên không biết trong hơn một năm rời ngành, những thử nghiệm phức tạp như thế này đã trở nên phổ biến hay chưa
  • Thực tế vẫn chỉ có số ít đang thử nghiệm, chưa có ca cách mạng nào nhưng đã có một số trường hợp hữu ích
  • Cũng có ý kiến rằng nếu bây giờ không làm kiểu công việc này thì chẳng mấy chốc sẽ lại phải rời ngành
  • Công việc hằng ngày của một số người giờ đã nghiêng hẳn sang tự động hóa thiết kế AI agent dựa trên LLM. Không hẳn vì họ muốn, mà là tự nhiên mọi thứ dần thành như vậy
• Có người thắc mắc vì sao lại dùng LLM để sắp xếp dữ liệu có cấu trúc
  • Mục tiêu chủ yếu là các xử lý dữ liệu phức tạp hơn như xây dashboard, tự động nhận diện issue ticket, review theo quý... Việc sắp xếp chỉ là ví dụ đơn giản để giúp dễ hình dung quy mô vấn đề
• huggingface smolagent là ví dụ tiêu biểu cho cách tiếp cận này, nhưng đi kèm nhược điểm là rollback hoặc khôi phục khi vận hành thực tế trở nên rất khó. Về nguyên tắc có thể giải quyết bằng cách bọc toàn bộ execution block trong distributed transaction, nhưng trên thực tế LLM lại khó tạo ra code đủ vững chắc theo mẫu này nên việc truy vết lỗi và xác định nguyên nhân thất bại trở nên khó khăn
  • Có sự đồng tình rằng ý tưởng cốt lõi của smolagent là tốt nhưng vấn đề nằm ở thực tế thực thi và xử lý lỗi. Ví dụ, khi việc thực thi code bị gián đoạn thì người ta muốn có thể tiếp tục ngay từ trạng thái đó. Đã xác nhận rằng LLM có thể viết code khôi phục trạng thái khá tốt, và hiện chức năng này đang hoạt động khá ổn trong sản phẩm thực tế (Lutra)
• Một cách tiếp cận khác là hướng LLM viết code gọi MCP như gọi hàm, dưới dạng Python script. Có chia sẻ ví dụ code
  • Lutra.ai được giới thiệu như một trường hợp đã áp dụng cách này trong thực tế. Điểm mấu chốt phụ thuộc vào việc thiết kế code runtime tốt đến đâu
• Có nhận xét rằng LLM đặc biệt yếu với JSON, nhất là JSON dung lượng lớn. Endpoint không nhất thiết phải trả dữ liệu ở dạng JSON. LLM đôi khi tỏ ra mạnh hơn nhiều với XML, hoặc cũng có thể tạo dữ liệu dưới dạng narrative text theo template
  • XML là định dạng có thông tin ngữ nghĩa nội tại, nên việc nó không được dùng rộng rãi như mặc định cho LLM có phần đáng ngạc nhiên. Khi cần, có thể chuyển XML sang JSON một cách quyết định rồi đưa vào pipeline, và cách này tỏ ra hiệu quả
  • Có người cho biết đã thu được kết quả khá tốt khi dùng bảng Markdown để trả dữ liệu cho LLM
  • Có người thắc mắc liệu XML cho hiệu năng tốt hơn là vì nó xuất hiện thường xuyên hơn trong dữ liệu huấn luyện của LLM hay vì số lượng token văn bản nhiều hơn. Cũng có nhắc đến khả năng các khối văn bản lại cung cấp nhiều ngữ cảnh hơn cho LLM