Tự xây công cụ AI nội bộ - Những bài học từ một ứng dụng ghi chú cuộc họp

Ngày đăng: 13:19 28/08/2026 - Lượt xem: 33

Ông Đặng Nghinh Nguyên - Ủy viên Hội đồng Khoa học Ứng dụng Trí tuệ nhân tạo Trong quá trình vận hành doanh nghiệp và ứng dụng AI vào công việc hằng ngày, tôi thường tự dựng những công cụ nhỏ để giải quyết một nhu cầu cụ thể. Gần đây, tôi hoàn thiện một ứng dụng ghi chú cuộc họp bằng AI. Điều tôi muốn chia sẻ không nằm ở bản thân công cụ, mà ở những bài học phía sau quá trình xây dựng: khi nào nên tự làm thay vì mua một giải pháp có sẵn, làm thế nào để tránh mất thời gian vào những vòng sửa chữa không cần thiết, và đâu là khoảng cách giữa một bản thử nghiệm chạy được với một công cụ có thể sử dụng lâu dài. BẮT ĐẦU TỪ MỘT ĐIỂM ĐAU THỰC TẾ Trước khi tự xây, tôi đã thử hai cách làm quen thuộc. Cách thứ nhất là mua phần mềm ghi chú cuộc họp theo gói thuê bao tháng. Công cụ hoạt động tốt, nhưng lịch họp của tôi không đều. Có tháng tôi dùng liên tục, có tháng gần như không mở đến. Nếu duy trì thuê bao, tôi phải trả tiền cho phần lớn dung lượng không sử dụng; nếu hủy, đến lúc cần lại phải đăng ký và thiết lập lại.

Cách thứ hai là làm thủ công: ghi âm cuộc họp, tải tệp lên một công cụ AI rồi yêu cầu tóm tắt. Phương án này không tạo ra phí cố định, nhưng có nhiều thao tác rời rạc và thời gian chờ. Khi phải lặp lại sau mỗi cuộc họp, những bước nhỏ ấy đủ tạo ra sức ì khiến quy trình dễ bị bỏ dở.

Nhìn lại, điểm đau của tôi không đơn thuần là thiếu một công cụ tóm tắt. Đây là bài toán lựa chọn giữa tự xây và mua giải pháp có sẵn. Với nhu cầu sử dụng ít, không đều và có quy trình tương đối đặc thù, một công cụ tự xây theo mô hình trả phí theo mức sử dụng có thể hợp lý hơn thuê bao cố định.

Tuy nhiên, chi phí API thấp không đồng nghĩa tổng chi phí sở hữu thấp. Khi cân nhắc phương án tự xây, doanh nghiệp vẫn phải tính thời gian phát triển, vận hành, bảo trì, lưu trữ, bảo mật và chi phí cơ hội của người thực hiện. Trong trường hợp của tôi, quy mô nhỏ và nhu cầu đủ rõ nên phương án tự xây phù hợp. Với một quy trình phổ biến, cần độ ổn định cao hoặc có nhiều người sử dụng, mua một sản phẩm hoàn chỉnh đôi khi vẫn kinh tế hơn.

CÔNG CỤ GIẢI QUYẾT VIỆC GÌ

Ứng dụng thực hiện một chuỗi tương đối đơn giản: ghi âm cuộc họp, chuyển giọng nói thành văn bản, sau đó tổng hợp nội dung thành biên bản, các quyết định chính và danh sách công việc cần thực hiện.

Hai yêu cầu quan trọng xuất phát từ bối cảnh làm việc thực tế tại Việt Nam.

• Thứ nhất là khả năng xử lý đa ngôn ngữ. Trong một cuộc họp, người tham dự có thể dùng tiếng Việt và tiếng Anh xen kẽ, thậm chí trong cùng một câu. Hệ thống cần xử lý được kiểu chuyển đổi ngôn ngữ này mà không buộc người nói phải giữ thuần một ngôn ngữ.
• Thứ hai là phân tách người nói. Hệ thống chia nội dung thành các lượt phát biểu và gắn nhãn cho từng người nói. Tính năng này giúp biên bản dễ theo dõi hơn, nhưng không nên nhầm với việc nhận diện chính xác danh tính. Trong điều kiện có tiếng ồn, nhiều người nói cùng lúc hoặc chất lượng micro không tốt, người dùng vẫn cần kiểm tra lại tên người nói và người chịu trách nhiệm cho từng công việc.

