Làm thế nào để trở thành chuyên gia tư vấn AI? [Video và bài kiểm tra]

Câu trả lời ngắn gọn: Trở thành chuyên gia tư vấn AI bằng cách hoàn thành một chu trình làm việc thực tế có trả phí, chứ không phải bằng cách tích lũy danh hiệu. Nắm vững LLM, truy xuất dữ liệu và đánh giá rủi ro mô hình, sau đó tiến hành khám phá, thử nghiệm, viết báo cáo và triển khai. Nếu không có quyền truy cập vào hệ thống, dữ liệu hoặc những người đang thực hiện công việc, hãy từ chối yêu cầu.

Những điểm chính cần ghi nhớ:

Hoàn thành một chu trình: Thực hiện tìm kiếm thông tin trả phí, một dự án thí điểm nhỏ, viết báo cáo và triển khai.

Đặt tên cho lời đề nghị: "Tôi giúp X làm Y mà không cần Z" và nhận tiền.

Trách nhiệm giải trình: Chỉ định người chịu trách nhiệm, ghi chép nhật ký quyết định và nêu rõ ai phải chịu trách nhiệm.

Tính minh bạch: Trước tiên hãy lập sơ đồ quy trình làm việc; bản demo không phải là một chẩn đoán.

Khả năng chống lạm dụng: Không bao giờ hứa hẹn độ chính xác chưa được đo lường hoặc rằng trí tuệ nhân tạo tạo sinh sẽ sửa chữa dữ liệu xấu.

Công việc mà chẳng ai có thể mô tả chính xác (và tại sao đó lại là vị trí tuyển dụng của bạn)

Đây không phải là một kỹ sư xử lý sự cố có vẻ "cao cấp" hơn một chút với một chiếc máy tính xách tay xịn hơn. Ý tôi là, đôi khi mọi chuyện trông có vẻ như vậy trong một tuần. Sau đó là một cuộc phỏng vấn tìm hiểu với một trưởng bộ phận tài chính mệt mỏi, một cuộc kiểm tra tính sẵn sàng của dữ liệu cho thấy chỉ có ba bảng tính và một lời cầu nguyện, và một cuộc trò chuyện về quản lý thay đổi về lý do tại sao bản demo truy xuất lại bị lỗi khi tiếp xúc với quyền truy cập sản xuất.

Phiên bản đáng giá nhất nằm giữa ba căn phòng chật chội:

• Ban lãnh đạo hỏi "chiến lược AI của chúng ta là gì?" mà không hề thống nhất về những gì bộ phận kinh doanh thực sự muốn

• Những người xây dựng có thể dựng lên một nguyên mẫu trước giờ ăn trưa, rồi sau đó biến mất vào những tranh luận về rủi ro mô hình

• Những người điều hành phải sống chung với bất cứ thứ gì bạn để lại

Bạn chính là mắt xích kết nối. Đó là phần khan hiếm. Nếu bạn có thể điều hành một buổi hội thảo, viết một bản mô tả công việc (SOW) chặt chẽ và ngăn chặn một nhóm nhồi nhét LLM vào quy trình làm việc vốn chỉ cần một ô chọn, thì bạn đã có giá trị hơn một nửa số người khác rồi.

Có một cách hình dung không hoàn hảo, nhưng tôi vẫn sẽ dùng cách đó: bạn là một thợ sửa ống nước kiêm luôn việc giải thích về vấn đề nước cho hội đồng quản trị. Bước vào phòng với vẻ mệt mỏi, sự phát hiện của bạn vẫn phải thật sắc bén.

Những khoản nào được tính phí (chiến lược, xây dựng và giai đoạn giữa không mấy hào nhoáng)

Khách hàng không trả tiền cho bạn để bạn "hiểu biết về AI". Họ trả tiền khi vấn đề đó tốn kém, mang tính chính trị hoặc gây khó xử đến mức việc thuê người ngoài sẽ rẻ hơn so với việc giải quyết bế tắc nội bộ.

Ba cái xô, và nước từ chúng rò rỉ vào nhau:

• Chiến lược. Phân loại trường hợp sử dụng, "liệu chúng ta có nên làm không?", phác thảo quản trị, thảo luận về rủi ro mô hình khiến bộ phận pháp lý phải cảnh giác. Độ tin cậy cao và rất dễ giả mạo nếu bạn chỉ nói trong khuôn khổ. Đừng làm vậy.

• Xây dựng. Nguyên mẫu, người hỗ trợ, truy xuất, thiết kế quy trình làm việc, tự động hóa cơ bản. Điều này giúp bạn bước chân vào lĩnh vực này, nhưng cũng có thể khiến bạn bị mắc kẹt nếu trở thành nhóm triển khai không được trả lương.

• Quản lý và tạo điều kiện cho sự thay đổi. Sổ tay hướng dẫn, đào tạo, "cách thức triển khai". Điều đáng ngạc nhiên là, đây thường là những phần được chú trọng nhất nhưng lại ít được phô trương nhất.

Việc nhắc nhở kịp thời rất quan trọng, đúng vậy. Nhưng đừng quá chú trọng vào nó. Nó chỉ là gia vị, chứ không phải bản thân món ăn. Sự sẵn sàng của dữ liệu, việc lập bản đồ các bên liên quan và một quy trình khám phá rõ ràng sẽ giúp cứu vãn nhiều dự án hơn là một lời nhắc nhở hệ thống thông minh.

Một mâu thuẫn nhỏ mà tôi luôn phải sống chung: bạn cần đủ sự lưu loát để phản bác những điều vô lý, và đủ sự kiềm chế để không xây dựng mọi thứ trước khi hỏi ai là người chịu trách nhiệm về kết quả. Tôi đoán đó là toàn bộ bản chất của nghề này, dù diễn đạt không được tốt lắm.

Năm con đường không cần đến nguồn gốc thần thoại

