Những bài học rút ra sau khi xử lý 500 triệu token GPT

 (kenkantzer.com)
4 điểm bởi GN⁺ 2024-04-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong 6 tháng gần đây, Truss đã vận hành các tính năng lấy LLM làm trung tâm và xử lý hơn 500 triệu token bằng các mô hình OpenAI, từ đó tổng hợp những giới hạn thực tế gặp phải trong các tác vụ tóm tắt, phân tích và trích xuất văn bản B2B
  • Prompt không hề ổn định hơn khi nhồi quá nhiều chỉ dẫn chi tiết, và với những kiến thức thường thức mà GPT vốn đã biết, chỉ dẫn ngắn hơn, ít cụ thể hơn đôi khi lại cho kết quả tốt hơn
  • Ngay cả khi không dùng Langchain, JSON mode, function calling hay assistants, họ vẫn vận hành được nhiều tính năng chỉ với API chat và một hàm trích xuất JSON; phần mã cốt lõi chỉ là một hàm 40 dòng cùng xử lý lỗi và tự động cắt bớt đầu vào
  • GPT yếu trong việc xử lý giả thuyết không (null hypothesis) như “nếu không có thì trả về giá trị rỗng”, đồng thời cũng yếu với đầu ra dài; tách biệt với cửa sổ đầu vào 128k của GPT-4, đầu ra vẫn chỉ quanh mức 4k
  • RAG và vector DB không phù hợp lắm với các tác vụ trích xuất văn bản có phạm vi hẹp của Truss; phân tích, tóm tắt, trích xuất khi đưa vào toàn bộ ngữ cảnh thì đáng tin cậy, nhưng vấn đề sẽ lớn hơn khi đầu vào trống hoặc không có thông tin liên quan

Phạm vi sử dụng và các giả định

  • Trong 6 tháng qua, Truss đã ra mắt một vài tính năng lấy LLM làm trung tâm, với tổng mức sử dụng ước tính nhỉnh hơn 500 triệu token
  • Các mô hình được dùng thuộc họ OpenAI, và tỷ lệ sử dụng token là GPT-4 85%, GPT-3.5 15%
  • Dữ liệu được xử lý chỉ là văn bản; không bao gồm các tính năng phi văn bản như gpt-4-vision, Sora hay Whisper
  • Bối cảnh sản phẩm là B2B, và các tác vụ chính là tóm tắt, phân tích, trích xuất
  • 500 triệu token tương đương khoảng 750.000 trang văn bản

Prompt có thể tốt hơn khi bớt cụ thể

  • Với những kiến thức phổ quát mà GPT đã biết, nếu nhét vào quá nhiều danh sách và chỉ dẫn chính xác thì kết quả đôi khi lại tệ hơn
  • Một pipeline phải phân loại xem mỗi khối văn bản liên quan đến bang nào trong 50 bang của Mỹ hoặc chính phủ liên bang
    • Prompt ban đầu đưa danh sách ID của 50 bang và federal vào trường locality_id dưới dạng JSON rồi yêu cầu chọn
    • Cách này hoạt động khoảng trên 98%, nhưng số lần thất bại vẫn đủ nhiều để phải điều tra thêm
  • Một trường khác là name thì dù không yêu cầu rõ ràng, mô hình vẫn trả về ổn định tên đầy đủ chính xác của bang
    • Sau đó họ đổi sang cách tìm bang bằng cách tra cứu chuỗi xuất hiện trong name, và nó hoạt động tốt
  • Cách tiếp cận tốt hơn là dùng một prompt kiểu giao cho thường thức, như “bạn biết 50 bang, hãy trả về tên đầy đủ của bang tương ứng hoặc Federal”
  • Cũng có vài quan sát phụ
    • Lỗi xảy ra thường xuyên hơn với các bang bắt đầu bằng chữ M như Maryland, Maine, Massachusetts, Michigan
    • Khi bắt mô hình chọn ID từ danh sách, một JSON dễ nhìn với mỗi bang trên một dòng ít gây nhầm lẫn hơn danh sách nối bằng dấu phẩy