Trong một cấu hình thử nghiệm tối giản, tôi từng ghi nhận chi phí API trực tiếp khoảng 2.700 đồng cho một giờ âm thanh, bao gồm chuyển giọng nói thành văn bản và tóm tắt bằng mô hình ngôn ngữ. Đây là chi phí biên của một lần xử lý, không phải tổng chi phí sở hữu. Con số thực tế có thể thay đổi đáng kể theo nhà cung cấp, mô hình, tính năng phân tách người nói, dung lượng lưu trữ và chính sách giá tại từng thời điểm.

CÔNG NGHỆ VÀ CÁCH PHÂN CHIA HỆ THỐNG

Tôi tách công cụ hỗ trợ phát triển khỏi các thành phần vận hành của ứng dụng.

Trong quá trình xây dựng, tôi sử dụng các trợ lý lập trình bằng AI như Claude và Codex cho phần chính, kết hợp thêm một số công cụ khác cho các tác vụ nhỏ. Ngân sách công cụ phát triển của tôi tại thời điểm thực hiện vào khoảng 20 USD mỗi tháng. Đây là mức chi cho trường hợp sử dụng cá nhân, không phải định mức chung, vì giá và hạn mức của các dịch vụ có thể thay đổi.

Khi ứng dụng vận hành, âm thanh được chuyển qua một dịch vụ nhận dạng giọng nói. Tôi đã thử nghiệm Soniox và Deepgram để đánh giá khả năng xử lý tiếng Việt, tiếng Anh xen kẽ và phân tách người nói. Văn bản sau đó được đưa sang một mô hình ngôn ngữ có chi phí thấp để tạo biên bản theo cấu trúc định sẵn. Kết quả cuối cùng được lưu và hiển thị để người dùng rà soát.

Tôi không chọn công cụ chỉ dựa vào mức độ nổi tiếng. Điều quan trọng hơn là kiểm tra nó trên dữ liệu gần với tình huống sử dụng thật: chất lượng micro, tiếng ồn, cách phát âm, thuật ngữ chuyên ngành và hiện tượng nhiều người nói chồng lên nhau. Một mô hình rẻ chỉ có ý nghĩa khi đầu ra không làm người dùng mất thêm quá nhiều thời gian để sửa.

Làm rõ quy trình trước khi viết mã Ở giai đoạn đầu, tôi mắc một lỗi khá phổ biến: muốn dựng nhiều tính năng cùng lúc. Khi phạm vi chưa rõ, lỗi phát sinh chồng chéo; sửa chỗ này lại ảnh hưởng chỗ khác. Chi phí không chỉ nằm ở lượng token hay dịch vụ sử dụng, mà còn ở thời gian phải quay lại xử lý những quyết định chưa được làm rõ từ đầu.

Sau một số vòng thử nghiệm, tôi thay đổi cách làm. Trước khi yêu cầu AI viết mã, tôi xác định luồng sử dụng, dữ liệu đầu vào, cấu trúc biên bản đầu ra và tiêu chí để đánh giá kết quả. Với những phần có nhiều tương tác, tôi dựng giao diện mẫu để nhìn rõ người dùng sẽ thao tác như thế nào.

Cách làm này cho AI một bản mô tả cụ thể để bám theo, đồng thời buộc tôi phải quyết định điều gì thực sự cần thiết. Nhờ đó, số vòng sửa đổi, lượng tài nguyên sử dụng và thời gian phát triển đều giảm. Bài học ở đây không chỉ dành cho việc viết phần mềm: đừng tự động hóa một quy trình khi chính mình chưa xác định rõ đầu vào, đầu ra và người chịu trách nhiệm ở từng bước.

TỪ CÔNG CỤ CÁ NHÂN ĐẾN QUY TRÌNH VẬN HÀNH

