Lợi nhuận:
- Khả năng giảm lỗi xuống mức nhỏ nhất có thể tái tạo và chuyển nó sang AI với bằng chứng đầy đủ
- Khả năng kiểm tra các giả thuyết dựa trên bằng chứng với biện pháp kiểm soát rẻ nhất và tìm ra nguyên nhân gốc rễ
- Khả năng giải quyết nguyên nhân gốc rễ và bảo vệ nó bằng kiểm tra hồi quy thay vì vá triệu chứng
Gỡ lỗi là quá trình tìm hiểu lý do tại sao phần mềm hoạt động không mong muốn và khắc phục nó. Đó là công việc mà nhà phát triển dành nhiều thời gian nhất và mệt mỏi nhất; Bởi vì phần lớn lỗi không phải ở chỗ nó xuất hiện mà nằm ở phía sau vài bước. AI là đối tác tư duy mạnh mẽ giúp đẩy nhanh nghiên cứu này - nhưng chỉ khi bạn đưa ra bằng chứng phù hợp. Gỡ lỗi mà không có bằng chứng là lĩnh vực mà AI tạo ra nhiều ảo giác nhất.
Trong đơn vị này, chúng tôi thiết lập một quy trình có kỷ luật từ việc tạo ra lỗi đến tìm ra nguyên nhân gốc rễ: làm rõ triệu chứng, thu thập bằng chứng (thông báo lỗi, dấu vết ngăn xếp, nhật ký, mục nhập), tạo giả thuyết, kiểm tra giả thuyết và xác thực cách khắc phục. AI trợ giúp ở mọi bước; nhưng quyết định "sửa chữa" được đưa ra bằng cách thấy rằng lỗi đã thực sự biến mất.
Tại sao bằng chứng là tất cả?
LLM không nhận ra lỗi như bạn; Anh ấy chỉ biết những gì bạn nói với anh ấy. Một câu như “Ứng dụng gặp sự cố” hầu như không cung cấp cho mô hình thông tin nào và mô hình sẽ lấp đầy khoảng trống bằng một dự đoán - tức là một ảo giác. Đổi lại, thông báo lỗi đầy đủ, dấu vết ngăn xếp - bản phân tích về chức năng gọi lỗi đã xảy ra, đầu vào gây ra lỗi và những gì được mong đợi, v.v. Với hành vi được quan sát, mô hình có thể xếp hạng xác suất thực.
Khi gỡ lỗi, hãy coi AI như một trợ lý cho thám tử: bạn càng đưa ra nhiều bằng chứng thì giả thuyết mà nó tạo ra càng chính xác. Nếu không có bằng chứng, trợ lý sẽ chỉ đoán và có thể dẫn bạn đi sai đường.
Mẹo: Trước khi chuyển lỗi sang AI, hãy giảm lỗi đó xuống ví dụ nhỏ nhất có thể tái tạo. Mã và thông tin đầu vào nhỏ nhất gây ra lỗi sẽ khiến mọi việc trở nên dễ dàng hơn rất nhiều cho cả bạn và mô hình; thường xuyên nhất trong quá trình giảm này bạn tự tìm ra nguyên nhân.
Từng bước: Quy trình phân tích nguyên nhân gốc rễ
- Làm rõ triệu chứng. "Chuyện gì đang xảy ra vậy, bạn đã mong đợi điều gì sẽ xảy ra?" Viết cả hai trong một câu.
- Thu thập bằng chứng. Thông báo lỗi đầy đủ, dấu vết ngăn xếp, dòng nhật ký có liên quan, mục nhập kích hoạt, thông tin phiên bản.
- Có giả thuyết được tạo ra. Từ AI “3 nguyên nhân có thể giải thích triệu chứng này và làm cách nào để kiểm tra từng nguyên nhân?” hỏi.
- Trước tiên hãy kiểm tra giả thuyết rẻ nhất. Thêm nhật ký, in giá trị, chạy thử nghiệm. Bằng chứng có xác nhận giả thuyết không?
- Khắc phục nguyên nhân gốc rễ chứ không phải triệu chứng. Thay vì làm im lặng triệu chứng bằng một miếng vá, hãy giải quyết nguyên nhân gốc rễ.
- Xác nhận và thêm thử nghiệm hồi quy. Xem lỗi biến mất; Sau đó viết một bài kiểm tra sẽ phát hiện lỗi đó để nó không quay trở lại.
Ba hộp nhỏ
Trường hợp 1 - Dấu vết ngăn xếp dẫn đến tệp chính xác. Một ứng dụng trả về lỗi 500 đối với một số yêu cầu nhất định. Nhà phát triển đã cung cấp toàn bộ dấu vết ngăn xếp và yêu cầu kích hoạt cho AI; Mô hình đưa ra giả thuyết rằng lỗi xảy ra do giá trị Không có trong lớp phân tích ngày tháng. Nhà phát triển đã thêm nhật ký vào dòng đó, xác minh và giải quyết trong 15 phút; 2 giờ ngày hôm trước đã bị lãng phí với những thí nghiệm chưa được chứng minh.
Trường hợp 2 - Ảo giác dẫn đến sai đường. Một nhà phát triển khác chỉ viết đơn giản là "kết nối cơ sở dữ liệu đang bị ngắt". AI đã buộc tội thiết lập nhóm kết nối mà không có bất kỳ bằng chứng nào; Nhà phát triển đã dành 40 phút để mày mò cài đặt này. Nguyên nhân thực sự là do phía mạng hết thời gian chờ và chỉ được tiết lộ khi xem nhật ký. Bài học: một giả thuyết được đưa ra mà không có bằng chứng thì chỉ có thể xảy ra chứ không đáng tin cậy.
Trường hợp 3 - Đã phát hiện lỗi không ổn định. Có một bài kiểm tra đôi khi thất bại. AI được cấp mã kiểm tra, thông báo lỗi và thông tin “có khi đạt, có khi không thành công”; mô hình chỉ ra sự phụ thuộc chung về thời gian/thứ tự của các thử nghiệm. Quá trình xem xét xác nhận rằng thử nghiệm dựa trên giờ địa phương của hệ thống. Khi đồng hồ đã được sửa (mô phỏng), bài kiểm tra trở nên ổn định.
Bốn mẫu có thể sao chép
Tạo giả thuyết dựa trên bằng chứng:
Tôi đang gỡ lỗi. Bằng chứng bên dưới.- Hành vi dự kiến: {{expected}}- Hành vi được quan sát: {{observed}}- Thông báo lỗi / dấu vết ngăn xếp: {{trace}}- Đầu vào kích hoạt: {{input}}- Môi trường/phiên bản: {{version}}Liệt kê 3 nguyên nhân gốc RẤT LỚN NHẤT giải thích hiện tượng này. Đối với từng vấn đề: làm cách nào để kiểm tra (kiểm tra rẻ nhất) và cách khắc phục nếu điều đó đúng. Nếu bằng chứng không đủ, hãy cho tôi biết bạn cần thêm thông tin gì.
Giải thích dấu vết ngăn xếp:
Đọc dấu vết ngăn xếp này. Phân biệt giữa dòng nào lỗi CÓ THỂ bắt đầu từ (gốc) và dòng nào chỉ là phần tiếp theo của chuỗi. Gợi ý 1-2 địa điểm nên tìm trước. Mã liên quan:{{code}}Trace:{{trace}}
Phép trừ repro tối thiểu:
Mã bên dưới tạo ra lỗi. Giảm nó xuống phiên bản NHỎ NHẤT vẫn gây ra lỗi nhưng loại bỏ mọi thứ không cần thiết. Đừng cho rằng mọi phần bạn xóa không ảnh hưởng đến lỗi mà hãy thêm ghi chú nói rằng "nếu lỗi biến mất khi bạn xóa phần này thì đó là lý do".{{code}}
Kiểm tra hồi quy và xác nhận sau hiệu chỉnh:
Giả sử nguyên nhân cốt lõi là {{nguyên nhân}} và tôi thực hiện cách khắc phục sau: {{fix}}.1) Cách khắc phục này có thực sự khắc phục được triệu chứng không, nó có gây ra bất kỳ tác dụng phụ nào không?2) Viết một bài kiểm tra hồi quy sẽ phát hiện lỗi này trong tương lai.
Dấu nhắc yếu / Dấu nhắc mạnh
Yếu: "Mã không dùng được, tại sao?"
Strong: "Node 20 / Express. POST /orders trả về 500 khi các mục là một chuỗi trống trong nội dung; đáng lẽ phải trả về 400. Dấu vết ngăn xếp: TypeError: Không thể đọc các thuộc tính không xác định (đọc '0') — đính kèm là dấu vết đầy đủ và trình xử lý liên quan. Hãy cho tôi 3 nguyên nhân có khả năng nhất giải thích hiện tượng này và cách kiểm tra từng nguyên nhân. [trace + code]"
Phiên bản mạnh mẽ; Nó cung cấp môi trường, điểm cuối, đầu vào kích hoạt, loại lỗi chính xác và hành vi dự kiến. Mô hình không còn có thể đưa ra dự đoán nữa mà có thể phân tích.
bước
Đóng góp của AI
sự kiểm soát của bạn
thu thập bằng chứng
Cần bằng chứng gì, nhắc nhở
Thực sự thu thập bằng chứng
tạo giả thuyết
Liệt kê các lý do có thể
Ưu tiên theo ngữ cảnh
kiểm tra giả thuyết
Đề xuất phương pháp thử nghiệm
Vận hành và quan sát cá nhân
sự sửa chữa
bản vá khuyến nghị
Nó có giải quyết được nguyên nhân gốc rễ không? Đó là sự thật.
hồi quy
viết bài kiểm tra
Xác minh rằng bài kiểm tra bị hỏng
Giải quyết nguyên nhân gốc rễ, không phải triệu chứng
Hầu hết thời gian AI sẽ đề xuất một bản vá để nhanh chóng làm im lặng triệu chứng: thêm một lần thử/bắt, đặt một kiểm tra rỗng, nuốt lỗi. Điều này đôi khi đúng nhưng thường nguy hiểm; bởi vì nguyên nhân ban đầu vẫn còn nguyên tại chỗ và lại bùng phát từ nơi nào khác. Với mỗi lần sửa lỗi, hãy tự hỏi: “Việc này có khắc phục được nguyên nhân gây ra lỗi hay làm cho lỗi không hiển thị được?” Một khi bạn tìm ra nguyên nhân gốc rễ, việc khắc phục thường nhỏ hơn, mạnh mẽ hơn và lâu dài hơn.
Thận trọng: Âm thầm nuốt một ngoại lệ (bắt trống) không giải quyết được lỗi; nó chỉ che giấu và khiến cho việc chẩn đoán trong tương lai không thể thực hiện được. Nếu AI gợi ý một “giải pháp” như vậy, đừng chấp nhận nó mà không đặt câu hỏi về nguyên nhân cốt lõi.
Những lỗi thường gặp
- Đặt câu hỏi mà không có bằng chứng. Những câu nói mơ hồ đẩy người mẫu vào tình trạng ảo giác; Cung cấp đầy đủ lỗi, dấu vết và đầu vào.
- Bám sát giả thuyết đầu tiên. Đề xuất đầu tiên của AI có thể không có khả năng xảy ra cao nhất; Bắt đầu với giả thuyết có thể kiểm soát được rẻ nhất.
- Vá triệu chứng và bỏ sót nguyên nhân gốc rễ. Lỗi im lặng trở lại.
- Đóng bản sửa lỗi mà không xác minh nó. Xem trong điều kiện giống như sản xuất, lỗi thực sự biến mất.
- Không viết bài kiểm tra hồi quy. Nếu không có kiểm tra nào được thêm vào, lỗi tương tự sẽ âm thầm quay trở lại trong các phiên bản sau.
Tóm lại
Trong quá trình gỡ lỗi, sức mạnh của AI tỷ lệ thuận với bằng chứng bạn đưa ra: không có thông báo lỗi đầy đủ, dấu vết ngăn xếp, đầu vào kích hoạt và hành vi dự kiến, mô hình chỉ suy đoán. Quy trình có kỷ luật—làm rõ triệu chứng, thu thập bằng chứng, đưa ra giả thuyết, kiểm tra với biện pháp kiểm soát rẻ nhất, khắc phục nguyên nhân gốc rễ, xác minh và thêm kiểm tra hồi quy—đóng lỗi nhanh chóng và vĩnh viễn. AI là người tạo ra giả thuyết; Bạn là người quyết định rằng lỗi thực sự đã được giải quyết.
Nhiệm vụ ứng dụng
Chọn một lỗi thực sự mà bạn gặp phải gần đây (hoặc tạo lại một lỗi thử nghiệm). Thực hiện bước "tái tạo tối thiểu" trước; Loại bỏ mã và đầu vào nhỏ nhất gây ra lỗi. Sau đó lấy 3 nguyên nhân có thể xảy ra và phương pháp kiểm tra từ AI với mẫu “tạo giả thuyết dựa trên bằng chứng”. Hãy tự mình kiểm tra giả thuyết rẻ nhất, tìm ra nguyên nhân gốc rễ, khắc phục nó và cuối cùng viết một bài kiểm tra hồi quy để phát hiện lỗi này trong tương lai và xác minh rằng bài kiểm tra đó thực sự bị lỗi.
danh sách kiểm tra
- [ ] Tôi giảm lỗi xuống mẫu có thể tái tạo nhỏ nhất trước khi chuyển nó sang AI.
- [ ] Tôi đang thêm thông báo lỗi đầy đủ, dấu vết ngăn xếp, dữ liệu đầu vào và hành vi dự kiến vào lời nhắc.
- [ ] Tôi bắt đầu với cái rẻ nhất có thể kiểm soát được mà không bị bó buộc vào một giả thuyết duy nhất.
- [ ] Tôi xác minh rằng tôi đã giải quyết được nguyên nhân gốc rễ thay vì vá lỗi triệu chứng.
- [ ] Tôi nhận thấy rằng bản sửa lỗi thực sự đã sửa được lỗi.
- [ ] Tôi thêm bài kiểm tra hồi quy cho từng lỗi đã được giải quyết.