Knowledge Graph là gì? Thực thể, Quan hệ và Bằng chứng

Knowledge Graph là gì?

Scrapeless Web Unlocker truy xuất nội dung web có thể cung cấp bằng chứng nguồn cho việc trích xuất thực thể và quan hệ trong một quy trình knowledge graph.

Knowledge Graph là gì?

Một knowledge graph biểu diễn các thực thể và các mối quan hệ giữa chúng dưới dạng mà các ứng dụng có thể truy vấn và diễn giải. Thực thể có thể là sản phẩm, tổ chức, địa điểm, tài liệu, hoặc khái niệm. Các mối quan hệ thể hiện những ý nghĩa cụ thể, như một sản phẩm được sản xuất bởi một tổ chức hoặc một tài liệu mô tả một sản phẩm. Graph trở nên hữu ích khi các danh tính và ý nghĩa đó nhất quán giữa các nguồn.

Một bản vẽ mạng lưới là hình ảnh trực quan của một graph, không phải định nghĩa của nó. Một knowledge graph hữu ích cũng cần các định danh, một mô hình các quan hệ được phép, bằng chứng cho các phát biểu của nó, và các quy tắc cho thay đổi. Nếu thiếu các yếu tố đó, việc nối các nhãn bằng mũi tên có thể che giấu sự mơ hồ thay vì giải quyết nó.

Tóm tắt

  • Danh tính của thực thể tách biệt với tên hiển thị. Tên giống nhau không chứng minh rằng các bản ghi mô tả cùng một sự vật.
  • Các mối quan hệ cần ý nghĩa được định nghĩa rõ. Một quan hệ người bán không được âm thầm trở thành quan hệ nhà sản xuất.
  • Các phát biểu trong graph cần bằng chứng và ngữ cảnh. Nguồn, thời gian, và phương pháp trích xuất ảnh hưởng đến cách một phát biểu nên được sử dụng.
  • Truy xuất và suy luận cần các kiểm soát khác nhau. Một quan hệ được tìm thấy và một quan hệ được suy ra phải có thể phân biệt được.

Thực thể và Quan hệ được biểu diễn như thế nào?

Một mô hình graph biểu diễn những thứ có thể nhận dạng và các liên kết có ý nghĩa giữa chúng. Trong một biểu diễn RDF, một phát biểu là một bộ ba subject, predicate và object. Các khái niệm và cú pháp trừu tượng của RDF định nghĩa cách các định danh, literal và triple tạo thành graph. Subject có thể định danh một sản phẩm, predicate có thể thể hiện nhà sản xuất của nó, và object có thể định danh một tổ chức.

Property graph thường biểu diễn node và quan hệ với các thuộc tính đi kèm. Một node sản phẩm có thể có tên hiển thị, trong khi một quan hệ có thể mang theo ngữ cảnh quan sát. Các mô hình này cung cấp các quy ước và công cụ khác nhau. Hãy lựa chọn dựa trên câu hỏi và yêu cầu trao đổi dữ liệu thay vì giả định rằng mọi knowledge graph đều phải dùng một biểu diễn duy nhất.

Giá trị literal và thực thể nên được tách biệt có chủ đích. Một con số giá là một giá trị. Một offer với người bán, thị trường, đơn vị tiền tệ và thời điểm quan sát có thể xứng đáng có danh tính riêng vì nhiều phát biểu phải tham chiếu đến cùng một đối tượng ngữ cảnh. Mô hình hóa offer một cách tường minh ngăn việc một con số trở thành một thuộc tính vĩnh viễn của sản phẩm.

Ontology hoặc Schema của Graph làm gì?

Schema hoặc ontology của graph định nghĩa các khái niệm và ý nghĩa của quan hệ để dữ liệu kết nối có thể được diễn giải. Hãy bắt đầu với các phân biệt mà ứng dụng thực sự cần. Sản phẩm, biến thể, offer, người bán và nhà sản xuất là các khái niệm khác nhau trong một catalog ngay cả khi trang nguồn trình bày chúng cùng nhau.

