Tôi đã quan sát thấy điều gì đó khi sắp xếp các bài kiểm tra nhánh DUSK theo độ trễ mạng P95. Cảnh báo 500 ms ban đầu trông có vẻ hữu ích cho đến khi tôi kiểm tra xem nó thực sự đang bắt gì.
Một ngưỡng nghe có vẻ chính xác nhưng vẫn có thể là một chỉ báo yếu.
Với DUSK Network, tôi sẽ không chỉ đánh giá độ trễ. ROC-AUC trên độ trễ P95, tỷ lệ mất gói và mức sẵn sàng của validator đều quan trọng vì mỗi tín hiệu có thể phân tách các vòng “fork” và “không fork” theo những cách khác nhau. Sau đó, ma trận nhầm lẫn cho thấy phần AUC có thể che giấu cảnh báo sai, bỏ sót các fork và mức độ một vòng có rủi ro cao thực sự có thể vô hại ra sao.
Ngưỡng 250 ms có thể bắt được nhiều sự kiện fork hơn nhưng lại làm hệ thống bị ngập tiếng ồn. Ở mức 750 ms, độ chính xác có thể cải thiện trong khi khả năng truy hồi (recall) sụp đổ. Đường 500 ms nằm giữa hai ngưỡng đó, nhưng “cân bằng” không tự động đồng nghĩa với “hữu ích”.
Điều quan trọng với DUSK là kiểm soát rủi ro so với khối lượng cảnh báo, chứ không phải độ trễ so với không độ trễ.
Tôi cũng sẽ theo dõi mức tăng rủi ro fork trong tứ phân vị độ trễ cao nhất. Nếu nhóm đó không cho thấy sự tập trung đáng kể các fork, thì độ trễ có thể có tương quan nhưng về mặt vận hành lại yếu.
Nghi ngờ thầm lặng của tôi thật đơn giản: bảo mật token của DUSK có được cải thiện vì cảnh báo có vẻ “tốt” về mặt thống kê, hay chỉ khi nó bắt được các sự kiện hiếm nhưng thực sự quan trọng?
@Dusk #dusk $DUSK
Một ngưỡng nghe có vẻ chính xác nhưng vẫn có thể là một chỉ báo yếu.
Với DUSK Network, tôi sẽ không chỉ đánh giá độ trễ. ROC-AUC trên độ trễ P95, tỷ lệ mất gói và mức sẵn sàng của validator đều quan trọng vì mỗi tín hiệu có thể phân tách các vòng “fork” và “không fork” theo những cách khác nhau. Sau đó, ma trận nhầm lẫn cho thấy phần AUC có thể che giấu cảnh báo sai, bỏ sót các fork và mức độ một vòng có rủi ro cao thực sự có thể vô hại ra sao.
Ngưỡng 250 ms có thể bắt được nhiều sự kiện fork hơn nhưng lại làm hệ thống bị ngập tiếng ồn. Ở mức 750 ms, độ chính xác có thể cải thiện trong khi khả năng truy hồi (recall) sụp đổ. Đường 500 ms nằm giữa hai ngưỡng đó, nhưng “cân bằng” không tự động đồng nghĩa với “hữu ích”.
Điều quan trọng với DUSK là kiểm soát rủi ro so với khối lượng cảnh báo, chứ không phải độ trễ so với không độ trễ.
Tôi cũng sẽ theo dõi mức tăng rủi ro fork trong tứ phân vị độ trễ cao nhất. Nếu nhóm đó không cho thấy sự tập trung đáng kể các fork, thì độ trễ có thể có tương quan nhưng về mặt vận hành lại yếu.
Nghi ngờ thầm lặng của tôi thật đơn giản: bảo mật token của DUSK có được cải thiện vì cảnh báo có vẻ “tốt” về mặt thống kê, hay chỉ khi nó bắt được các sự kiện hiếm nhưng thực sự quan trọng?
@Dusk #dusk $DUSK
