Mục tiêu

Làm cho việc hiển thị địa điểm trong AI chat có thể quản lý và có cấu trúc: thay vì văn bản/liên kết tùy ý, tác nhân phải có khả năng tham chiếu rõ ràng đến một địa điểm bằng ID nội bộ của nó và giao diện chat sẽ thay thế liên kết đó bằng một thẻ địa điểm đầy đủ.

Vấn đề

Hiện tại, khi đề xuất hoặc đề cập đến các công ty/địa điểm, tác nhân phản hồi theo dạng tự do: viết tên bằng văn bản, thêm URL hoặc định dạng liên kết theo ý muốn. Giao diện người dùng không thể xác định đáng tin cậy rằng một đoạn phản hồi cụ thể tương ứng với một bản ghi địa điểm cụ thể trong cơ sở dữ liệu, do đó không thể hiển thị thẻ một cách ổn định.

Hợp đồng đề xuất

Thêm một thẻ tùy chỉnh đặc biệt vào giao thức phản hồi của tác nhân, chỉ chứa mã định danh của một địa điểm hiện có. Ví dụ:

<place id="PLACE_ID" />

Tên thẻ có thể được chọn theo các quy ước hiện tại của dự án (place, company, venue, v.v.), nhưng định dạng phải rõ ràng, có thể phân tích cú pháp bằng máy và được tài liệu hóa.

Nguyên tắc cốt lõi: LLM chỉ cung cấp id, trong khi tất cả dữ liệu thẻ được hiển thị (tên, địa chỉ, ảnh, đánh giá, liên kết, giờ làm việc, v.v.) sẽ được máy khách/máy chủ lấy từ dữ liệu ứng dụng cập nhật. Không truyền các trường này bên trong thẻ LLM.

Backend / AI

1. Bổ sung prompt/hướng dẫn hệ thống của tác nhân với quy tắc: khi đề xuất, liệt kê hoặc đề cập cụ thể đến một địa điểm từ danh mục có sẵn cho nó, hãy sử dụng thẻ tùy chỉnh với ID của địa điểm đó.
2. Đảm bảo rằng ID địa điểm có sẵn trong ngữ cảnh/công cụ của tác nhân cùng với dữ liệu mà mô hình sử dụng để chọn địa điểm.
3. Cấm mô hình tự tạo ID. Thẻ chỉ được phép đối với ID lấy từ kết quả tìm kiếm/danh mục/công cụ.
4. Xác định phương án dự phòng (fallback): nếu một địa điểm không thể được khớp đáng tin cậy với ID nội bộ, tác nhân sẽ viết văn bản thông thường không có thẻ tùy chỉnh.
5. Duy trì khả năng thêm văn bản giải thích xung quanh thẻ: ví dụ "Để đi chơi cùng gia đình thì phù hợp là…" + thẻ địa điểm.
6. (Không bắt buộc hoặc giữ nguyên nếu không có)

Chat Frontend

1. Nhận dạng thẻ tùy chỉnh trong assistant-message và không hiển thị nó cho người dùng dưới dạng văn bản thô.
2. Sử dụng id để tải/lấy dữ liệu địa điểm và kết xuất thẻ địa điểm nhỏ gọn hiện có hoặc mới trực tiếp bên trong tin nhắn.
3. Hỗ trợ nhiều thẻ trong một phản hồi, giữ nguyên thứ tự tương đối với văn bản.
4. Thẻ phải có thể nhấp vào và chuyển đến trang của địa điểm tương ứng.
5. Không diễn giải HTML tùy ý từ mô hình: bộ phân tích cú pháp chỉ được hỗ trợ định dạng thẻ/thuộc tính được phép rõ ràng.
6. Nếu ID không tồn tại, bản ghi đã bị xóa hoặc việc tải thẻ gặp lỗi — tin nhắn không được bị hỏng. Sử dụng phương án dự phòng an toàn (ví dụ: ẩn thẻ không hợp lệ hoặc hiển thị trình giữ chỗ văn bản trung tính — chọn hành vi đồng nhất).
7. Tính đến việc truyền phát trực tuyến (streaming): thẻ thô chưa hoàn thành không được nhấp nháy đối với người dùng trong quá trình tạo. Phân tích cú pháp thành phần sau khi nhận được thẻ hoàn chỉnh hoặc đệm tiền tố thẻ tiềm năng.

Định dạng kết xuất được đề xuất

Phản hồi của mô hình:

Nếu bạn thích phòng tắm hơi cổ điển trong thành phố, tôi sẽ xem xét:

<place id="abc123" />

Và nếu định dạng SPA hiện đại quan trọng hơn:

<place id="def456" />

Trong UI, người dùng nhìn thấy văn bản, thẻ địa điểm đầu tiên, văn bản tiếp theo và thẻ địa điểm thứ hai — mà không hiển thị đánh dấu hệ thống.

Tiêu chí nghiệm thu

• Đã xác định và tài liệu hóa cú pháp thống nhất của thẻ địa điểm tùy chỉnh với id bắt buộc.
• Tác nhân nhận được ID địa điểm thực và sử dụng thẻ khi đề xuất các địa điểm cụ thể.
• Tác nhân không tạo thẻ cho địa điểm không xác định/không khớp.
• Đoạn chat chuyển đổi chính xác thẻ thành thẻ địa điểm tương ứng.
• Nhiều thẻ được đan xen với văn bản Markdown thông thường hoạt động chính xác trong một tin nhắn.
• Thẻ hệ thống không hiển thị cho người dùng, bao gồm cả quá trình streaming.
• ID không hợp lệ/không tồn tại không làm hỏng việc kết xuất tin nhắn.
• Thẻ dẫn đến trang địa điểm chính xác.
• Markdown thông thường và các liên kết hiện có trong tin nhắn tiếp tục hoạt động mà không bị hồi quy.
• Đã thêm các bài kiểm tra ít nhất cho: một thẻ, nhiều thẻ, ID không hợp lệ, thẻ bị lỗi cú pháp, streaming/thẻ một phần.

Cần kiểm tra riêng trước khi triển khai

Cần xem xét pipeline kết xuất Markdown/streaming hiện tại và quyết định nơi thực hiện chuyển đổi tốt nhất: trước bộ phân tích cú pháp Markdown qua tokenizer/AST hoặc như một phần mở rộng kết xuất được phép. Không sử dụng dangerouslySetInnerHTML không an toàn để xử lý phản hồi của mô hình.