Hãy định nghĩa hướng quan hệ và các đích mong đợi. Một tổ chức bán một sản phẩm không nhất thiết là nhà sản xuất nó. Một trang đề cập đến một thương hiệu không thiết lập quyền sở hữu. Những phân biệt này là các yêu cầu ngữ nghĩa, và không có engine lưu trữ graph nào có thể suy ra chúng một cách an toàn chỉ từ một nhãn ở gần.

Các ràng buộc có thể biến kỳ vọng thành thứ có thể kiểm thử. Shapes Constraint Language có thể mô tả các yêu cầu đối với dữ liệu RDF, bao gồm số lượng thuộc tính và kiểu giá trị. Việc kiểm tra so với một shape xác lập sự phù hợp với shape đó. Nó không khẳng định rằng một tuyên bố trong thế giới thực là chính xác.

Giữ mô hình ban đầu đủ nhỏ để có thể rà soát. Một graph hẹp trả lời một câu hỏi đã xác định thì dễ bảo trì hơn một vốn từ vựng rộng mà các quan hệ của nó không có diễn giải nhất quán. Chỉ thêm khái niệm khi có một truy vấn thực tế hoặc yêu cầu bằng chứng đòi hỏi chúng.

Entity Resolution hoạt động như thế nào?

Entity resolution quyết định liệu các bản ghi nguồn khác nhau có đề cập đến cùng một thực thể trong thế giới thực hay không. Các định danh nguồn ổn định là điểm khởi đầu hữu ích, nhưng phạm vi của chúng phải được hiểu rõ. Một định danh listing có thể định danh một offer thay vì một sản phẩm. Một tên công ty có thể chỉ đến vài tổ chức không liên quan hoặc thay đổi theo thời gian.

Hãy dùng bằng chứng mạnh trước khi gộp thực thể. Một định danh sản phẩm tiêu chuẩn hóa, một domain tổ chức đã được xác minh, hoặc một ánh xạ nguồn được ghi chép có thể hỗ trợ việc khớp. Độ giống nhau của tên có thể giúp tìm ứng viên, nhưng không nên tự động quyết định danh tính. Hãy giữ lại các bản ghi gốc và lý do của việc ánh xạ.

Các khớp mơ hồ cần một trạng thái tường minh. Một khớp ứng viên có thể vẫn chưa được giải quyết trong khi thực thể nguồn vẫn có thể truy vấn dưới định danh riêng của nó. Điều này thường an toàn hơn so với việc buộc mọi bản ghi vào một thực thể hợp nhất và khiến việc chỉnh sửa sau này trở nên tốn kém.

Các thay đổi resolution nên có thể đảo ngược trong mô hình dữ liệu. Nếu hai sản phẩm bị gộp sai, graph phải lưu đủ tham chiếu nguồn để tách chúng ra. Lịch sử ánh xạ cũng giải thích vì sao một báo cáo trước đó nhóm các bản ghi khác đi.

Nội dung web có thể trở thành bằng chứng cho Graph như thế nào?

Một quy trình web-to-graph thu thập bằng chứng, trích xuất các phát biểu ứng viên, phân giải danh tính, xác thực cấu trúc, và chấp nhận các quan hệ đủ điều kiện. Hãy xem xét một nhiệm vụ minh họa về nghiên cứu sản phẩm–nhà cung cấp. Một trang nguồn đã được phê duyệt mô tả một sản phẩm và liệt kê một người bán. Bước thu thập giữ lại tham chiếu trang và ngữ cảnh quan sát. Bước trích xuất xác định nhãn quan hệ chính xác của nguồn trước khi có bất kỳ chuẩn hóa nào.

Scrapeless Web Unlocker hỗ trợ truy xuất tài liệu nguồn. Khả năng thu thập web và hiển thị nội dung không tự động biến văn bản trên trang thành các sự kiện đồ thị đã được kiểm chứng. Quy trình trích xuất và rà soát của bạn phải quyết định trang thực sự hỗ trợ điều gì.

