Pulse

Mã nguồn mở

Dạy phần mềm và tác tử AI biết một quyết định cần bằng chứng gì.

Dữ liệu sản phẩm được tạo cho cơ sở dữ liệu, nguồn cấp và cửa hàng. Một tác tử AI cần nhiều hơn: người mua đang muốn quyết định điều gì, điều đó cần bằng chứng gì, sản phẩm thực sự cho thấy gì, và điều gì vẫn chưa rõ. Open Pulse là nền tảng mở cho lớp đó. Pulse API là bộ máy ra quyết định đứng sau.

Giấy phép MIT. Dành cho lập trình viên, người bán, nhà nghiên cứu và tác tử AI, trong mọi ngành mà các lựa chọn có thuộc tính.

Thương mại có rất nhiều dữ liệu sản phẩm, nhưng rất ít dữ liệu quyết định.

Danh mục biết gì

  • Tiêu đề
  • Thương hiệu
  • Giá
  • Màu sắc
  • Ngành hàng
  • Mô tả
  • Hình ảnh

Người mua đang muốn trả lời điều gì

  • “Chiếc sofa này có lọt qua cửa nhà tôi không?”
  • “Bộ sạc này có tương thích với laptop của tôi không?”
  • “Laptop này có dựng video được không?”
  • “Trong hộp thực sự có những gì?”
  • “Bảo hành có hiệu lực ở nơi tôi sống không?”

Đó là yêu cầu quyết định, không phải câu tìm kiếm. Khi bằng chứng cho một yêu cầu bị thiếu, bị khuất hoặc mâu thuẫn, cả người mua lẫn tác tử AI đều không thể ra quyết định chắc chắn.

Bản ghi sản phẩm cho biết những gì được lưu. Bằng chứng quyết định cho biết điều gì có thể quyết định.

  1. 01

    Yêu cầu

    Điều cần biết.

  2. 02

    Bằng chứng sản phẩm

    Các thông tin được ghi, và nguồn của từng thông tin.

  3. 03

    Bằng chứng nhìn thấy được

    Điều người mua hoặc tác tử thực sự thấy.

  4. 04

    Quyết định

    Bằng chứng có đủ hay không.

  5. 05

    Kết quả

    Điều gì xảy ra sau đó.

Một sản phẩm có thể có dữ liệu mà vẫn có vấn đề về bằng chứng: một thông tin nằm trong nguồn cấp của nhà cung cấp nhưng không bao giờ lên trang, một thông số ghi hai lần với hai giá trị, một bức ảnh che mất đúng đặc điểm quan trọng.

Trên danh mục trình diễn 2.176 sản phẩm của chúng tôi, 52,6% giá trị được ghi lặp lại điều ảnh sản phẩm đã cho thấy. Xem nghiên cứu →

Tác tử AI cần nói được “bằng chứng không cho biết”.

Mô hình ngôn ngữ được tạo ra để trả lời. Pulse cho chúng câu trả lời thứ ba ngoài có và không, dựa trên những gì từng lựa chọn thực sự ghi.

Người mua

Chiếc sofa này có lọt qua cửa rộng 78 cm của tôi không?

Tác tử

Trang sản phẩm ghi chiều rộng khi lắp ráp, nhưng không ghi chiều rộng kiện hàng, nên tôi không thể xác nhận nó lọt qua cửa. Người bán cần công bố kích thước kiện hàng.

POST /decideĐã có
requirement  width <= 300 cm          meets
requirement  package_width <= 78 cm   unknown
verdict      cannot_tell
missing      package_width

POST /decide và công cụ MCP resolve_products trả về meets, fails, unknown hoặc conflicting cho từng yêu cầu, và fits, fails hoặc cannot_tell cho tổng thể.

Không trả lời cũng là một tính năng.

Hầu hết hệ thống sản phẩm được tạo ra để luôn trả về một thứ gì đó. Một hệ thống ra quyết định đôi khi phải trả về: không đủ bằng chứng.

