Uncertain<T>

• Giới thiệu khái niệm kiểu Uncertain<T>, một lớp trừu tượng mới để xử lý tính không chắc chắn ở cấp độ mã nguồn
• Kiểu này áp dụng phương pháp lập trình xác suất, mô hình hóa độ tin cậy hoặc khả năng của giá trị thay cho logic boolean truyền thống
• Cung cấp khả năng xử lý dữ liệu thực tế nhiều nhiễu như GPS, dữ liệu cảm biến dưới dạng các phân phối xác suất toán học
• Hỗ trợ cân bằng giữa hiệu quả tính toán và độ tin cậy của kết quả bằng các kỹ thuật lấy mẫu như SPRT và Monte Carlo
• Có thể tích hợp dần với mã hiện có, nên rất thực tiễn để áp dụng trong công việc

---

Mã hóa tính không chắc chắn: khoảng cách giữa sự tự tin và dữ liệu thực tế

• Đề cập đến hiện tượng nhiều người phụ thuộc quá mức vào sự xác quyết
• Chỉ ra rằng khi kinh nghiệm phát triển phần mềm tăng lên, tần suất nói “còn tùy tình huống” cũng tăng theo
• Trong mã nguồn, các mẫu chỉ dựa vào phán đoán đúng/sai vẫn tiếp tục lặp lại
• Đặc biệt phê phán thực tế xử lý dữ liệu không chắc chắn như GPS nhưng vẫn chỉ dùng giá trị boolean
• Mô hình lập trình nhị phân hóa quá nhanh tính ‘không chắc chắn’ của thế giới thực, từ đó che giấu sự phức tạp

Lựa chọn lớp trừu tượng phù hợp

• Năm 2014, University of Washington và Microsoft Research đã đề xuất khái niệm phản ánh trực tiếp tính không chắc chắn vào hệ kiểu
• Thông qua bài báo "Uncertain<T>: A First-Order Type for Uncertain Data", họ chứng minh rằng cách tiếp cận lập trình xác suất là thực tiễn
• Mã đã được port ý tưởng sang Swift được đăng trên kho GitHub
• Khi dùng Uncertain<T>, kết quả so sánh cũng được biểu diễn bằng xác suất tương đối, và trả về dưới dạng Uncertain<Bool> thay vì đúng/sai
• Sai số vị trí GPS được mô hình hóa theo đặc tính dữ liệu thực tế như phân phối Rayleigh

Thực tế của các phép toán bất định đa dạng

• Hỗ trợ nhiều toán tử và mô hình phân phối xác suất, xây dựng đồ thị tính toán và chỉ thực hiện lấy mẫu khi cần
• Điều chỉnh số lượng mẫu hiệu quả bằng SPRT(Sequential Probability Ratio Testing)
• Mã ví dụ giải thích sự khác biệt về số lượng mẫu cần thiết giữa so sánh đơn giản và so sánh phức hợp
• Với lớp trừu tượng này, có thể không bỏ qua tính không chắc chắn mà tận dụng nó một cách tự nhiên trong quá trình tính toán, từ đó hiện thực hóa mã “thông minh” hơn

Ứng dụng phương pháp Monte Carlo

• Đưa vào lấy mẫu Monte Carlo để phân tích phân phối xác suất và ước tính kỳ vọng
• Có thể dễ dàng rút ra giá trị kỳ vọng bằng cách mô phỏng lặp lại kết quả của máy đánh bạc
• Ngay cả không cần tính toán giải tích phức tạp, vẫn có thể tạo ra kết quả thực tế chỉ bằng lấy mẫu lặp trên máy tính

Mô hình hóa phân phối xác suất phong phú

• Uncertain<T> tích hợp sẵn nhiều hàm tạo phân phối xác suất, cho phép mô hình hóa tinh vi dữ liệu thế giới thực như nhiễu cảm biến, hành vi người dùng, độ trễ mạng
• Hỗ trợ tham số hóa cho nhiều tình huống như mixture distribution, Bernoulli, exponential, normal
• Để giúp hiểu trực quan về từng phân phối, còn có riêng dự án trực quan hóa tương tác

Cung cấp các phép toán thống kê và phân tích

• Cung cấp nhiều hàm thống kê như kỳ vọng, độ lệch chuẩn, khoảng tin cậy, độ lệch (skewness), độ nhọn (kurtosis), entropy
• Kết quả tính toán cũng có thể điều chỉnh số lượng mẫu, cho phép đánh đổi giữa độ chính xác và hiệu quả
• Có thể dễ dàng tính cả xác suất nhỏ hơn hoặc bằng một giá trị nhất định bằng cách dùng hàm phân phối tích lũy (CDF)