Nếu công cụ chỉ xuất ra một đoạn tóm tắt, giá trị của nó vẫn còn hạn chế. Giá trị lớn hơn xuất hiện khi kết quả cuộc họp được đưa vào bước công việc tiếp theo.

Hướng phát triển của tôi là để hệ thống soạn bản nháp email tổng hợp, liệt kê quyết định, người phụ trách và thời hạn. Người chủ trì sẽ kiểm tra, điều chỉnh và xác nhận trước khi nội dung được gửi đi. Bước kiểm duyệt này cần thiết vì AI có thể nghe nhầm tên, thời gian hoặc mức độ cam kết của người tham dự.

Sau khi được xác nhận, danh sách công việc có thể được chuyển vào hệ thống quản lý công việc, CRM hoặc nền tảng nội bộ thông qua API hay giao thức tích hợp phù hợp. Khi đó, công cụ không chỉ giúp một cá nhân tiết kiệm thời gian mà còn trở thành một mắt xích trong quy trình vận hành của tổ chức.

Đây là khác biệt đáng chú ý giữa năng suất cá nhân và năng suất vận hành. Ở cấp độ cá nhân, AI giúp một người làm việc nhanh hơn. Ở cấp độ tổ chức, AI phải đưa được thông tin vào đúng hệ thống, đúng người và đúng thời điểm, đồng thời vẫn giữ được khả năng kiểm soát.

BẢO MẬT KHÔNG PHẢI PHẦN BỔ SUNG

Ghi âm cuộc họp có thể liên quan đến dữ liệu nhân sự, khách hàng, tài chính hoặc chiến lược kinh doanh. Vì vậy, chi phí và độ chính xác không phải là hai tiêu chí duy nhất khi lựa chọn công nghệ.

Trước khi triển khai, cần xác định rõ người tham dự có được thông báo và đồng ý ghi âm hay không; dữ liệu được gửi tới nhà cung cấp nào; ai có quyền truy cập; bản ghi được lưu trong bao lâu; và có cơ chế xóa dữ liệu khi không còn cần thiết hay không. Với những cuộc họp chứa thông tin nhạy cảm, doanh nghiệp cần có chính sách riêng và đánh giá kỹ điều khoản xử lý dữ liệu của nhà cung cấp.

Khi công cụ được mở rộng cho nhiều người, các yêu cầu như phân quyền, nhật ký truy cập, mã hóa, sao lưu và xử lý sự cố cũng trở thành một phần của sản phẩm. Đây là những chi phí khó nhìn thấy trong bản thử nghiệm ban đầu nhưng không thể bỏ qua khi đưa vào vận hành.

CHẶNG CUỐI MỚI LÀ PHẦN KHÓ NHẤT

Ngày nay, người không chuyên lập trình cũng có thể dùng các trợ lý AI để tạo ra một bản thử nghiệm giải quyết nhu cầu tương đối hẹp. Điều đó không có nghĩa việc xây một sản phẩm đáng tin cậy đã trở nên dễ dàng.

Phần khó nhất nằm ở chặng cuối: làm cho công cụ chạy ổn định, xử lý được tình huống bất thường, bảo vệ dữ liệu, cho phép người dùng kiểm tra sai sót và duy trì được khi số người sử dụng tăng lên. Khoảng cách giữa một bản demo chạy được và một công cụ dùng được hằng ngày được lấp đầy bằng công sức kiểm thử, sửa lỗi và hoàn thiện quy trình.

Với những người làm công tác điều hành, kinh nghiệm này gợi ra một cách tiếp cận thực tế. Không phải mọi nhu cầu nhỏ và không thường xuyên đều cần thêm một thuê bao phần mềm; nhưng cũng không phải bài toán nào cũng nên tự xây. Quyết định phù hợp chỉ xuất hiện khi doanh nghiệp nhìn đủ cả tần suất sử dụng, mức độ đặc thù, yêu cầu bảo mật và tổng chi phí sở hữu.

Giá trị của AI không nằm ở số lượng công cụ doanh nghiệp đang có. Nó nằm ở khả năng nhận diện đúng vấn đề, đặt AI vào đúng vị trí và thiết kế một quy trình trong đó con người vẫn giữ quyền kiểm tra đối với những quyết định quan trọng.