Câu phát biểu ứng viên có thể nói rằng một ưu đãi được bán bởi một tổ chức. Không nên mở rộng để nói rằng tổ chức đó sản xuất sản phẩm trừ khi bằng chứng hỗ trợ cho tuyên bố riêng biệt đó. Lưu một liên kết bằng chứng hoặc đoạn trích được cho phép cùng với câu phát biểu, kèm phương pháp trích xuất và trạng thái chấp nhận.

Chuẩn bị nguồn rất quan trọng trước khi bất kỳ mô hình nào diễn giải nội dung. Quy trình AI training data pipeline mô tả con đường từ thu thập đến tập dữ liệu. Đối với việc xây dựng đồ thị, hãy điều chỉnh ranh giới đó để bảo toàn định danh thực thể và nguồn gốc câu phát biểu thay vì coi tất cả văn bản được trích xuất là đáng tin như nhau.

Tại Sao Nguồn Gốc và Thời Gian Lại Thiết Yếu?

Bản ghi nguồn gốc cho biết lý do một câu phát biểu trong đồ thị tồn tại và bằng chứng nào hỗ trợ nó. Họ PROV family of provenance models kết nối thông tin với các hoạt động và tác nhân chịu trách nhiệm tạo ra nó. Một quy trình làm việc đồ thị có thể sử dụng các ý tưởng này để phân biệt khẳng định từ nguồn, kết quả trích xuất và câu phát biểu đã được rà soát.

Đừng gộp mọi thời điểm vào một trường cập nhật. Một nguồn có thể mô tả một mối quan hệ đã áp dụng trong quá khứ. Trình thu thập của bạn có thể quan sát mô tả đó muộn hơn. Đồ thị của bạn có thể chấp nhận câu phát biểu còn muộn hơn nữa. Những thời điểm đó trả lời các câu hỏi khác nhau về tính hợp lệ, quan sát và xử lý.

Các câu phát biểu mâu thuẫn có thể cùng tồn tại với bằng chứng và trạng thái của chúng. Một nguồn có thể liệt kê một nhà cung cấp trước đây trong khi nguồn khác mô tả mối quan hệ hiện tại. Một truy vấn nên áp dụng chính sách thời gian và bằng chứng dự định thay vì tùy tiện chọn hàng được nạp sau cùng.

Giá trị độ tin cậy cần một cách diễn giải được xác định. Điểm số nội bộ của một mô hình không tự động là xác suất đã hiệu chỉnh rằng câu phát biểu là đúng. Nếu lưu trữ điểm số, hãy ghi lại cái gì đã tạo ra chúng và cách một bên sử dụng nên dùng chúng. Sự phê duyệt của con người là một trạng thái khác, không phải là bảo đảm số học về tính đúng đắn.

Đồ Thị Tri Thức Có Thể Trả Lời Những Câu Hỏi Nào?

Một đồ thị tri thức hỗ trợ các câu hỏi phụ thuộc vào mối quan hệ giữa các thực thể. Một nhóm quản lý danh mục có thể hỏi những ưu đãi nào tham chiếu đến các sản phẩm do một tổ chức cụ thể sản xuất, rồi nhóm các ưu đãi đó theo người bán và thị trường. Một hệ thống tài liệu có thể kết nối các tuyên bố với các trang và tổ chức hỗ trợ chúng.

Truy vấn đồ thị khớp với các mối quan hệ thực sự được biểu diễn. SPARQL graph pattern matching định nghĩa một ngôn ngữ truy vấn cho các đồ thị RDF. Truy vấn một đồ thị không tự động bổ sung các mối quan hệ còn thiếu hoặc bảo đảm rằng mọi thực thể liên quan đều đã được thu thập.

Suy diễn là một quyết định riêng biệt. Một luật có thể suy ra một mối quan hệ từ các câu phát biểu đã được chấp nhận, nhưng kết quả được suy ra vẫn phải lần vết được tới luật đó và các đầu vào của nó. Nếu một đầu vào bị rút lại hoặc sửa, các kết luận bị ảnh hưởng cần một lộ trình cập nhật được xác định.

