Hãy hình dung một màn hình back-office nhận các biên bản thăm để xếp vào hồ sơ. Biên bản O-035 nhắc đến thiết bị BX-07 và địa điểm Cèdre, nhưng không có số hồ sơ. Ứng dụng nhận bốn hồ sơ để lựa chọn. Nên gợi ý hồ sơ nào cho người phụ trách phân loại? Và quan trọng hơn: khi nào tốt hơn là không gợi ý gì?
Nếu phát triển ứng dụng web, có thể bạn đã giải quyết một phần vấn đề này bằng tìm kiếm văn bản và các phép nối. Nhưng hai hồ sơ có thể có cách diễn đạt giống hệt nhau, và một quan hệ đã biết với thiết bị không nhất thiết cho một khớp nối chắc chắn.
Vì vậy chúng ta sẽ so sánh nhiều cách tiếp cận: chỉ văn bản, một mạng nơ-ron không có quan hệ, rồi một mạng khai thác đồ thị, tức các đối tượng được liên kết với nhau. Ta sẽ đi theo chuỗi văn bản và quan hệ sẵn có → biểu diễn số → điểm của bốn ứng viên → đề xuất hoặc không đưa ra đề xuất.
Mục tiêu là hiểu ngữ cảnh thực sự mang lại điều gì mà không bí mật cung cấp sẵn đáp án cần tìm. Một mô hình vẫn thấy liên kết tài liệu–hồ sơ bị ẩn trong đầu vào không giải quyết vấn đề: nó chỉ đọc lại lời giải.
Hướng dẫn này tạo ra một đề xuất gắn kết, chứ không bao giờ là một gắn kết hành chính. Dữ liệu là dữ liệu tổng hợp. Kết quả mô tả giao thức r001, không phải xác nhận trên tài liệu của một doanh nghiệp.
Tải toàn bộ dự án, bản sửa đổi r001
Bắt đầu từ những gì thực sự có sẵn
Đồ thị không nhất thiết là một cơ sở dữ liệu mới
Một GED, hay hệ thống quản lý tài liệu điện tử, tổ chức các tài liệu, siêu dữ liệu và liên kết của chúng. Trong ví dụ này, một tài liệu là biên bản thăm; một hồ sơ tập hợp thông tin liên quan đến một vụ việc hoặc một lần can thiệp.
Để biểu diễn thế giới nhỏ này, mỗi đối tượng trở thành một nút: tài liệu, thiết bị, địa điểm hoặc hồ sơ. Một cạnh là quan hệ có hướng giữa hai nút. Loại của nó cho biết quan hệ này có ý nghĩa gì.
Ví dụ, ta biết O-035 — concerne → BX-07 và BX-07 — situé à → Cèdre. Theo cách nhìn của cơ sở dữ liệu quan hệ, đây giống các liên kết giữa bản ghi, với hướng và bản chất xác định. Dùng đồ thị trong phép tính không có nghĩa đoạn Python này cài đặt hay cần một cơ sở dữ liệu đồ thị: ở đây nó thao tác các bảng nút và quan hệ.
Liên kết ta muốn đề xuất thì khác: tài liệu O-035 nên được gắn với hồ sơ nào? Nó không được có sẵn trong các đầu vào dùng để trả lời.
Văn bản và các quan hệ đã quan sát được cung cấp cho chương trình. Hướng dẫn không chứng minh việc tự động trích xuất các quan hệ này từ PDF hoặc ghi chú tự do.
Xếp hạng bốn ứng viên, rồi quyết định có trả lời hay không
Bốn hồ sơ ứng viên cũng được cung cấp làm đầu vào. Chương trình không chọn chúng sau khi đã xem hồ sơ kỳ vọng. Đây là khác biệt quan trọng: tìm đáp án đúng trong bốn ứng viên đã biết không phải là tìm tự do trong toàn bộ GED.
Phép tính tạo ra bốn điểm. Hồ sơ xếp hạng cao nhất chỉ trở thành đề xuất khi điểm của nó vượt ngưỡng đã định; nếu không, chương trình sẽ không đưa ra đề xuất.
Hãy lấy một ví dụ điểm giả định, chỉ để hiểu quy tắc này: 0,64 ; 0,62 ; 0,21 ; 0,08. Với ngưỡng 0,60, hồ sơ đầu tiên được đề xuất. Tuy vậy, điểm của nó gần điểm của hồ sơ thứ hai. Quy tắc ở đây xem điểm cao nhất, không xem chênh lệch giữa hai điểm đứng đầu. Do đó, theo thiết kế nó không phát hiện mọi dạng mơ hồ.
Bốn giá trị này không nhất thiết là các xác suất cộng lại thành 1. Điểm 0,64 không có nghĩa là « 64 % khả năng việc gắn kết này đúng về mặt hành chính ». Chúng ta sẽ quay lại khác biệt giữa điểm và xác suất đã hiệu chỉnh.
Một quan hệ vắng mặt không tự động là sai
Trong một GED thực tế, liên kết thiếu có thể có nghĩa là « chưa được điền ». Nó không nhất thiết có nghĩa là « tài liệu này không thuộc hồ sơ đó ».
Ở đây tập dữ liệu tổng hợp có một lợi thế thực nghiệm: trình tạo của nó biết các tài liệu mà không ứng viên nào trong bốn ứng viên là đúng. Những trường hợp này được gọi là ngoài phạm vi. Chúng cho phép kiểm tra liệu chương trình có biết từ chối một yêu cầu không có đáp án tốt trong danh sách được đề xuất hay không.
Vì vậy phạm vi của việc từ chối chỉ mang tính cục bộ: « không có ứng viên tốt trong bốn hồ sơ này » không có nghĩa là « không có hồ sơ tốt nào trong doanh nghiệp ».
Tách toàn bộ các cụm độc lập, không chỉ các dòng dữ liệu
Tập dữ liệu gồm 80 cụm độc lập. Một cụm là nhóm nhỏ các nút và quan hệ không chia sẻ ngữ cảnh với các cụm khác. Phân chia giữ lại 56 cụm để huấn luyện, 12 để xác thực và 12 để kiểm thử.
Huấn luyện điều chỉnh các tham số của mạng. Xác thực, đặc biệt, dùng để chọn các ngưỡng. Sau đó kiểm thử đo hành vi của quy tắc đã chọn, không thay đổi quy tắc sau khi quan sát.
Các phân vùng không chia sẻ nút, cạnh, thiết bị hay địa điểm. Tuy nhiên, từ ngữ, loại tài liệu và mảnh câu vẫn có thể chung. Vì vậy ta kiểm thử trên định danh mới và ngữ cảnh đồ thị mới, chứ không nhất thiết trên từ vựng hoàn toàn mới.
Mỗi cụm có bốn hồ sơ. Với mỗi hồ sơ, sáu liên kết với tài liệu vẫn hiển thị làm ngữ cảnh và sáu liên kết khác bị che vĩnh viễn. Bốn tài liệu bổ sung không có hồ sơ ứng viên nào đúng. Chi tiết các tài liệu như sau:
| Tài liệu trong một cụm | Tính từ giao thức | Số lượng |
|---|---|---|
| Tài liệu có gắn kết hiển thị | 4 hồ sơ × 6 tài liệu | 24 |
| Tài liệu có gắn kết bị che | 4 hồ sơ × 6 tài liệu | 24 |
| Tài liệu không có ứng viên tốt | Do trình tạo thêm vào | 4 |
| Tổng số tài liệu | 24 + 24 + 4 | 52 |
Điểm cần lưu ý về cách đếm r001. Mô tả gốc nêu « 80 cụm độc lập gồm 52 nút », đồng thời công bố 5 600 nút, trong đó 4 160 là tài liệu. Các cách diễn đạt này không khớp: 80 × 52 = 4 160, không phải 5 600. Chi tiết trên cho thấy 52 tài liệu mỗi cụm, tức 4 160 tài liệu. Tổng số 5 600 nút được giữ nguyên, nhưng phát biểu « 52 nút mỗi cụm » cần được kiểm tra trong tập dữ liệu đã tạo. Phép tính này không phải là một lần đếm mới các tệp dự án.
Cho cả xác thực lẫn kiểm thử, các đích là 24 tài liệu có liên kết bị che và bốn tài liệu ngoài phạm vi của từng cụm trong 12 cụm. Điều này cho 12 × 24 = 288 trường hợp có thể gắn kết và 12 × 4 = 48 trường hợp ngoài phạm vi, tức 336 đích mỗi phân vùng. 24 tài liệu có liên kết hiển thị trong mỗi cụm vẫn là ngữ cảnh: chúng không trở thành đáp án để chấm.
Che đáp án theo cả hai chiều
Giả sử gắn kết đã biết được biểu diễn cả bằng pièce → dossier và quan hệ ngược dossier → pièce. Chỉ bỏ cạnh đầu tiên vẫn sẽ để cùng thông tin sẵn có theo chiều kia.
Vì vậy quy trình loại bỏ cả hai hướng của mỗi liên kết bị che trước khi suy luận. Suy luận đơn giản là dùng mô hình để tính một dự đoán sau khi huấn luyện.
Cần đồng thời tính lại bậc, tức số quan hệ dùng để chuẩn hóa các thông điệp. Giữ một bộ đếm cũ sẽ lưu lại dấu vết của đồ thị chưa che, ngay cả sau khi đã bỏ các cạnh. Cả lân cận lẫn bậc đều phải xuất phát từ đồ thị thực sự được phép dùng.
Biện pháp này không loại bỏ các manh mối hợp lệ: thiết bị và địa điểm vẫn có sẵn theo giao thức. Nó ngăn quan hệ đích vẫn được cung cấp, trực tiếp hoặc thông qua một phép tính đã thực hiện trước khi loại bỏ.
Biến văn bản thành vectơ với E5
Mô hình multilingual-e5-small, tại commit 614241f622f53c4eeff9890bdc4f31cfecc418b3, biến văn bản thành các embedding. Embedding là một danh sách số biểu diễn văn bản cho các phép tính tương đồng. Ở đây, mỗi danh sách có 384 giá trị float32, các số thực dấu phẩy động lưu trên 32 bit.
384 vị trí này không phải 384 trường nghiệp vụ mà ta đặt tên là « địa điểm », « thiết bị », v.v. Chúng là các đặc trưng do bộ mã hóa học được. Bộ mã hóa tạo ra một biểu diễn số; nó không soạn câu trả lời hội thoại.
Các vectơ được chuẩn hóa theo L2: ta chia mỗi vectơ cho độ dài của nó. Trong ví dụ sư phạm hai chiều, [3 ; 4] có độ dài 5 và trở thành [0,6 ; 0,8]. Nhờ đó văn bản được so sánh theo hướng của biểu diễn thay vì chỉ theo biên độ.
Tất cả đều nhận tiền tố nguyên văn query: , kể cả văn bản của hồ sơ, cho biểu diễn đối xứng này. Tài liệu E5 của bản sửa đổi được dùng mô tả lựa chọn này cho các tác vụ đối xứng và việc dùng embedding làm đặc trưng.
Quy trình từ chối trung bình rỗng, không hữu hạn hoặc bằng không, và thất bại vượt quá 512 token. Token là đơn vị văn bản do mô hình xử lý, không nhất thiết là cả một từ. Không như xử lý âm thầm cắt phần cuối, giới hạn này trở thành lỗi rõ ràng.
E5 được đóng băng trong quá trình huấn luyện: các tham số của nó không thay đổi. Ta học các biến đổi sử dụng vectơ của nó, chứ không học bộ mã hóa văn bản mới. Định danh hồ sơ không bao giờ thành embedding được học riêng lẻ; chỉ số đồ thị dùng để tìm các dòng bảng, không phải để ghi nhớ một vectơ có thể huấn luyện cho từng hồ sơ.
Truyền đúng ngữ cảnh
Một lớp đồ thị: đọc các nút lân cận mà không quên văn bản của chính nó
Một R-GCN, viết tắt của Relational Graph Convolutional Network, là mạng nơ-ron kết hợp biểu diễn của các nút với biểu diễn của các nút lân cận, đồng thời phân biệt các loại quan hệ. Bài báo nền tảng về R-GCN trình bày nguyên lý này cho đồ thị đa quan hệ.
Trực giác gần với phép nối rồi nhóm: với một nút đích, ta tìm các nút lân cận, nhóm vectơ của chúng theo loại quan hệ và tính trung bình. Sau đó một biến đổi đã học xử lý từng trung bình.
Tại sao giữ các loại? Vì « liên quan đến thiết bị » và « nằm tại địa điểm » không mô tả cùng một liên kết. Biến thể có kiểu có thể học các xử lý khác nhau. Điều đó cho nó thêm một khả năng, không phải bảo đảm đưa ra đề xuất tốt hơn.
Với từng đích và từng quan hệ, lớp thực hiện bốn thao tác: cộng các vectơ nguồn, chia tổng này cho số cạnh hiển thị tương ứng, áp dụng ma trận của quan hệ đó, rồi cộng tất cả vào một phép chiếu của chính nút. Một kích hoạt ReLU kết thúc phép tính: nó thay các giá trị âm bằng 0.
Có thể tóm tắt cơ chế như sau: biểu diễn mới = ReLU(văn bản nút đã biến đổi + đóng góp đã biến đổi từ các nút lân cận).
Đọc các chiều trước các phép toán
Ở đây, tensor là một bảng số. Với N nút và E cạnh đã quan sát, lớp đầu tiên thao tác các chiều sau:
| Đối tượng mã | Dạng và ý nghĩa |
|---|---|
features |
N × 384 : một vectơ mỗi nút |
edges |
E × 3 : nguồn, đích, loại quan hệ |
relation_weights |
8 × 384 × 64 trong lớp có kiểu đầu tiên |
| Đầu ra của lớp | N × 64 : cùng các nút, với các vectơ mới |
Một ma trận là bảng hai chiều. Một phép chiếu tuyến tính kết hợp các giá trị đầu vào với trọng số đã học để tạo vectơ có kích thước mong muốn. Chuyển từ 384 sang 64 chiều không loại bỏ nút: nó thay đổi độ dài biểu diễn của từng nút.
Dự án xếp chồng hai lớp: 384 → 64, rồi 64 → 64. Sau một lớp, nút có thể dùng thông tin từ các nút lân cận trực tiếp; sau hai lớp, nó cũng có thể nhận thông tin đi qua một nút trung gian, tùy các hướng thực sự hiện có. Điều này không đồng nghĩa đọc tức thời mọi đường đi của một đồ thị lớn.
Mã được thực thi: một trung bình cho mỗi đích và mỗi quan hệ
Đây là trích đoạn của quy trình r001. Hãy đọc forward() trước, nơi thực hiện phép tính; sau đó ta sẽ quay lại phần khởi tạo.
import torch
from torch import nn
import torch.nn.functional as F
class RelationalLayer(nn.Module):
def __init__(self, inputs, outputs, relations, layer, seed=17):
super().__init__()
self.self_projection = nn.Linear(inputs, outputs, bias=False)
self.relation_weights = nn.Parameter(torch.empty(relations, inputs, outputs))
self.relations = relations
nn.init.xavier_uniform_(
self.self_projection.weight,
generator=torch.Generator().manual_seed(seed + layer),
)
for r in range(relations):
nn.init.xavier_uniform_(
self.relation_weights[r],
generator=torch.Generator().manual_seed(seed + 100 + layer * 20 + r),
)
def forward(self, features, edges):
if edges.ndim != 2 or edges.shape[1] != 3 or edges.dtype != torch.long:
raise ValueError("Edges are source,target,relation integer rows")
if len(edges) and (
(edges[:, :2] < 0).any()
or (edges[:, :2] >= len(features)).any()
or (edges[:, 2] < 0).any()
or (edges[:, 2] >= self.relations).any()
):
raise ValueError("Invalid observed edge")
result = self.self_projection(features)
for r in range(self.relations):
selected = edges[edges[:, 2] == r]
source = selected[:, 0]
target = selected[:, 1]
aggregate = torch.zeros_like(features)
degree = torch.zeros(
len(features), dtype=features.dtype, device=features.device
)
# Every degree and message uses only this currently observed relation.
aggregate.index_add_(0, target, features[source])
degree.index_add_(
0,
target,
torch.ones(len(source), dtype=features.dtype, device=features.device),
)
aggregate = aggregate / degree.clamp_min(1)[:, None]
result = result + aggregate @ self.relation_weights[r]
return F.relu(result)
Kiểm tra đầu vào yêu cầu một bảng cạnh hai chiều, có ba cột và kiểu số nguyên torch.long. Chỉ số nút phải tương ứng với các dòng hiện có của features, còn chỉ số quan hệ phải nằm trong khoảng dự kiến. Một cạnh trỏ tới nút không tồn tại bị từ chối trước khi tham gia phép tính.
Phép chiếu riêng bắt đầu bằng self.self_projection(features). Nhờ vậy mỗi nút giữ một đóng góp từ chính đặc trưng của nó, kể cả khi không nhận thông điệp nào. Tùy chọn bias=False nghĩa là lớp tuyến tính PyTorch này không thêm một hằng số được học vào phép biến đổi.
Lọc theo quan hệ được thực hiện bằng edges[edges[:, 2] == r]. Với loại hiện tại, source cho các dòng cần đọc và target cho các dòng đích. Các quan hệ khác không bị trộn vào trung bình này.
Cộng các thông điệp dùng aggregate.index_add_(0, target, features[source]). Hãy hình dung một GROUP BY destination cộng các vectơ thay vì một cột số tiền. Nếu nhiều nguồn có cùng đích, giá trị của chúng được cộng vào cùng dòng. Hậu tố _ ở đây cho biết tensor tích lũy bị sửa tại chỗ. Tài liệu index_add_ mô tả thao tác này.
Một index_add_ thứ hai cộng các 1 vào những đích đó. Nó thu được bậc cho quan hệ này và đồ thị đã quan sát này, không phải bậc lấy trước khi che.
Phép chia biến mỗi tổng thành trung bình. degree.clamp_min(1) thay bậc bằng 0 bằng 1 để tránh chia cho 0. Điều này không tạo nút lân cận giả: tổng rỗng vẫn bằng 0, và 0 / 1 vẫn bằng 0. [:, None] đặt bậc ở dạng cột để chia mọi thành phần của một nút cho cùng một số.
Biến đổi quan hệ diễn ra với aggregate @ self.relation_weights[r]. Ký hiệu @ là phép nhân ma trận. Đóng góp đã biến đổi được cộng vào kết quả, rồi F.relu(result) kết thúc lớp.
Lớp khởi tạo các ma trận bằng Xavier và các hạt giống được xác định bởi seed, lớp và quan hệ. Hạt giống đặt điểm khởi đầu của một bộ sinh giả ngẫu nhiên. Nó giúp kiểm soát khởi tạo; tự nó không thay thế tất cả kiểm tra cần thiết để tái lập.
Một phép tính nhỏ để kiểm tra tác dụng của mặt nạ
Hãy lấy ví dụ sư phạm hai chiều, độc lập với kết quả tập dữ liệu. Hai nút lân cận gửi [2 ; 4] và [6 ; 0] đến cùng một đích, theo cùng một quan hệ.
Tổng là [8 ; 4], bậc là 2 và trung bình là [4 ; 2]. Nếu ma trận quan hệ được chọn cho ví dụ này giữ thành phần đầu và nhân đôi thành phần thứ hai, đóng góp của nó thành [4 ; 4]. Với phép chiếu riêng bằng [1 ; −1], tổng là [5 ; 3], không thay đổi bởi ReLU.
Bây giờ hãy bỏ cạnh thứ hai. Trung bình đúng là [2 ; 4] / 1 = [2 ; 4]. Dùng lại bậc cũ 2 sẽ cho [1 ; 2]: biểu diễn vẫn phụ thuộc vào nút lân cận đã bị bỏ qua bộ đếm cũ của nó.
Nếu bỏ tất cả cạnh, đóng góp của các nút lân cận trở thành 0, nhưng đầu ra không nhất thiết vậy. Phép chiếu riêng của ví dụ này vẫn là [1 ; −1], rồi ReLU cho [1 ; 0].
Hai giới hạn khác có thể thấy trong trích đoạn. Nó không biết các chú thích bị che: việc bỏ liên kết đích phải diễn ra trước lời gọi. Và nó không khử trùng lặp các cạnh: cùng một dòng lặp lại góp nhiều lần vào tổng và bậc. Vì vậy tính hợp lệ của chỉ số không đủ để bảo đảm chất lượng đồ thị được cung cấp.
Từ vectơ đến điểm, rồi so sánh các biến thể
Sau hai lớp, chương trình so sánh biểu diễn của tài liệu với mỗi hồ sơ bằng một điểm song tuyến tính. Nguyên lý là kết hợp hai vectơ với trọng số đã học để tạo một số tương thích. Từ « song tuyến tính » mô tả phép tính; nó không có nghĩa quan hệ nghiệp vụ đã được chứng minh. Trích đoạn trên cho thấy lớp quan hệ, không phải toàn bộ đầu điểm hay toàn bộ vòng lặp huấn luyện trong ZIP.
Các điểm nơ-ron dùng cho quyết định đi qua một sigmoid, hàm biến điểm thô thành giá trị giữa 0 và 1. Nó bằng 0,5 khi điểm thô bằng 0 và tăng theo điểm này. Định nghĩa của nó trong PyTorch bổ sung cơ chế đó. Áp dụng sigmoid không chứng minh các giá trị thu được là xác suất gắn kết đáng tin cậy.
So sánh phân biệt bốn cách tiếp cận. Cosine E5 so sánh trực tiếp các vectơ văn bản đã chuẩn hóa: đây là mốc chỉ văn bản, không phải công cụ từ khóa đơn giản. mlp bỏ các cạnh và giữ một mạng biến đổi đặc trưng nút. untyped dùng các cạnh nhưng gom mọi loại thành một quan hệ duy nhất. Cuối cùng, typed áp dụng tám biến đổi quan hệ riêng biệt.
Các biến thể dùng lại cùng ứng viên, cùng vectơ E5 và cùng mặt nạ. Số tham số của chúng không hoàn toàn giống nhau. Vì vậy ta so sánh các lựa chọn trên một tập dữ liệu cụ thể, không tự động quy mọi khác biệt cho riêng việc phân loại quan hệ.
Thực hiện mọi bước theo đúng thứ tự
Chuẩn bị môi trường
Bạn cần có thể đọc Python, dùng terminal và chạy Docker. Các thao tác số cần thiết vừa được giới thiệu: bảng, trung bình, ma trận và điểm. Không cần từng phát triển một mạng đồ thị.
Giải nén ZIP vào một thư mục mới và mở terminal tại thư mục gốc. Mọi lệnh sau đây đều chạy từ thư mục này. Hãy dùng cấu hình GPU mà dự án quy định. Trước khi chạy, xem README của dự án để biết tài nguyên cần thiết và điều kiện cài đặt.
Preflight kiểm tra Docker, Compose, GPU, bộ nhớ và dung lượng trống. setup.sh chuẩn bị dự án; sau đó Compose kiểm tra cấu hình và xây dựng các dịch vụ.
sh scripts/preflight.sh
sh scripts/setup.sh
docker compose config --quiet
docker compose build acquisition tutorial learning inference calibration
Hãy kiểm tra chẩn đoán trước khi tiếp tục. Lỗi môi trường không được giải quyết bằng cách sửa mô hình hoặc thay đổi ngưỡng của nó.
Tải E5, rồi xác minh một phép tính thực trong Docker
Dịch vụ acquisition tải chín tệp E5 đã khóa, được kiểm soát theo kích thước và dấu vân tay SHA-256. Dấu vân tay cho phép kiểm tra danh tính tệp đã tải, không phải chất lượng dự đoán của chúng.
docker compose run --rm acquisition python scripts/acquire.py --config configs/minimum.yaml
docker compose run --rm tutorial python scripts/check_environment.py
docker compose run --rm tutorial python -m pytest -q
check_environment.py chạy E5 trong Docker. Thấy GPU bằng nvidia-smi trên máy chủ không chứng minh phép tính được chứa này hoạt động. Sau đó pytest -q chạy các kiểm thử của dự án. Hãy xác minh chúng thành công trước khi tiếp tục: kiểm thử chương trình và phép đo chất lượng đề xuất không kiểm tra cùng một thứ.
Các dịch vụ tính toán không tải trình điều khiển nào và không mở cổng máy chủ nào. Lắp một môi trường tính toán và chạy một API công khai là hai chủ đề khác nhau.
Xây dữ liệu và quan sát đầu vào
docker compose run --rm tutorial python -m ged_rattachement_graphe.cli prepare --config configs/minimum.yaml
docker compose run --rm inference python -m ged_rattachement_graphe.cli encode --config configs/minimum.yaml
docker compose run --rm inference python -m ged_rattachement_graphe.cli baseline --config configs/minimum.yaml
docker compose run --rm inference python -m ged_rattachement_graphe.cli inspect-mechanism --config configs/minimum.yaml
prepare xây dựng tập dữ liệu. Đây là lúc kiểm tra các cụm, phân vùng và số lượng, nhất là khác biệt giữa tài liệu và toàn bộ nút. encode tính vectơ E5. Mốc baseline làm điểm so sánh văn bản, rồi inspect-mechanism cho phép xem cơ chế trước khi huấn luyện các biến thể.
Với một tài liệu như O-035, hãy tự hỏi ba câu khi kiểm tra đầu vào: bốn ứng viên là gì? Quan hệ nào đang hiển thị? Liên kết cần dự đoán, chiều ngược của nó, hay bậc được tính trước khi bỏ nó vẫn còn không? Một ví dụ được kiểm tra thường hữu ích hơn điểm tổng hợp hiển thị quá sớm.
Huấn luyện các biến thể và cố định quyết định
sh scripts/train_variants.sh
docker compose run --rm calibration python -m ged_rattachement_graphe.cli calibrate --config configs/minimum.yaml
docker compose run --rm tutorial python -m ged_rattachement_graphe.cli evaluate --config configs/minimum.yaml
train_variants.sh chạy typed, untyped và mlp. calibrate chọn ngưỡng trên xác thực, rồi evaluate đo kết quả bằng quy tắc đã cố định này.
Ở mỗi epoch, tức mỗi lượt học trên các ví dụ đã định, ba trong sáu liên kết hiển thị của mỗi hồ sơ huấn luyện bị che tạm thời, cùng với các chiều ngược của chúng. Mạng phải học mà không có liên kết đã bỏ đó trong ngữ cảnh trực tiếp. Các liên kết bị che vĩnh viễn thì không bao giờ được đưa lại.
Hãy phân biệt rõ hai cơ chế này: che tạm thời tạo tình huống huấn luyện từ ngữ cảnh được phép; che vĩnh viễn duy trì sự tách biệt của giao thức. Không cơ chế nào được hoàn tác để cải thiện dự đoán một cách giả tạo.
Dự án huấn luyện trong ba mươi epoch, với bốn cụm mỗi batch. Batch là nhóm ví dụ được xử lý cho một bước học. Bộ tối ưu AdamW dùng tốc độ học 0,003, weight decay 0,001 và clipping chuẩn 1.
Một bộ tối ưu điều chỉnh trọng số từ gradient, tức thay đổi của lỗi theo các trọng số đó. Tốc độ học điều chỉnh biên độ cập nhật; weight decay giảm trọng số theo quy tắc AdamW; clipping giới hạn chuẩn của gradient quá lớn. Tài liệu AdamW giải thích sâu hơn vai trò của bộ tối ưu. Các thiết lập này nhận diện thí nghiệm, không hứa hẹn thành công.
Tiếp tục huấn luyện không chỉ là nạp lại trọng số
Quy trình dự kiến dừng sau mười hai epoch, rồi tiếp tục và phải tìm lại chính xác đường chạy liên tục. Checkpoint, hay điểm lưu, giữ trọng số, bộ tối ưu, sampler quyết định thứ tự ví dụ và trạng thái các bộ sinh ngẫu nhiên.
Chỉ nạp lại trọng số có thể cho một mô hình giống mô hình đã dừng mà không tái tạo các cập nhật tiếp theo. Đó là lý do kiểm tra so sánh các trạng thái cần thiết để tiếp tục, chứ không chỉ một chỉ số cuối gần giống.
Yêu cầu này vẫn phụ thuộc vào môi trường. Tài liệu PyTorch về khả năng tái lập cảnh báo rằng kết quả giống hệt không được bảo đảm giữa các phiên bản và nền tảng; index_add_ cũng có lưu ý liên quan đến CUDA. Vì vậy một hạt giống cố định không đủ để công bố khả năng tái lập phổ quát. Hãy giữ các phiên bản ZIP và kiểm tra kết quả các kiểm soát tiếp tục.
Đọc chỉ số trước khi đọc con số
Trước hết: hồ sơ đúng có được xếp hạng tốt không?
Top-1 đo tỷ lệ tài liệu có thể gắn kết mà hồ sơ đúng đứng đầu. MRR, viết tắt của Mean Reciprocal Rank, là trung bình các nghịch đảo thứ hạng của hồ sơ đúng. Nó không phải thứ hạng trung bình, cũng không phải nghịch đảo của thứ hạng trung bình.
Nếu hai tài liệu có hồ sơ đúng ở hạng 1 và 2, Top-1 là 1 / 2 = 0,50. MRR là (1/1 + 1/2) / 2 = 0,75. Nghịch đảo của thứ hạng trung bình sẽ là 1 / 1,5, xấp xỉ 0,667: đó là một phép tính khác.
Trong hướng dẫn này, hai chỉ số đó áp dụng cho 288 tài liệu có ứng viên tốt, ngay cả khi ngưỡng sau đó dẫn đến không đưa ra đề xuất cho một số tài liệu. Chúng đo xếp hạng, không phải số đề xuất gửi cho người dùng.
Tiếp theo: đề xuất nào được đưa ra, và đề xuất nào đúng?
Độ chính xác được chấp nhận đếm đề xuất đúng trong số đề xuất thực sự được đưa ra. Độ bao phủ đếm đề xuất được đưa ra trong 336 đích, dù đúng hay sai. Tỷ lệ thu hồi từ chối đếm các trường hợp ngoài phạm vi bị từ chối trong 48 trường hợp ngoài phạm vi.
Cuối cùng, tỷ lệ quyết định đúng tổng thể cộng các đề xuất đúng và các từ chối đúng rồi chia cho 336. Không đưa ra đề xuất cho một tài liệu có ứng viên tốt không được tính là quyết định tốt trong phép tính này.
Hãy lấy ví dụ giả định mười tài liệu: tám tài liệu có hồ sơ đúng, hai tài liệu không có. Chương trình đưa ra sáu đề xuất, năm đề xuất đúng, và từ chối bốn tài liệu, trong đó có hai trường hợp ngoài phạm vi.
Độ chính xác được chấp nhận của nó là 5/6 ≈ 0,8333, độ bao phủ 6/10 = 0,60, tỷ lệ thu hồi từ chối 2/2 = 1, và tỷ lệ tổng thể (5 + 2)/10 = 0,70. Nó từ chối hoàn hảo các trường hợp ngoài phạm vi, nhưng cũng từ chối hai tài liệu lẽ ra có thể gắn kết. Vì vậy một chỉ số từ chối tốt không đủ mô tả toàn bộ hành vi.
Nếu không có đề xuất nào, độ chính xác được chấp nhận là không xác định: không có mẫu số. Theo quy ước nó không trở thành 1. Tương tự, độ bao phủ cao không có nghĩa các hồ sơ được đề xuất là đúng.
Chọn ngưỡng mà không điều chỉnh kiểm thử sau sự kiện
Quy trình khảo sát các ngưỡng chỉ trên tập xác thực. Với cosine, lưới chạy từ −1 đến 1 với bước 0,01. Với điểm sigmoid, lưới chạy từ 0 đến 1 với bước 0,05.
Khi hòa, quy tắc giữ giá trị gần 0 cho cosine hoặc gần 0,5 cho sigmoid, rồi giữ ngưỡng thấp hơn. Cách phân xử này được cố định trước khi đọc kiểm thử. Bài viết không tái hiện tiêu chí tối ưu hóa đầy đủ của calibrate: hãy xem phần cài đặt trong ZIP thay vì suy ra một mục tiêu không được nêu.
Từ calibration ở đây chỉ việc chọn ngưỡng. Nó không đủ để xác lập hiệu chỉnh xác suất, vốn cần kiểm tra liệu mức tin cậy được thông báo có tương ứng với tần suất thành công quan sát được không. Tài liệu scikit-learn về hiệu chỉnh xác suất giải thích khác biệt này; đây không phải bước bổ sung do dự án thực hiện.
Khi ngưỡng đã chọn, kiểm thử mô tả quy tắc có sẵn đó. Thay đổi nó vì một con số kiểm thử không vừa ý sẽ làm mất sự tách biệt này.
Kết quả quan sát được và phạm vi của chúng
Xếp hạng vẫn giống nhau
Trên 336 đích kiểm thử, mọi biến thể chính đều đạt Top-1 = 0,50 và MRR = 0,75 trên 288 trường hợp có thể gắn kết. Vì vậy đồ thị có kiểu không làm tốt hơn các phương pháp khác trong việc đưa hồ sơ đúng lên hạng nhất ở lần tái hiện này.
Đừng nhầm nhận định này với việc hoàn toàn không có khác biệt. Quy tắc đề xuất và từ chối có thể thay đổi, kể cả khi xếp hạng không cải thiện.
Tái dựng các quyết định của đồ thị có kiểu
Với ngưỡng xác thực 0,40, typed chấp nhận 288 đích, đề xuất đúng 144 và từ chối 48 trường hợp ngoài phạm vi.
Các số lượng giúp đọc chỉ số mà không cần thuật ngữ: độ chính xác được chấp nhận là 144/288 = 0,50, độ bao phủ là 288/336 = 0,857143, và tỷ lệ tổng thể là (144 + 48)/336 = 0,571429. Tỷ lệ thu hồi từ chối là 48/48 = 1.
Vì vậy chương trình không đề xuất hồ sơ sai cho 48 tài liệu ngoài phạm vi, nhưng một nửa trong 288 đề xuất được đưa ra vẫn sai. Từ chối hoàn hảo trên quần thể này không làm xếp hạng đáng tin cậy.
So sánh mà không gán cho đồ thị một lợi ích nó không chứng minh
Cosine dùng ngưỡng 0. untyped dùng 0,30 và có cùng số lượng như typed. Kết quả công bố không nêu ngưỡng của MLP; bảng so sánh các quyết định được báo cáo mà không gán cho nó một ngưỡng bổ sung.
Trên thiết bị di động, hãy cuộn ngang bảng.
| Phương pháp | Đề xuất được đưa ra | Đề xuất đúng | Ngoài phạm vi bị từ chối, trên 48 | Độ chính xác được chấp nhận | Tỷ lệ đúng tổng thể |
|---|---|---|---|---|---|
| Cosine E5, chỉ văn bản | 336 | 144 | 0 | 0,428571 | 0,428571 |
mlp, không cạnh |
287 | 143 | 47 | 0,498258 | 0,565476 |
untyped, một quan hệ duy nhất |
288 | 144 | 48 | 0,50 | 0,571429 |
typed, các quan hệ được phân biệt |
288 | 144 | 48 | 0,50 | 0,571429 |
Với cosine, chấp nhận cả 336 đích cũng có nghĩa đề xuất một hồ sơ cho 48 tài liệu không có hồ sơ nào đúng trong danh sách. Do đó độ chính xác là 144/336 = 0,428571. Đồ thị có kiểu ở đây cải thiện việc từ chối so với mốc này, không phải Top-1 hay MRR.
Kết quả MLP cũng đáng chú ý. Với 287 đề xuất, nó từ chối 336 − 287 = 49 tài liệu. Trong số đó, 47 là ngoài phạm vi: vì vậy hai tài liệu còn lại có ứng viên tốt. Chi tiết này là suy luận số học từ các số lượng đã công bố, không phải phân tích mới các dự đoán riêng lẻ.
Tỷ lệ tổng thể của nó được giải thích bởi (143 + 47)/336 = 0,565476. Nó gần với tỷ lệ của các đồ thị. Vì vậy không thể gán toàn bộ chênh lệch với cosine chỉ cho ngữ cảnh quan hệ, cũng không thể tuyên bố phân biệt các loại quan hệ nhất thiết cải thiện kết quả.
Kết quả cần nhớ có giới hạn nhưng rõ ràng: các đồ thị được nghiên cứu từ chối trường hợp ngoài phạm vi tốt hơn chỉ văn bản trong giao thức này, mà không xếp hạng hồ sơ tốt hơn. Những chỉ số trên dữ liệu tổng hợp này không xác nhận gắn kết nghiệp vụ cũng không xác nhận đóng góp nhân quả của một quan hệ nhất định.
Bài tập: kiểm tra giả thuyết trước khi sửa nó
Dự đoán tác động trước khi đo
Hãy quay lại O-035. Ta có văn bản của nó và một quan hệ với BX-07. Nếu kênh quan hệ này cung cấp thông tin hữu ích, điều gì sẽ xảy ra khi bỏ nó? Xếp hạng có thay đổi không? Số đề xuất có ít hơn không? Các lần từ chối sẽ tốt hơn hay kém hơn?
Hãy viết giả thuyết trước khi thực thi. Tác động có thể dương, bằng không hoặc âm. Một liên kết có vẻ hữu ích trực giác không nhất thiết cải thiện hành vi được đo.
Bỏ một kênh ngữ cảnh để quan sát vai trò của nó là một ablation. Ở đây thí nghiệm không chỉ xóa cạnh trong mô hình đã huấn luyện: nó huấn luyện biến thể no-equipment trong ba mươi epoch, với cùng ứng viên và cùng vectơ E5. Ngưỡng của nó lại được chọn trên xác thực.
Đây là so sánh các biến thể được huấn luyện lại, không phải nhiễu loạn phút chót đơn giản ở đầu vào của mô hình cố định. Vì văn bản vẫn được giữ, bỏ liên kết tài liệu–thiết bị không nhất thiết loại bỏ phần văn bản nhắc đến thiết bị.
Chạy biến thể và đánh giá của nó
docker compose run --rm learning python -m ged_rattachement_graphe.cli exercise --config configs/minimum.yaml
docker compose run --rm inference python -m ged_rattachement_graphe.cli predict --config configs/minimum.yaml --variant no-equipment --mode continuous
docker compose run --rm calibration python -m ged_rattachement_graphe.cli calibrate-exercise --config configs/minimum.yaml
docker compose run --rm tutorial python -m ged_rattachement_graphe.cli evaluate-exercise --config configs/minimum.yaml
exercise thực hiện thí nghiệm đã định, predict tạo đầu ra của no-equipment, rồi calibrate-exercise và evaluate-exercise áp dụng cùng sự tách biệt xác thực/kiểm thử. Các đầu ra ban đầu vẫn được bảo vệ bằng hash: bài tập không được âm thầm ghi đè mốc so sánh.
So sánh với các quan sát được cung cấp
Trong kết quả r001, no-equipment đưa ra 287 đề xuất, trong đó 143 đề xuất đúng, và từ chối 47 trong 48 trường hợp ngoài phạm vi. Các số lượng này gần đồ thị ban đầu và giống các số lượng MLP báo cáo phía trên. Số lượng bằng nhau không chứng minh lỗi liên quan đến cùng tài liệu: câu hỏi đó cần so sánh đầu ra theo từng tài liệu.
Vì vậy bạn không thể kết luận « quan hệ thiết bị bảo đảm hồ sơ đúng ». Bạn cũng không thể kết luận nó vô ích trong mọi GED. Kết quả mô tả tập dữ liệu, kiến trúc, huấn luyện và quy tắc quyết định này.
Việc sửa bài là đối chiếu giả thuyết của bạn với các đề xuất và từ chối, rồi xem các ví dụ. Để kéo dài lập luận bằng tay, hãy dùng lại hai vectơ ở phần trước: nếu bỏ một cạnh, cả tử số và bậc đều phải thay đổi. Kiểm tra cục bộ này giúp hiểu một nguyên nhân rò rỉ trước khi nhìn vào điểm cuối.
Tạo hình và kiểm tra các bản lưu
docker compose run --rm tutorial python lesson/figures/plot.py
docker compose run --rm tutorial python scripts/check_checkpoints.py
Các hình bổ sung cho đánh giá; kiểm tra checkpoint xác minh các trạng thái mong đợi của quy trình. Hãy giữ đầu ra cần nghiên cứu trước khi làm sạch được trình bày bên dưới. Một đường cong không thay thế việc kiểm tra tài liệu, ứng viên và ngữ cảnh hiển thị của nó.
Khắc phục sự cố, dọn dẹp và chuyển sang sản phẩm
Phân biệt lỗi môi trường với lỗi mô hình
GPU không truy cập được trong Docker? Hãy theo chẩn đoán preflight, sửa môi trường máy chủ, rồi bắt đầu lại trong một thư mục giải nén mới. Trạng thái nvidia-smi trên máy chủ không thay thế phép tính E5 trong container.
Việc tải thất bại? Hãy kiểm tra các tệp đã khóa, kích thước và SHA-256 của chúng. Đừng thay một mô hình hoặc bản sửa đổi khác để làm lỗi biến mất: bạn sẽ thay đổi điều kiện thí nghiệm.
Kiểm tra checkpoint thất bại? Hãy giữ các phần tử hữu ích cho chẩn đoán. Việc dọn dẹp được cung cấp chỉ xóa outputs; nó không sửa hay thay checkpoint đã giữ. Với một quy trình hoàn chỉnh mới, giải nén mới tránh trộn lẫn trạng thái của nhiều lần thử.
Trước khi dọn dẹp, hãy sao chép kết quả và hình cần giữ. Các lệnh sau dừng dự án, hiển thị rồi chỉ xóa outputs, và kết thúc quy trình. Dữ liệu, mô hình và checkpoint vẫn còn. Không cần dọn dẹp Docker toàn cục.
docker compose down
docker compose run --rm tutorial python scripts/clean.py --outputs-only
docker compose down
Hiểu những gì sự cô lập cung cấp
Các dịch vụ dùng UID và GID của người dùng, tức định danh hệ thống của họ. Hệ thống tệp gốc của chúng là chỉ đọc; chỉ các vùng cần cho vai trò của từng dịch vụ được gắn ở chế độ ghi. Dự án loại bỏ các khả năng Linux bổ sung, dùng no-new-privileges, đặt giới hạn CPU, bộ nhớ và tiến trình, và có không gian tạm thời trong tmpfs.
Dịch vụ tải có thể kết nối tới các tệp công khai đã khóa. Các dịch vụ tính toán hoạt động khi mạng bị vô hiệu hóa. Sự tách biệt này giúp giữ quy trình trong phạm vi dự kiến; nó không phải chứng nhận an ninh trước một quản trị viên Docker.
Từ điểm số đến giao diện rà soát
Trong ứng dụng thực tế, hãy bắt đầu bằng việc xác định cùng các nhóm nghiệp vụ thế nào là gắn kết đúng, tài liệu nào liên quan và các hồ sơ ứng viên đến từ đâu. Hãy tạo chú thích và đánh giá mang tính đại diện trước khi thay tập dữ liệu hư cấu.
Quyền phải được áp dụng trước điểm số: đứng đầu bảng xếp hạng không cho phép hiển thị hồ sơ mật. Cũng cần quyết định phải làm gì khi không có hồ sơ được phép nào, trong khi hướng dẫn luôn cung cấp bốn hồ sơ.
Các trường hợp hòa trong quy trình được phân xử theo định danh để ổn định phép tính. Lựa chọn này không mang ý nghĩa nghiệp vụ. Nếu hai ứng viên bằng nhau, định danh nhỏ hơn không làm một ứng viên phù hợp hơn.
Giao diện rà soát có thể trình bày tài liệu, các ứng viên, quan hệ đã tham chiếu và đề xuất, rồi để một người xác nhận, từ chối hoặc sửa. Đây là hướng sản phẩm cần phát triển, không phải giao diện đã được cung cấp trong trích đoạn. Đồ thị con cho thấy ngữ cảnh có sẵn; nó không phải lời giải thích nhân quả cho tính hợp lệ của gắn kết.
Vẫn cần dự liệu xác thực, API, lưu trữ bền vững, nhật ký đề xuất, giám sát, sao lưu, kiểm thử tải và đánh giá nghiệp vụ. Hãy quản lý phiên bản cùng đồ thị, dữ liệu, quy tắc quyết định và mô hình. Một đề xuất phải có thể được tìm lại và phản biện, không chỉ hiển thị rồi bị quên.
Quy trình của hướng dẫn này không sửa đổi hồ sơ hay quyền nào. Tự động hóa một hành động hành chính sẽ là phạm vi khác cần xác định và xác nhận.
Tóm tắt
Ta bắt đầu từ một câu hỏi back-office: đề xuất hồ sơ từ một biên bản và các quan hệ đã biết. E5 biến văn bản thành vectơ đóng băng; mạng quan hệ kết hợp các vectơ đó với nút lân cận được phép; điểm số xếp hạng bốn ứng viên; một quy tắc riêng quyết định đề xuất hay không.
Kiểm soát cốt yếu nằm ở đầu vào: bỏ liên kết đích và chiều ngược của nó, tính lại bậc và tách các cụm. Nếu không, một chỉ số đẹp có thể chỉ đo sự hiện diện của đáp án trong ngữ cảnh.
Các con số sau đó cho thấy vì sao phải tách các mục tiêu. Trong lần tái hiện này, đồ thị cải thiện việc từ chối các trường hợp ngoài phạm vi so với cosine, nhưng không cải thiện xếp hạng hồ sơ. Mô hình không cạnh vẫn gần, và việc phân loại quan hệ không chứng minh mức tăng trên các chỉ số công bố.
Nhờ đó bạn có một quy trình để học cách biểu diễn ngữ cảnh, kiểm tra một phép tổng hợp và diễn giải quyết định. Bước tiếp theo không phải biến điểm số thành sự chắc chắn: mà là đánh giá điều còn sai trên tài liệu và cách dùng thực sự nhắm tới.
Nguồn gốc và tài liệu đọc thêm
Các tham chiếu ban đầu của quy trình là bài báo R-GCN, tài liệu E5 của bản sửa đổi đã tải và tài liệu PyTorch 2.8 về index_add_.
Các liên kết bổ sung trong văn bản giải thích sâu hơn phép chiếu tuyến tính, sigmoid, AdamW, khả năng tái lập và hiệu chỉnh xác suất. Chúng giải thích các khái niệm; chúng không thêm huấn luyện hay phép đo mới vào quy trình r001. Để tái tạo quy trình này, hãy giữ các phiên bản và lệnh trong ZIP thay vì thay bằng tài liệu hiện hành.