API và lớp trừu tượng vẫn được giữ đơn giản

  • Trong trường hợp này, Langchain gần như là một lớp trừu tượng hóa quá sớm, và ngay cả sau hàng triệu token cùng 3–4 tính năng production khác nhau, file openai_service vẫn chỉ còn một hàm dài 40 dòng
  • API thực sự được dùng chỉ là chat
    • Luôn trích xuất JSON
    • Không cần JSON mode, function calling hay assistants
    • Cũng không dùng system prompt
    • Khi gpt-4-turbo ra mắt, họ chỉ thay đúng một chuỗi trong codebase
  • Phần lớn các hàm còn lại lo xử lý lỗi như lỗi 500 từ OpenAI hay việc socket bị đóng
    • Các lỗi này đã được cải thiện, và xét đến tải của OpenAI thì điều đó cũng không có gì đáng ngạc nhiên
  • Giới hạn độ dài ngữ cảnh được xử lý bằng cơ chế tự cắt bớt
    • Nếu độ dài chuỗi lớn hơn model_context_size * 3 thì sẽ cắt
    • Khi có rất nhiều dấu chấm hoặc chữ số, tỷ lệ token có thể thấp hơn 1 token cho 3 ký tự nên cách này có thể thất bại
    • Nếu gặp context_length_exceeded, họ sẽ cắt lại theo ngưỡng model_context_size * 3 / 1.3 rồi thử lại

UX streaming khó mà đánh giá thấp

  • Ban đầu, việc dùng API streaming để giảm độ trễ và hiển thị cho người dùng các ký tự xuất hiện với tốc độ thay đổi trông giống một trò tiểu xảo
  • Nhưng người dùng thực tế lại phản hồi rất tích cực với hiệu ứng “gõ chữ” ở tốc độ biến thiên đó
  • Trải nghiệm này giống như một khoảnh khắc kiểu UX chuột/con trỏ trong thế giới AI

Kết quả rỗng và đầu ra dài là điểm yếu

  • “Nếu không tìm thấy thì trả về đầu ra rỗng” gần như là kiểu câu trong prompt gây lỗi nhiều nhất
    • Ý ở đây không phải là hoàn toàn không in gì ra, mà là trả về dạng biểu diễn giá trị rỗng như {value: ""}
    • Vấn đề không hẳn là vượt giới hạn đầu ra, mà gần hơn với việc mô hình gặp khó trong đánh giá giả thuyết không
  • Khi cần trả về giá trị rỗng, GPT đôi khi chọn bịa ra; ngược lại, đôi lúc do thiếu tự tin nó lại trả về giá trị rỗng quá thường xuyên
  • Khi có một lỗi khiến khối văn bản đầu vào có thể bị trống, hiện tượng bịa đặt xảy ra rất nặng
    • Ví dụ xuất hiện các tên tiệm bánh giả như Sunshine Bakery, Golden Grain Bakery, Bliss Bakery
    • Cách xử lý là nếu không có văn bản thì đừng gửi prompt đi ngay từ đầu
  • GPT-4 có thể có cửa sổ đầu vào 128k token, nhưng cửa sổ đầu ra vẫn chỉ quanh mức 4k
    • Cách gọi “context window” dễ khiến người ta nhầm giữa đầu vào và đầu ra
  • Khi yêu cầu trả về danh sách đối tượng JSON, ngay cả với đối tượng đơn giản cũng khó vượt quá 10 mục
    • Nếu yêu cầu 15 mục thì ước tính chỉ thành công khoảng 15%
    • Ngay cả khi dừng ở mức 10 mục, đầu ra cũng chỉ khoảng 700–800 token
  • Có thể lách giới hạn đầu ra bằng cách yêu cầu từng mục một rồi đưa kết quả trước đó trở lại vào prompt, nhưng như vậy sẽ thành kiểu chơi trò truyền tin với GPT và phải đụng đến các công cụ như Langchain

