TypeChat: Nền tảng AI dựa trên trò chuyện

 (microsoft.github.io)
3 điểm bởi GN⁺ 2023-07-21 | 2 bình luận | Chia sẻ qua WhatsApp
  • Khó khăn lớn nhất khi gắn đầu vào ngôn ngữ tự nhiên vào ứng dụng hiện có là biến ý định của người dùng thành cấu trúc mà phần mềm có thể tin cậy xử lý, và TypeChat là một thư viện nhằm giải quyết điểm này bằng kiểu TypeScript
  • Vì phản hồi văn bản tự do của LLM khó parse ổn định, TypeChat hướng phản hồi thành JSON và gắn thêm kiểm chứng schema để biến nó thành dữ liệu mà ứng dụng có thể xử lý
  • Kiểu TypeScript có thể biểu diễn cấu trúc JSON một cách chính xác, và cũng là định dạng mà LLM đã tiếp xúc rất nhiều trong quá trình huấn luyện nên phù hợp để dùng làm schema phản hồi
  • Nếu phản hồi không khớp với kiểu, có thể phản hồi lại lỗi từ trình biên dịch TypeScript để sửa, nhờ đó tăng độ an toàn kiểu trước khi hậu xử lý hoặc yêu cầu người dùng xác nhận
  • TypeChat có thể cài bằng npm install typechat, được phát hành mã nguồn mở theo giấy phép MIT, đồng thời cung cấp tích hợp với OpenAI API và Azure OpenAI Service

Chuyển yêu cầu ngôn ngữ tự nhiên thành dữ liệu mà ứng dụng có thể xử lý

  • Các mô hình ngôn ngữ lớn mới nhất có thể được gắn vào trợ lý trò chuyện một cách dễ dàng, nhưng việc tích hợp ngôn ngữ tự nhiên một cách ổn định vào giao diện của ứng dụng hiện có lại là một bài toán riêng
  • TypeChat tập trung vào việc biến yêu cầu của người dùng thành dạng mà ứng dụng có thể xử lý, đồng thời giúp thực hiện các tác vụ mà cả nhà phát triển lẫn người dùng đều có thể tin cậy
  • Thư viện được công bố sử dụng định nghĩa kiểu trong codebase để lấy phản hồi AI có cấu trúc và hướng tới tính an toàn kiểu
  • Có thể cài đặt bằng lệnh sau
npm install typechat

Dùng JSON và kiểu thay cho parse ngôn ngữ tự nhiên

  • Về bản chất, LLM được tối ưu cho hội thoại bằng ngôn ngữ tự nhiên như tiếng Anh, nên ngay cả khi đưa các quy tắc như “hãy trả lời bằng danh sách bullet” vào prompt thì phần mềm thông thường vẫn khó parse một cách ổn định
  • Nếu yêu cầu trả lời bằng JSON, nhìn chung có thể tạo ra phản hồi ở dạng mà ứng dụng dễ xử lý hơn
    • Trong ví dụ, yêu cầu 1 “blueberry muffin” và 1 “grande latte” được chuyển thành JSON có mảng items
  • Những ví dụ đơn giản tuy giúp dẫn dắt cấu trúc, nhưng không định nghĩa đủ rõ AI phải trả về gì và cũng không cung cấp tiêu chí kiểm chứng

Dùng kiểu TypeScript làm schema phản hồi

  • TypeChat đưa kiểu TypeScript vào prompt để hướng dẫn cấu trúc JSON mà LLM phải trả về
  • Trong schema ví dụ, kiểu Response chứa items: Item[], còn Item có các trường name, quantity, cùng size, notes là tùy chọn
  • TypeScript phù hợp để mô tả JSON một cách chính xác, và vì LLM đã tiếp xúc với rất nhiều định nghĩa kiểu nên nó hữu ích trong việc hướng dẫn định dạng phản hồi
  • Nếu phản hồi không khớp với kiểu, trình biên dịch TypeScript sẽ kiểm chứng dựa trên định nghĩa kiểu là mã TypeScript hợp lệ
  • Phản hồi lỗi từ trình biên dịch được dùng để dẫn dắt việc sửa phản hồi, giúp quy trình nhận được phản hồi đúng kiểu trở nên vững chắc hơn