Hướng dẫn áp dụng vào thực tế

• Giải thích các vấn đề có thể phát sinh trong ứng dụng thực tế khi bỏ qua tính không chắc chắn (ví dụ: hiển thị tốc độ GPS vô lý)
• Nhấn mạnh chuyển đổi dần dần: khuyến nghị tích hợp Uncertain<T> từng phần, bắt đầu từ các luồng cốt lõi như đo khoảng cách
• Có thể điều chỉnh cân bằng giữa độ chính xác và hiệu năng bằng cấu hình chi phí tính toán như số lượng mẫu
• Trong thực tế, khuyến nghị tích cực sử dụng các công cụ profiling như Instruments.app
• Mục tiêu không phải là loại bỏ tính không chắc chắn, mà là xây dựng mẫu phát triển biết thừa nhận và xử lý nó đúng cách

Kết luận và triển vọng

• Nhà phát triển có thể bắt đầu từ những phạm vi nhỏ để đưa xử lý bất định vào, kỳ vọng cải thiện khả năng sử dụng và giảm lỗi
• Chấp nhận rằng không tồn tại sự chắc chắn tuyệt đối, và nâng chất lượng phần mềm thêm một bậc bằng công cụ cùng lớp trừu tượng phù hợp
• Về bản chất, xử lý đúng chính sự không chắc chắn đang tồn tại mới là một cải tiến thực tiễn đích thực

[GN⁺]

Ý kiến trên Hacker News

• Độ bất định của GPS nhìn chung chỉ có thể được xấp xỉ thành hình tròn trong những điều kiện cụ thể như định vị lâu dưới bầu trời quang đãng; thực tế mô hình sai số tổng thể phức tạp hơn nhiều và tồn tại nhiều cách đo sai số khác nhau, điều này trở nên quan trọng trong nhiều tình huống khiến việc coi vị trí là một điểm duy nhất trở nên khó khăn; ví dụ với xe tự hành, người ta thường gặp các trường hợp mà độ bất định của ước lượng vị trí bị chi phối bởi hiện tượng đa đường phi tròn, và nếu suy nghĩ đủ sâu về những khó khăn này thì cuối cùng sẽ lại đi tới việc tái phát minh các kỹ thuật như particle filter
  • GPS cho ô tô thường được bổ trợ bằng nhiều cảm biến và các giả định bổ sung; đặc biệt quan trọng là đồng hồ tốc độ, la bàn, và kiến thức rằng xe sẽ nằm trên một trong các con đường trên bản đồ; ngoài ra còn có thể định vị nhanh nhờ giả định rằng vị trí không thay đổi giữa lần tắt nguồn cuối cùng và lúc khởi động lại
  • Các điểm lidar thực ra không chỉ là những điểm đơn giản, mà tồn tại dưới dạng các khối elipxoit xoay quanh vị trí có khả năng cao nhất
• Tại University of Cambridge, người ta đã thiết kế vi kiến trúc bộ xử lý lấy cảm hứng từ Uncertain<T>(James Bornholt) và các nghiên cứu liên quan; không chỉ các phân phối tham số như Gaussian, Rayleigh..., mà cả các tập mẫu tùy ý cũng có thể được nạp vào thanh ghi/bộ nhớ để các giá trị trong chương trình lan truyền qua các phép toán số học như những phân phối phi tham số; dựa trên công nghệ này, công ty spin-off Signaloid đang thâm nhập thị trường, và tôi cũng đang nghiên cứu áp dụng nó vào ước lượng trạng thái (ví dụ: particle filter) liên kết bài báo
• Nếu hiểu được khái niệm rằng trong lập trình, một biến có thể chứa “đặc tả” của biến toán học, thì sẽ mở ra những khả năng đáng kinh ngạc, nền tảng của AI hiện đại; hãy nghĩ đến công thức quen thuộc y = m * x + b: khi tất cả đều là literal thì nó chỉ là một hàm render đơn giản, nhưng nếu các biến mang toàn bộ cấu trúc của con đường tính toán đã sinh ra chúng, thì tùy theo hướng tính toán, ta có thể dự đoán giá trị để render (forward pass), hoặc tự động tính gradient/đạo hàm để đi tới việc huấn luyện mạng nơ-ron; nếu lấy mẫu các kết quả sinh ra này theo cách toán học, ta có thể thu được các trọng số hình thành nên mô hình; mỗi lớp trong deep learning đều được thiết kế như vậy, và các hệ thống như PyTorch có thể biên dịch thành mã tối ưu chỉ từ việc chỉ định tổ hợp các phép toán; nói cách khác, Uncertain<T> mới chỉ là điểm khởi đầu, và sẽ là một thử nghiệm rất thú vị nếu tưởng tượng rằng mọi biến số đều có thể được định nghĩa bất kỳ lúc nào bằng metadata của các giá trị ứng viên, và metadata này có thể được thao tác dễ dàng như cộng thêm một giá trị vào biến
  • Nghe thật sự rất thú vị, tôi tự hỏi liệu có thể giải thích theo cách mà người như tôi, không có nhiều kiến thức về machine learning hay toán học, cũng dễ hiểu được không
  • Tôi tò mò không biết trong số các PL (ngôn ngữ lập trình), có ví dụ thực tế nào hỗ trợ kiểu khái niệm này ở cấp độ ngôn ngữ hay không
  • Có vẻ bình luận này đang trộn lẫn biến, hàm và hệ tuyến tính vào với nhau; tôi không nghĩ nhất thiết phải gộp chúng như vậy