Các mối quan hệ thiếu vắng cần được diễn giải cẩn thận. Một cạnh người bán vắng mặt có thể nghĩa là nguồn bỏ sót người bán, việc trích xuất không thể nhận dạng được, hoặc thực thể nằm ngoài phạm vi. Ứng dụng không nên coi mọi sự vắng mặt là một phủ định đã được chứng minh.

Đồ Thị So Với Bảng và Tìm Kiếm Vector Khác Nhau Như Thế Nào?

Đồ thị nhấn mạnh các mối quan hệ tường minh, bảng nhấn mạnh bản ghi có cấu trúc và phép nối, còn tìm kiếm vector nhấn mạnh sự tương đồng trong không gian embedding. Các khả năng này có thể bổ trợ cho nhau. Một đồ thị có thể xác định tổ chức mà một tài liệu mô tả, trong khi truy xuất vector tìm các đoạn liên quan từ tài liệu của tổ chức đó.

Hãy chọn đồ thị khi ý nghĩa, việc duyệt qua các mối quan hệ và định danh là trung tâm của câu hỏi. Một báo cáo trực tiếp trên các quan sát độc lập có thể đơn giản hơn dưới dạng bảng. Tìm kiếm tương đồng có thể tìm ngôn ngữ liên quan mà không thiết lập rằng hai thực thể là giống hệt nhau hoặc một mối quan hệ là đúng.

Chi phí vận hành còn bao gồm nhiều hơn cả việc thu thập. Scrapeless pricing giúp ước tính thành phần truy cập nguồn. Rà soát thực thể, bảo trì ánh xạ, lưu trữ bằng chứng và các hoạt động truy vấn cũng cần người phụ trách và ngân sách. Một đồ thị đã được chấp nhận nhỏ hơn có thể hữu ích hơn một đồ thị lớn chứa đầy các tuyên bố chưa được giải quyết.

Kết Luận

Xây dựng một đồ thị tri thức xoay quanh một câu hỏi đòi hỏi các mối quan hệ tường minh. Định nghĩa định danh thực thể, bảo toàn bằng chứng và định tính các câu phát biểu trước khi đưa chúng cho ứng dụng sử dụng. Đồ thị thu được nên giải thích cả những gì nó nói và lý do ứng dụng có quyền dựa vào nó.

Đưa Lớp Thu Thập Vào Thực Tiễn

Chọn khả năng thu thập Scrapeless phù hợp với nguồn của bạn, sau đó áp dụng các quyết định xác thực và vận hành được mô tả ở trên.

Đăng ký hôm nay và nhận $5 in free credit — không cần thẻ tín dụng.

Nhận $5 Credit của bạn →

FAQ

Đồ thị tri thức có phải là cơ sở dữ liệu đồ thị không?

Đồ thị tri thức là một biểu diễn các thực thể và mối quan hệ; cơ sở dữ liệu đồ thị là một cách để lưu trữ và truy vấn biểu diễn đó. Lựa chọn lưu trữ không cung cấp ngữ nghĩa hoặc bằng chứng còn thiếu.

Đồ thị tri thức có loại bỏ ảo giác (hallucination) không?

Không. Một đồ thị có thể cung cấp ngữ cảnh tường minh, có thể lần vết, nhưng các câu phát biểu của nó vẫn có thể sai, lỗi thời hoặc bị diễn giải sai. Ứng dụng phải xác thực bằng chứng và duy trì sự bất định.

Các tên tương tự có thể được gộp tự động không?

Chỉ độ tương đồng tên thôi là chưa đủ bằng chứng cho định danh. Hãy dùng nó để xác định các cặp ứng viên trùng khớp, rồi áp dụng các định danh mạnh hơn hoặc rà soát trước khi gộp thực thể.

Một cạnh bị thiếu có chứng minh mối quan hệ không tồn tại không?

Không. Một cạnh thiếu có thể phản ánh phạm vi hạn chế hoặc bằng chứng chưa được giải quyết. Một tuyên bố phủ định đòi hỏi một cách diễn giải tường minh và phạm vi hỗ trợ, chứ không chỉ là sự vắng mặt.

Tài liệu tham khảo