Cách dùng TypeChat và ví dụ

  • TypeChat có thể được dùng theo cách tiếp cận schema dữ liệu để biến ý định của người dùng thành phản hồi có cấu trúc
  • Mã ví dụ định nghĩa interface SentimentResponse để phân loại cảm xúc của câu người dùng nhập thành một trong negative, neutral, positive
  • Tạo mô hình ngôn ngữ dựa trên biến môi trường bằng createLanguageModel(process.env), đọc file schema, rồi tạo bộ chuyển đổi bằng createJsonTranslator<SentimentResponse>
  • Nếu translator.translate(request) thành công thì in ra response.data.sentiment, nếu thất bại thì in thông báo lỗi
  • Ngoài schema dữ liệu, cũng có thể dùng schema API để xây dựng các chương trình cơ bản
  • Có thể xem cách sử dụng tại docs và examples

Mã nguồn mở và tính trung lập với mô hình

  • TypeChat là mã nguồn mở theo giấy phép MIT và được công khai trên GitHub
  • Để thuận tiện, nó cung cấp tích hợp mặc định cho OpenAI API và Azure OpenAI Service
  • Mục tiêu thiết kế là trung lập với mô hình, hướng tới cách tiếp cận có thể dùng với mọi API kiểu chat completion
  • Hiện tại, TypeChat hoạt động tốt nhất với các mô hình được huấn luyện trên cả văn xuôi và mã nguồn
  • Gói này đã có trên npm nên có thể thử ngay

Bài viết liên quan

2 bình luận

 
sungwoo 2023-07-26

Haha, vừa đọc tin xong định đăng lên thì đúng là không thể theo kịp AI.
 
