MSTeams Bot Meeting Transcript - 2026-09-04
Summary
Bản transcript thô buổi họp trao đổi về sửa lỗi bot, phương án đếm item qua API search, và định hướng proposal Phase 2 cho dự án MSTeams Bot (E-607) ngày 2026-09-04.
Content
Lô lô Rồi nghe nghe. Ok. Ý thứ nhất, note chi tiết nội dung sửa sửa cái gì. Cái này review viết lại cho nó ấy nha Nhân. Dạ. Này do AI viết ra đúng không? Dạ. Mấy cái này nè, cái này đọc lại bị chửi cho. Mấy cái này viết ra làm cái gì? Mục đích của cái này là để cho bên anh Đăng biết được là mình sửa cái gì. Cái view của bên anh Đăng là client thì client người ta không cần phải hiểu sâu xuống bên dưới. Tức là không cần phải giải thích bao gồm những cái chi tiết technical bên dưới, nhưng mà cần phải cho người ta hiểu được là cái hướng mình giải thích. Ví dụ như cái này đi ha. Cái này là nội dung lỗi là hiện tại bây giờ đã có skill Outlook nhưng mà nó không trả lời được đúng không? Thì giải thích là lý do là tại vì đã có skill Outlook ở bên trong con bot, nhưng mà skill đang bị lỗi. Sửa bằng cách là xóa cái skill Outlook này đi. Chứ em viết tùm lum như thế này thì anh đọc anh lại... Dạ, tại tại ban đầu tại ban đầu em tưởng là viết cho anh Quang hiểu để deploy, chứ không biết là cho anh Đăng đọc. Cái này là bên anh Đăng đọc. Bên đó là report cái bug như thế này. Cái này là memo lúc trước Khoa viết đúng không? Hay đứa nào viết đấy? Thì bây giờ người ta sẽ không bên kia người ta sẽ không có review được những cái nội dung mình sửa, người ta không biết là mình sửa cái gì. Thì cái này là nội dung cho giải thích cho bên kia biết là cái hướng mình sửa. Thì viết ở cái mức độ là cách sửa thôi chứ không cần phải giải thích chi tiết nhé. Dạ. Không cần phải giải thích giải thích code kiếc chạy làm sao hết. Như cái này là chỉ là xóa cái Outlook đi này. Cái này nè, là hướng sửa là sao? Là sẽ phải gom các câu hỏi vô thành các group đúng không? Group nào mà nó out of scope á thì rải thêm prompt cho nó trả lời để nó không bịa ra thêm. Còn những cái group nào mà nó rớt vô đúng cái intent á, đúng cái mục đích user hỏi á thì bắt đầu mới đẩy xuống dưới cho agent. Dạ, để tí em sửa lại. Rồi, hai cái case này á là bây giờ Từ từ, ý đó đã. Hiểu nội dung cách viết rồi chứ gì nữa? Dạ hiểu anh ơi. Ok. Mấy cái ngày tháng như vậy cũng vậy nè. Mấy cái này là Quang nắm rồi chứ gì Nhân? Ni Quang? Này ngày tháng release như thế này là lịch như thế nào viết lại đi nhé. Dạ dạ dạ. Bên này cũng vậy nè. Ý thứ hai, cho này lên trước đi. Estimate hướng sửa cho issue đếm số lượng item. Là cái này nè, là hiện tại bây giờ con bot nó không làm được. Thì bên anh Đăng Cái này á chắc cho thêm một cái cột là những cái nào mà mình đánh giá là enhancement, improve á. Nhás, cái nào là bug, cái nào là ấy thì thêm vô nhé. Hai cái này là pro... hai cái này là request change nè. Thì cái này là sẽ phải estimate thêm, nhưng mà đầu tiên là tụi bay làm á là Okay không? Yeah. RAG search with API thì nhận vô là cái gì? Nhận vô là theo cái channel với lại cái ngày, bắt buộc. Bắt buộc là phải có channel và ngày tháng. Okay không? Yeah, channel ID với lại ngày tháng. Chỗ đó có thể là sẽ phải cần với lại anh Đăng nữa là em giới hạn lại như vậy có được hay không nhé. Là input vào là require hai param. Khi mà user nó hỏi á là sẽ require hai param là ngày, thời gian và channel. Okay không? Yeah, yeah. Cái channel đưa vô cũng khó nha, tại nó đưa name mà, nó đưa tên mà. Đưa tên... Của cái đưa tên là mình phải tự parse ra cái channel ID. Thì cái phần đó là nó sẽ nằm trong skill. Tức là cái code của em thì em sẽ có một cái hàm là RAG search with API gì đó thôi nhé. Thì em sẽ nhận vô hai cái gọi là channel name cộng với lại datetime, hai cái đó là đều require hết. Thì cái phần đó là phần hàm search đúng không? Dạ. Ở trên á cái skill á là mình sẽ sửa phần trên skill chỗ này là ta có thêm một cái hàm là RAG search with API gì đó. Okay không? Dạ. Nhận hai tham số là channel name cộng với lại datetime. Cái channel name này á cần lấy từ đâu? Từ chắc là sẽ đưa cho nó một cái bản list đi cho nó đơn giản, tách cái này ra thành một cái file nữa file reference hay cái gì đó chẳng hạn kiểu kiểu thế. Hay là có làm code được không ta? REF này á? Anh nghĩ làm vậy đi cho đơn giản nhé. ref.md gì đó trong đó là đây là cái bảng tra của tao là tên channel này. Channel X gì đó ID như thế này. Channel Y Hay là cái đó làm code luôn cho nó đơn giản? Cái đó chắc quăng vô cái tool luôn. Ừ, tức là nếu mà có API lấy được cái đống này không Quang? Có chứ anh. Lấy được danh sách các channel kèm ID. Dạ được, dạ được. Cái cái đó là cái đầu tiên mình làm luôn á. Cái... Okay. Thì có phải là như vậy là em sẽ có cái code đúng không? Có source code em viết là em có cái hàm search with API này. Rồi em có một cái hàm gọi là get channel metadata gì đó chẳng hạn. Okay không? Dạ. Đây là cái phần code của em. Xong rồi bắt đầu ở bên trên là cái phần skill này thì em sẽ hướng dẫn nó. Là nhận khi mà nhận được yêu cầu từ user á thì parse sử dụng cái đống metadata này. Nếu mà không parse được ấy thì trả lời là fail hay là cái gì đấy chẳng hạn, trả lời lại cho user. Còn nếu mà được ấy thì bắt đầu đem đi gọi cái hàm này, okay không? Okay không? Dạ. Ghê chưa. Ồ cái phần này Nhân chắc nó nắm này. Thì cái mấy cái hàm chỗ này á, mấy cái API này này thi Quang nắm thì Quang làm phần này đi nhé. Phần skill hay là cái gì đấy Nhân nó làm để nó test thì hai đứa phối hợp với nhau làm. Dạ. Thì cái mục đích của cái hàm bên dưới này mình mục đích là mình đang muốn xử cái case này cho anh Đăng đây này là đếm số lượng đây này. Cho nên là gọi làm sao cho nó hiệu quả. Ví dụ như cái này, search với API anh không biết data nó trả về cái gì nhưng mà mình thực ra mình đâu cần message đâu đúng không? Hoặc là mình cũng đâu cần Nếu vậy mình sửa lại cái hàm này là gọi là cái get summarize gì đó chẳng hạn. Get search summarize gì đó. Hoặc là để sau này mà có khả năng mở rộng á thì có thể là cứ get search API này nhưng mà kết quả trả về đây là mình chỉ cần làm sao để để mình trả ra được cái số lượng này thôi. Ví dụ như chỗ này data nó trả về đang là nếu mà nó có số luôn rồi thì quá ngon ha. Còn không thì nó sẽ trả về dạng list như thế này đúng không? List mess số 1 rồi meta gì đó, mess số 2 Oke anh Nhân. Rồi, clear chưa? Clear chỗ này chưa? Dạ dạ, cũng oke anh. Rồi. Bên này bên này còn cái gì không? Bên này Bên này cái vụ này á Nhân, cái này là hiện tại bây giờ là đang trả về cái link của cái thread đúng không? Dạ đúng rồi. Oke. Tức là mess kiểu gì đó nó trả về một cái thread cha bên trên này, bấm vô cái là nó lên được cái cái thread chính ở đây đúng không? Còn mess có thể là nó nằm đâu đó ở dưới này cũng cũng không chừng. Rồi, cái này anh nghĩ là khả năng cái này là hên xui nhiều nè, không biết là nó nó gen ra tại ta không biết là tại vì coi được là Nhân nó test kiểu đó thôi, còn gen đúng hay sai, có nhiều case nó có case có case không hay không á cũng cũng lằng nhằng lắm. Cho nên là cái này là test kỹ lại này. Cần phải test kỹ lại cái chỗ này. Rồi, cái này là cái gì? Cái này là cũng xong rồi đúng không? Còn mấy cái này là cái gì đây? Mấy cái này là Quang ấy hết rồi đúng không? Mấy ý này là có xử lý hết chưa Quang? Dạ mấy cái... Mấy cái hồi nãy anh anh anh Đăng ở kia đúng không anh? Anh Đăng show à? Tại thấy trên sheet nó còn mấy cái này nè. Cái này là add vô từ khi nào đây? Thấy nó mới thêm hồi sáng anh ơi. Meeting xong rồi có hay gì á. Để để em check con bot check... À à, dạ cái đó anh Đăng thêm á anh. Cái đó xử lý chỉnh lý lại cái sheet này luôn nhé. Dạ dạ. Đấy thì cái nào làm cái nào không ấy... Cái phần feedback này là chắc là mình sẽ phải support thêm một tháng, hết tháng 9 này nè. Bây giờ bên kia bắt đầu test thì đang support hết tháng 9 này. Cái... Cái không trả lời liên quan tới hệ thống là là là bên... Bên Nhân nhỏ nó nó nó rà lại rồi đúng không anh? Cái này hình như là trùng lặp đúng không? Đang ấy rồi nè. Không trả lời liên quan hệ thống là hình như là cái... Cái này chứ gì nữa? Ý số 2 nè. Ý số 2 này tức là hỏi những cái mà liên quan tới hệ thống bắt đầu vẽ ra là bên dưới chạy làm sao, rác làm sao thì user nó không cần cái đó, chính là cái nội dung này nè. Dạ. Cái này là của Nhân luôn đấy. Ý số 2 của Nhân luôn đấy. Dạ dạ. Dạ đúng rồi. Chạy ra chỉ vô đàng expiration time, mấy cái chỗ này là cái phần liên quan tới phần bên rác webhook của Quang nhé. Dạ dạ. Mấy nghẽn rùa... Rồi oke. Khả năng là vẫn sẽ vẫn còn feedback đấy, nhưng mà hiện tại bây giờ như thế này là mình clear hết rồi, còn cái này là mình cần proposal lại nè. Trước khi sửa cái này, cái này thực ra anh đánh giá là sửa thì cũng nhanh thôi, nhưng mà request change mà nó cũng out of scope ban đầu của mình cho nên là mình cứ báo, anh nghĩ là chắc khoảng tầm mấy ngày đấy. Test nữa. Rồi. Coi lại lịch release nhé. Bữa nay cuối tuần rồi thì không release, để qua tuần đi. Nhưng mà release thì cần đánh giá rõ là data mấy cái sửa này nè, cần coi kỹ lại. Thực ra là bây giờ đâu đâu có ấy gì đâu, hoàn toàn có thể test được trên... Trên trên app hoặc là staging của mình mà. Tại vì cái data này là mình dùng y trang. Data phần rác này là dùng y trang, bữa chỉ cho Nhân cấu hình rồi. Móc vô thôi nhé. Dạ. 4 tháng 9 nó lấy đây, 4 tháng 9 nè. Rồi. Còn gì nữa? Rồi ok. Anh realloc lên là... Là có cần phải setting gì không anh? Hay là cứ vậy mà chạy thôi? Cái gì anh? Cái... Cái cái phần em đổi á, em đổi là chỉ cần anh down up lại là được đúng không? Đổi cái nào ấy? Đổi cái phần... Mấy mấy cái feedback. Bốn bốn cái bug hồi sáng rồi hả? Đúng rồi. Tức là em có thêm biến môi trường hay cái gì không ấy để anh set up ở dưới local server ấy? Ờ không, chỉ thay đổi code của cái RAG service với cái cấu hình của con bot thôi. À, đổi code thôi đúng không? Mấy cái skill rồi đó. Đúng rồi. Để coi deploy lại nhé. Xong cái phần đó thì bây giờ bắt đầu tới ý tiếp theo là cái proposal cho phần phase 2. Phần proposal cho phần phase 2 thì bây giờ mình sẽ có hai cái. Một là xử lý đọc file. Hai là xử lý meeting. Cái này chắc để tuần sau đi nhưng mà anh đang suy nghĩ hướng làm trước, chưa cần phải ấy. Xử lý đọc file thì cái này easy game. Dựng lên một con service đọc file, sẽ hỗ trợ file PDF, tất cả các loại file phổ biến ha, PDF, Excel, ảnh hay gì đó, text, các thứ các thứ. Slide không biết có đọc được hay không. Thì hiện tại bây giờ ví dụ như anh test trên con My con Mi kia là dùng mấy cái Docling ấy, dựng lên một container là có thể chạy được rồi. Rồi cắm cái skill vào hướng dẫn nó. Thì cái phần còn lại ấy là từ đây này, từ đây phải làm sao mà để cho con bot nó đọc được file, tức là liên quan tới cái phần API của bọn bọn Teams này, hiểu không? Như trên Chatwork ấy thì hiện tại bây giờ nó làm là sao? Ví dụ như anh làm ấy là giả sử như cái này anh reply anh tag con bot vào đúng không? Thì nó tag như thế này khả năng là nó không đọc được, phải tag như thế này này. Xong tag con bot vào, kêu đọc cho tao cái file thì nó sẽ nhìn vào đây nó sẽ có cái ID này. Có cái ID này bắt đầu nó gọi một cái API download cái file đó xuống thư mục temp. Xong bắt đầu nó mới đọc. Thì hiện tại bây giờ đang làm như vậy. Hình như nó lưu xuống đâu đây này. Biết con này chưa test thì Có phần media, phần file gì đó. Con này ấy rồi. Con này cùi rồi. Đây nó có media nó lưu xuống này, có file này, tức là nó lưu tạm xuống, xong rồi nó ném cho cái service kia đọc. Thì cái này cũng sẽ phải xử lý này, sau khi đọc là xóa đi này, có thêm cái phần đó nữa. Tóm váy lại là cái phần đọc file này là anh bao kê cho là làm easy game ha. Chỉ có là những cái file những cái API mà liên quan tới phần phần phần Teams API để lấy được cái file này về ấy là phải nghiên cứu nhé. Attach file nghĩ là chắc phải có hết chứ đúng không Quan? Dạ có anh. Ừ. Attach file image. Rồi xong ấy thì bắt đầu người ta sẽ mong muốn là có thể sẽ muốn gửi file lên nữa, đúng không? Có thể sẽ gửi file lên nữa. Thì đấy thì cứ coi trước cái API đó. Thì về lý thuyết là em chỉ cần chuẩn bị sẵn cái đoạn code là down cái file về template, xong rồi dựng một cái Docling service container, ví dụ như mấy con này là có hết rồi. Docling service thì chắc là cần phải coi lại cái spec phần server ấy. Tại con này thời gian chạy là nó... à để mà nó chạy ấy là cũng tốn thời gian, cũng tốn tài nguyên ấy. Nó cũng down cái model 1 2GB gì về nó chạy đấy, model trên Hugging Face ấy. Mình có thể mình giới hạn lại. Đây là cái gì quên mẹ rồi. Đúng rồi, vậy là cái này là ok này. Rồi. Bây giờ cái hướng thứ hai là xử lý meeting. Thì cái bài toán nó cũng giống như là bên mình đang làm đây Teams meeting á, là họ muốn có một cái tool để đẩy cái phần thông tin mà meeting này vào trong cái bot xử lý. Ok không? Kiểu cũng lấy trên Graph rồi quăng vô bot hả? Đúng rồi. Transcript á thì mình sẽ phải tính tới cái bài là hiện tại bây giờ anh nghĩ là proposal thì cứ làm một cái hướng là lấy transcript của Teams trước đi. Cái này là Quang làm rồi đúng không? Dạ, hôm đó em làm rồi. Ừ, từ API lấy được transcript của buổi meeting. Nghĩa là nó sẽ có ai làm cái gì đó. Thì mày thảy qua thêm một cái pipeline cái LLM prompt phát để cho nó tổng hợp ra tổng hợp ra bản data. Rồi từ cái bản data này á thì bắt đầu mới inject vào RAG. Thì trong RAG có thể là sẽ vẽ là thêm một cái gọi là meeting chứ không phải là chat nữa. Ok không? Đây là cái hướng là mình đang bị vendor lock-in gốc theo cái thằng Teams này. Còn ví dụ như là team nó muốn sử dụng là bên Meet này, bên Zoom này kia các thứ này, thì mấy cái này là có thể sẽ phải vẽ thêm cái extension. Nhưng mà cái này anh nghĩ là optional, muốn làm thì mình sẽ viết thêm extension. Nhưng mà đó, nó sẽ bị một cái là không xử lý được các cái bài toán là không xử lý được ai nói cái gì đó, user nói cái gì. Độ chính xác nó sẽ thấp hơn ở cái phần Teams này. Có thể là chắc user nó sẽ bỏ cái này, chưa chắc. Đấy thì nói sơ qua là phần phần hai này là anh đang dự tính để anh viết pro- proposal cho phần bên kia để làm cái phần hai này. Vậy có vẻ như là bên kia muốn làm cái này hơn. Bên kia sẽ muốn làm cái này hơn. Rồi, đấy, đấy là cái nội dung sơ. Có cần phải làm cái gì trước không? Cái này chưa cần. Proposal... viết API... API test ba này. Cái này chưa cần phải viết, viết proposal chỗ này á Nhân. Này mình viết chung chung thôi nghe, không cần viết chi tiết đâu. Bên kia anh đang là cũng có team dev á, nếu mà chi tiết nhiều khi mà thấy công số cao á, thì bên anh là để đó làm luôn. Cho nên là em chỉ cần viết là sử dụng API, cần research thêm hướng API để search thay vì dựa vào cái data của RAG. Thì cái API của search á có khả năng là sẽ search được. Thì dự tính là sẽ viết một cái API trong RAG search, xử lý code, về số lượng, viết skill, test, đóng gói lại, test tiếp này kia các thứ. Tức là mình viết cái proposal làm sao mà nó phù hợp với lại cái công số dự tính của mình khoảng tầm 4 ngày ha. Là cái team Graph đúng không anh? Xài team Graph để lấy đúng không? Ừ, Graph UI, Graph QL á, cái đó hỏi Quang nghe, chắc confirm được rồi đúng không? Dạ, dạ hiểu rồi. Còn không thì kêu Quang phải test trước đi, mình proposal cho đã xong tới lúc test thì bắt đầu lại ấy. Tức là có lấy được hay không, có đúng là dùng Graph QL là có lấy được theo ngày chính xác hay không đã. Mới là lấy kiểu gì. Hoặc là nó lấy, nó lấy về cái cái thread này. Người ta muốn đếm á, cần phải confirm lại phía bên kia nữa là nó đang là bắn lên một phát là một cái thread, xong dưới thread đó là message, nó có message kiểu này không trời? Chứ lấy kiểu này là xong đếm là cũng không biết kiểu gì luôn. Anh thì anh đang đoán là nó nó chỉ là một cái thread như vậy thôi. Chắc đếm cái Red thôi chứ, nó bắn nhiều cái Red. Kiểu như bên kia là nó có một cái form dành cho user nó đặt câu hỏi ấy. Cái event nó lễ hội nó xảy ra thì bắt đầu user cứ submit cái form. Cứ submit lên thì sẽ là cái này là một cái một cái bài post này. Xong rồi một ngày là biết bao nhiêu bài post như thế này thì nó muốn thống kê thôi. Thì đó thì cái phần này là vẽ ra là ờ là em sẽ phải điều tra API, em sẽ phải test API, em sẽ phải viết skill em test. Rồi gì nữa? Em sẽ phải handle lỗi đúng không? Read image image các thứ gì đó chẳng hạn. Thì chắc là bao gồm công số luôn trong này đi, anh chốt cho công số khoảng tầm 4 ngày đó. Dev thì em cần khoảng tầm 2 ngày, test feedback lại khoảng 2 ngày nữa, tổng công số khoảng tầm 4 ngày cho cái sự này. Proposal chắc ghi cái pipeline vô anh. Ừ ừ, viết pipeline đơn giản thôi, nhưng mà ý anh là cũng không cần giải thích chi tiết là các bước đâu. Chỉ cần biết là ờ em muốn tạo ra một cái API thay vì em dùng data của Red đúng không? Độ chính xác nó nó nó thấp mà mà giờ không làm được luôn ấy. Cho nên là em dùng API của team. Dùng API của team thì em sẽ phải viết API em tạo skill. Em test skill. Đó thì cái pipeline đơn giản là user tới, parse ra cái intent là ngày tháng năm. Với lại channel ID, gọi thêm một cái API để lấy group ID nữa. Rồi trường hợp mà parse sai ấy thì con bot trả lời lại là thiếu thông tin. Kiểu thế. Nói chung là phải tạo coi đơn giản vậy thôi chứ cái skill cứ đụng tới skill hoặc là agent làm là nó không có nhất định ấy. Là nhiều cases lắm, cứ chạy lúc chạy đúng lúc chạy sai rồi bắt đầu la bài hãi lên nữa, mệt lắm. OK không? OK rồi. Ừ, rồi, OK, thì bây giờ cái phần này sửa này. Chắc là plan đi ha, cứ plan trong tuần sau hết đi cho mấy cái này. Cái phần nào xong rồi thì lên lịch release thôi. Còn cái này thì cứ viết proposal trước đi, còn bắt tay vào làm thì tính sau nhé. Chắc là chắc là bên kia cũng sẽ làm thôi, tại cái này là bên bên bên bên sếp anh đang dí mà. Nhưng mà mình làm thì mình sắp xếp, có thể là qua tuần qua tuần lúc nào đó thì mình sắp xếp mình làm. Rồi, OK nhé, còn gì không? Không anh ơi. Rồi, OK, thank you mấy đứa. Cảm ơn anh. Cười.