Không có một con đường duy nhất. Có nhiều môi trường sống khác nhau, và chúng tác động đến con người theo những cách khác nhau. Hãy chọn môi trường mà bạn có thể sống sót.

Không có lựa chọn nào tốt hơn về mặt đạo đức. Làm việc độc lập nghe có vẻ lãng mạn cho đến khi bạn định giá sai một phát hiện. Làm việc nội bộ nghe có vẻ an toàn cho đến khi bạn trở thành người được chỉ định để thực hiện mọi ý tưởng chatbot.

Làm thế nào để trở thành một chuyên gia tư vấn AI? Hãy bắt đầu với một vấn đề thực tế, chứ không phải chỉ là một chức danh công việc

Câu trả lời thẳng thắn cho câu hỏi "Làm thế nào để trở thành một chuyên gia tư vấn AI?" gần như là một lời xúc phạm vì tính thực tế. Hãy ngừng thu thập thông tin cá nhân. Hãy bắt đầu thu thập những vấn đề mà bạn có thể giải quyết.

1. Hãy thành thạo đến mức có thể gây nguy hiểm theo đúng nghĩa. LLM, thu hồi, phi công phụ, tự động hóa cơ bản, nơi rủi ro mô hình tồn tại. Bạn không cần phải huấn luyện bất cứ thứ gì từ đầu.

2. Ngồi cạnh một quy trình làm việc thực tế. Vận hành bán hàng, hỗ trợ, quyết toán tài chính, tìm kiếm kiến ​​thức. Quan sát xem công việc bị tồn đọng ở đâu.

3. Thực hiện một chu trình hoàn chỉnh. Khám phá, thử nghiệm thí điểm nhỏ, viết báo cáo về những lỗi gặp phải, và hướng dẫn sử dụng cho những người cần vận hành nó.

4. Hãy nêu rõ tên người đưa ra lời đề nghị. "Tôi giúp X làm Y mà không cần Z." Lời đề nghị không hay thì được, nhưng mơ hồ thì không.

5. Hãy nhận tiền công, ngay cả khi tấm séc đầu tiên có vẻ khó khăn. Những công việc "dự án" không được trả công thường sẽ mãi không được trả công.

Nếu bạn có nền tảng về kỹ thuật, điểm yếu của bạn thường là hiểu về các bên liên quan và ngôn ngữ thể hiện lợi tức đầu tư (ROI). Nếu bạn đến từ lĩnh vực chiến lược hoặc vận hành, điểm yếu là khả năng phân biệt khi nào bản demo chỉ là màn kịch. Dù sao đi nữa: hãy mượn một vấn đề thực tế, hoàn thành nó và mô tả nó một cách ngắn gọn, không thêm thắt chi tiết.

Tôi suýt nữa đã viết "xây dựng thương hiệu cá nhân" ở đây. Nhưng tôi sẽ không làm vậy. Một lời đề nghị rõ ràng và một vài người sẵn sàng nghe điện thoại của bạn sẽ tốt hơn nhiều so với một cỗ máy tạo nội dung không bao giờ tính phí. Công việc thì quanh co hơn cả việc chào hàng. Đó mới là con đường đúng đắn.

Hãy chọn một lĩnh vực thích hợp mà không cần đóng cửa lại

Tóm lại. Các phân khúc thị trường.

Lời khuyên chuyên biệt thường là "chọn một khách hàng lý tưởng (ICP) hoặc thất bại" hoặc "giữ vững lập trường chung". Cả hai đều đúng một nửa và hơi khó chịu. Một thị trường ngách hiệu quả ở đây thường là quy trình làm việc + người mua, chứ không phải một nhóm khách hàng mẫu. Hỗ trợ các nhà lãnh đạo đang ngập trong các yêu cầu. Các nhóm vận hành với các quy trình chuyển giao rối rắm. Những người làm về rủi ro cần một hệ thống quản trị không phải là một bản PDF dài chín mươi trang mà chẳng ai đọc.

Bạn được phép thay đổi sau này. Ban đầu, một lĩnh vực chuyên môn chỉ là một bộ lọc, chứ không phải là hình xăm. Đừng tự bó buộc mình vào việc "Tôi chỉ sử dụng công cụ mình mới học tháng trước". Các công cụ sẽ thay đổi liên tục. Còn việc đánh giá về độ sẵn sàng của dữ liệu, quản lý thay đổi và liệu một dự án thí điểm có cơ hội thành công hay không... thì cần thời gian.

Thêm một điều nữa, tôi viết với dấu gạch ngang đặt sai vị trí vì đó là cách ghi chú của tôi trông như thế: thị trường ngách là cánh cửa mở ra, chứ không phải là cái lồng. Nếu bạn có thể giải thích được tuần làm việc của người mua, thì bạn đã đủ chuyên môn rồi.

Khách hàng đầu tiên, bằng chứng và vấn đề khó xử trong giai đoạn đầu của danh mục đầu tư

Đây là phần mà chẳng ai thích cả. Bạn cần bằng chứng. Bạn không có loại bằng chứng mà người mua yêu cầu. Công việc được trả tiền đầu tiên thường là kiểm tra quy trình làm việc phức tạp, chứ không phải là một mô hình đột phá. Điều đó là bình thường.

Khi không có những nghiên cứu điển hình hấp dẫn, điều gì được coi là bằng chứng?

• Một cuộc chẩn đoán tập trung: hệ thống, sự sẵn sàng của dữ liệu, LLM sẽ hữu ích ở đâu và sẽ gây ra những sai lệch chính sách

• Một buổi hội thảo tạo ra các trường hợp sử dụng được xếp hạng cùng với người chịu trách nhiệm, chứ không phải là một cuộc thảo luận ý tưởng đơn thuần