• Tôi tò mò liệu cách này có xử lý được hiệp phương sai giữa nhiều biến hay không; ví dụ, vị trí của chính đối tượng được đo cũng có thể có sai số, và sai số đó có thể tương quan với sai số vị trí của tôi (nhất là nếu GPS được đo cùng một thời điểm); nếu hệ kiểu chỉ có mô hình đơn biến thì vẫn hữu ích, nhưng nếu xử lý được cả hiệp phương sai thì sẽ mạnh hơn và chính xác hơn rất nhiều
  • Nếu dùng cách tiếp cận dựa trên lấy mẫu thì việc mô hình hóa hiệp phương sai sẽ tự động được bao gồm; chỉ cần lấy mẫu một lần cho giá trị lá được dùng nhiều lần trong một quá trình đánh giá cụ thể, và có thể xác nhận rằng cách triển khai thực sự làm vậy trong đoạn mã bên dưới mã Uncertain.swift
  • Từ lâu tôi đã tự hỏi liệu chương trình có thể “học” hiệp phương sai trong quá trình sử dụng thực tế hay không; nếu mô hình hóa các biến như độc lập thì có vẻ sẽ liên tục lệch khỏi thực tế, và trong các chương trình quy mô lớn thì việc thủ công xem xét tương quan giữa mọi cặp biến gần như là bất khả thi; có lẽ cần nghĩ ra một cách để học điều đó tự động
  • Nếu cần theo dõi hiệp phương sai thì cũng đáng thử thư viện gvar cho python
  • Nếu muốn mô hình hóa cơ học lượng tử một cách đúng đắn, thì cần gắn một hàm sóng dạng số phức cho mỗi tập biến vướng víu với nhau
• Khi giao tiếp với thợ gia công trong các bản vẽ cơ khí v.v., người ta dùng khái niệm “dung sai”; ví dụ: 10cm +8mm/-3mm để biểu thị rõ phạm vi cho phép theo hướng trên và dưới; với những câu hỏi như “đến gần nơi chưa?” dựa trên GPS, có thể kỳ vọng rằng việc hiểu được tính định hướng của sai số và phân biệt trường hợp tốt/xấu tùy theo “hướng” của độ bất định là rất quan trọng
  • Điểm đáng tiếc của cách ký hiệu này là trong một số trường hợp, nó có thể mang nghĩa “tuyệt đối không bao giờ vượt quá giới hạn tối đa/tối thiểu”, còn trong trường hợp khác lại có thể được hiểu là “chỉ có 10% xác suất vượt quá phạm vi”
  • Cách ước lượng ba điểm (lạc quan, thực tế, bi quan) thường dùng trong lập kế hoạch công việc cũng tương tự; ngay cả với một phân phối xác suất rất đơn giản, góc nhìn dựa trên phân phối xác suất vẫn đem lại sự rõ ràng vượt trội trong mọi lĩnh vực có sự bất định
