Lợi nhuận:
- Có thể mô tả cấu trúc cơ bản của yêu cầu API LLM (điểm cuối, mô hình, thông báo, max_tokens)
- Hiểu sự khác biệt giữa vai trò hệ thống, người dùng và trợ lý cũng như lịch sử hội thoại không trạng thái
- Có thể đọc và giải thích các trường (khối nội dung, stop_reason, cách sử dụng) của phản hồi được trả về
Trong các mô-đun trước, chúng tôi đã sử dụng trí tuệ nhân tạo từ cửa sổ trò chuyện. Nhưng nếu bạn muốn nhúng AI vào sản phẩm, tự động hóa hoặc quy trình làm việc của riêng mình, giao diện trò chuyện sẽ không đáp ứng được điều đó; Bạn cần kết nối với mô hình theo chương trình, nghĩa là bằng mã hoặc một công cụ tự động hóa. Tên của cây cầu này là API (Giao diện lập trình ứng dụng, hợp đồng cho phép hai phần mềm nói chuyện với nhau theo những quy tắc nhất định). Khi hoàn thành phần này, bạn sẽ biết điều gì cấu thành một yêu cầu API LLM (Mô hình ngôn ngữ lớn), vai trò của thông báo là gì và cách đọc phản hồi. Đây là nền tảng để xây dựng phần còn lại của mô-đun.
API hoạt động như thế nào?
Luồng cơ bản trong API là thế này: bạn gửi yêu cầu theo một định dạng nhất định; Máy chủ trả về phản hồi ở một định dạng cụ thể. Trong LLM, đây thường là cuộc gọi HTTP (HTTP: giao thức chuẩn để truyền phản hồi yêu cầu trên web) đến một địa chỉ duy nhất (điểm cuối, địa chỉ cố định trên máy chủ xử lý yêu cầu của bạn). Ví dụ: trong API nhắn tin, tất cả các yêu cầu đều chuyển đến một địa chỉ duy nhất và được chứa trong nội dung dưới dạng JSON (Ký hiệu đối tượng JavaScript - một định dạng văn bản bao gồm các cặp khóa/giá trị mà cả con người và máy móc đều có thể đọc được).
Trong một yêu cầu, bạn chỉ định ít nhất ba điều sau:
- Mô hình: Bạn sẽ sử dụng mô hình nào (ví dụ: mô hình nhanh và rẻ hoặc mô hình mạnh).
- max_tokens: Số lượng mã thông báo tối đa (đơn vị nhỏ nhất trong đó văn bản được xử lý, sẽ được xử lý chi tiết trong đơn vị tiếp theo) mà mô hình có thể tạo ra; tức là giới hạn đầu ra.
- tin nhắn: Danh sách các tin nhắn tạo nên cuộc trò chuyện.
Từng bước: Cách thiết lập yêu cầu
- Chuẩn bị điểm cuối và thông tin xác thực. Bạn thêm khóa API (chuỗi bí mật chứng minh danh tính của bạn) vào yêu cầu trong tiêu đề. Bạn không bao giờ nhúng khóa vào mã; Chúng tôi sẽ đảm bảo việc lưu trữ an toàn ở đơn vị 9.
- Chọn mô hình và giới hạn đầu ra. Mô hình nhẹ + max_tokens nhỏ cho một tác vụ đơn giản; Mô hình mạnh mẽ + giới hạn lớn hơn cho một nhiệm vụ phức tạp.
- Thiết lập danh sách tin nhắn. List the system instruction, user message, and past rounds (if any).
- Gửi yêu cầu và phân tích phản hồi. Đọc nội dung văn bản, lý do dừng và việc sử dụng mã thông báo từ JSON được trả về.
Vai trò của tin nhắn: hệ thống, người dùng, trợ lý
Một cuộc trò chuyện bao gồm các tin nhắn được sắp xếp theo trình tự và mỗi tin nhắn có một vai trò. Vai trò xác định cách mô hình xử lý văn bản đó.
Vai trò
Ai viết
Mục đích
hệ thống
Nhà phát triển/điều hành
Những hướng dẫn, tính cách và quy tắc thường trực áp dụng xuyên suốt toàn bộ cuộc trò chuyện
người dùng
người dùng cuối
Câu hỏi hoặc thông tin đầu vào hiện tại của người dùng
trợ lý
người mẫu
Phản hồi do mô hình tạo ra (và các phản hồi trước đó)
Vai trò hệ thống có sẵn dưới dạng trường hệ thống riêng biệt trong phần yêu cầu ở hầu hết các nhà cung cấp; người dùng và trợ lý được liệt kê tuần tự trong danh sách tin nhắn. Critical point: the system instruction is the high-level instruction, the user message is the request to be answered at that moment.
{ "model": "claude-opus-4-8", "max_tokens": 1024, "system": "Bạn là trợ lý hỗ trợ của công ty. Đưa ra câu trả lời ngắn gọn, chính thức và đã được xác minh. Đừng bịa đặt những thông tin mà bạn không chắc chắn.", "messages": [ { "role": "user", "content": "Làm cách nào để tôi bắt đầu quá trình hoàn trả của mình?" } ]}
Lời nói không có trạng thái
Đây là quan niệm sai lầm phổ biến nhất: Lệnh gọi API LLM không có trạng thái — máy chủ không giữ lại bộ nhớ giữa hai yêu cầu. Mô hình không nhớ yêu cầu trước đó của bạn. Nếu bạn đang thiết lập một cuộc trò chuyện nhiều vòng, bạn sẽ cần gửi lại các vòng trước đây cùng với mỗi yêu cầu mới. "Bộ nhớ" của mô hình bao gồm danh sách các tin nhắn bạn đã gửi.
{ "model": "claude-opus-4-8", "max_tokens": 512, "messages": [ { "role": "user", "content": "Xin chào, tên tôi là Deniz." }, { "role": "trợ lý", "nội dung": "Xin chào Deniz, tôi có thể giúp gì cho bạn?" }, { "role": "user", "content": "Tôi vừa nói tên tôi, bạn có nhớ không?" } ]}
Việc trả lời chính xác tin nhắn thứ ba phụ thuộc vào việc bạn gửi cả hai tin nhắn trước đó. Nếu bạn không gửi, người mẫu sẽ không biết "Biển" và sẽ trả lời sai. Điều này cũng ảnh hưởng trực tiếp đến chi phí: cuộc trò chuyện càng dài, danh sách càng lớn, mỗi yêu cầu tiêu tốn nhiều token hơn.
Mẹo: Trong các cuộc trò chuyện dài, việc tóm tắt và di chuyển các vòng cũ (tóm tắt + vài vòng cuối) thay vì gửi toàn bộ lịch sử sẽ giảm chi phí và duy trì cửa sổ ngữ cảnh. Chúng ta sẽ đào sâu vấn đề này ở bài 6 và 11.
Đọc câu trả lời
Khi mô hình trả về phản hồi, bạn sẽ nhận được một đối tượng có cấu trúc chứ không phải văn bản thuần túy. Các khu vực điển hình:
{ "id": "msg_01ABC...", "model": "claude-opus-4-8", "role": "assistant", "content": [ { "type": "text", "text": "Để bắt đầu hoàn trả, hãy truy cập trang 'Đơn hàng của tôi' trong tài khoản của bạn..." } ], "stop_reason": "end_turn", "usage": { "input_tokens": 47, "output_tokens": 88 }}
- nội dung: Bản thân phản hồi; Đây là danh sách các khối nội dung. Trường văn bản của khối văn bản là câu trả lời thực tế.
- stop_reason: Tại sao mô hình dừng lại. end_turn = kết thúc tự nhiên; max_tokens = bị kẹt ở giới hạn đầu ra (phản hồi có thể không đầy đủ); từ chối = từ chối vì lý do an ninh. Mã của bạn phải luôn nhìn vào stop_reason trước tiên.
- cách sử dụng: Số mã thông báo đầu vào và đầu ra. Nó là cơ sở của việc theo dõi chi phí và giới hạn.
Chú ý: Nếu stop_reason là max_tokens thì phản hồi chưa hoàn thành. Coi đây là "phản hồi thành công" và hiển thị một nửa văn bản cho người dùng là một trong những lỗi phổ biến nhất trong quá trình sản xuất. Tăng max_tokens hoặc sử dụng tính năng phát trực tuyến.
Dấu nhắc yếu / Dấu nhắc mạnh
Cùng một tác vụ với hai lời nhắc hệ thống khác nhau:
# YẾU Bạn là trợ lý. Trả lời các câu hỏi.
# MẠNH MẼBạn là trợ lý hỗ trợ của công ty. Quy tắc:- Chỉ dựa vào thông tin trong văn bản chính sách được cung cấp; Nếu trong văn bản không có thì nói “Tôi không có thông tin này, tôi đang chuyển cho đơn vị liên quan”. - Câu trả lời không quá 3 câu, chính thức, rõ ràng. - Không yêu cầu dữ liệu cá nhân (số TC ID, số thẻ) và không lặp lại. - Đừng đoán khi bạn không chắc chắn.
Phiên bản mạnh mẽ; Nó xác định phạm vi, hình thức, giới hạn an toàn và hành vi không chắc chắn. Tính nhất quán của đầu ra mô hình xuất phát trực tiếp từ sự rõ ràng này.
Ba hộp nhỏ
Trường hợp 1 - Bot hỗ trợ (bẫy không quốc tịch). Một nhóm thương mại điện tử đã đưa bot vào hoạt động; Khi người dùng nói “hủy đơn hàng trước đó” thì bot “quên” mã đơn hàng. Lý do: họ chỉ gửi mỗi yêu cầu với tin nhắn cuối cùng. Giải pháp: họ đã thêm 6 vòng cuối vào danh sách tin nhắn. Kết quả: ngữ cảnh được giữ nguyên nhưng dữ liệu đầu vào cho mỗi yêu cầu đã tăng từ 40 mã thông báo lên ~600 mã thông báo — chúng ta sẽ đề cập đến bài học về chi phí trong phần 2.
Trường hợp 2 - Tóm tắt hợp đồng không đầy đủ. Một nhóm pháp lý đang soạn thảo hợp đồng dài 10 trang; max_tokens: 300 vẫn ở mức thấp, phần tóm tắt bị cắt giữa câu. stop_reason lần nào cũng là max_tokens nhưng không ai để ý. tăng max_tokens lên 1500 và thêm kiểm tra stop_reason; Tỷ lệ tóm tắt bị cắt ngắn giảm từ 18% xuống 0%.
Trường hợp 3 - Trộn các vai trò. Một nhóm tiếp thị đang viết tất cả các hướng dẫn vào tin nhắn của người dùng, để trống hệ thống. Khi đầu vào của người dùng kết hợp với hướng dẫn, mô hình đôi khi sẽ tuân theo lệnh của người dùng là "hãy quên các quy tắc trước đó". Họ chuyển các quy tắc vĩnh viễn vào hệ thống; Bằng cách tách đầu vào của người dùng khỏi hướng dẫn, việc vi phạm quy tắc đã giảm đáng kể.
Những lỗi thường gặp
- Quên gửi quá khứ: Người mẫu bị cho là “không nhớ”; trong khi nó không có trạng thái. Bạn mang theo bối cảnh.
- Không nhìn vào `stop_reason`: Phản hồi đã dừng với max_tokens được coi là hoàn tất.
- Nhúng lệnh vào `user`: Các quy tắc liên tục vào hệ thống; đầu vào ngay lập tức đi đến người dùng. Trộn tạo ra lỗ hổng bảo mật.
- Nhầm `nội dung` với một chuỗi đơn giản: Câu trả lời là danh sách các khối; đọc trường văn bản của khối văn bản đầu tiên, xác minh loại của nó trước khi lấy nội dung [0] bằng chỉ mục mù.
- Nhúng khóa vào mã: Sử dụng biến môi trường (đơn vị 9).
Sâu hơn: Khối nội dung và câu trả lời gồm nhiều phần
Hiểu lý do tại sao trường nội dung trong phản hồi lại là một danh sách là điều cơ bản đối với các tính năng nâng cao mà bạn sẽ gặp sau này. Đôi khi mô hình trả về không phải một khối văn bản mà là một số khối: một khối suy nghĩ, theo sau là một khối văn bản; hoặc một khối văn bản theo sau là một khối sử dụng công cụ. Đó là lý do tại sao việc coi content[0] một cách mù quáng là "câu trả lời" là điều dễ hiểu. Cách tiếp cận đúng là xem qua danh sách và sắp xếp nó theo loại: bạn thu thập nội dung văn bản của các khối có trường loại là văn bản và xử lý riêng các loại khác (suy nghĩ, công cụ).
Điều khác biệt này thực hiện trong thực tế là bạn có thể ghi lại lý do của mô hình (nếu có) mà không tiết lộ cho người dùng, chuyển hướng lệnh gọi công cụ sang logic riêng biệt và chỉ in câu trả lời thực tế lên màn hình. Khi mô-đun tiến triển (đặc biệt là ở bài 4 và 11), bạn sẽ thấy cấu trúc khối này hữu ích như thế nào trong việc xác thực và định hướng đầu ra.
Một điểm thực tế khác: bạn có thể truy cập cùng một mô hình từ các nền tảng nhà cung cấp khác nhau (API trực tiếp, thông qua nhà cung cấp đám mây). Mặc dù địa chỉ điểm cuối và định dạng xác thực có thể thay đổi nhưng các khái niệm cơ bản như vai trò của thông báo, trạng thái không trạng thái và cấu trúc phản hồi vẫn giữ nguyên. Vì vậy, những kiến thức cơ bản trong bài học này sẽ áp dụng được cho dù bạn sử dụng nền tảng nào.
Tóm lại
Yêu cầu API LLM bao gồm mô hình, giới hạn đầu ra và danh sách thông báo; vai trò (hệ thống, người dùng, trợ lý) xác định hành vi của mô hình. Cuộc gọi không có trạng thái: bạn mang theo ngữ cảnh với mỗi yêu cầu. Phản hồi là một đối tượng có cấu trúc; Đọc và giải thích các trường nội dung, stop_reason và use là cơ sở cho độ bền trong sản xuất.
Nhiệm vụ ứng dụng
Chọn một nhiệm vụ từ nghề nghiệp của bạn (ví dụ: sắp xếp e-mail đến, tạo bản tóm tắt ngắn gọn). Trên một tờ giấy: (1) viết lời nhắc hệ thống với 4-5 quy tắc, (2) thiết lập thông báo mẫu cho người dùng và lịch sử 2 vòng nếu có, (3) xác định giá trị hợp lý cho max_tokens và viết lời giải thích, (4) liệt kê các giá trị stop_reason mà bạn sẽ xử lý trong phản hồi trả về và cách thực hiện.
danh sách kiểm tra
- [ ] Tôi có thể đếm ba phần bắt buộc của một yêu cầu (model, max_tokens, messages).
- [ ] Tôi có thể giải thích sự khác biệt giữa vai trò hệ thống, người dùng và trợ lý.
- [ ] Tôi biết rằng các cuộc gọi là không quốc tịch và tôi cần phải mang theo quá khứ.
- Tôi có thể đọc và nhận xét về nội dung [ ], các trường stop_reason và cách sử dụng.
- [ ] Với max_tokens tôi có thể nhận thấy và xử lý phản hồi bị cắt ngắn.