• Một dự án thí điểm nhỏ với so sánh trước/sau về thời gian hoàn thành - giữ cho các con số ở mức độ địa phương và trung thực, không bị thổi phồng

• Hỗ trợ và duy trì năng lực: một cẩm nang ngắn gọn mà nhóm vẫn sử dụng sau khi bạn rời đi

Làm thế nào để bạn tiếp cận những khách hàng đầu tiên: đồng nghiệp cũ đã tin tưởng bạn (hầu hết mọi người đều bắt đầu như vậy, đừng giả vờ); công việc liên quan nếu bạn đã làm về vận hành; thời gian làm thêm cho một nhóm cần người có đầu óc chuyên môn một ngày mỗi tuần.

Đừng bịa đặt ra một danh mục đầu tư. Hãy bịa ra một câu chuyện mạch lạc về vấn đề, những gì bạn đã thử, những gì thất bại và những gì bạn sẽ làm tiếp theo. Người mua bị đánh lừa bởi những lời lẽ sáo rỗng có thể nhận ra sự giả tạo. Họ thường tôn trọng câu nói "điều này không hiệu quả vì nguồn dữ liệu tìm kiếm chỉ là một mớ hỗn độn"

Có thể nói hơi phóng đại một chút: ba khách hàng đầu tiên dạy bạn nhiều hơn bất kỳ khóa học nào. Tuy nhiên, một khóa học buộc bạn phải triển khai ứng dụng thử nghiệm cũng không phải là vô ích. Tôi rút lại lời nói của mình, một chút.

Giá cả, phí giữ chân khách hàng và cách nói không mà không tỏ ra kiêu căng

Việc định giá là nơi mà những người có năng lực thường cảm thấy ngại ngùng. Họ giảm giá vì cảm thấy mình là người mới. Sau đó, họ cảm thấy khó chịu với công việc. Và rồi mọi thứ trở nên cẩu thả.

• Hãy cân nhắc giá trị của quyết định, chứ không phải số giờ, khi bạn có thể. Một phát hiện giúp gỡ rối một vấn đề lớn không phải là chuyện "vài ngày".

• Hợp đồng tư vấn định kỳ phù hợp với việc hỗ trợ, kiểm tra quản trị và tư vấn bán thời gian. Tuy nhiên, chúng không phù hợp nếu khách hàng muốn một chu kỳ phát triển phần mềm mà không có người chịu trách nhiệm chính từ phía họ.

• phạm vi công việc (SOW) cần nêu rõ "hoàn thành" trông như thế nào. Nếu không thể mô tả được, bạn không thể định giá. Chấm hết.

• Hãy từ chối khi yêu cầu chỉ là "hãy lập cho chúng tôi một chiến lược AI" mà không cho phép bạn tiếp cận hệ thống, dữ liệu hoặc những người đang thực hiện công việc đó.

Mức phí theo ngày khá thẳng thắn nhưng nó giúp giữ cho phạm vi công việc không bị thu hẹp quá nhiều. Mô hình kết hợp khá phổ biến: tìm hiểu thông tin trả phí, sau đó là giai đoạn thử nghiệm với mức phí cố định, rồi đến hợp đồng dài hạn nếu họ vẫn muốn bạn tiếp tục hợp tác. Tôi sẽ không đưa ra những con số giả. Bất cứ ai đưa ra mức phí theo ngày chung cho tất cả khách hàng đều đang cố bán một thứ gì đó. Hãy so sánh chi phí của các công việc tư vấn tương tự trong lĩnh vực của bạn - ví dụ như tư vấn sản phẩm, quản lý vận hành bán thời gian.

Đạo đức, rủi ro và những lời hứa sẽ ám ảnh bạn

Phần này tồn tại vì hậu quả của sự mệt mỏi sau đó. Đừng hứa hẹn độ chính xác mà bạn không thể đo lường. Đừng hứa rằng cả một nhóm sẽ biến mất "một khi hệ thống phụ hoạt động". Đừng hứa rằng trí tuệ nhân tạo tạo sinh sẽ khắc phục vấn đề chất lượng dữ liệu mà trên thực tế nó sẽ làm trầm trọng thêm. Đừng hứa hẹn tính bảo mật mà bạn chưa vận hành: dữ liệu đi đâu, ai ghi nhật ký nhắc nhở, những gì được lưu giữ.

Rủi ro mô hình không phải là một khẩu hiệu bạn chỉ cần thêm vào slide. Nó là "điều này chắc chắn sẽ sai trong một quy trình làm việc được kiểm soát chặt chẽ". Quản trị là người anh em không hấp dẫn: quyền truy cập, đánh giá, xem xét của con người, nhật ký kiểm toán. Nếu bạn bỏ qua nó, người khác sẽ phát hiện ra lỗ hổng trong quá trình sản xuất.

Ngoài ra còn có những nguyên tắc đạo đức nhỏ hơn: đừng dọa dẫm khách hàng bằng những chương trình khổng lồ khi mà việc thiết kế lại quy trình làm việc trong hai tuần là đủ. Đừng chào bán một hệ thống truy xuất tùy chỉnh khi vấn đề thực sự là quyền tìm kiếm tốt hơn.

Một phép ẩn dụ hơi gượng ép: Tư vấn AI mà thiếu đạo đức giống như một cái chuông báo cháy kiêm luôn bán diêm. Nghe có vẻ hay ho cho đến khi không còn hay nữa. Bạn sẽ được yêu cầu "cứ đưa nó vào sản xuất" sau một buổi trình diễn thành công. Hãy dành thời gian để thảo luận kỹ hơn về việc đánh giá và ai sẽ chịu trách nhiệm khi mô hình tự điều chỉnh.

Khi bản demo không phải là một chẩn đoán

Công cụ thì hấp dẫn. Chúng khiến bạn trông nhanh nhẹn. Các bên liên quan vỗ tay tán thưởng. Rồi đến thứ Hai.

