Cơ chế để AI tự động kiểm tra việc dùng thẻ mỗi tối, chỉ thông báo 'chi tiêu cần trao đổi'

Chào buổi sáng, mình là まさきん.

Trước đây mình đã giới thiệu cơ chế kết hợp AI với freee để xem lại chi tiêu gia đình mỗi sáng. Lần này là phiên bản buổi tối của cơ chế đó. Mình viết về cơ chế để AI tự động kiểm tra việc dùng thẻ trong ngày, ngay trước khi đi ngủ.

Nếu việc xem lại buổi sáng là “rút ra một nhận thức từ xu hướng hôm trước”, thì cơ chế buổi tối có tính chất khác một chút. Đây là cơ chế để nhặt ra ngay trong ngày câu hỏi “hôm nay có chi tiêu nào cần xác nhận lại không”. Lần này mình giới thiệu cả công thức của quy tắc xác định và các chi tiết điều khiển khi thực thi.

Lý do bắt đầu: “chi tiêu lớn dễ bị để sau”

Những chi tiêu nhỏ hàng ngày tự nhiên được ghi lại qua app sổ chi tiêu gia đình. Nhưng chi tiêu đơn lẻ với số tiền lớn thì khác. Có khi mình nghĩ “để sau nói chuyện” rồi lại quên mất.

Vì vậy mình đã tạo một cơ chế chỉ nhặt riêng những chi tiêu có số tiền lớn, để có thể nhận biết ngay trong ngày. Cơ chế này không phải do người khởi động, mà chạy dưới dạng “tác vụ theo lịch”, tự động thực thi vào giờ cố định.

Những điều cần lưu ý chính vì đây là thực thi tự động

Vì chạy tự động vào giờ cố định, không thể xác nhận trực tiếp với người dùng ngay lúc đó. Vì vậy mình đặt ra các quy tắc sau làm tiền đề cho việc thực thi:

• Nếu một bước lấy dữ liệu nào đó thất bại, không dừng xử lý mà tiếp tục các bước còn lại
• Nếu không xác định được, không cố ép mà bỏ qua và chỉ ghi lại vào log
• Ngày nào việc lấy dữ liệu từ API bên ngoài thất bại, sẽ bỏ tổng hợp thông thường và chuyển sang chế độ xem lại đơn giản

Mình thiết kế theo hướng ưu tiên “mỗi ngày chắc chắn để lại một kết quả nào đó” hơn là “hoạt động hoàn hảo” đối với tác vụ tự động.

Xử lý chi tiêu theo 3 loại

Nếu kiểm tra toàn bộ chi tiêu theo cùng một tiêu chí, sẽ có quá nhiều thông báo đến mức ngược lại không ai xem nữa. Vì vậy mình chia chi tiêu thành 3 loại sau:

Chi phí cố định vì hàng tháng giống nhau nên kiểm tra mỗi lần cũng vô nghĩa. Chi tiêu đã thống nhất trước cũng đã được bàn bạc rồi nên không cần thông báo. Cái cần kiểm tra chỉ là những “chi tiêu phát sinh tại chỗ” ngoài hai loại trên.

Đại diện của chi phí cố định là tiền nhà hay chi phí viễn thông. Chính vì số tiền hầu như không thay đổi nên mình mới loại nó ra khỏi đối tượng kiểm tra hàng ngày.

Với những nhà cung cấp khó xác định trong việc phân loại thuê bao — không rõ là mua một lần hay mua định kỳ — mình không cố ép vào nhóm “thuê bao” mà ghi riêng thành một dòng “chưa xác định”. Nếu để mơ hồ ở bước này, độ tin cậy của toàn bộ tổng hợp sau đó sẽ bị lung lay.

Nhưng ngay cả những chi tiêu bị loại khỏi kiểm tra cũng có ngoại lệ. Mình cảm thấy chính chi phí cố định như chi phí viễn thông lại là thứ đáng để xem lại theo định kỳ. Việc theo dõi hàng ngày có thể tự động hóa được, nhưng mức chi phí cố định tự nó thì chỉ có thể tự mình thay đổi.

Quy tắc xác định “chi tiêu cần trao đổi”

Trong số chi tiêu thuộc đối tượng kiểm tra, mình chỉ coi những khoản vượt quá một mức nhất định là “chi tiêu cần trao đổi”. Xin giới thiệu chỉ dẫn đã tổng quát hóa đưa cho AI.

Từ chi tiết sử dụng thẻ hôm nay, hãy trích xuất "chi tiêu cần trao đổi" theo các bước sau.