GN⁺ 2023-07-21
Ý kiến trên Hacker News

  • Tôi không rõ giá trị gia tăng ở đây là gì
    Thông điệp cốt lõi gửi tới LLM nằm ở đây: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    Rốt cuộc, trông như chỉ là yêu cầu trả về dữ liệu có cấu trúc bằng một prompt cố định, rồi phủ thêm một chút tự động hóa và khóa chân vào nhà cung cấp. Phần lớn các thư viện LLM kiểu này gần như chỉ là API vụng về bọc quanh API cấp thấp hơn; một script làm cùng việc có thể được tạo rất dễ, và còn linh hoạt hơn khi mô hình và nhu cầu người dùng thay đổi
    Ví dụ, nếu muốn đổi prompt hoặc dùng class Python, khối lượng công việc giữa thư viện kiểu này và cách đẩy lời gọi API/mẫu văn bản lên cho người dùng (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...) là rất khác nhau

    • Giá trị nằm ở đây: 1) chạy bộ kiểm tra kiểu TypeScript trên kết quả LLM trả về, 2) nếu có lỗi kiểu, gom chúng lại thành “prompt sửa lỗi” để dẫn dắt đầu ra có khả năng cao vượt qua kiểm tra kiểu, 3) xử lý gọn gàng cả trường hợp heuristic ở mục 2 thất bại
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      Theo kinh nghiệm từng thử nghiệm ý tưởng tương tự, heuristic ở mục 2 hoạt động tốt đến đáng ngạc nhiên với các kiểu tương đối đơn giản, tức là record và mảng không lồng quá sâu, cùng việc dùng biến kiểu ở mức hạn chế. Chỉ cần prompt LLM trả về giá trị thuộc một kiểu tương đối đơn giản cũng đã có thể tạo ra ứng dụng hữu ích; thư viện này có giá trị ở chỗ giảm nhu cầu phải tự triển khai mẫu yêu cầu đó và cung cấp tích hợp chuẩn với codebase TypeScript
    • Gần như tất cả thư viện LLM tôi thấy gần đây đều kiểu này. Cuối cùng vẫn quy về việc yêu cầu LLM làm một việc nào đó theo một cách cụ thể, và tôi đã thấy trong các điều kiện phức tạp thì nó ít tuân theo chỉ dẫn hơn và quay về hành vi mặc định
      Dù vậy, có vẻ dùng thư viện vẫn là hướng đúng, nên tôi đang tiếp tục theo dõi xem cách tiếp cận nào sẽ đủ trưởng thành
    • Tôi không hiểu khóa chân vào nhà cung cấp nằm ở đâu. Đây là thư viện nguồn mở, và trong file được liên kết cũng có cấu hình cho hai nhà cung cấp là ChatGPT và Bard
    • Giá trị nằm ở việc biến dữ liệu phi cấu trúc thành dữ liệu có cấu trúc, và bảo đảm nó thỏa các ràng buộc schema
      Ví dụ, nếu có 1000 phản hồi khảo sát dạng văn bản tự do về một sản phẩm, bạn có thể tạo schema rồi chạy TypeChat cho từng phản hồi để thu được một dataset cho phần văn bản tự do đó. Cực kỳ hữu ích
    • Trừu tượng hóa càng tốt thì càng dễ code ra thứ hữu ích

  • Có một điểm tôi không hiểu
    Tôi không rõ vì sao phải đi qua một quy trình phức tạp: hy vọng nhận được phản hồi hợp lệ, gắn bộ kiểm chứng ở bước cuối để phát hiện phản hồi sai, rồi cầu xin mô hình trả lời theo cú pháp mình muốn
    Nếu chỉ sampling các token phù hợp với định dạng được yêu cầu thì có thể bảo đảm cú pháp JSON hợp lệ. Thay vì lần nào cũng tham lam chọn token có điểm cao nhất, hãy chọn token có điểm cao nhất trong số các token phù hợp với định dạng yêu cầu
    Guidance của Microsoft đã làm như vậy: https://github.com/microsoft/guidance
    Nhưng OpenAI dường như không công khai toàn bộ điểm của mọi token mà chỉ công khai token có điểm cao nhất. Nếu chạy mô hình cục bộ thì dùng Guidance rất đơn giản, có thể bảo đảm JSON luôn đúng và tốc độ sinh cũng nhanh hơn, nên thấy lạ

    • Giống câu chuyện M&M màu nâu[0]. Nếu mô hình trả về dữ liệu đúng về mặt ngữ nghĩa, thì ít nhất có thể kỳ vọng nó đúng cú pháp. Nếu không làm được điều đó thì dù sao cũng phải bỏ phản hồi đi
      Ngoài ra, tôi nghĩ cách đó khó bao quát toàn bộ độ phức tạp của kiểu TypeScript
      [0] https://www.snopes.com/fact-check/brown-out/
    • Bằng cách đó có thể bảo đảm JSON đúng về mặt cú pháp, nhưng đúng về mặt ngữ nghĩa hay không lại là chuyện khác
      Nếu mô hình thật sự muốn đặt token khác nhưng bị ép đặt {, chất lượng văn bản sinh ra sau đó cũng có thể giảm. Tôi không chắc, chỉ là nghĩ vậy thôi
    • Tôi thấy cách chỉ sampling token hợp lệ rất hứa hẹn
      Tôi từng fine-tune một LLM nguồn mở để phân tích JSON, và tùy mục đích sử dụng thì 70B tham số có thể là quá mức, ngay cả khi không có guided token sampling. Tôi đã thấy kết quả khá tốt trên các mô hình nhỏ hơn nhiều, và sẽ rất thú vị nếu kết hợp fine-tune mô hình nhỏ với guided token sampling
      Tuy nhiên, với ứng dụng rất tổng quát thì fine-tune có thể không hoàn hảo. Sẽ rắc rối nếu gặp đầu vào không được dự đoán trong dataset huấn luyện
    • LLM có thể xử lý các kịch bản phức tạp hơn. Ví dụ, ở máy bán hàng tự động, nếu không đi qua toàn bộ quy trình đặt hàng mà chỉ nói đơn hàng, nó có thể suy đoán những cụm như “vài thanh sô-cô-la” rồi khớp với tồn kho
      Tất nhiên trên web thì không hợp lý. Dùng chuột bấm vài món hàng dễ hơn nhiều
    • Như Llama.cpp gần đây đã mô tả, họ đã thêm sampling dựa trên ngữ pháp để ràng buộc việc chọn token theo một định dạng cố định
      https://github.com/ggerganov/llama.cpp/pull/1773

  • Cứ như hễ tôi nghĩ ra điều gì đó là Anders Hejlsberg lại làm ra nó vậy
    Yêu cầu và phản hồi có cấu trúc chắc chắn 100% là bước tiến hóa tiếp theo của LLM. Mọi người đã bắt đầu chán chatbot rồi, và nếu có thể cắm bất kỳ backend nào vào mà không phải lo phân tích cú pháp văn bản hay prompt thì sẽ rất tuyệt

    • Tôi muốn gắn vào một LLM chạy cục bộ các giao diện có thể hành động mà tôi cung cấp. Đại loại như “kiểm tra giờ”, “kiểm tra lịch”, “gửi tin nhắn cho người dùng”
      TypeChat có vẻ đang đi đúng hướng. Có thể hình dung thêm một tầng kiểu “hãy khớp input JSON này với một trong các hành động khả dĩ, nếu có thể”
      Tôi thấy một tương lai hybrid gọn gàng, nơi bot, tức LLM và những thứ tương tự, nối các tầng mã thực tế lại với nhau. Lúc thì trở thành một phần của việc thu thập/gắn thẻ, lúc thì là một phần phản hồi input
      Nhìn chung đây là một lĩnh vực rất thú vị, nhưng mọi thứ chuyển động quá nhanh nên tôi vẫn chưa đào sâu. Nhiều người thông minh đang làm về nó, nên tôi cảm thấy cần đợi bụi lắng xuống một chút. Dù vậy, có vẻ giao diện gia đình mà tôi từng mơ tới đã đến mức có thể xây dựng được rồi
    • Hôm qua tôi vừa triển khai một thứ tương tự, nhưng tập trung vào hướng lấy hàm làm trung tâm hơn là đối tượng
    • Nếu dùng làm mapper động ở tầng backend thì có thể cực kỳ mạnh
      Ví dụ hãy thử theo kịp các payload API thường xuyên thay đổi quanh một Java consumer. Trong môi trường ngân hàng, các payload JSON khổng lồ và backend Java, chúng tôi đã tạo hẳn một tầng NodeJS riêng để giữ cho đầu óc còn tỉnh táo
      Mapping là lĩnh vực LLM có thể tỏa sáng
    • Đáng xem: https://news.ycombinator.com/item?id=36750083

  • Nói một cách hơi cực đoan, chúng ta đang dần bước vào giai đoạn công cụ hóa của AI. Mọi người nhận ra rằng ở đây không có mấy giá trị thực được tạo ra, nhưng vì đã đầu tư quá nhiều vào AI nên tiền vẫn tiếp tục được đổ vào. Đây cũng là chủ đề tốt để viết bài học thuật, còn LangChain thì gần như một trò đùa mà vẫn gọi được 10 triệu đô la vòng seed
    DeFi/crypto đã trải qua giai đoạn này 2 năm trước. Sau vài năm ở trạng thái lấp lửng kỳ quặc, mọi người sẽ dần nhận ra rằng AI không phải là sản phẩm mà là tính năng, phạm vi áp dụng có hạn và nó sẽ không cứu thế giới. Vì mọi edge case nên không thể làm xe tự lái, và vì có thể giết người nên cũng không thể làm phẫu thuật
    Tôi vẫn luôn nói rằng ngay cả những công cụ AI hữu ích nhất như Copilot cùng lắm cũng chỉ hữu ích ở rìa. Trong trường hợp tốt nhất, nó chỉ giảm vài cú nhấp trên Google, còn agent thì hoàn toàn không “thông minh”. Vài năm trước chúng ta đã trải qua một bong bóng tương tự với chatbot[1], và giờ chẳng ai quan tâm nữa. “Metaverse” kết thúc còn nhanh hơn nhiều, nhưng cùng một tâm lý đám đông đã vận hành. Từ “xu hướng lớn tiếp theo” rồi thành không phải vậy
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • Tôi phản đối mạnh mẽ ý kiến rằng AI chỉ là một bong bóng với phạm vi áp dụng hạn chế
      Bạn đang chọn đúng những ca ứng dụng khó nhất của AI như xe tự lái và phẫu thuật. Công việc của đại đa số mọi người không phải chuyện sống còn, nên rất phù hợp để tự động hóa. Ngay cả khi yếu tố con người vẫn còn trong các nghề liên quan đến sinh tử, rất có khả năng chúng sẽ được bổ trợ bằng AI agent. Ví dụ phẫu thuật vẫn do con người thực hiện, nhưng việc bác sĩ hoặc y tá chẩn đoán cùng AI có thể trở thành bắt buộc
      Bạn thật sự đang so sánh hiện tại với bong bóng chatbot vài năm trước sao? ChatGPT đạt 100 triệu người dùng chỉ trong vài tháng, và rất nhiều người đã dùng thử. Bong bóng chatbot vài năm trước gần như chẳng có sự hiện diện đáng kể
      Việc Copilot và những thứ tương tự chỉ hữu ích ở rìa là vì bạn đang nhìn vào phiên bản tệ nhất hiện nay. ChatGPT đã thay đổi cuộc sống của tôi, và nó còn chưa chạy code. Code Interpreter thì có, nhưng tôi chưa thử
      Đến khoảng năm 2030, con người có lẽ sẽ không còn gõ code nữa, mà sẽ đưa prompt cho máy và chỉ huy các AI agent. Đến lúc đó, phần lớn công việc cũng có khả năng đã được tự động hóa
      AI không chỉ là một trào lưu; nó sẽ thay đổi mọi ngành công nghiệp, và nhanh hơn rất nhiều so với mọi người nghĩ. Sự hoài nghi đem AI so với metaverse rồi hạ thấp hàm ý của AI là vô lý và thiếu trí tưởng tượng. Đặc biệt là phía AI agent vẫn còn nhiều việc phải làm, nhưng có lẽ chúng ta sẽ tới đó nhanh hơn rất nhiều so với mọi người nghĩ, và tác động sẽ khổng lồ
    • Mỗi lần dùng ChatGPT, tôi có cảm giác mình đang thấy một công nghệ khác với thứ người khác nhìn thấy. Người ta nói nó trả lời mọi câu hỏi và dạy được bất cứ điều gì, nhưng thực tế nó giống một dịch vụ content farm hơn. Copilot cũng tương tự; đa phần tự viết code còn dễ hơn là tìm cái đỡ tệ nhất trong những ví dụ tệ rồi sửa bug
      Tuy nhiên, AlphaGo đã không mất nhiều thời gian để đi từ trạng thái “ảo giác” ra các nước đi tệ đến chỗ trở thành kỳ thủ mạnh nhất thế giới. Nếu điều này cũng có thể xảy ra với mô hình ngôn ngữ, GPT-x có thể thổi bay toàn bộ cuộc tranh luận hiện tại
    • Tôi phản đối mạnh mẽ câu “không tạo ra giá trị thực”. Trong các use case của tôi có phản ví dụ rất rõ ràng
      GPT-4 cực kỳ hữu ích khi một người có kinh nghiệm làm các tác vụ lân cận, nơi kỹ năng của họ nhìn chung vẫn áp dụng được nhưng kiến thức domain còn yếu
      Tôi đã viết code 10 năm và gần đây mới bắt đầu học machine learning lần đầu, tôi dùng GPT-4 hằng ngày và rất hài lòng
      Tất nhiên đôi khi những chỗ thô ráp có thể gây khó chịu. Với tôi thì ở mức kiểm soát được và không quá phiền. Tôi đã quen với việc bỏ qua hoặc đi vòng, và rõ ràng có kỹ năng riêng trong việc dùng những công cụ như thế này
      Tôi cho rằng giá trị được cung cấp sẽ tiếp tục tăng. Chúng ta thậm chí còn chưa hái hết những quả thấp và quả ở tầm trung
    • Khác biệt cốt lõi với DeFi/crypto là, dù bên đó có ấn tượng đến đâu về mặt kỹ thuật, mọi người vẫn phải thay đổi hoàn toàn những gì họ đang làm để có được lợi ích đầu tiên
      AI hiện đại, thực ra thường là LLM, có thể áp dụng rộng rãi gần như ngay lập tức vào hầu hết mọi lĩnh vực kinh tế. Vì vậy rất nhiều người đã và đang xây dựng, phát hành tính năng. Công nghệ này có giá trị khổng lồ. Nó có thay đổi hoàn toàn thế giới không? Không, nhưng đủ để tạo ra các nhóm sản phẩm mới và cải thiện căn bản một phần lớn năng lực của các sản phẩm hiện có
    • Tôi thấy đây là một cách diễn giải khá hợp lý. AI có nhiều công dụng và thật sự rất tốt cho một số việc, nhưng không phải là giải pháp vạn năng như mọi người kỳ vọng

  • Không rõ vì sao trong số các trợ lý giọng nói của Apple, Google, Amazon, Microsoft vẫn chưa có cái nào tích hợp LLM vào dịch vụ, và vì sao OpenAI chưa tung ra trợ lý giọng nói của riêng mình.
    Ngoài ra, nếu giống như RSS, các website phơi bày một URL tiêu chuẩn dành cho tương tác AI và công khai giao diện bằng TypeChat, thì có vẻ mọi thứ có thể tiến khá xa theo hướng này.

    • Khả năng cao OpenAI sẽ tự làm trợ lý riêng. Nhìn câu “Building a kind of JARVIS @ OреոΑӏ” của Karpathy thì thấy vậy, và Microsoft chắc chắn cũng đang làm việc để tích hợp hoặc diễn giải lại Cortana bằng LLM của OpenAI.
      Tuy nhiên, giá trị của khả năng thực sự thực hiện hành động lớn hơn nhiều so với LLM dựa trên giọng nói. Lấy Alexa làm ví dụ, cần một hệ thống xử lý điều khiển nhà thông minh theo cách có thể dự đoán và debug được. Nếu không, người dùng sẽ bực mình.
      Rõ ràng tôi nghĩ điều đó là khả thi, nhưng các hệ thống hiện tại như Alexa hay Siri, hoặc Cortana ít được dùng hơn, đang dùng các quy tắc và phần mềm được xây dựng trong nhiều năm trên các mô hình kém mạnh hơn, với nhiều hook và API. Để làm cho nó hoạt động, vừa phải cải thiện trong khi duy trì chất lượng hiện tại, vừa phải thay thế các phần chính của hệ thống, nên sẽ mất thời gian.
      Hơn nữa, những trợ lý này thực ra không kiếm được tiền và nhìn chung là lỗ. Chúng chỉ có giá trị với các tập đoàn lớn có thể kiếm tiền bằng cách khác như điện thoại, mua sắm, hoặc thúc đẩy mảng kinh doanh của họ, nên startup ít có động lực làm.
      Trước đây tôi từng làm ở cả Cortana lẫn Alexa, và cũng đã suy nghĩ nhiều về việc xây dựng phiên bản mới từ đầu dựa trên sự tiến bộ của LLM. Về tổng thể, công nghệ khá trực quan và cũng có những ý tưởng use case mới giờ mới khả thi, nhưng tôi không tìm được mô hình kinh doanh nào hoạt động được. Vì vậy hiện giờ tôi đang làm việc hoàn toàn khác.
    • Khi lần đầu biết ChatGPT là gì, suy nghĩ của tôi là “À, ra Siri lẽ ra phải như thế này mới đúng”.
    • Sau khi dùng ChatGPT và Bing, nói chuyện với Alexa trở nên buồn cười đến mức khó tin. Thật sự rất bực khi thấy phần cứng tốt bị phần mềm tệ kéo chân suốt nhiều năm.
    • Microsoft đang làm việc đó để thay thế Cortana trong Windows 11.
    • Tôi thực sự mong có thứ gì đó có thể dùng để điều khiển Home Assistant.
      Nhưng dùng API dựa trên cloud cho việc này thì quá bất an, nên tôi muốn nó chạy trên server trong nhà. Đồng thời nhận dạng giọng nói và thời gian phản hồi phải rất nhanh, đến mức hoàn toàn không có cảm giác phải chờ.
      Tôi đã thấy vài nỗ lực DIY trợ lý cá nhân, nhưng luôn có độ trễ khá lớn, nên nếu dùng thường xuyên chắc sẽ nhanh chóng gây khó chịu.

  • Có đoạn nói rằng dễ nhận được phản hồi kiểu { "name": "grande latte" }.
    Nhưng nếu kiểu là Item = { name: string; ... size?: string; } thì tôi không hiểu nó giúp tránh name: "grande latte" như thế nào.
    Phản hồi ví dụ có "size": 16 và được nói là “khá tuyệt”, nhưng thực tế nó thậm chí còn không trả về đúng kiểu đã yêu cầu. Có lẽ là lỗi đánh máy trong ví dụ, và nếu vậy thì bản thân ý tưởng có vẻ hay.

    • Cảm ơn đã chỉ ra. Trong một phiên bản trước của bài blog, chúng tôi dùng một schema khác trong đó size bị đặt nhầm là number. Schema đã được đổi nhưng prompt chưa được chạy lại, và giờ chắc đã được sửa.
    • Tôi thấy ví dụ này nhìn chung khá yếu. Vấn đề không chỉ là lỗi đánh máy đơn giản.
      Ngay từ đầu có lẽ bạn không muốn một trường chuỗi name. Không có gì ngăn việc nhận các giá trị như { name: “the brown one”, size: “the espresso cup”, … }, và như vậy cũng tệ chẳng kém việc parse chuỗi ban đầu.
      Có lẽ thứ bạn muốn là một kiểu union chuỗi lớn biểu diễn các giá trị đã biết cho từng trường. Khi đó có thể buộc LLM chọn trong số đó.
      Nhưng tôi cũng thắc mắc vì sao phải gắn nó vào cú pháp kiểu. Những thứ như Zod, có thể dùng dữ liệu runtime để xây dựng các kiểu union như vậy, có vẻ phù hợp hơn.
      Cũng cần các ràng buộc kiểu như số lượng phải là số nguyên dương và không được là phân số. Dĩ nhiên có thể kiểm tra JSON sau đó, nhưng khi ấy người dùng sẽ thấy hai loại lỗi. Một là lỗi do LLM đưa ra bằng giọng văn con người trôi chảy, và loại kia là lỗi kỹ thuật kỳ quặc kiểu “giá trị số lượng quá lớn”.
      Cú pháp kiểu có vẻ là chỗ không đúng để diễn đạt những nội dung như vậy.
    • Có vẻ chỉ là lỗi tài liệu. Có lẽ vào giai đoạn cuối khi viết bài công bố, họ đã đổi từ số ounce sang kích cỡ tiêu chuẩn nhưng quên đổi giá trị đầu ra cho khớp.
      Chỉ với đoạn code được cung cấp thì hệ thống không có cách nào ánh xạ “grande” thành 16, và 16 cũng có vẻ không được dùng ở chỗ nào khác.
    • Đoạn tiếp theo nói về “điều gì xảy ra nếu bỏ qua kiểu”, nên có lẽ họ viết với ý đó.

  • Trông giống cách chạy LLM lặp lại cho đến khi nó nhả ra thứ vượt qua kiểm tra kiểu, rồi đưa lại prompt kèm thông báo lỗi.
    Ý tưởng dễ thương và có vẻ sẽ hoạt động, nhưng với mô hình lớn và prompt đầu vào dài thì chi phí có thể lớn. Có lẽ không phải lời giải cho mọi kịch bản.

    • Ít nhất với OpenAI, chẳng phải dùng tính năng gọi hàm mới ở bên trong sẽ tốt hơn sao?
    • Tôi không rõ TypeChat hoạt động thế nào, nhưng Guidance [1] cũng là một dự án tương tự và thực sự có thể tích hợp vào sampling token để cưỡng chế định dạng.
      [1]: https://github.com/microsoft/guidance
    • Tôi nghĩ phần lớn sản phẩm trước hết sẽ lo về độ phù hợp sản phẩm-thị trường, rồi sau đó mới cố giảm chi phí.
      Cũng có một giả định khá hợp lý rằng vì thị trường đang đòi hỏi đầu ra có cấu trúc, các mô hình cũng sẽ được cải thiện theo hướng đó.

  • Tuần này tôi đã làm và công bố một thứ rất giống thế này cho Laravel PHP, nhưng phạm vi nhỏ hơn nhiều: https://github.com/adrenallen/ai-agents-laravel
    Tôi nghĩ kỹ sư nên có thể dễ dàng khởi chạy một “bot” mới với LLM được chỉ định. Có rất nhiều việc tẻ nhạt như chuyển hàm sang dạng mà ChatGPT có thể hiểu, rồi xử lý phản hồi và phân tích cú pháp lại
    Dùng hệ thống kiểu này thì bạn có thể tập trung vào việc viết mã PHP thật và thêm vài chú thích rõ ràng; khi đó bot có thể dùng ngay đoạn mã đó như một công cụ cho bất kỳ tác vụ nào
    Cách này cũng giúp việc chia sẻ mã dễ hơn nhiều. Ai đó viết một hàm, bạn đưa vào bot mới là dùng được ngay. Điểm hay là nó loại bỏ “lớp chuyển đổi để LLM sử dụng và hiểu”, và tăng tốc độ xây dựng lên rất nhiều
    Vẫn chưa hoàn hảo, nhưng tôi nghĩ cuối cùng mọi thứ sẽ đi theo hướng này nếu muốn tận dụng mã của nhau tốt hơn. Nghĩ đến cách chúng ta dùng trình quản lý gói trong lập trình ngày nay, tôi muốn có một trình quản lý gói dành cho các công cụ chuyên cho AI. Kiểu như cài thư viện “lấy thời tiết”, thêm vào bot của tôi, và từ đó nó có thể lấy thời tiết

    • Tôi đã đánh dấu sao vì đang làm một cách tiếp cận tương tự nhưng phạm vi rộng hơn một chút. Một vài ý tưởng thật sự rất gọn gàng

  • Khoan đã, đây là xác thực runtime đối tượng dựa trên định nghĩa kiểu TypeScript à? Nếu có thể phát hành thành thư viện hoặc tính năng độc lập, nó có thể thay đổi hoàn toàn cuộc chơi trong các codebase TypeScript, chẳng hạn để xác thực payload phản hồi API

  • Rất ngạc nhiên là ở đây không dùng guidance [0]
    Nó có thể gợi ý hoàn thiện các trường bắt buộc, từ đó giảm nhu cầu xác thực[1], và cuối cùng có lẽ còn tiết kiệm được thời gian GPU
    Chắc hẳn phải có lý do, và tôi thật sự muốn biết
    Nói thêm, tôi đang làm đúng thứ kiểu này thì Microsoft bất ngờ nhảy vào và ăn mất bữa trưa của tôi
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...