RAG và vector DB không hợp với ca sử dụng này

  • Trong trường hợp của Truss, vector DB và RAG/embedding phần lớn là không mấy hữu ích
  • Họ cho rằng vector DB và RAG hợp với bài toán search hơn, đặc biệt là search thực thụ như Google hay Bing
  • Vấn đề cốt lõi là tiêu chí về độ liên quan
    • Không có ngưỡng cắt rõ ràng cho mức độ liên quan
    • Có thể dùng các cách như rerank của Cohere hoặc heuristic tự xây, nhưng không ổn định
    • Kết quả tìm kiếm có thể bị nhiễm bởi kết quả không liên quan, hoặc ngược lại quá bảo thủ đến mức bỏ lỡ kết quả quan trọng
  • Việc lưu vector trong một DB chuyên biệt, tách khỏi dữ liệu thông thường, cũng gây tổn thất đáng kể
    • Nếu không ở quy mô Google hay Bing, họ cho rằng mất mát ngữ cảnh này không đủ đáng để đánh đổi
  • Trong các ứng dụng doanh nghiệp, người dùng search thường là chuyên gia trong miền đó
    • Họ cho rằng người dùng không thích semantic search kiểu đoán cả những ý nghĩa mà chính họ không hề gõ vào
  • Với đa số trường hợp search, có thể tốt hơn nếu dùng LLM như một completion prompt thông thường để chuyển truy vấn của người dùng thành faceted search, truy vấn phức tạp hoặc SQL
    • Cách này không phải RAG

Ảo giác giảm mạnh khi ngữ cảnh đủ đầy

  • Đa số ca sử dụng của Truss là kiểu “đưa một khối văn bản vào rồi trích xuất thứ gì đó từ đó”
  • Nếu yêu cầu tên công ty được nhắc tới trong văn bản, GPT thường không tự dưng trả về công ty ngẫu nhiên
    • Tuy vậy, khi văn bản không có công ty nào thì vấn đề giả thuyết không lại xuất hiện
  • Trong code cũng vậy, khi GPT viết lại khối mã đã được đưa vào, nó hiếm khi bịa ra biến hay tự ý chèn lỗi chính tả giữa chừng theo nghĩa ảo giác
    • Nhưng nếu yêu cầu nó tạo ra thứ gì đó mới, nó có thể bịa cả sự tồn tại của hàm trong standard library
    • Điều này cũng gần với vấn đề không biết cách nói “tôi không biết”
  • Với các tác vụ cung cấp toàn bộ ngữ cảnh để phân tích, tóm tắt, trích xuất, họ thấy mô hình rất đáng tin cậy
  • Nó gần với một cấu trúc kiểu “đưa dữ liệu tốt vào thì nhận lại phản hồi token GPT tốt”