1. Loại trừ các giao dịch đã được phân loại là chi phí cố định, thuê bao
2. Loại trừ các giao dịch đã có trong danh sách thống nhất trước
3. Trong các giao dịch còn lại, trích xuất những giao dịch có số tiền từ một mức nhất định trở lên mỗi lần (tham khảo mức 10.000 yên)
4. Các giao dịch trích xuất được, liệt kê theo 3 mục: "số tiền", "nơi sử dụng", "thời gian"

Nếu không có giao dịch nào vượt mức nhất định, chỉ cần trả lời "hôm nay không có trường hợp nào".

Mức tiền làm tiêu chí sẽ khác nhau tùy vào mức phù hợp của từng gia đình. Mình cảm thấy điều quan trọng không phải “bao nhiêu tiền” mà là “quyết định trước tiêu chí”. Nếu không có tiêu chí, cuối cùng mỗi lần sẽ lại phải tranh luận “khoản này có nên trao đổi không”.

Xử lý độ trễ đồng bộ bằng số liệu

Việc liên kết thẻ với app sổ chi tiêu gia đình thường có độ trễ phản ánh vài ngày, đó là điều bình thường. Sau các kỳ nghỉ dài, độ trễ còn tăng thêm. Nếu coi đây là “bất thường”, thông báo sẽ toàn là báo nhầm. Vì vậy mình số hóa độ trễ theo các chỉ số sau:

• latest_txn_date: ngày giao dịch gần nhất quan sát được với thẻ đó
• lag_days: ngày hôm nay trừ latest_txn_date theo số ngày
• lag_status: phân loại thành 4 mức dựa vào độ lớn của lag_days

Điểm mấu chốt là không lập tức kết luận stalled — không phản ánh trong thời gian dài — là “lỗi liên kết”. Vì trên thực tế trường hợp “chỉ đơn giản là chưa dùng thẻ đó gần đây” mới là trường hợp phổ biến hơn.

Phân biệt “chỉ là chưa dùng” và “lỗi liên kết”

Khi quan sát thấy stalled, trước khi kết luận, mình kiểm tra lại mẫu giao dịch trong 30 ngày gần nhất.

• Có ít nhất một giao dịch trong 30 ngày qua, chỉ riêng gần đây mới trống trên 10 ngày → chỉ là chưa dùng trong thời gian dài, bản thân liên kết vẫn còn hoạt động
• Hoàn toàn không có giao dịch nào trong 30 ngày qua, nhưng thực tế lại có nhớ là đã dùng → nghi ngờ lỗi liên kết

Nhưng chỉ với trường hợp thứ hai, mình cũng không lập tức kết luận là “lỗi”. Chỉ khi cả 3 điều kiện sau đều thỏa mãn, mình mới coi đó là lỗi liên kết.

1. Nhiều thẻ cùng lúc xảy ra tình trạng stalled
2. Có ghi chép thực tế đã dùng — như hóa đơn hay ghi chú — nhưng không hiện trên app sổ chi tiêu gia đình
3. Có thể xác nhận bằng mắt thông báo lỗi đồng bộ trên màn hình của app sổ chi tiêu gia đình

Nếu 3 điều kiện không đủ, mình xử lý trung tính theo hướng “đã N ngày chưa dùng thẻ, tiếp tục xu hướng tiết kiệm”, tránh phát cảnh báo một cách vô cớ. Trước khi có cách phân biệt này, mỗi lần thấy một thẻ đơn giản là chưa dùng, mình lại lo lắng “có phải liên kết đang bị hỏng không”.

Đặt giới hạn số lần gọi API bên ngoài

Vì đây là tác vụ thực thi tự động, để tránh rơi vào vòng lặp gọi API vô hạn do một sự cố nào đó, mình đặt giới hạn số lần gọi cho mỗi lần thực thi.

• Đếm trước số lần gọi dự kiến với các trường hợp thông thường như lấy dữ liệu trong ngày, lấy dữ liệu tích lũy từ đầu tháng
• Nếu xảy ra lỗi ngoài dự kiến, khi đạt đến giới hạn số lần thì dừng thử lại, chuyển ngay sang “lấy dữ liệu thất bại”
• Ưu tiên việc “dừng xử lý khi đạt giới hạn số lần” hơn là chờ hết thời gian timeout

Nếu không đặt trước giới hạn, khi xảy ra lỗi xác thực chẳng hạn, hệ thống có thể lặp lại thử lại liên tục, gửi đi những request vô nghĩa. Mình cảm thấy cơ chế thực thi tự động lại càng cần loại chốt chặn như vậy.