Nếu kích thước kiện hàng không được ghi, tác tử không nên suy từ chiều rộng lắp ráp rằng sofa lọt qua cửa. Nếu hai nguồn ghi dung tích khác nhau, sự mâu thuẫn phải được giữ nguyên cho tới khi có người giải quyết.

AI có thể trình bày tốt hơn. Nó không được bịa ra sản phẩm.

AI có thể giúp

  • Sắp xếp lại thông số đã xác minh
  • Tóm tắt bằng chứng đã xác minh
  • Vẽ sơ đồ từ kích thước đã xác minh
  • Giải thích vì sao bằng chứng ủng hộ một quyết định

Không bao giờ được bịa ra

  • Kích thước hoặc dung tích
  • Chất liệu hoặc chứng nhận
  • Khả năng tương thích
  • Những gì có trong hộp, hoặc điều khoản bảo hành

Tạo ra cách trình bày. Không bao giờ tạo ra một thông tin sản phẩm chưa được xác minh.

Gọi đúng tên vấn đề về bằng chứng.

Dự kiến, thuộc các định dạng bằng chứng chung. Sáu trạng thái nói được nhiều hơn việc gọi mọi vấn đề là thiếu dữ liệu.

  • Thiếu

    Dự kiến

    Bằng chứng không được ghi.

  • Bị khuất

    Dự kiến

    Có, nhưng người mua hoặc tác tử khó tìm thấy.

  • Không hiển thị

    Dự kiến

    Nội bộ biết, nhưng không hiện ở nơi ra quyết định.

  • Chưa rõ

    Dự kiến

    Có một ít thông tin, nhưng không đủ để trả lời.

  • Mâu thuẫn

    Dự kiến

    Các nguồn ghi khác nhau.

  • Không quan sát được

    Dự kiến

    Bằng chứng hiện có không thể trả lời.

Mô tả cách sửa theo cùng một cách.

Dự kiến, cùng với các trạng thái bằng chứng. Tám động từ bao quát những gì có thể làm với một khoảng trống.

  • Ghi lại

    Bổ sung thông tin còn thiếu.

  • Hiển thị

    Đưa ra bằng chứng đã có sẵn.

  • Đối chiếu

    Giải quyết các nguồn mâu thuẫn.

  • Tạo

    Trình bày bằng chứng đã xác minh tốt hơn.

  • Hỏi

    Yêu cầu người bán, nhà cung cấp hoặc người mua.

  • Tính

    Suy ra an toàn từ dữ liệu đã xác minh.

  • Không trả lời

    Không trả lời khi thiếu bằng chứng.

  • Không sửa

    Chấp nhận có những khoảng trống không đáng sửa.

Hai động từ cuối là quan trọng nhất. Một hệ thống đáng tin phải nói được "tôi không biết", và một hệ thống hợp lý phải nói được "cái này không đáng sửa".

Mở ở nơi chia sẻ có ích. Trả phí ở nơi kết quả tạo ra giá trị.

Open Pulse

  • SDK cho trình duyệt, @thepulseapi/sdk 0.2.0Đã có
  • Máy chủ MCP cho tác tử AI, @thepulseapi/mcp 0.2.0Đã có
  • Ví dụ chạy được và hướng dẫn cho tác tửĐã có
  • Định dạng yêu cầu và bằng chứngDự kiến
  • Trạng thái bằng chứng và bộ từ vựng sửa lỗiDự kiến
  • Gói ngành hàngDự kiến
  • Bộ kiểm tra và kết nối cho nền tảng và PIMDự kiến
  • Bộ phân tích truy vấn và phân loại lý do trả hàngDự kiến

Pulse

  • Decision Audit: khoảng trống nào quan trọng nhất
  • Ưu tiên bản sửa và bài toán chi phí
  • Decision Verification: bản sửa có thay đổi gì không
  • Decision Monitor: bằng chứng có còn tốt không
  • Return Verification và Promotion Audit
  • Decision API khi vận hành thật
  • Học từ kết quả đo được

Open Pulse mô tả bằng chứng. Pulse quyết định điều gì đáng làm với nó.