Bản demo trả lời câu hỏi "liệu hệ thống này có thể tạo ra kết quả hợp lý hay không?". Bản chẩn đoán trả lời câu hỏi "tổ chức này có nên sử dụng nó ở đây, với dữ liệu này, những người này, và mức độ chấp nhận rủi ro này hay không?". Mỗi lĩnh vực lại khác nhau.

Hãy để ý những dấu hiệu này: không ai có thể cho bạn thấy quy trình hiện tại từ đầu đến cuối; "cơ sở kiến ​​thức" là một mớ hỗn độn trên ổ đĩa dùng chung mà không có người quản lý; thành công được định nghĩa là "chúng tôi đã ra mắt một sản phẩm"; người hỗ trợ chỉ dựa vào một quy trình làm việc đã gặp lỗi vì những lý do không liên quan đến trí tuệ nhân tạo.

Công việc của bạn, thường là, làm chậm nhịp độ của cuộc họp. Không phải vì bạn quá cầu kỳ. Mà vì một người điều khiển tồi sẽ làm hỏng cả nhóm. Hãy thực hiện việc tìm hiểu một cách nghiêm túc. Lập sơ đồ quy trình làm việc. Hỏi xem ai sẽ chịu trách nhiệm nếu có sai sót. Sau đó hãy chọn công cụ.

Phán đoán là sản phẩm. Trình bày chỉ là hình thức bên ngoài. Tôi nói điều này khi biết rõ rằng một bản mẫu hoàn chỉnh vẫn mở ra những cánh cửa mà một bản ghi nhớ không bao giờ làm được. Hãy sử dụng bản demo như bằng chứng trong quá trình chẩn đoán, chứ không phải là sự thay thế. Nó chứng tỏ giá trị của mình; tùy thuộc vào hoàn cảnh, một bài kiểm tra thực tế có thể hiệu quả hơn một bản trình bày được trau chuốt kỹ lưỡng. Hãy quan sát tình hình. Sau đó, cứ tiến hành thử nghiệm.

Vận hành, hợp đồng, giao hàng: phần công việc không mấy hào nhoáng

Nếu bạn làm việc độc lập hoặc theo mô hình studio, công việc kinh doanh sẽ cố gắng "nuốt chửng" hoạt động tư vấn. Hộp thư đến, hóa đơn, hợp đồng, "bạn có thể gọi điện thoại được không?"

Số lượng người lớn tối thiểu cần thiết để chuẩn bị:

• Một hợp đồng đơn giản: phạm vi, sở hữu trí tuệ, bảo mật, xử lý dữ liệu, chấm dứt hợp đồng

• Mỗi hợp đồng cần có một bản mô tả phạm vi công việc (SOW), ngay cả với những người bạn thích. Đặc biệt là với những người bạn thích.

• Chu kỳ giao hàng: ghi chú hàng tuần, nhật ký quyết định, rủi ro. Khô khan. Vàng.

• Các tệp tin không có trong thư mục tải xuống của bạn, cùng với các quy tắc truy cập cho các hệ thống mà bạn sử dụng

Việc hoàn thành nhiệm vụ là nơi danh tiếng được xây dựng và phát huy. Hãy đọc kỹ tài liệu trước khi tham gia. Đừng biến mất giữa các buổi hội thảo. Khi phi công gặp sự cố, hãy báo sớm và đưa ra các phương án giải quyết, chứ không phải lời xin lỗi muộn màng dưới dạng cập nhật tình trạng.

Nếu bạn rời đi và chỉ mình bạn điều hành mọi việc, điều đó có nghĩa là bạn không tham khảo ý kiến; bạn trở thành nút thắt cổ chai với mức lương theo ngày. Hãy hướng dẫn, ghi chép lại, rồi bàn giao.

Con đường này rốt cuộc dẫn đến điều gì?

Vậy nên, đúng vậy, "Làm thế nào để trở thành một chuyên gia tư vấn AI?" là một câu hỏi có câu trả lời hơi khô khan. Nắm vững hệ thống đến mức có thể nhận ra đó là điều hư cấu. Tham gia vào một quy trình làm việc thực tế. Hoàn thành một vòng lặp. Tính phí cho việc đánh giá. Từ chối những thứ hào nhoáng.

Con đường này không phải là một khóa học, một tấm huy hiệu, hay một tiêu đề hồ sơ được đổi tên. Đó là những vấn đề có giới hạn, được trả phí, nơi bạn đã giúp con người đưa ra quyết định tốt hơn về chiến lược AI, tự động hóa, hoặc một trợ lý phi công mà lẽ ra chưa từng tồn tại. Rồi lại thêm những vấn đề khác nữa.

Bạn không cần phải là người thông minh nhất trong cuộc họp đánh giá rủi ro mô hình. Bạn cần là người vẫn có thể giải thích được công việc ngay cả khi các slide đã được đóng lại. Điều đó hiếm hơn so với lẽ ra phải vậy. Và chỉ cần như thế là đủ để bắt đầu.

Ví dụ thực tế: Chương trình hỗ trợ khách hàng kéo dài hai tuần như một hoạt động quảng cáo trả phí đầu tiên

Kịch bản

Maya 34 tuổi. Cô đã có sáu năm kinh nghiệm làm việc trong bộ phận vận hành tại một công ty môi giới bảo hiểm khu vực, là người mà các đồng nghiệp liên lạc khi một bài kiểm tra Copilot đưa ra câu trả lời sai nhưng đầy tự tin về cách diễn đạt trong hợp đồng bảo hiểm. Cô ấy có thể điều hành một buổi hội thảo, viết một bản tóm tắt ngắn gọn và biết khi nào một quy trình làm việc cần một ô chọn thay vì một mô hình. Cô ấy không thể đào tạo bất cứ thứ gì từ đầu, và cô ấy cũng không giả vờ là như vậy.