Phân biệt “bất thường đang kéo dài” và “bất thường mới”

Mình có đặt quy tắc thông báo khi chi tiêu trong tháng vượt quá một tỷ lệ tham khảo nào đó, nhưng nếu áp dụng nguyên vậy cho thông báo hàng ngày, sau khi vượt một lần thì thông báo giống nhau sẽ tiếp tục mỗi tối đến cuối tháng. Như vậy sẽ không phân biệt được “ngày mới vượt ngưỡng” và “ngày vẫn đang vượt như trước không đổi”.

Vì vậy mình đếm số ngày liên tiếp vượt ngưỡng, kèm thêm dạng “ngày thứ ◯ vượt ngưỡng liên tiếp”. Khi phân biệt được bất thường mới và bất thường đang kéo dài, việc xem lại theo tuần cũng dễ nắm bắt tình hình chính xác hơn.

Thông báo cố ý giữ ở mức đơn giản

Ngay cả ngày phát hiện “chi tiêu cần trao đổi”, nội dung thông báo mình vẫn giữ đơn giản. Chỉ trình bày số tiền và nơi sử dụng, không đưa ra đánh giá tốt xấu.

Việc đánh giá là do chính mình và người thân quyết định. Mình xác định rõ vai trò của AI chỉ dừng ở “giúp nhận ra chi tiêu có thể bị bỏ sót”.

Những gì cảm nhận được khi thực hiện

Hiệu quả lớn nhất là không còn xảy ra tình trạng “nói rồi mà” hay “chưa nói gì” với các chi tiêu lớn. Vì thông tin được chia sẻ ngay trong ngày, ít bị lỡ thời điểm để trao đổi hơn.

Mặt khác, việc đặt mức tiền tiêu chí không thể hoàn hảo ngay từ đầu. Nếu quá thấp, thông báo quá nhiều sẽ trở nên hình thức; nếu quá cao, sẽ bỏ lỡ những chi tiêu có ý nghĩa. Sau vài lần điều chỉnh, mình đã ổn định ở mức hiện tại.

Phù hợp với những ai

• Người đã liên kết thẻ với app sổ chi tiêu gia đình nhưng có độ trễ trong việc chia sẻ chi tiêu lớn
• Người muốn làm rõ “ngưỡng chi tiêu cần trao đổi” trong gia đình
• Người không ngại việc tinh chỉnh dần để giảm báo nhầm, báo quá mức của tác vụ tự động

Tổng kết

Loại trừ chi phí cố định và chi tiêu đã thống nhất trước, chỉ nhặt ra những chi tiêu lớn còn lại. Mình cảm thấy việc thu hẹp đơn giản như vậy chính là bí quyết để thông báo không trở nên hình thức.

Cả việc số hóa độ trễ đồng bộ để phân biệt “chỉ là chưa dùng” với “lỗi”, và việc đặt chốt giới hạn số lần gọi API, đều là những chi tiết nhỏ nhưng mình cảm nhận rõ chúng có tác dụng để duy trì tự động hóa ổn định lâu dài.

Cơ chế này chỉ nhặt ra những chi tiêu biến động. Trong khi đó, chi phí cố định như chi phí viễn thông lại có tính chất khác. Thay vì kiểm tra mỗi lần, việc xem lại một lần có lẽ mang hiệu quả lâu dài hơn. Mình định để mắt đến phần đó song song với việc tự động hóa.

Bài viết này có chứa quảng cáo liên kết. Nếu bạn đăng ký sản phẩm hoặc dịch vụ qua liên kết trên trang này, chúng tôi có thể nhận được hoa hồng từ đối tác. Ngoài ra, người vận hành trang là nhân viên của Rakuten Group và có thể nhận thù lao qua chương trình giới thiệu nhân viên. Nội dung và đánh giá trong bài được viết dựa trên trải nghiệm thực tế và tìm hiểu của người vận hành, không phụ thuộc vào việc có quảng cáo hay không, nhưng mong bạn đọc với sự hiểu biết về mối quan hệ trên. Chi tiết xem tại phần Miễn trừ trách nhiệm & Tiết lộ liên kết. Miễn trừ trách nhiệm & Tiết lộ liên kết

Bài viết này có sử dụng dịch máy. Vui lòng tham khảo trang đa ngôn ngữ trên website chính thức của Rakuten Mobile để biết điều kiện chính xác.

Nếu bạn có thắc mắc về khu vực phủ sóng hoặc chất lượng tín hiệu của Rakuten Mobile, có thể liên hệ qua mẫu đề nghị khảo sát và cải thiện sóng chính thức.