Dạy hệ sinh thái cách mọi người quyết định trong ngành hàng của bạn.

Dự kiến. Một gói ngành hàng liệt kê các yêu cầu quan trọng với một loại sản phẩm và bằng chứng mỗi yêu cầu cần. Laptop, sofa và bộ sạc không nên dùng chung một mô hình.

category-pack.yamlMinh hoạ
category: furniture.sofa
requirements:
  - id: delivery_clearance
    question: "Can it reach the room?"
    evidence: [package_width, package_height, removable_legs]
  - id: room_fit
    question: "Will it fit in the room?"
    evidence: [width, depth, height]

Một gói tốt trả lời được

  1. Người mua thường quyết định điều gì?
  2. Mỗi quyết định cần bằng chứng gì, và cái nào bắt buộc?
  3. Bằng chứng đó có thể đến từ đâu, có hiển thị hoặc tính được không?
  4. Nên làm gì khi không có bằng chứng?

Bạn không cần làm về học máy mới đóng góp được.

Những đóng góp hữu ích gồm:

  • Thêm một yêu cầu

    Một câu hỏi mua hàng có thật mà ngành hàng còn thiếu.

  • Cải thiện công cụ cho tác tử

    Giúp tác tử truy vấn và đọc bằng chứng an toàn.

  • Thêm một kết nối

    Ánh xạ một nền tảng, PIM hoặc nguồn cấp vào Open Pulse.

  • Thêm ví dụ

    Dữ liệu tổng hợp hoặc chia sẻ an toàn được.

  • Cải thiện tài liệu

    Cho lập trình viên, người bán và chuyên gia.

  • Báo một mô hình sai

    "Người mua không chọn sản phẩm này như vậy" là một issue hữu ích.

Chuyên gia ngành cũng là người đóng góp.

Người hiểu nội thất, điện tử, làm đẹp hay linh kiện công nghiệp có thể biết rõ hơn người viết phần mềm về bằng chứng một quyết định cần. Nếu bạn biết những câu người mua hay hỏi, bạn có thể dạy hệ sinh thái cách ngành hàng đó được quyết định.

Tác tử AI có thể đề xuất, kèm duyệt.

Tác tử gặp rất nhiều câu hỏi chưa có lời đáp. Khi một tác tử phát hiện yêu cầu chưa mô hình nào có, nó có thể đề xuất. Con người duyệt trước khi bất cứ điều gì thay đổi.

  1. Người mua hỏi
  2. Tác tử thử quyết định
  3. Phát hiện một yêu cầu còn thiếu
  4. Tác tử đề xuất
  5. Con người duyệt
  6. Tri thức mở được cải thiện

Hãy mở issue trên GitHub trước. Điều khoản đóng góp đang được hoàn thiện, và chúng tôi sẽ công bố trước khi nhận các thay đổi lớn.

Open Pulse dành cho ai

  • Lập trình viên thương mại điện tử

    Cửa hàng, quy trình PIM và công cụ danh mục hiểu bằng chứng quyết định.

  • Lập trình viên tác tử AI

    Bằng chứng có cấu trúc, và cách an toàn để nói điều chưa biết.

  • Người bán và sàn

    Chất lượng dữ liệu đo bằng quyết định, không bằng số trường đã điền.

  • Đội PIM và danh mục

    Từ "trường đã điền chưa?" tới "bằng chứng này có giải quyết được quyết định không?"

  • Nhà nghiên cứu

    Yêu cầu mua hàng và độ phủ bằng chứng, trong cấu trúc tái lập được.

  • Chuyên gia ngành

    Tri thức về bằng chứng nào quan trọng trong một ngành hàng.

Open Pulse không phải là

  • Một bộ máy gợi ý sản phẩm
  • Công cụ tạo mô tả hay tạo thông tin sản phẩm
  • Thứ thay thế PIM
  • Giỏ hàng, giao thức thanh toán hay sàn thương mại
  • Lời hứa rằng mọi trường còn thiếu đều quan trọng
  • Hệ thống trả lời khi bằng chứng không đủ