Tháng 3 tới, cô ấy sẽ nghỉ việc để thử làm tự do. Công ty không có hệ thống tiếp nhận cuộc gọi tự động. Có Dan, một đồng nghiệp cũ, hiện là Trưởng bộ phận Hỗ trợ Khách hàng tại Northline, một công ty SaaS B2B với 180 nhân viên ở Manchester. Bốn nhân viên hỗ trợ. Một ổ đĩa dùng chung không có người quản lý. Ban lãnh đạo đã bắt đầu đề cập đến việc thử nghiệm chatbot trong các cuộc họp toàn thể. Các nhân viên hỗ trợ đã âm thầm ngừng mở nó. Dan cần sự giúp đỡ trước cuộc họp điều hành tiếp theo, chứ không phải là việc đổi tên chức danh công việc của mình.

Maya không bán "chiến lược AI". Cô ấy bán một gói khám phá cố định kéo dài hai tuần: lập bản đồ cách một yêu cầu được xử lý trong thực tế, xác định AI tạo sinh sẽ hữu ích ở đâu và sẽ gây ra rắc rối ở đâu, và đề xuất một dự án thí điểm có giới hạn với người chịu trách nhiệm cụ thể. Nếu kết quả là "sửa lỗi quyền truy cập và viết các bài viết còn thiếu", thì đó chính là sản phẩm cần bàn giao. Dan trả tiền cho quyết định, chứ không phải cho một nguyên mẫu mà cô ấy chưa xác định phạm vi.

Những gì nhà tư vấn cần

• Bản báo cáo công việc một trang nêu rõ những việc đã "hoàn thành": sơ đồ quy trình làm việc, danh sách các trường hợp sử dụng được chấm điểm kèm người chịu trách nhiệm, quyết định tiếp tục hay dừng dự án thí điểm, và bản mô tả hai trang về những vấn đề có thể gây lỗi

• Truy cập vào 12 phiếu yêu cầu hỗ trợ đã được giải quyết gần đây thuộc loại "tôi phải làm thế nào / chính sách là gì", đã loại bỏ tên khách hàng

• Chỉ được phép truy cập đọc vào trung tâm trợ giúp, ổ đĩa dùng chung và nhật ký ghi lại cuộc trò chuyện chatbot bị bỏ dở

• Mỗi buổi 45 phút với hai đặc vụ, trưởng nhóm và người được cho là sở hữu kho kiến ​​thức (có thể chẳng ai cả; đó là một phát hiện)

• Dan là người đưa ra quyết định, và sẽ có cơ hội chấp nhận hoặc từ chối đề xuất này vào tuần thứ hai

• Quy tắc bảo mật dữ liệu bằng văn bản: không sử dụng dữ liệu cá nhân khách hàng trong các công cụ dành cho người tiêu dùng, không ghi chép dữ liệu sản xuất, mọi thứ liên quan đến khách hàng đều phải được con người xem xét

• Một nhật ký quyết định đơn giản. Khô khan. Sẵn sàng ngay khi ai đó hỏi "tại sao chúng ta không khởi chạy bot?"

Ví dụ hướng dẫn

Maya đưa điều này vào bản mô tả công việc, bằng ngôn ngữ thông thường, chứ không phải trong hộp thoại nhắc nhở:

Bạn đang thuê tôi để chẩn đoán quy trình trả lời hỗ trợ khách hàng của Northline, chứ không phải để cài đặt chatbot. Trong mười ngày làm việc, tôi sẽ (1) theo dõi quy trình hiện tại, (2) chỉ ra những bước nào chậm do thiếu bài viết, quyền hạn hoặc chuyển giao, (3) đánh giá xem liệu trợ lý tìm kiếm có thể soạn thảo câu trả lời ở đâu so với việc sử dụng mô hình ngôn ngữ là không phù hợp, và (4) đề xuất một chương trình thử nghiệm với người chịu trách nhiệm, quy tắc dừng và một bộ thử nghiệm gồm 12 phiếu yêu cầu. Tôi sẽ không đưa bất cứ thứ gì ra trước mặt khách hàng. Tôi sẽ không hứa hẹn tiết kiệm nhân sự. Nếu thử nghiệm chatbot không phù hợp, tôi sẽ nói rõ điều đó bằng chứng cứ từ các phiếu yêu cầu, chứ không phải bằng một khuôn khổ nào cả.

Nếu sau này Northline muốn thử nghiệm việc thu hồi dữ liệu, hướng dẫn cho công cụ cũng rất đơn giản:

Hãy soạn thảo câu trả lời cho yêu cầu này chỉ sử dụng các bài viết trợ giúp được liên kết. Trích dẫn tiêu đề bài viết. Nếu câu trả lời không có trong các bài viết đó, hãy nói "không có trong kho dữ liệu" và dừng lại. Không được tự bịa ra thời gian hoàn tiền, ngoại lệ theo khu vực hoặc số liệu SLA.

Đoạn văn thứ hai chỉ là gia vị. Bản mô tả công việc mới là món chính.

Một bản nháp tốt sẽ trông như thế này: "Không có trong dữ liệu. Thời hạn hoàn tiền không được nêu trong 40 điều khoản. Hãy chuyển vấn đề này cho bộ phận thanh toán." Một bản nháp tồi sẽ trông như thế này: "Theo quy định, bạn đủ điều kiện được hoàn tiền trong vòng 14 ngày. Tôi đã phê duyệt yêu cầu của bạn." Sự khác biệt nằm ở toàn bộ rủi ro.

Cách kiểm tra nó

Trước khi tuyên bố hoàn tất việc khám phá, Maya tiến hành một thử nghiệm nhỏ, khá khó chịu với hai đặc vụ có mặt trong phòng.

• Mười hai phiếu yêu cầu đã được xử lý, cùng loại, được tính thời gian bằng đồng hồ bấm giờ trên điện thoại từ khi mở phiếu đến khi "Tôi đã có đoạn mã cần gửi"

