0:00 Hôm nay tôi sẽ nói về năm kỹ thuật xử lý lỗi mà bạn cần nắm vững nếu muốn đưa quy trình làm việc của mình vào sản xuất. Tùy thuộc vào trường hợp sử dụng, nhưng đôi khi một quy trình làm việc cần các yếu tố của cả năm kỹ thuật này để bạn có thể thiết lập và quên nó đi, đồng thời yên tâm rằng quy trình sẽ chạy và xử lý lỗi đúng cách. Vì vậy, tôi sẽ hướng dẫn bạn thực hiện cả năm điều này. Tôi sẽ cho các bạn xem ví dụ. Và số bốn là số cực kỳ cực kỳ mạnh mẽ và tôi cảm thấy nó hiếm khi được nhắc đến. Vì vậy, các bạn sẽ hiểu ý tôi. Vì vậy, tôi không muốn lãng phí thời gian ở đây. Chúng ta hãy cùng đi thẳng vào quy trình làm việc này để tôi có thể chỉ cho các bạn những kỹ thuật xử lý lỗi này. Được rồi, chúng ta hãy cùng xem qua những ví dụ thực tế mà tôi có dành cho các bạn ở đây. Tôi muốn nói về ý nghĩa của từ "sẵn sàng sản xuất"? Vì vậy, trong NN, khi bạn đang xây dựng một quy trình làm việc và bạn đang ở trong môi trường thử nghiệm, nơi bạn đang kiểm tra mọi thứ và bạn đang
0:46 thay đổi mọi thứ và bạn thấy dữ liệu chạy trực tiếp, bạn đang ở trong một quy trình làm việc không hoạt động và ngay khi bạn, bạn biết đấy, bật công tắc này và chuyển nó sang quy trình làm việc đang hoạt động, về cơ bản có nghĩa là được rồi, đây là quy trình làm việc trực tiếp. Nếu mọi người, bạn biết đấy, bất kể lý do gì khiến bạn căng thẳng, thì lý do đó hiện đang được lắng nghe một cách tích cực. Vì vậy, nếu mọi người gửi email cho bạn hoặc gửi cho bạn một cuộc trò chuyện trên WhatsApp hoặc bất kỳ nơi nào khác, quy trình làm việc sẽ thực sự thực hiện các tác vụ và hành động trong các công cụ của bạn. Và đó chính xác là ý nghĩa của một quy trình làm việc tích cực. Và để bạn tin rằng mình đã sẵn sàng đưa vào sản xuất và biến đây thành một quy trình làm việc chủ động, cần có nhiều yếu tố, đúng không? Giống như vấn đề bảo mật, chỉ là tính nhất quán của đầu ra và chất lượng đầu ra nói chung. Nhưng hôm nay chúng ta tập trung vào khía cạnh xử lý không khí, thực sự là để mang lại sự an tâm. Bởi vì hãy tưởng tượng nếu bạn không thiết lập chế độ xử lý lỗi phù hợp và bạn không nhận được thông báo và mọi thứ không
1:31 tiếp tục diễn ra. Bạn có thể thức dậy và thấy có khoảng 2.000 lỗi và toàn bộ logic đều sai, bạn sẽ bỏ lỡ tất cả các lệnh khác nhau và những thứ tương tự như vậy. Vì vậy, theo tôi, xử lý lỗi sẵn sàng sản xuất có nghĩa là bạn có một quy trình làm việc mà khi có lỗi, nó sẽ gửi thông báo cho bạn. Nó đang ghi lại tất cả những lỗi đó. Nó có logic thử lại và dự phòng và khi thất bại, nó sẽ thất bại một cách an toàn. Nghĩa là không phải gửi email cho hàng nghìn người hay xóa hồ sơ khỏi cơ sở dữ liệu hoặc chèn hàng loạt hồ sơ vào cơ sở dữ liệu. Và lý do tại sao bạn phải lên kế hoạch cho những thất bại đó là vì thất bại là điều không thể tránh khỏi trong môi trường sản xuất. Mọi việc sẽ thất bại. Nhưng gần cuối, chúng ta sẽ nói về việc xây dựng lan can bảo vệ. Và để xây dựng được lan can bảo vệ, bạn cần biết loại hư hỏng nào có thể xảy ra. Cho dù bạn có thể dự đoán được những trường hợp ngoại lệ đến đâu, bạn cũng không thể biết được những điều mình không biết. Và mọi chuyện sẽ xảy ra. Vì vậy, bằng cách theo dõi và ghi lại tất cả lỗi,
2:18 bạn có thể bắt đầu xác định các mẫu. Và khi bạn bắt đầu xác định các mô hình, bạn có thể xây dựng các rào chắn chống lại các mô hình đó. Thôi, nói thế là đủ rồi . Chúng ta hãy chuyển ngay đến loại xử lý lỗi đầu tiên mà chúng ta sẽ nói đến, đây là loại dễ thực hiện nhất và dễ thiết lập nhất. Mỗi quy trình công việc của bạn đều phải chỉ ra một số loại quy trình công việc có lỗi, mà bạn biết đó là quy trình công việc có lỗi số một. Vậy thì quy trình xử lý lỗi là một quy trình riêng biệt bắt đầu bằng một tác nhân gây lỗi. Và trình kích hoạt lỗi có thể liên kết tới bất kỳ quy trình làm việc nào đang hoạt động của bạn. Và ý tưởng là bất cứ khi nào một quy trình công việc đang hoạt động xảy ra lỗi, nó sẽ chỉ thông báo cho quy trình công việc này và sau đó bạn có thể thiết lập logic về những gì tôi muốn xảy ra với lỗi đó. Vì vậy, tôi sẽ không đi sâu vào cách bạn thực sự thiết lập điều này. Tôi đã liên kết một video đầy đủ trên kênh YouTube của tôi ngay tại đây nếu các bạn muốn xem.
3:04 Nhưng giả sử ông Bad agent ở đây có một công cụ Air Table và thông tin xác thực của Air Table đột nhiên hết hạn hoặc phạm vi thay đổi hoặc điều gì đó. Nếu chúng ta không có tác nhân này chỉ ra quy trình làm việc lỗi này, về cơ bản chúng ta sẽ không biết rằng hàng nghìn bản ghi đang có lỗi và chúng ta sẽ không biết điều gì đã xảy ra sau đó vì khi chúng ta quay lại và kiểm tra quy trình làm việc, chúng ta sẽ thấy rằng có tất cả các lỗi này, nhưng chúng ta sẽ không biết thông báo lỗi. Vì vậy, sẽ rất khó để gỡ lỗi. Vì vậy, vì chúng ta có thể thiết lập logic để thực hiện bất kỳ điều gì chúng ta muốn, chúng ta có thể tiếp tục và kiểm tra trình ghi lỗi, chúng ta có thể nhận được thông báo và sửa lỗi càng sớm càng tốt. Vậy thì đó chính là lỗi số một trong quy trình làm việc. Thứ hai là khả năng thử lại quy trình làm việc khi gặp lỗi. Điều này có nghĩa là bất cứ khi nào nút của chúng ta gặp lỗi, nó sẽ thử lại. Và bạn có thể kiểm soát bằng cách chờ trong khoảng thời gian này rồi thử lại, thử lại năm lần rồi tiếp tục,
3:51 tùy bạn muốn. Và trường hợp sử dụng ở đây là, bạn biết đấy, đôi khi máy chủ có thể ngừng hoạt động tạm thời hoặc đôi khi có một lỗi nhỏ. Đôi khi, chỉ cần đảm bảo các nút quy trình làm việc của bạn sẽ thử lại và cách bạn thực hiện điều đó nằm trong bất kỳ nút nào cũng là một điều tốt. Vì vậy, giống như một nút tác nhân AI, bạn sẽ vào phần cài đặt và bạn có thể thấy ngay tại đây, bạn có thể bật công tắc có nội dung thử lại khi không thành công. Vậy thì tôi sẽ bật nó lên. Và bạn có thể thấy nó mở ra hai mục khác cho biết số lần thử tối đa, số lần bạn muốn thử lại và thời gian chờ giữa các lần thử. Vì vậy, bạn có một vài đòn bẩy ở đây để kéo nhằm thay đổi cách thức hoạt động của logic thử lại này. Và như tôi đã nói, nó không chỉ là một nút tác nhân AI. Về cơ bản, nó là bất kỳ nút nào trong NN. Vì vậy, giống như Gmail API, bạn cũng có thể thử lại và thất bại. Và sau đó, ngay cả các nút lõi của Naden thậm chí không thực sự sử dụng
4:39 một máy chủ khác hoặc AI như một nút mã, bạn có thể yêu cầu nó thử lại khi yêu cầu HTTP không thành công, về cơ bản, bất kỳ nút nào ở đây cũng có thể thử lại và không thành công. Vì vậy, đó thực sự là một loại lỗi thử lại dễ thực hiện, loại có rào cản thấp để tham gia mà bạn có thể thực hiện. Có một loại kỹ thuật tiên tiến hơn gọi là thăm dò, không hẳn là thử lại thất bại nhưng tôi sẽ đề cập đến kỹ thuật này trong phần giới thiệu ở cuối video. Nhưng chúng ta hãy chuyển sang số ba, đó là có bằng LLM dự phòng. Vậy chúng ta hãy bắt đầu câu chuyện ở đây. Chúng ta có một tác nhân dự phòng với bộ định tuyến mở đóng vai trò là bộ não. Giả sử chúng ta vào đây và về cơ bản muốn thử lại khi thất bại ba lần. Được rồi. Nhưng điều xảy ra là tôi thiết lập thông tin xác thực bộ định tuyến mở này bằng một khóa giả. Vậy thì nó sẽ không hiệu quả. Vì vậy, khi tôi tiếp tục và cố gắng trò chuyện với người đại diện, điều chắc chắn sẽ xảy ra là thất bại. Nó sẽ thử lại lần nữa.
5:25 Nó sẽ thử lại lần nữa. Và nó đã thử ba lần trước khi đưa ra thông báo lỗi là thông tin đăng nhập không hợp lệ . Vì vậy, điều chúng ta có thể làm là sử dụng một kỹ thuật xử lý lỗi khác ở đây, trong đó chúng ta có thể thử lại nhưng cũng có thể thực hiện mô hình dự phòng. Vì vậy, nếu tôi kiểm tra điều này, về cơ bản nó cho phép chúng ta kết nối một mô hình khác trong trường hợp mô hình chính bị lỗi. Giả sử bộ định tuyến mở là lựa chọn ưa thích của chúng tôi và chúng tôi đang sử dụng GPT 4.1 mini. Bộ định tuyến mở bị hỏng hoặc AI mở bị hỏng. Điều chúng ta có thể làm là kết nối một mô hình khác ở đây và sử dụng Google Gemini. Và bây giờ chúng ta đã có mô hình này. Bây giờ nếu tôi lưu quy trình làm việc này và nói xin chào, nó sẽ thử mô hình đầu tiên, nhưng nó sẽ thất bại. Và sau đó điều xảy ra là nó chỉ chuyển sang mô hình dự phòng. Và bây giờ chúng ta phải đảm bảo rằng ít nhất chúng ta vẫn nhận được một số câu trả lời. Và nếu bạn không thấy tùy chọn mô hình dự phòng đó, tôi nghĩ đó
6:10 là bản phát hành mới của Naden 1.101 ở đâu đó gần đó. Vậy hãy tiếp tục cập nhật nó và bạn sẽ thấy điều đó. Được rồi, số bốn, như tôi đã nói, đây là số tôi thích nhất và tôi cảm thấy nó không được nhắc đến thường xuyên, nhưng đây là khả năng để các nút của bạn tiếp tục hoạt động ngay cả khi có lỗi. Vì vậy, đôi khi bạn có thể có một số logic dự phòng hoặc bất cứ thứ gì đó, nhưng vì lý do nào đó, có điều gì đó không hoạt động, nhưng điều bạn không muốn xảy ra là toàn bộ luồng của bạn dừng lại. Vậy hãy nghĩ về ví dụ này. Mỗi sáng, bạn phải xử lý hàng ngàn mục nhập mới và bạn muốn nghiên cứu và viết một số nội dung. Điều xảy ra là nếu bạn muốn lặp qua tất cả một nghìn lần chạy đó và mục đầu tiên bị lỗi, thì phần còn lại trong 999 mục sẽ không được xử lý. Nhưng nếu bạn có thể tiếp tục ngay cả khi có
6:56 lỗi, thì có thể 998 trong số đó là tốt, hai là xấu, nhưng ít nhất bạn không phải ngồi đó mà không có gì cả. Vậy để tôi cho các bạn xem một ví dụ nhanh về điều đó. Chúng ta có nút mã này . Đừng lo lắng về nút mã. Về cơ bản, tôi chỉ yêu cầu lệnh này đưa ra ba giá trị khác nhau cho chúng ta. Google, meta, Nvidia. Nó sẽ xuất ra các mục đó và lặp lại chúng và thực hiện nghiên cứu về chúng bằng Tavali. Và điều sẽ xảy ra là tôi đã thiết lập cái thứ ba để báo lỗi yêu cầu nội dung. Vì vậy, nếu tôi chạy thử thật nhanh, chúng ta sẽ thấy nó kéo ba mục đó vào. Nó sẽ lặp lại. Cái đầu tiên sẽ ổn thôi. Cái thứ hai sẽ ổn thôi. Và bây giờ lỗi thứ ba sẽ xảy ra. Và điều xảy ra là nó đã chặn dòng chảy. Vì vậy, nếu chúng ta phải xử lý thêm 20 mục nữa, nó sẽ không xử lý chúng. Và trong trường hợp các bạn tò mò, lý do khiến luồng dừng lại là vì tôi đã chuyển giá trị thực tế bằng dấu ngoặc kép. Vì vậy, nếu các bạn biết
7:42 nội dung JSON, nếu bạn có dấu ngoặc kép, thì yêu cầu đó sẽ bị hỏng . Vì vậy, các bạn có thể thấy nếu tôi đang chạy ở lượt đầu tiên, thì vẫn ổn vì truy vấn tìm kiếm là Google mà không có dấu ngoặc kép. Lần chạy thứ hai thì ổn, nhưng lần chạy thứ ba thì không thành công và Nvidia bị nháy kép. Vì vậy, điều chúng ta có thể làm là thay đổi cài đặt trong yêu cầu HTTP này thành Tavi để tiếp tục ngay cả khi một trong các lần chạy không thành công. Vì vậy, tôi có thể nhấp vào đây, tôi có thể vào phần cài đặt và tất cả những gì tôi phải làm là thay đổi lỗi, theo mặc định là dừng toàn bộ quy trình làm việc. Và chúng ta chỉ cần chuyển đổi nó để tiếp tục. Vậy thì đó là cùng một luồng chính xác. Tôi sẽ thực hiện điều này. Nó sẽ kéo theo ba mục đó. Nó sẽ lặp lại thông qua chúng. Cái đầu tiên thì tốt. Cái thứ hai thì tốt. Cái thứ ba thì lỗi, nhưng nó không làm dừng toàn bộ quy trình làm việc. Vậy, nếu bây giờ tôi vào nút Tavly, chúng ta có thể thấy hai nút đầu tiên đã chạy, đúng không? Họ có kết quả tìm kiếm của mình
8:28 và kết quả thứ ba về cơ bản chỉ gửi một thông báo lỗi, trong đó tham số JSON cần phải là JSON hợp lệ , nhưng nó vẫn tuân theo phần còn lại của vòng lặp. Và nếu có thêm 20 nữa thì 20 còn lại cũng sẽ được xử lý . Và sau đó, nếu chúng ta muốn theo dõi những thứ không hoạt động trong một nhánh riêng biệt mạnh mẽ hơn nữa, chúng ta thực sự có thể làm thêm một điều nữa là nếu tôi di chuyển trình kích hoạt này xuống đây, chúng ta có thể đưa các mục bị lỗi xuống một nhánh riêng biệt , đó là tiếp tục xử lý lỗi. Và vì vậy, các bạn có thể đã thấy điều này trong một số video khác của tôi, trong đó tôi có một số tác nhân thực hiện điều này để ghi lại, bạn biết đấy, các đầu ra khác nhau dựa trên việc liệu tôi thành công hay nếu tác nhân thất bại, nó sẽ thực hiện điều này. Nhưng để tôi cho các bạn xem một ví dụ nhanh nhé. Trong cài đặt của Tavi, chúng tôi chỉ thay đổi thao tác báo lỗi để tiếp tục sử dụng đầu ra lỗi tạo ra đầu ra bổ sung
9:13 . Và bây giờ nếu tôi kích hoạt chương trình này, nó sẽ chạy chính xác ba truy vấn đó. Cái đầu tiên sẽ ổn, cái thứ hai cũng ổn, cái thứ ba sẽ lỗi, nhưng không dừng quy trình làm việc. Và bây giờ bạn có thể thấy về cơ bản những gì đã xảy ra là chúng ta có hai mục đi xuống nhánh thành công. Ừm, hai người kia đâu rồi? Ngay tại đây. Tôi không thể di chuột qua nó được, nhưng bạn biết đấy, nó nằm ngay chính giữa. Và sau đó chúng ta có một mục đi xuống nhánh lỗi. Vì vậy, tôi có thể nhấp vào nút này. Chúng ta có thể thấy mục lỗi là Nvidia, nhưng hai mục thành công là Google và Meta như bạn có thể thấy. Vì vậy, bây giờ chúng ta có thể đưa thức ăn vào theo con đường này. Chúng ta có thể tạo ra một số logic mới như tự gửi email cho mình và nói rằng đây là các biến có lỗi hoặc tương tự như vậy để chúng ta vẫn có thể theo dõi. Được rồi, vậy thì số năm chính là cuộc thăm dò mà tôi đã
9:59 ám chỉ trước đó. Tôi đã nói là nó sẽ nằm trong phần bảo vệ nhưng tôi đã biến nó thành một phần riêng biệt, đúng không? Vì vậy, thăm dò về cơ bản là một kỹ thuật mà chúng ta sẽ kiểm tra trạng thái của một việc gì đó cho đến khi nó hoàn tất. Vì vậy, đây là ví dụ mà tôi dành cho các bạn, chúng ta sẽ thực hiện một yêu cầu tới PI API để tạo cho chúng ta một hình ảnh bằng AI. Điều xảy ra là chúng ta truy cập vào máy chủ API PI và nói rằng "Tôi muốn một hình ảnh và tôi muốn nó trông như thế này". Và sau đó họ bắt đầu làm việc trên sản phẩm đó. Và điều xảy ra là chúng ta cần đưa ra một yêu cầu khác để lấy lại được vật phẩm. Nhưng nếu chúng ta đưa ra yêu cầu và mục đó không được thực hiện, về cơ bản chúng ta sẽ không có hình ảnh, nhưng chúng ta vẫn có thể tiếp tục phần còn lại của quy trình làm việc. Vì vậy, chúng tôi sử dụng một kỹ thuật gọi là thăm dò ý kiến. Để tôi cho các bạn thấy nó trông như thế nào nhé . Tôi sẽ nhấn nút thực hiện quy trình làm việc. Về cơ bản, nó sẽ gửi yêu cầu tới PI API để tạo hình ảnh đó. Và sau đó chúng ta kiểm tra ngay tại đây xem
10:45 hình ảnh đã hoàn tất chưa. Và hình ảnh vẫn chưa hoàn thành. Bây giờ bạn có thể thấy chúng ta sẽ đợi cho đến khi hình ảnh hoàn thành. Vậy nên phải chờ đợi. Nó lại kiểm tra lần nữa. Vẫn chưa xong. Nó kiểm tra lại lần thứ ba. Vẫn chưa xong. Và chúng ta chỉ cần ngồi đây và kéo cho đến khi hình ảnh thực sự xuất hiện trở lại. Và đó là cách bạn có thể chắc chắn rằng mình không phải đắn đo với việc phải đợi 30 giây hay thời gian trung bình là bao lâu? Tôi có nên đợi một phút không? Điều này cho phép chúng ta đảm bảo rằng chúng ta chỉ tiếp tục đi xuống nhánh thực sự với phần còn lại của quá trình tự động hóa sau khi hoàn tất. Vì vậy, nếu bạn xem bất kỳ video ngắn nào của tôi hoặc bất kỳ video nào tương tự, chúng tôi luôn sử dụng kỹ thuật thăm dò để đảm bảo rằng tài sản của chúng tôi đã sẵn sàng. Vì vậy, bạn có thể thấy ở đây tổng cộng phải kiểm tra tám lần và đến lần thứ tám thì hình ảnh đã hoàn thành. Vì vậy, nếu tôi nhấp vào biểu thức nhỏ này ngay tại đây, chúng ta có thể thấy rằng thực ra chúng ta có URL hình ảnh. Để tôi mở nó ra để chứng minh với các bạn rằng nó ở đây. Và chúng ta có
11:32 bức ảnh đẹp về một người làm bánh quế . Và vì thế, tôi sẽ chỉ cho các bạn cách thức hoạt động của nó một cách nhanh chóng. Như tôi đã nói, đây là yêu cầu đầu tiên. Chúng tôi đang gửi yêu cầu tới PI API. Và chúng tôi nói, này, chúng tôi muốn một bức ảnh về một chiếc bánh quế được nhân cách hóa thành con người. Anh chàng bánh quế mặc vest và thắt cà vạt. Từ đó, chúng ta tính trọng số ban đầu. Vì vậy, tôi đặt 1 giây để làm ví dụ, nhưng thông thường bạn vẫn muốn đặt con số này là 40 hoặc tương tự như vậy. theo thời gian chờ trung bình. Sau đó, chúng tôi sẽ kiểm tra trạng thái yêu cầu của mình. Chúng tôi gửi ID tác vụ và những thông tin tương tự như vậy. Và những gì bạn có thể thấy là ở lần đầu tiên, chúng tôi nhận được mã 200. Vậy là không có lỗi nào xảy ra. Chúng tôi vẫn nhận được phản hồi thành công. Nhưng nếu chúng ta cuộn xuống, về cơ bản chúng ta có thể thấy rằng chúng ta không có URL. Và thực ra chúng ta đang tìm kiếm trường trạng thái ngay tại đây. Và nó nói rằng trạng thái tương đương với quá trình xử lý. Vì vậy, về cơ bản điều đó cho chúng ta biết
12:18 rằng chúng ta vẫn chưa hoàn thành. Trạng thái chạy thứ hai đang được xử lý. Trạng thái chạy thứ năm đang được xử lý. Nhưng đến ngày thứ tám , trạng thái đã hoàn tất. Vì vậy, tất cả những gì tôi tự nghĩ là, được rồi, làm sao chúng ta có thể đảm bảo rằng chúng ta không chuyển sang bước tiếp theo cho đến khi trạng thái hoàn tất? Vâng, những gì chúng ta sẽ làm là có một nút if ngay tại đây, chúng ta chỉ cần kiểm tra xem trạng thái có bằng hoàn thành hay không. Và khi nó xảy ra, nó sẽ đi xuống nhánh thật, nhưng bảy lần chạy trước đó, nó sẽ đi xuống nhánh giả. Và nhánh giả chỉ là, bạn biết đấy, phải chờ 20 giây , 5 giây, bất kể là bao lâu. Và sau đó nó quay trở lại. Vì vậy, đây là một vòng lặp vô hạn cho đến khi trạng thái bằng hoàn thành và sau đó chúng ta có thể cấu hình phần logic còn lại theo cách này cho đến nhánh thực. Về cơ bản thì đó là cách hoạt động của cuộc thăm dò. Chỉ cần nhớ rằng tùy thuộc vào dịch vụ bạn đang sử dụng, bạn có thể không cần phải kéo. Nhưng nếu bạn thực sự cần phải kéo, chúng sẽ luôn
13:04 khác nhau một chút về cách bạn thực hiện. Vì vậy, trạng thái bằng xử lý rồi trạng thái bằng hoàn thành hoặc trạng thái bằng chạy rồi trạng thái bằng xong. Vì vậy, bạn phải hiểu cả hai. một lượt chạy đang diễn ra trông như thế nào và một lượt chạy đã hoàn thành trông như thế nào và sau đó bạn có thể điều chỉnh logic có điều kiện của mình. Được rồi. Và cuối cùng, tôi chỉ muốn cho các bạn xem một ví dụ về lan can. Nhưng tôi muốn nói nhanh về tư duy xử lý lỗi và xây dựng các biện pháp phòng ngừa. Vì vậy, điều tôi luôn muốn nói là bạn không biết những gì bạn không biết. Và khi bạn xây dựng một sơ đồ dây thực sự chắc chắn và nghĩ về nguồn dữ liệu cũng như quá trình chuyển đổi của mình, bạn cũng có thể nghĩ về những điều có thể xảy ra sai sót. Và bạn luôn phải cho rằng có nhiều thứ có thể xảy ra sai sót hơn thế nữa vì thế giới này rất khó đoán và LLM cũng vậy,
13:50 bạn không biết mọi người sẽ nói gì với hệ thống của bạn hoặc bạn không biết hệ thống của bạn có thể nhận được loại thông tin đầu vào nào . Vì vậy, vì chúng tôi có một hệ thống mà chúng tôi có thể ghi lại tất cả các lỗi và hy vọng có thể thấy được toàn bộ quá trình thực thi, đó là nơi chúng tôi có thể xác định, được rồi, khi chúng tôi nhận được kết quả tệ, tại sao lại như vậy? Hoặc khi chúng ta thực sự nhận được thông báo lỗi, tại sao lại như vậy? Và trong tự động hóa, người bạn tốt nhất của bạn chính là khả năng dự đoán. Vì vậy, nếu bạn có thể phát hiện ra các mẫu trong một số lỗi nhất định, về cơ bản, điều đó tạo ra một chút khả năng dự đoán về thời điểm loại đầu vào này đi qua, điều gì xảy ra, nó bị hỏng ở đâu và tôi có thể xây dựng gì để bảo vệ nó khỏi bị hỏng ngay tại đó, và sau đó bạn có thể thực hiện. Vậy, một ví dụ thực tế nhanh thường xảy ra với tôi trong một số quy trình sản xuất và rất dễ quên là
14:37 yêu cầu nội dung của API bị hỏng. Vì vậy, chúng ta sẽ quay lại ví dụ Tavly mà chúng ta đã sử dụng ở trên khi thực hiện lệnh continue on error. Vì vậy, như các bạn đã biết, nếu chúng ta gửi một cái gì đó đến một yêu cầu nội dung, nó sẽ thất bại nếu nó có dấu ngoặc kép hoặc dòng mới hoặc bất cứ thứ gì tương tự như vậy. Vậy nên, những gì tôi đã làm ở đây là tôi đặt dứa trên bánh pizza với dấu ngoặc kép, và điều đó được đưa vào yêu cầu trên máy tính bảng của chúng ta ở đây trong phần thân, tất nhiên là nó sẽ bị hỏng vì có dấu ngoặc kép . Và điều xảy ra có thể là bạn có một nút AI đang đưa vào yêu cầu về cơ thể, những thứ tương tự như vậy. Và trong môi trường thử nghiệm, nó hoạt động vì bạn không phải xử lý những dấu ngoặc kép đó. Nhưng nếu bạn biết điều đó sẽ phá vỡ tính năng tự động hóa hoặc phá vỡ các yêu cầu, thì bạn có thể xây dựng một rào chắn trước để đảm bảo điều đó không bao giờ xảy ra. Vì vậy, chúng ta có thể sử dụng tập lệnh thực sự đơn giản này, bất kể bạn muốn gọi nó là gì, trong đó nó
15:22 chỉ nói rằng tôi sẽ thay thế bất kỳ dấu ngoặc kép nào. Và bây giờ chúng ta không còn thứ gì cả. Vì vậy, như bạn có thể thấy, nếu tôi xóa nó đi, chúng ta sẽ có dấu ngoặc kép. Tôi dán đoạn đó vào và bây giờ chúng ta không còn dấu ngoặc kép nữa. Vì vậy, về cơ bản, điều này đảm bảo rằng bất kể chuyện gì xảy ra, chúng ta vẫn có thể để Tavi xử lý thông tin mọi lúc. Và thực ra, điều khá tuyệt là nếu chúng ta loại bỏ yêu cầu HTTP này vì Tavi thực sự chỉ có một nút cộng đồng đã được xác minh, nếu bạn không biết. Vì vậy, chúng tôi đã kết nối với Tavi và tất cả những gì tôi phải làm là kéo truy vấn tìm kiếm của mình vào đây. Và điều xảy ra là, thực ra điều này có liên quan đến điều sai trái. Vì vậy, tôi đang kéo kết quả này vào truy vấn tìm kiếm của chúng tôi . Chúng tôi có quả dứa trên bánh pizza với dấu ngoặc kép. Nhưng các bạn có thể thấy tôi có thể thực hiện nó và nó vẫn hoạt động vì những gì tôi cho là đang diễn
16:08 ra ở phía sau là Tavi đã biết về điều này và họ đã xây dựng sẵn rào chắn đó khi họ tạo ra nút cộng đồng này, bạn biết đấy, ừm, vì dù tôi có thêm dứa vào pizza bằng dấu ngoặc kép hay không thì cả hai đều vẫn hoạt động. Vì vậy, đôi khi nếu một nút cộng đồng đã được xác minh hoặc bạn biết có một nút gốc khả dụng thì hãy chọn nút đó vì chúng có thể đã tích hợp sẵn một số biện pháp xử lý lỗi và rào cản. Và nhân tiện, nếu các bạn muốn truy cập toàn bộ mẫu này miễn phí chỉ để thử nghiệm một số cách xử lý lỗi thì các bạn có thể nhận nó miễn phí như tôi đã nói trong cộng đồng trường học miễn phí của tôi . Tất cả những gì bạn phải làm là tham gia vào liên kết trong phần mô tả. Và khi bạn vào đây, chỉ cần tìm kiếm tiêu đề của video ở đây. Hoặc nếu bạn nhấp vào tài nguyên YouTube và đi đến tiêu đề của video, bạn sẽ có thể thấy tệp JSON và đó là tệp bạn sẽ tải xuống và nhập vào NN của mình.
16:54 Và bạn sẽ có ngay mẫu chính xác mà chúng ta đã xem xét ngày hôm nay. Nếu bạn thích loại nội dung này và muốn thảo luận thêm về các vấn đề như quy trình làm việc sẵn sàng sản xuất và xử lý lỗi, cũng như muốn giao lưu với một cộng đồng gồm những người có cùng chí hướng, thì hãy tham gia cộng đồng trả phí của tôi. Đường dẫn đến trang đó cũng nằm ở phần mô tả bên dưới. Chúng tôi có một cộng đồng tuyệt vời với hơn 2.000 thành viên đang cùng Nitto xây dựng, triển khai quy trình sản xuất mỗi ngày và chia sẻ những bài học kinh nghiệm cũng như thách thức của họ. Chúng tôi cũng có một phần lớp học với hai khóa học đầy đủ, agent zero, là nền tảng về AI dành cho người mới bắt đầu và sau đó là 10 giờ đến 10 giây, nơi bạn học cách xác định, thiết kế và xây dựng hoạt ảnh thời gian. Vì vậy, tôi rất mong được gặp các bạn ở những cộng đồng đó. Nhưng thế là hết video rồi. Nếu bạn thích hoặc học được điều gì mới, hãy thích nhé. Chắc chắn giúp ích cho tôi rất nhiều. Và như thường lệ, tôi rất cảm kích vì các bạn đã theo dõi đến hết video. Hẹn gặp lại bạn
17:40 ở bài viết tiếp theo.