Nhiều dữ liệu sản phẩm hơn không tự động là dữ liệu tốt hơn. Mục tiêu là bằng chứng giải quyết được quyết định thật.

Nguyên tắc mã nguồn mở của chúng tôi

  1. 01Bằng chứng trước câu trả lời. Biết điều gì ủng hộ một nhận định trước khi nói nó là sự thật.
  2. 02Nguồn gốc quan trọng. Nguồn của bằng chứng luôn kiểm tra được.
  3. 03Không trả lời là hợp lệ. Không đủ bằng chứng tốt hơn một điều bịa đặt đầy tự tin.
  4. 04Yêu cầu trước độ đầy đủ. Một trường quan trọng vì quyết định cần nó.
  5. 05Kết quả âm tính cũng được ghi lại. Thí nghiệm thất bại cũng là thông tin.
  6. 06Con người luôn tham gia. Tác tử đề xuất; con người duyệt.
  7. 07Định dạng mở để liên thông. Bằng chứng hiểu được giữa các hệ thống, không bị khoá trong Pulse.

Câu hỏi về Open Pulse

Bằng chứng quyết định là gì?

Các thông tin người mua cần để đưa ra một quyết định cụ thể, kèm nguồn của từng thông tin và việc người mua có thực sự thấy nó hay không. Dữ liệu sản phẩm cho biết điều được lưu; bằng chứng quyết định cho biết điều có thể quyết định.

Open Pulse có giống Pulse không?

Không. Open Pulse là nền tảng mở: SDK, máy chủ MCP, các ví dụ, và khi phát hành, các định dạng chung và tri thức ngành hàng. Pulse là nền tảng trả phí đo, ưu tiên, xác minh, theo dõi và vận hành Decision API.

Tác tử AI có dùng được Open Pulse không?

Có. Máy chủ MCP đã có: với API key, tác tử có thể hỏi lựa chọn nào đáp ứng yêu cầu của người mua và nhận fits, fails hoặc cannot tell, kèm điều còn thiếu. Không có key, nó vẫn tìm được trong tài liệu của chúng tôi.

Có dùng Open Pulse mà không cần Pulse API được không?

SDK và máy chủ MCP dùng giấy phép MIT, bạn có thể đọc, sửa và phát hành. Bản thân các quyết định đến từ Pulse API và cần key. Các định dạng và gói ngành hàng dự kiến sẽ dùng độc lập được.

Open Pulse có tạo ra thông tin sản phẩm còn thiếu không?

Không. Nó không bao giờ bịa ra thông tin chưa xác minh. Kích thước, chất liệu, khả năng tương thích, chứng nhận hay điều khoản bảo hành còn thiếu sẽ vẫn để trống cho tới khi có nguồn đáng tin.

Open Pulse có phải là PIM không?

Không. PIM lưu thông tin sản phẩm. Open Pulse tập trung vào mối liên hệ giữa yêu cầu mua hàng và bằng chứng giải quyết chúng, nên nó bổ trợ cho PIM.

Gói ngành hàng là gì?

Một định dạng dự kiến liệt kê các yêu cầu quan trọng với một loại sản phẩm và bằng chứng mỗi yêu cầu cần. Chuyên gia ngành sẽ cải thiện chúng qua GitHub.

Vì sao có "không sửa"?

Vì không phải khoảng trống nào cũng đáng thời gian kỹ thuật hay chi phí nội dung. Open Pulse mô tả được khoảng trống; Pulse giúp quyết định việc sửa có đáng chi phí không.

Cùng xây lớp bằng chứng cho thương mại AI.

Tác tử AI tìm nhanh hơn và so sánh nhiều sản phẩm hơn bất kỳ ai. Chúng vẫn cần bằng chứng đáng tin để biết một sản phẩm có thực sự đáp ứng quyết định trước mắt hay không. Nền tảng đó nên là mã nguồn mở.

Mở ngôn ngữ. Chia sẻ tri thức. Đo điều quan trọng.