• Với mỗi yêu cầu hỗ trợ: chatbot bị bỏ dở đó có đưa ra câu trả lời hữu ích, câu trả lời sai một cách chắc chắn, hay không có câu trả lời nào mà nhân viên hỗ trợ muốn gửi?

• Sau bất kỳ thử nghiệm truy xuất nào: bản thảo có trích dẫn một bài báo thực sự không, và bài báo đó có nói điều đó không?

• Cô ấy cố tình tạo ra những trường hợp ngoại lệ: một ngoại lệ mang tính khu vực chỉ tồn tại trong suy nghĩ của ai đó, một yêu cầu hoàn tiền, một vé thực chất là tranh chấp về hóa đơn, một câu hỏi mà bài viết về nó đã lỗi thời hai năm

• Chấp nhận cho chính sự tham gia: Dan có thể chỉ ra bước tiếp theo được đề xuất, người chịu trách nhiệm và một câu anh ấy có thể nói với ban lãnh đạo mà không cần phải nói quá lời

Nếu cô ấy không thể tính toán thời gian cơ sở, cô ấy sẽ không có cơ hội nói về thời gian tiết kiệm được sau này. Nếu không ai sở hữu dữ liệu, thì nhiệm vụ của phi công không phải là "xây dựng một phi công phụ". Mà là "chỉ định người sở hữu hoặc dừng lại"

Kết quả

Đây chỉ là kết quả minh họa, được tạo ra từ một thiết lập thử nghiệm giả định, không phải là số liệu chính thức do Northline công bố.

Giả định: 12 phiếu yêu cầu hỗ trợ theo kiểu chính sách; hai nhân viên hỗ trợ; thời gian được đo bằng đồng hồ bấm giờ trong quá trình theo dõi, bao gồm cả việc tìm kiếm trong ổ đĩa dùng chung; thử nghiệm truy xuất chỉ sử dụng 40 bài viết trợ giúp đã được chỉnh sửa; mỗi bản nháp phải vượt qua danh sách kiểm tra ba điểm (chính sách chính xác, nguồn được trích dẫn, không có điều khoản bổ sung được tạo ra) trước khi được coi là chấp nhận được.

Kết quả ban đầu, tuần đầu tiên: thời gian trung bình để có được một đoạn thông tin hữu ích là 14 phút. Bảy trong số 12 yêu cầu hỗ trợ cần phải gửi tin nhắn Slack cho đồng nghiệp. Thử nghiệm chatbot hiện tại không đưa ra được câu trả lời nào trong số 12 câu trả lời mà nhân viên hỗ trợ sẵn sàng gửi. Hai trong số những câu trả lời của chatbot đó đã tự bịa ra khung thời gian hoàn tiền 14 ngày mà không hề được đề cập trong bất kỳ bài viết nào.

Sau buổi hướng dẫn kéo dài 90 phút và thử nghiệm truy xuất trên kho ngữ liệu gồm 40 bài báo: thời gian trung bình để hoàn thành bản nháp đầu tiên là 6 phút. Việc kiểm tra bài báo được trích dẫn đã mất thêm 3 phút, vì vậy thời gian thực tế là 9 phút cho mỗi yêu cầu trong mẫu này. Con số này ít hơn 5 phút so với 14, hay 60 phút trên tổng số 12 yêu cầu. Tám trong số 12 bản nháp đáp ứng danh sách kiểm tra ngay từ lần xem xét đầu tiên. Ba bản nháp chỉ đơn giản là lỗi "không có trong kho ngữ liệu" (các bài báo bị thiếu). Một bản nháp vẫn cố gắng tạo ra một ngoại lệ theo vùng miền; hệ thống đã phát hiện ra lỗi này vì hướng dẫn yêu cầu mở nguồn.

Những con số này chỉ là ước tính ví dụ dựa trên bài kiểm tra đã nêu, một mẫu nhỏ và các trường hợp xử lý đơn hàng dễ hơn so với tranh chấp hóa đơn. Chúng không phải là lý do để cắt giảm nhân sự, và cũng không phải là bằng chứng cho thấy "AI đã tiết kiệm được 36% thời gian xử lý" trong sản xuất. Thời gian xem xét cũng được tính vào. Chatbot mà họ đã sử dụng trước đó cho thấy chất lượng kém hơn, không chỉ về tốc độ.

Kết quả sự nghiệp mới là điều quan trọng ở đây. Maya ra đi với một bài viết được trả phí, một sơ đồ quy trình làm việc, một câu trả lời "không" cho chatbot ban đầu, một câu trả lời "có" (có điều kiện) cho một thử nghiệm thu hồi dữ liệu với chủ sở hữu, và một khách hàng sẽ nghe điện thoại của cô ấy. Đó là một vòng khép kín hoàn chỉnh. Đó cũng là một câu chuyện mà cô ấy có thể kể mà không cần thêm thắt gì.

Điều gì có thể xảy ra sai sót?

• Ban lãnh đạo vẫn muốn sử dụng chatbot phiên bản gốc vì bản demo khá đẹp. Một chẩn đoán chỉ ghi "chưa" có thể thua kém một bản trình chiếu.

• 40 bài viết sẽ trở nên lỗi thời trong vòng sáu tuần nếu không ai sở hữu chúng. Khi đó, việc truy xuất sẽ được thực hiện một cách khéo léo hơn.

• Maya viết một bản mô tả công việc khá chung chung ("chuẩn bị hệ thống hỗ trợ cho AI") và trở thành thành viên nhóm triển khai không lương.

• Một chính sách hoàn tiền sai sót một cách tự tin đến tay khách hàng vì khâu xem xét thủ công chỉ đơn giản là "chúng tôi sẽ bổ sung điều đó sau"