• Khái niệm này trước đây đã nhiều lần được triển khai dưới tên “interval arithmetic”; Boost và flint cũng có hỗ trợ Boost Interval flint(arb), và dù liên tục được tái khám phá như vậy, tôi vẫn thắc mắc vì sao nó chưa thực sự trở thành xu hướng chính; nếu có ai từng dùng nó ngoài thực tế rồi thấy không ổn mà bỏ cuộc, tôi rất muốn nghe trải nghiệm
  • Bài gốc giải thích rằng Uncertain<T> dùng phân phối Rayleigh cho độ bất định GPS; phân phối Rayleigh không phải là phân phối đều mà mô hình hóa phân phối sai số trong thế giới thực tốt hơn; ví dụ, nếu tính (-2,2)*(-2,2) trong thư viện Boost thì kết quả là (-4,4), nhưng về mặt xác suất thì khả năng các cực trị cùng xảy ra thấp hơn nhiều, nên khoảng xấp xỉ (-2.35,2.35) sẽ thực tế hơn
  • Trong vật lý, người ta học về lan truyền sai số (error propagation) từ rất sớm; nếu giả định sai số có phân phối Gaussian thì việc tính toán rất thanh nhã, nhưng trên thực tế phần lớn phép đo không tuân theo phân phối Gaussian, sai số phi xác suất (mang tính hệ thống) mới là vấn đề, và vì rất khó xử lý chúng cho đúng nên việc tự động lan truyền sai số thường gần như vô dụng; trong đa số trường hợp vẫn cần phân tích thủ công
  • Tôi không hiểu vì sao bài này lại được chú ý như vậy; dự án này hỗ trợ không chỉ interval arithmetic mà cả nhiều phân phối bất định khác nhau
  • Các kiểu đơn giản như Boolean thì có thể suy luận dễ dàng nên ràng buộc cũng rõ ràng; ngược lại, bất định vật lý thì phức tạp và cần mô hình khác nhau theo từng miền, và một khi đã quyết định xử lý bất định phức tạp thì thay vì dùng một thư viện được đóng gói đẹp mắt, có lẽ nên dùng các mô hình chuyên biệt dành riêng cho mục đích đó
  • Interval arithmetic chỉ chậm hơn phép toán số đơn giản một hằng số lần chứ không khác biệt quá lớn, và với mỗi phép toán đều tồn tại một kết quả khoảng chính xác nhất riêng; tuy nhiên độ chính xác không phải lúc nào cũng được đảm bảo; còn đồ thị phép toán lấy mẫu như trong bài thì chậm hơn nhưng bù lại có thể tiếp cận mô hình sai số thực tế chính xác hơn, với lợi thế là không cần miền trừu tượng làm mất độ chính xác
• Kiểu dữ liệu mà tôi từng muốn tạo ra là thứ biểu diễn mức độ một giá trị được biết đến trong một phân phối xác suất nhất định (hoặc hàm mật độ xác suất), đồng thời ở mỗi bước biến đổi lại cộng thêm chừng ấy bất định; tôi hình dung một dòng chảy trong đó tập các phân phối xác suất này liên tục được tinh chỉnh khi có thêm quan sát (hoặc khi phân loại có điều kiện thay đổi); mục tiêu cuối cùng là mô phỏng các trường hợp kết quả ngẫu nhiên dựa trên phân phối như vậy
• Khái niệm này cũng có liên hệ rất chặt với Functional Pearl cũ “Probability Functional Programming” liên kết PDF, thật sự rất tuyệt; trong buổi học nhập môn Haskell đầu tiên, tôi thường bắt đầu bằng cách trình diễn bài toán Monty Hall bằng probability monad, rồi tính xác suất thắng của hai chiến lược dưới dạng phân số nguyên một cách rất trực quan
  • Cũng nên xem thêm thư viện monad-bayes của Haskell bài blog liên quan
• Có lẽ sẽ hay nếu Uncertain trở thành kiểu mặc định, còn chỉ khi thực sự chắc chắn mới phải ghi riêng là certain T
  • Nếu chỉ giới hạn ở các đại lượng đo vật lý thì đúng, nhưng những thứ như tiền tệ thì phải chính xác tới cả phần thập phân; nhân tiện, cách tiếp cận này cũng đã được triển khai trong một số thư viện Fortran hiện đại
  • Nó có thể hoạt động như phần bổ sung cho kiểu Optional
• Tôi tự hỏi liệu về mặt tiệm cận, đây có phải là một phiên bản fuzzy logic trong lập trình hay không Fuzzy Logic Wikipedia
  • Có lẽ nó gần với probabilistic programming hơn, một lĩnh vực đã tồn tại sẵn, với đại diện tiêu biểu là Pyro