Nhận định về triển vọng sắp tới

  • Họ cho rằng chỉ với transformer hiện tại, dữ liệu Internet và hạ tầng trị giá hàng chục tỷ USD thì vẫn chưa thể đạt AGI
  • GPT-4 không phải chiêu tiếp thị mà là một công nghệ hữu ích 100%, và hiện vẫn đang ở giai đoạn giống thời kỳ đầu của Internet
    • Đây không phải công nghệ sẽ sa thải tất cả mọi người
    • Nhưng nó giúp hạ thấp rào cản tiếp cận ML/AI vốn trước đây gần như chỉ Google mới có
  • Với Claude, Gemini v.v., họ chưa làm A/B test nghiêm ngặt
    • Nhưng khi thử trong công việc coding hằng ngày, họ cảm thấy các mô hình này chưa thật sự gần GPT-4 ở những khác biệt tinh tế về khả năng hiểu đúng ý định
  • Họ cho rằng không cần phải chạy theo mọi làn sóng LLM/AI
    • Nếu nhìn qua The Bitter Lesson và tin rằng hiệu năng của mô hình tổng quát quan trọng hơn các tối ưu chuyên biệt, thì chỉ cần quan tâm GPT-5 có ra hay không là đủ
    • Ngoài các mảng riêng biệt như Sora, phần lớn các bản phát hành trung gian của OpenAI gần như chỉ là nhiễu
  • GPT-5 có khả năng chỉ là cải tiến dần dần hơn là thay đổi mọi thứ
    • Khi chuyển từ GPT-3 sang GPT-3.5, người ta từng kỳ vọng nếu tăng cường độ huấn luyện gấp 2 thì hiệu năng sẽ tăng siêu tuyến tính lên 2,2 lần
    • Nhưng thực tế trông giống tăng trưởng theo log hơn, và để có cải tiến dần dần thì tốc độ token lẫn chi phí trên mỗi token lại tăng theo cấp số nhân
  • GPT-4 có thể là điểm tối ưu cho bộ tác vụ hiện tại
    • Họ sẵn sàng trả chi phí gấp 20 lần để dùng GPT-4 thay cho GPT-3.5, nhưng có lẽ sẽ không trả thêm gấp 20 lần mỗi token để đi từ GPT-4 lên GPT-5
    • GPT-5 có thể phá vỡ nhận định này, hoặc cũng chỉ giống như nâng từ iPhone 4 lên iPhone 5

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-14
Ý kiến trên Hacker News

  • Nhóm tôi phụ trách đang xử lý hơn 5 tỷ token mỗi tháng và con số này vẫn tiếp tục tăng; chúng tôi đã rút ra vài bài học
    Thứ nhất, có quá nhiều lớp trừu tượng hóa quá sớm. Những công cụ như Langchain có thể hữu ích vào một ngày nào đó, nhưng rốt cuộc prompt cũng chỉ là lời gọi API, và thay vì coi lời gọi LLM là thứ gì đó đặc biệt, xử lý nó bằng mã tiêu chuẩn như một lời gọi API không ổn định sẽ dễ hơn
    Thứ hai, ảo giác chắc chắn là một vấn đề lớn. Tóm tắt thì qua kiểm thử khá vững, nhưng suy luận thì thật sự khó; các mô hình hành động nhận đầu vào từ người dùng rồi để LLM quyết định hành động tiếp theo đặc biệt khó ở phần hiểu ngữ cảnh và khiến nó nói “không chắc”. Dù vậy, riêng việc có thể làm được điều này đã thay đổi cuộc chơi
    Thứ ba, tôi nghiêng về phía “thay đổi cuộc chơi” hơn tác giả một chút, nhưng không nghĩ thế giới sẽ tận thế. Một số nghề sẽ bị ảnh hưởng lớn, và có thể sẽ có vài năm khó khăn khi bot thao túng dư luận trên các nền tảng. Nhìn chung, nó có vẻ giống một bộ khuếch đại năng lực hơn là một đột phá kiểu Internet
    Cá nhân tôi thấy nó giống với sự chuyển dịch DevOps những năm 2000. Giờ không cần một đội chuyên trách khổng lồ để hỗ trợ triển khai nữa; người ta tuyển một số ít chuyên gia và phần lớn mua giải pháp có sẵn. Tương tự, một số công việc machine learning giờ đã trở nên đủ dễ để một web developer như tôi cũng có thể triển khai

    • Khi giải thích nên kỳ vọng LLM như thế nào trong luồng phát triển hiện đại, phép so sánh này rất hữu ích. Vì nó cho thấy đây không phải lời giải vạn năng, mà là sự đánh đổi
      Sự tiến hóa của DevOps cũng có những đánh đổi. Ví dụ, hệ quả trực tiếp của việc “cứ dùng AWS RDS là được” là các năng lực cốt lõi như quản trị cơ sở dữ liệu bị mai một, còn hóa đơn cloud thì tăng vọt. Đặc biệt, chi phí vận hành của các startup không có quy mô dữ liệu hay độ phức tạp khu vực quá lớn cũng tăng lên, và tôi cho rằng xu hướng này cũng dẫn đến những sự cố tương tự vụ gián đoạn lớn của GitLab
    • Việc khiến nó nói “không chắc” gần như là một hàm của chính mô hình ngôn ngữ. Đến thời điểm tạo ra đầu ra, sự bất định vốn có trong phép tính đã biến mất trong dự đoán
      Điều này giống như khi bảo ai đó đoán mặt sấp/ngửa của đồng xu và họ trả lời “mặt ngửa”: trước khi trả lời, họ có thể nói về sự bất định như Pr[mặt ngửa] = .5, nhưng trong dự đoán thực tế và kết quả tung đồng xu, sự bất định đó biến mất. Với LLM cũng vậy, sự bất định trong quá trình tính toán biến mất ở dự đoán token cuối cùng, nên trừ khi bản thân dự đoán là một biểu đạt về sự bất định, đầu ra kiểu “tôi không hiểu” hầu như sẽ không xuất hiện. Nhưng lý do là vì ngay từ đầu nó không hiểu mà chỉ dự đoán
    • Trước đây tôi chưa từng nghĩ đến phép so sánh DevOps, nhưng thấy nó khá khớp nên vừa viết một bài dựa trên ý tưởng này: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      Về cơ bản, tôi cho rằng chúng ta đang dùng GPT như một thứ tương đương PaaS/Heroku/Render trong vận hành AI
    • Tôi đồng ý với nhận định “giống một bộ khuếch đại năng lực hơn là một đột phá kiểu Internet”. Khách hàng cũng đang cảm thấy sốc giá khi so sánh chi phí của các mô hình lớn với đầu ra. Theo thời gian chi phí sẽ giảm
    • Tôi đồng cảm với nhận định tóm tắt thì vững nhưng suy luận thì khó. Cách yêu cầu dùng phép so sánh rất thú vị và hữu ích một cách bất ngờ

  • Tôi tò mò về đoạn “chúng tôi luôn trích xuất JSON. Không cần chế độ JSON”. Trong trường hợp của tôi thì nó hoạt động khá tốt
    Tôi thật sự đồng tình với câu “Bài học 4: GPT rất kém trong việc tạo giả thuyết không”. Hôm qua tôi cũng đang thử nghiệm prompt về các quy tắc chỉnh sửa văn bản và viết ở cuối: “Nếu không có quy tắc nào áp dụng cho văn bản, hãy trả về nguyên văn không thay đổi”
    Bạn biết ChatGPT đã trả lời gì với một văn bản không áp dụng bất kỳ quy tắc nào không? Nó trả về đúng nguyên chuỗi “The original text without any changes”

    • Có những câu chuyện về thần đèn thất thường diễn giải từng chữ trong lời ước và ban cho những điều ước bị nguyền rủa; thứ chúng ta có hiện nay chính là vậy. Những người đã dùng prompt cho mô hình tạo ảnh từ lâu phần nào đã nắm được cảm giác này, nhưng với những người bước vào vì LLM thì có thể khá bất ngờ
      Trước đây khi tạo hình ảnh ba người phụ nữ uống rượu trong một khu vườn đẹp cho bài tarot, tôi thêm “lush vegetation” ở cuối prompt, và do tính đa nghĩa của từ lush, bầu không khí thanh lịch đã biến thành cảm giác nữ sinh đại học tiệc tùng với mũi đỏ
    • Tôi hiểu ý là “cách của chúng tôi hoạt động tốt nên không cần dùng chế độ JSON”. Công ty tôi cũng ở tình huống tương tự. Đã vận hành được 1 năm và không cần đổi. Prompt của chúng tôi khá hiệu quả trong việc khiến GPT-3.5 luôn xuất JSON
    • Nhìn các trang về những lỗi trang trí bánh kem thì thấy con người cũng luôn mắc những lỗi kiểu này

  • Viết prompt tốt hơn thì có thể dùng mô hình rẻ hơn
    “Nếu không tìm thấy gì thì đừng trả về gì cả” là cách cấp 0 để cho LLM một lối thoát. Tốt hơn là nên cho một lối thoát mềm hơn. Ví dụ, viết kiểu “Nếu không có đủ thông tin để đưa ra một phát biểu chắc chắn, bạn có thể nêu giả thuyết miễn là nói rõ rằng mình đang làm vậy và ghi ra căn cứ cùng nền tảng logic của giả thuyết”, rồi cuối cùng yêu cầu nó tự đánh giá câu trả lời của mình

    • Không nên phát triển prompt theo kiểu trừu tượng. Mục tiêu của prompt là kích hoạt biểu diễn nội bộ của mô hình để nó thực hiện nhiệm vụ tốt nhất
      Nếu không có phương pháp tự động, bạn phải kiểm thử lặp đi lặp lại phản hồi của mô hình trên nhiều đầu vào khác nhau để hiểu nó diễn giải yêu cầu ra sao, thất bại ở đâu, rồi lấp các lỗ hổng đó. Thậm chí còn phải kiểm chứng xem mô hình có biết nothing nghĩa là gì hay không

  • Tôi đăng ký cả 3 dịch vụ hàng đầu trong lĩnh vực LLM và thường xuyên đưa cùng một prompt cho chúng, và GPT-4 có lợi thế rất áp đảo. Thật đáng ngạc nhiên dù GPT-4 đã ra mắt được 1 năm và trong thời gian đó đã có vài lần cập nhật
    Ít nhất với kiểu sử dụng của tôi, hiện tượng ảo giác cũng khá hiếm. Trong khi đó Claude khi viết code lại khá dễ bịa ra những API nghe có vẻ hợp lý nhưng không tồn tại. GPT-4 cứng rắn hơn và ít hùa theo hơn khi nó biết mình đúng. Những khác biệt này gần như không thể hiện trên các chỉ số, nên phải tự dùng mới thấy được

    • Với tôi thì Claude 3 Opus tốt hơn GPT-4. Đặc biệt là giải thích hay hơn, và quan trọng hơn là kỹ lưỡng hơn
      Ngay cả trong các tác vụ lập trình, tôi thường yêu cầu giải thích chủ đề hoặc code hơn là bắt nó viết code, và nó có xu hướng đưa ra câu trả lời tinh tế hơn nhiều. Khi đưa một văn bản dài và trò chuyện, Claude Opus cho cảm giác hiểu nội dung sâu hơn; GPT-4 thì thường dừng ở mức tóm tắt văn bản được đưa vào, còn Claude suy luận và mở rộng tốt hơn
    • Tôi tò mò là bạn đang so với Claude Opus hay với các biến thể cấp thấp hơn. Opus thì tôi thật sự rất thích khi tạo nội dung tiếng Anh
    • GPT-4 xử lý tốt hơn các prompt có hình thức kém, thiếu thông tin hoặc cấu trúc lộn xộn. Nếu không cấu trúc một prompt lớn một cách thông minh, Claude có thể bối rối không biết bạn đang yêu cầu gì
      Tuy nhiên, với prompt được xây dựng tốt, Claude Opus có xu hướng cho đầu ra tốt hơn GPT-4. Claude linh hoạt hơn và đưa ra câu trả lời dài hơn, trong khi ChatGPT/GPT-4 thường nghe như kiểu trả lời ngắn và “điển hình” đặc trưng của nó
    • Trải nghiệm của tôi thì ngược lại. Tôi đăng ký nhiều dịch vụ và copy-paste cùng một câu hỏi, và với các câu hỏi liên quan đến phát triển phần mềm, Claude Opus vượt xa đến mức tôi đang nghĩ có lẽ không cần dùng GPT-4 nữa
      Trong các ví dụ code tôi yêu cầu, code do GPT-4 tạo ra nhiều khi thậm chí không biên dịch được, còn với Claude thì gần như không gặp chuyện đó
    • Tôi cũng đăng ký cả ba dịch vụ và so sánh theo cùng cách. Đặc biệt là mỗi khi có phiên bản mới
      Bài test giấy quỳ tôi hay dùng gần đây là “hãy cho tôi biết 10 quán bar độc đáo trong bán kính 200 dặm từ Austin”. Câu này cực khó với tất cả, GPT-4 còn tạm gần đúng, nhưng Claude thì bịa ra luôn, còn Gemini thì sụp hoàn toàn

  • GPT rất tuyệt, nhưng tôi không đồng ý mạnh với cách diễn giải trong hai đoạn của bài viết
    Có thể tóm tắt rằng cách tiếp cận tốt hơn là kiểu “GPT này, bạn rõ ràng biết 50 tiểu bang, nên hãy đưa tên đầy đủ của tiểu bang tương ứng, hoặc trả lời Federal nếu thuộc chính phủ Mỹ”
    Nhưng tôi nghĩ diễn giải rằng khi nói mơ hồ hơn thì chất lượng và khả năng khái quát hóa của GPT tốt hơn là dấu hiệu điển hình của ủy quyền/tư duy bậc cao thì hơi quá. Ngôn ngữ tự nhiên là đầu ra có xác suất cao nhất đối với GPT, vì nó giống với văn bản đã được huấn luyện. Trong trường hợp này, nhà phát triển chỉ dựa nhiều hơn vào thứ GPT làm tốt, chứ không phải giao thêm việc cho nó
    Có nhiều tác vụ đơn giản khiến GPT thất bại. Những việc như thay thế chữ cái, cố ý tạo lỗi chính tả rất khó với GPT. Mapping ID cũng vậy, đặc biệt khi mapping đó khác xa những gì nó đã thấy trong quá trình huấn luyện. Ví dụ như các mã ba chữ cái tương tự nhưng không phải mã quốc gia ISO
    Điểm thú vị là bản thân việc GPT “hiểu” được mapping. Tôi nghĩ đó mới là manh mối thực sự của khớp mẫu bậc cao

    • Hoặc cũng có thể nó chỉ ghi nhớ mapping. Không có nghĩa là tái tạo nguyên xi, mà là nó có vector tương tự với mapping đã từng thấy trước đó

  • Mẹo cho vấn đề ‘null’: LLM được tạo ra để xuất token, chứ không phải để không xuất token
    Vì vậy thay vì nói “đừng trả về gì cả”, hãy bảo nó “trả về giá trị mặc định của XYZ” khi không có kết quả, rồi tìm kiếm văn bản giá trị mặc định đó, ví dụ XYZ, trong kết quả như khi tìm tên tiểu bang
    Ngoài ra system prompt có thể rất hữu ích. Về cơ bản đó là cơ hội để cho LLM nhập vai X. Sẽ tốt hơn nếu có thể truyền trực tiếp system prompt, nhưng dù sao vẫn hơn là không có

  • Việc GPT không thể trả về đúng danh sách hơn 10 đối tượng JSON là vấn đề prompt. Tôi từng khiến nó trả về ổn định tới 200 mục theo đúng thứ tự
    Mẹo là hoàn toàn không dùng danh sách, mà dùng các khóa JSON trong đầu ra như "item1": {...}. Khi với một đầu vào có thể có 0~n đầu ra, có thể dùng danh sách làm giá trị

    • Tôi nói với nó rằng người dùng đến từ một nền văn hóa coi việc trả lời bằng danh sách không đầy đủ là bất lịch sự và xúc phạm
    • Nếu bạn có thể giải thích chi tiết hơn thì tốt quá. Tôi đang đau đầu với đúng vấn đề này
      Nếu đưa cho GPT-4 một danh sách các mục hiện có với cấu trúc đã định nghĩa và yêu cầu chuyển thành JSON kiểu như chuyển đổi schema, nó làm tốt cả ngày. Nhưng nếu cần bất kỳ kiểu suy luận nào và thực chất phải tự tạo danh sách của nó, nó chỉ đưa ra một tập con rất hạn chế
      Các LLM khác cũng có vấn đề tương tự. Tôi rất tò mò bạn tiếp cận như thế nào

  • Các tác vụ như “trích xuất tên công ty từ khối văn bản” có thể chia thành hai bước
    Trước tiên hỏi “trong khối văn bản này có công ty nào được nhắc đến không?”, nếu không thì ta có kết quả null. Nếu có, hãy hỏi “hãy liệt kê tên các công ty trong khối văn bản này”

  • Tôi đang dùng mô hình OpenAI trong một ứng dụng viết cá nhân, và bài này thật sự chính xác. Tôi đã học được một điều liên quan đến Bài học 1: “prompt càng ít càng tốt”
    Khi xây dựng tính năng tìm kiếm thông minh cho ghi chú, tôi đã cố để ChatGPT trả về dữ liệu JSON có cấu trúc. Ví dụ hỏi “hãy đưa tất cả ghi chú của tôi trong 2 năm qua có nhắc đến Haskell và được đánh dấu là bản nháp”, rồi để ChatGPT tự phán đoán cần trả về gì. Cách này chỉ thỉnh thoảng hoạt động
    Thay vào đó, tôi đưa dữ liệu vào cơ sở dữ liệu SQLite, gửi schema cho ChatGPT, rồi nhờ nó viết truy vấn trả về kết quả mong muốn; cách này hoạt động tốt hơn nhiều

    • Việc này có vẻ phù hợp với cơ sở dữ liệu và bộ lọc tìm kiếm tốt hơn là LLM
    • Tôi tò mò bạn đã thử response_format=json_object chưa
      Gọi hàm phù hợp hơn để nhận phản hồi có cấu trúc, nhưng nó có nhiều ràng buộc hơn so với việc chỉ nhận phần thân JSON

  • Ví dụ về việc chỉ dẫn quá chính xác lại làm giảm độ chính xác nghe có lý theo hiểu biết còn thô sơ của tôi về cách các hệ thống này hoạt động
    Nếu đưa toàn bộ danh sách tiểu bang vào, tức là phần nào kích hoạt các vector cho mọi tiểu bang. Nếu chỉ nói “state” và văn bản truyền vào có một tiểu bang rõ ràng, thì ít vector liên quan đến mục tiêu cần tìm được kích hoạt hơn. Vì vậy khi thực hiện softmax, khả năng chọn đúng tiểu bang sẽ cao hơn
    Cùng mạch đó, so sánh giữa /n và dấu phẩy có lẽ cũng rất có khả năng là do khác biệt token hóa