• Văn bản trên hóa đơn chứa thông tin cá nhân của khách hàng được dán vào một công cụ dành cho người tiêu dùng. Lời hứa bảo mật chỉ được đưa ra bằng miệng.

• Dan đổi việc vào tháng thứ hai. Không có chủ sở hữu, không có người giữ hợp đồng, không ai nói rằng phi công đang sa sút.

• Cô ấy báo cáo việc tiết kiệm được 5 phút như một chỉ số KPI của công ty. Các bên liên quan nhớ con số đó nhưng quên mất quy mô mẫu.

Bài học thực tiễn

Con đường dẫn đến thành công là một quy trình làm việc trực tiếp, một ranh giới được trả phí, một bài kiểm tra bạn có thể chạy lại, và sự thẳng thắn để nói rằng mô hình ngôn ngữ là công cụ không phù hợp khi các phiếu yêu cầu cho thấy điều đó. Khả năng phán đoán là thứ bạn đang bán. Vòng lặp hoàn chỉnh đầu tiên chính là cách bạn trở thành người đáng được tuyển dụng.

Câu hỏi thường gặp

Chuyên gia tư vấn AI làm những công việc gì?

Công việc này là chuyển đổi. Bạn tìm ra điểm nghẽn trong một nhóm người hoài nghi và đưa ra một giải pháp thí điểm không làm ai phải xấu hổ. Điều đó có thể bao gồm chiến lược, xây dựng, hỗ trợ hoặc quản trị, cộng với việc biết khi nào LLM (Learning Level Management) là công cụ không phù hợp. Bạn ngồi giữa ban lãnh đạo, những người xây dựng nguyên mẫu nhanh chóng và những người vận hành phải sống chung với những gì bạn để lại. Tổ chức một buổi hội thảo. Viết một bản mô tả công việc (SOW) ngắn gọn. Đừng nhồi nhét LLM vào một quy trình làm việc vốn chỉ cần một ô chọn.

Làm thế nào để trở thành một chuyên gia tư vấn AI?

Hãy ngừng thu thập thông tin cá nhân. Bắt đầu thu thập những vấn đề bạn có thể giải quyết. Nắm vững các mô hình LLM, truy xuất thông tin, người hỗ trợ, tự động hóa cơ bản và rủi ro mô hình đến mức bạn có thể nhận ra những điều vô lý - mà không cần phải đào tạo mô hình từ đầu. Ngồi cạnh một quy trình làm việc thực tế. Chạy một vòng lặp hoàn chỉnh (khám phá, một dự án thí điểm nhỏ, viết báo cáo về những gì đã xảy ra, kích hoạt), đặt tên cho dịch vụ là "Tôi giúp X làm Y mà không cần Z", và nhận tiền. Một lời đề nghị rõ ràng và một vài người sẵn sàng nghe điện thoại của bạn sẽ hiệu quả hơn một cỗ máy tạo nội dung không bao giờ tính phí.

Tôi có cần phải huấn luyện mô hình hay nắm vững kỹ thuật tạo lời nhắc trước không?

Không. Bạn không cần phải huấn luyện mô hình từ đầu, và kỹ thuật hỗ trợ nhanh chỉ là gia vị, chứ không phải món chính. Sự sẵn sàng của dữ liệu, việc lập bản đồ các bên liên quan và một quy trình khám phá rõ ràng sẽ cứu vãn nhiều dự án hơn là một lời nhắc nhở hệ thống thông minh. Các kỹ sư thường cần ngôn ngữ về các bên liên quan và lợi tức đầu tư (ROI). Những người làm chiến lược và vận hành cần biết khi nào bản demo chỉ là màn trình diễn. Dù sao đi nữa, hãy mượn một vấn đề thực tế, hoàn thành nó và mô tả nó mà không thêm thắt gì cả.

Tôi nên chọn con đường sự nghiệp nào: làm việc tự do, làm việc tại doanh nghiệp, làm việc tại studio hay tại agency?

Không có con đường nào cố định. Những người làm việc tự do giữ được lợi nhuận từ việc khám phá và các dự án thử nghiệm, nhưng chu kỳ là lúc thịnh lúc suy. Các studio nhỏ bán cả một đội ngũ. Các chuyên gia AI nội bộ nhận được lương, quyền tiếp cận và cả những vấn đề chính trị. Các gói tư vấn được đóng gói thành sản phẩm bao gồm hội thảo và kiểm toán. Các nhà thầu của agency nhận được nguồn khách hàng tiềm năng và có thể trở thành người hỗ trợ đắc lực nếu hợp đồng không rõ ràng. Làm việc độc lập có vẻ hấp dẫn cho đến khi bạn định giá sai một dự án khám phá. Làm việc nội bộ có vẻ an toàn cho đến khi bạn trở thành người được chỉ định để thực hiện mọi ý tưởng chatbot.

Tôi nên chọn lĩnh vực chuyên môn nào khi làm tư vấn viên AI?

Một phân khúc thị trường hiệu quả ở đây thường là sự kết hợp giữa quy trình làm việc và người mua, chứ không phải là một mô hình gia đình cụ thể. Hãy nghĩ đến những người lãnh đạo bộ phận hỗ trợ đang ngập trong các yêu cầu, các nhóm vận hành với các quy trình chuyển giao rối rắm, hoặc những người quản lý rủi ro cần một hệ thống quản trị không phải là một cuốn PDF dài chín mươi trang mà chẳng ai đọc. Ban đầu, phân khúc thị trường chỉ là một bộ lọc, chứ không phải là một hình xăm. Đừng tự bó buộc mình vào công cụ bạn mới học tháng trước. Các công cụ sẽ thay đổi, trong khi đánh giá về tính sẵn sàng của dữ liệu, quản lý thay đổi và liệu một dự án thí điểm có cơ hội thành công hay không cũng thay đổi theo. Nếu bạn có thể giải thích được tuần làm việc của người mua, bạn đã đủ chuyên môn rồi.

Làm thế nào để trở thành chuyên gia tư vấn AI mà không cần nghiên cứu trường hợp hay hồ sơ năng lực ấn tượng?

Công việc được trả lương đầu tiên thường là kiểm toán quy trình làm việc phức tạp, chứ không phải mô hình đột phá. Bằng chứng có thể là một bản chẩn đoán phạm vi hẹp, một buổi hội thảo tạo ra các trường hợp sử dụng được xếp hạng với người chịu trách nhiệm, một dự án thí điểm nhỏ với so sánh trước/sau về thời gian hoàn thành, hoặc một cẩm nang mà nhóm vẫn sử dụng sau khi bạn rời đi. Hầu hết mọi người bắt đầu với đồng nghiệp cũ, công việc vận hành liền kề, hoặc làm việc bán thời gian một ngày một tuần. Đừng tạo ra một danh mục đầu tư giả. Hãy tạo ra một câu chuyện rõ ràng về vấn đề, những gì bạn đã thử, những gì thất bại và những gì bạn sẽ làm tiếp theo.

Tôi nên định giá dịch vụ tư vấn và phí dịch vụ định kỳ về trí tuệ nhân tạo như thế nào?

Hãy định giá quyết định, chứ không phải số giờ, khi bạn có thể. Một khám phá giúp gỡ rối một vấn đề lớn không thể chỉ diễn ra trong vài ngày. Hợp đồng tư vấn định kỳ phù hợp với việc hỗ trợ, kiểm tra quản trị và tư vấn bán thời gian, nhưng lại không phù hợp với một chu kỳ xây dựng nhanh mà không có người chịu trách nhiệm chính. Bản mô tả phạm vi công việc (SOW) cần nêu rõ "hoàn thành" trông như thế nào, bởi vì nếu bạn không thể viết ra, bạn không thể định giá nó. Mô hình kết hợp khá phổ biến: khám phá có trả phí, sau đó là dự án thí điểm cố định, rồi đến hợp đồng tư vấn định kỳ. Hãy định giá gần với mức giá của các dịch vụ tư vấn tương tự trong lĩnh vực của bạn thay vì chạy theo mức giá ngày cố định chung.

Tôi không nên hứa hẹn điều gì với khách hàng về trí tuệ nhân tạo tạo sinh?

Đừng hứa hẹn độ chính xác mà bạn không thể đo lường, một nhóm sẽ biến mất sau khi hệ thống vận hành thử nghiệm đi vào hoạt động, hoặc rằng trí tuệ nhân tạo tạo sinh sẽ khắc phục vấn đề chất lượng dữ liệu mà chính nó sẽ làm trầm trọng thêm. Đừng hứa hẹn tính bảo mật mà bạn chưa thực hiện: dữ liệu được lưu trữ ở đâu, ai ghi nhật ký yêu cầu và dữ liệu nào được lưu giữ. Rủi ro mô hình là khi một mô hình tự tin đưa ra kết luận sai trong một quy trình làm việc được kiểm soát. Bỏ qua quản trị và người khác sẽ tìm ra lỗ hổng trong quá trình sản xuất. Đừng dọa dẫm khách hàng bằng một chương trình khổng lồ khi việc thiết kế lại quy trình làm việc trong hai tuần là đủ.

Khi nào thì bản demo không phải là một chẩn đoán?

Bản demo trả lời liệu một hệ thống có thể tạo ra kết quả khả thi hay không. Chẩn đoán trả lời liệu tổ chức này có nên sử dụng nó ở đây, với dữ liệu này, những người này và mức độ chấp nhận rủi ro này hay không. Hãy chú ý đến các dấu hiệu: không ai có thể trình bày quy trình từ đầu đến cuối, cơ sở kiến ​​thức không có người chịu trách nhiệm, hoặc người đồng hành đang sử dụng một quy trình đã thất bại. Làm chậm quá trình, lập sơ đồ quy trình và hỏi ai sẽ chịu trách nhiệm nếu có sai sót, sau đó mới chọn công cụ. Phán đoán là sản phẩm. Hệ thống là trang phục.

Các chuyên gia tư vấn AI độc lập cần những loại hợp đồng và quy trình giao hàng nào?

Nếu bạn làm việc độc lập hoặc theo mô hình studio, doanh nghiệp sẽ cố gắng "nuốt chửng" dịch vụ tư vấn của bạn. Thiết lập tối thiểu: một hợp đồng đơn giản bao gồm phạm vi, sở hữu trí tuệ, bảo mật, xử lý dữ liệu và chấm dứt hợp đồng; một bản mô tả công việc (SOW) cho mỗi dự án; một bản ghi chú hàng tuần, nhật ký quyết định và rủi ro; cộng với các tài liệu không bị kẹt trong thư mục tải xuống của bạn. Hãy đọc kỹ tài liệu trước khi tham gia. Đừng biến mất giữa các buổi hội thảo. Khi một dự án thử nghiệm gặp trục trặc, hãy báo sớm và đưa ra các phương án thay thế. Nếu bạn rời đi và chỉ mình bạn điều hành dự án, bạn sẽ trở thành nút thắt cổ chai với mức phí theo ngày. Hãy giảng dạy, lập tài liệu và bàn giao.

Tài liệu tham khảo

1. NIST - nvlpubs.nist.gov

2. NIST - airc.nist.gov

3. ICO - ico.org.uk

4. NCSC - www.ncsc.gov.uk

5. Microsoft Learn - learn.microsoft.com

6. OpenAI - nhà phát triển.openai.com

7. OpenAI - Kỹ thuật nhanh chóng - developers.openai.com

Tìm kiếm những công nghệ AI mới nhất tại Cửa hàng Trợ lý AI chính thức

Về chúng tôi