OGIF Office Hours #25 - Team & Community updates, Hybrid culture, Product design commentary, AI Tooling Insights, Golang weekly

85 minutes

Topics and Highlights

Hybrid Work & AI Focus: Encouraging office visits, knowledge sharing, and AI/LLM projects with ICY rewards.
OGIF & Tutorials: Regular demos on Golang, AI, product design, and AI tools by Tom.
Company Trip: Planning a December trip to Penang.
Product Design Insights: Covered VUI, AR/VR, Modular Design, and AI tools for UX/UI.
Golang & AI Tech: Discussed register allocation, BBQV vector index, and GUI libraries.
YouTube Transcription Tool: Using Whisper API for transcripts.
Newsletter Bot: Collecting and scoring newsletter content with ChatGPT.
AI Tool Integration: Summarizing Discord/Twitter content using AI.
Q&A & Wrap-up: Technical issues, API use, and future demos.

Vietnamese Transcript

00:00 Hello mọi người, Ok chúng ta ổn rồi. Anh Thành đang nói phải không? Không nghe được, thử kiểm tra lại mic nhé.

00:20 Ok, đã nghe được rồi. Chắc đợi chị Ngọc lên một chút rồi bắt đầu nhé. Chủ yếu là vài vấn đề gần đây, chắc 70% thời gian sẽ dành để trao đổi về các vấn đề nội bộ của chúng ta.

00:40 Đã có 36 người tham gia, còn đợi ai nữa không? Nếu không, mình bắt đầu luôn nhé. Điểm qua nhanh một số việc trong tháng vừa rồi: Chúng ta đã quay trở lại với văn hóa hybrid, khuyến khích mọi người mỗi tuần sẽ lên văn phòng vài ngày.

06:47 Mục đích của việc lên văn phòng là để trao đổi kiến thức, học hỏi lẫn nhau một cách nhanh hơn so với làm việc online hoặc chỉ qua các buổi OGIF. Sau vài tuần triển khai chương trình này, thấy mọi người cũng khá hào hứng. Bên cạnh đó, có nhiều chính sách hỗ trợ cho việc lên văn phòng như khi check-in sẽ nhận được ICY, gửi xe cũng được ICY. Bên cạnh đó, phần ăn trưa của mọi người cũng sẽ được hỗ trợ.

07:20 Như mọi người cũng đã biết, định hướng của chúng ta là học và thực hiện các dự án liên quan đến AI và LLM càng nhiều càng tốt. Mình thấy các bạn khá hứng thú với những series hướng dẫn về prompting từ phía Tom hoặc những kiến thức mới. Thành, em chia sẻ thêm nhé.

07:58 Em thấy bình thường chúng ta có OGIF vào cuối thứ Sáu, nhưng giờ anh em đã bổ sung thêm buổi demo của Tom vào thứ Tư. Trong thời gian tới, dự kiến sẽ tiếp tục duy trì chu kỳ này trong khoảng 1-2 tháng nữa. Mục đích là để thúc đẩy việc sử dụng những công cụ AI, những automation tools cho công việc và học thêm các kỹ thuật liên quan đến ứng dụng.

08:40 Mọi người nên theo dõi để biết tình hình và cập nhật các công cụ hiện tại. Chủ yếu chúng ta sẽ học cách xây dựng (build-up), sử dụng các tool, như việc định nghĩa workflow, viết prompts sao cho đúng để áp dụng vào công việc coding hay các task liên quan đến development. Chắc là Tom sẽ phụ trách việc này và cập nhật kiến thức cho mọi người.

09:23 Ngoài ra, hiện tại chúng ta có một vài chính sách để khuyến khích mọi người tập trung vào AI/LLM nhiều hơn. Ví dụ, những hoạt động hay demo liên quan đến LLM từ tuần này, lượng reward ICY sẽ nhân 3 hoặc 4 lần, tùy vào chất lượng của bài viết hay output của mọi người. Đây là một sự khích lệ cho những ai quan tâm đến AI.

10:13 Về các mục tiêu cụ thể hơn, có lẽ đầu tuần sau sẽ có thông báo chi tiết về những thứ cần tập trung và các công cụ nào nên sử dụng. Tóm lại là vậy, tình hình chung là như vậy.

10:58 Ok, cảm ơn Thành. Như vậy, những hoạt động nghiên cứu liên quan đến AI sẽ được nhân 3 hoặc 4 lần reward. Có ai hỏi nếu spam link liên quan đến AI thì có được thêm ICY không? Chắc là mình sẽ xem xét thêm, mỗi ICY tương đương 1.5$.

11:56 Để nhắc lại cho mọi người, trong các buổi OGIF của chúng ta, ngoài các phần demo, sẽ luôn có những phần liên quan đến market commentary, cập nhật từ Go Weekly, AI, và sắp tới sẽ có thêm mảng product design.

12:47 Một thông báo cuối cùng, team ops đang sắp xếp cho chuyến company trip vào tháng 12 tới tại Penang, Malaysia. Thông tin chi tiết sẽ được chia sẻ trên kênh alert hoặc do Inno chia sẻ. Thành, còn gì nữa không hay Bảo muốn chia sẻ thêm gì với mọi người trước khi vào phần tiếp theo?

13:42 Không có gì thêm, anh chị em nhớ hoàn thành BP sớm nhé. Cung cấp thông tin qua Inno để chuẩn bị cho company trip. Rồi, Thành, mình chuyển tiếp qua phần OGIF thôi.

14:56 Hôm nay, mình dự định pick-up một vài demo về tool-building mà anh em đã làm trong đợt vừa rồi. Đầu tháng Bảo có phát động, nên hiện đang có một vài demo và commentary.

15:56 Đầu tiên, nhường diễn đàn cho bên phía design với phần của Nam Bùi. Nam ơi, em lên được chưa?

16:44 Dạ, em lên rồi. Hôm nay, em sẽ trình bày về chủ đề Product Design Commentary năm 2024 - phần 1. Em sẽ nói về các domain đang nổi, phổ biến và tương lai trong ngành Product Design. Đồng thời, em cũng đề cập đến những vấn đề đau đầu (pain points) mà các domain này gặp phải. Nếu team mình phát triển trong các mảng này, có thể dùng đó làm unique selling point.

16:56 Em sẽ đề cập đến 4 domain chính:

VUI (Voice User Interface)
AR/VR (Augmented/Virtual Reality)
Modular Design Systems
AI tools hỗ trợ quy trình UI/UX workflow.

17:29 Đầu tiên, em nói về VUI. Hiện tại, VUI được ứng dụng nhiều trong ngành Smart Home, như điều khiển các thiết bị nhà thông minh, xe hơi thông minh. Dự đoán vào năm 2026, khoảng 50% dân số Mỹ sẽ sử dụng VUI trên các thiết bị của họ.

17:44 Ở Việt Nam, hiện FPT.AI đang là đơn vị mạnh nhất trong lĩnh vực này, với các ứng dụng như Kiki App tích hợp trong thiết bị ô tô để chỉ đường. Trên thế giới, các ứng dụng VUI phổ biến như Alexa của Amazon, Google Assistant, và Siri của Apple đang chiếm lĩnh thị trường.

17:44 Tổng hợp phản hồi từ người dùng, Alexa có ưu thế về NLP nhưng không mạnh về lập trình. Google Assistant tích hợp Google Search nên có kiến thức đa dạng nhưng không sâu. Siri là kém nhất trong ba, chủ yếu dùng Bing, nhưng giọng điệu của nó không được thân thiện lắm.

17:56 Chuyển qua PP (Predictive Programming), công nghệ này hiện chưa áp dụng nhiều cho tiếng Trung và tiếng Việt. Chủ yếu tập trung vào tiếng Anh và các ngôn ngữ phổ biến khác, do thiếu dữ liệu huấn luyện AI cho ngôn ngữ phức tạp. Nhưng trong tương lai, với sự phát triển về công nghệ và dữ liệu, em tin rằng PP sẽ trở nên phổ biến hơn với các ngôn ngữ này.

18:13 Về phần Predictive Programming (PP), công nghệ này hiện chưa áp dụng được rộng rãi cho các ngôn ngữ khác ngoài tiếng Anh. Những ngôn ngữ phức tạp như tiếng Trung hoặc tiếng Việt chưa được hỗ trợ tốt. Thường thì người sử dụng cần phải thành thạo tiếng Anh mới tận dụng hiệu quả được PP. Về mặt flexibility, PP hiện vẫn chưa đủ thông minh để hiểu mọi ngữ cảnh mà mình nói; nó chỉ hiểu được khi mình tuân theo đúng những mẫu câu lệnh đã được lập trình sẵn. Đây cũng là một điểm yếu cần được cải thiện trong tương lai.

19:00 Tiếp theo, em sẽ nói về lĩnh vực AR/VR (Augmented Reality/Virtual Reality). Lĩnh vực này hiện đang tập trung chủ yếu vào các ngành như e-commerce, bất động sản, giúp người dùng có thể trải nghiệm trực tiếp mà không cần phải đến tận nơi. Ví dụ, họ có thể xem trước căn nhà qua ứng dụng VR thay vì phải đến thăm trực tiếp. Năm 2019, giá trị thị trường của AR/VR chỉ khoảng 0,44 triệu tỷ đô, dự đoán đến năm 2024 sẽ đạt 1,73 tỷ đô, và có khả năng chạm mốc 40 tỷ đô vào năm 2027.

19:46 Tuy nhiên, nhiều doanh nghiệp đã thử ứng dụng AR/VR vào các website của họ, nhưng phần lớn đã rút lại do vấn đề hiệu suất không ổn định. Trong giai đoạn đầu năm 2023 đến cuối năm 2023, AR/VR được áp dụng rộng rãi, nhưng đến đầu năm 2024, nhiều doanh nghiệp bắt đầu rút khỏi website vì trải nghiệm người dùng kém, đặc biệt là khi người dùng truy cập mà gặp phải lag hoặc tốc độ tải chậm.

20:54 Điều này gây khó chịu cho người dùng, khiến họ nhanh chóng thoát khỏi trang web. Hơn nữa, chi phí để phát triển và duy trì AR/VR là rất cao, nên chỉ có những doanh nghiệp lớn, dư ngân sách mới đầu tư vào công nghệ này. Các doanh nghiệp vừa và nhỏ thường không muốn chi quá nhiều cho việc tích hợp AR/VR vào trang web của họ.

21:38 Phần tiếp theo là về Modular Data Systems, tập trung vào việc sử dụng các reusable design components giúp phối hợp hiệu quả giữa designer và developer. Hiện nay, trên thị trường có nhiều bộ design system phổ biến, kết hợp cả file UI Figma và các UI components hỗ trợ từ các thư viện.

22:17 Ví dụ phổ biến nhất là Ant Design System, tuy nhiên UI của Ant Design hiện đã hơi cũ. Ngoài ra, còn có các lựa chọn hiện đại hơn như Tailwind UI và Chakra UI. Cách phối hợp giữa designer và developer là cùng sử dụng một bộ file Figma từ thư viện, designer sẽ thiết kế dựa trên bộ đó, và developer sử dụng các component tương ứng để phát triển.

23:00 Ví dụ, nếu designer muốn làm một bảng (table), họ sẽ chọn component table trong Figma, còn developer sẽ sử dụng đúng component đó để xây dựng trong code. Điều này đảm bảo sự đồng nhất giữa thiết kế và việc triển khai, giúp giảm thiểu sai lệch giữa thiết kế và sản phẩm cuối cùng. Hiện tại, nhiều thư viện còn hỗ trợ responsive design, giúp developer không cần phải làm lại cho từng thiết bị khác nhau.

24:09 Đội ngũ của mình cũng có một team tên là Mochi đang phát triển bộ Design System riêng. Một vấn đề khi áp dụng các thư viện này là sản phẩm có thể thiếu đi sự độc đáo, dấu ấn riêng của từng ứng dụng. Ví dụ, 10 ứng dụng cùng sử dụng Ant Design thì giao diện sẽ rất giống nhau, không có sự khác biệt.

24:56 Do đó, designer và developer cần phải phối hợp rất chặt chẽ. Nếu designer muốn tùy chỉnh bất kỳ component nào trong Figma, họ cần thông báo ngay cho developer để cập nhật lại code tương ứng. Điều này đòi hỏi sự giao tiếp liên tục giữa hai bên để đảm bảo tính nhất quán trong suốt quá trình phát triển.

25:41 Về các công cụ AI hỗ trợ UX/UI, AI tools giúp chúng ta phân tích hành vi người dùng một cách chính xác và nhanh chóng. Về phần UI, AI có thể hỗ trợ tạo ra các components hoặc styles phù hợp với từng lĩnh vực khác nhau. Các công cụ như ChatGPT, Claude AI, và Midjourney đang làm rất tốt trong việc hỗ trợ nghiên cứu và phát triển UX/UI.

26:32 Hiện tại, về phần UI thì nó hỗ trợ phần lớn việc tạo ra các hình ảnh (image) nhưng không thể tạo ra được dạng vector hay pixel mà mình có thể chỉnh sửa được. Tuy nhiên, có một số công cụ đang cố gắng cải thiện, ví dụ như khi sử dụng công cụ Midjourney, mình có thể generate ra hình ảnh rồi đưa vào Figma, và hiện tại nó đã có khả năng copy ra thành các layout có auto layout của Figma luôn, giúp việc chỉnh sửa dễ dàng hơn.

27:24 Nhưng nhìn chung, output của AI về UI hiện tại chủ yếu vẫn chỉ ở dạng hình ảnh (image), rất hiếm khi có thể generate ra vector hoặc những component có thể sử dụng trực tiếp trong thiết kế. Đó là một điểm yếu và hạn chế của công nghệ AI hiện tại trong việc hỗ trợ thiết kế UI.

28:20 Đối với UX, em nhận thấy AI đang hỗ trợ tốt hơn rất nhiều. Ví dụ, khi mình nhận được một yêu cầu (requirement) ngắn gọn từ phía client, mình có thể thả vào ChatGPT để nó đưa ra một gợi ý về cấu trúc thông tin (info architecture) hoặc các giải pháp UX phù hợp. Thực tế là đôi khi em không nắm rõ hết các yêu cầu nhưng khi thả vào ChatGPT, nó lại cho ra những ý tưởng rất hữu ích, đáp ứng đúng nhu cầu của client.

28:55 Tuy nhiên, với UI, dù mình có sử dụng AI thì nó vẫn khó có thể tạo ra được những thiết kế đúng ý mình mong muốn. Ngay cả khi nó có thể tạo ra, thì output thường chỉ là dạng image, không phải là những file có thể sử dụng trực tiếp như Figma hay Sketch. Vì vậy, trong mảng UI, AI hiện tại vẫn còn nhiều hạn chế và cần được cải thiện thêm.

29:20 Anh có đồng ý với em không? Phần UX thì AI có vẻ đang làm tốt hơn UI.

29:45 Chính xác. Đặc biệt là khi mình làm việc với các yêu cầu dạng info architecture, AI thường cho ra các kết quả khá đúng và phù hợp, giúp tiết kiệm rất nhiều thời gian cho designer. Nhưng với UI, hiện tại vẫn cần có sự can thiệp của con người để đảm bảo tính thẩm mỹ và độ chính xác.

30:30 Nếu không còn câu hỏi nào khác, em xin phép kết thúc phần chia sẻ của mình. Rất cảm ơn mọi người đã lắng nghe và hy vọng mọi người có thể áp dụng được một vài điểm trong phần trình bày này vào công việc hàng ngày của mình.

31:00 Cảm ơn Nam Bùi về phần chia sẻ rất chi tiết và đầy đủ về Product Design Commentary 2024. Những insights về việc AI hỗ trợ UX/UI thực sự rất hữu ích và cung cấp cho team những góc nhìn mới về việc ứng dụng AI trong thiết kế. Hy vọng sẽ được nghe thêm nhiều bài chia sẻ thú vị từ bạn trong các buổi OGIF tiếp theo.

32:51 Tuần rồi em thấy có hai bài như thế này. Thực ra, còn một bài nữa liên quan đến GUI nhưng lát nữa em sẽ nói sau. Đầu tiên là bài về “register allocation” của Golang compiler. Bài này hơi phức tạp một chút nên em không thể đưa hết nội dung vào đây được. Chủ yếu là phía Go họ thực hiện việc register allocation thông qua bước SSA (Static Single Assignment).

Mọi người có thể đọc tham khảo thêm ở trong link mà em đã bỏ vào đây. Nhưng nhìn chung, bài viết này tập trung vào quá trình tối ưu hóa việc compile bằng cách sử dụng SSA để quản lý register allocation.

37:43 Để tổng kết lại, quá trình này giúp cải thiện thời gian compile của chương trình Golang. Cụ thể, nó tập trung vào việc tối ưu hóa hai bước chính là register allocation và stack allocation, từ đó giúp giảm khoảng 20% thời gian compile, đặc biệt hữu ích cho những ứng dụng Go có logic phức tạp hoặc những ứng dụng lớn.

Đây là một bài viết rất chi tiết và kỹ lưỡng, được thực hiện bởi một trong những chuyên gia trong cộng đồng Rust. Bài viết này rất hữu ích cho những ai có quan tâm đến quá trình compiler hoặc muốn tìm hiểu sâu hơn về hiệu suất của Go.

38:17 Chuyển qua phần thứ hai liên quan đến lĩnh vực AI. Đó là một giải pháp mới có tên gọi BBQV, đây là một Vector Index được phát triển bởi một nhóm gọi là Dexa ở bên Mỹ. BBQV tập trung vào điểm mạnh chính của nó là “scalable vector search.” Điểm thú vị là BBQV không phải là giải pháp nhanh nhất, cũng không phải là giải pháp chính xác nhất, nhưng nó lại có khả năng build index cực kỳ nhanh so với các giải pháp khác. Xíu nữa em sẽ cho mọi người thấy biểu đồ mà nhóm tác giả của BBQV đã so sánh với các giải pháp ANN (Approximate Nearest Neighbor) khác.

39:13 Điều nổi bật của BBQV là khả năng build index với tốc độ rất nhanh, mặc dù carry time của nó chỉ nằm ở mức trung bình so với các giải pháp khác. Để so sánh cụ thể hơn, trên biểu đồ dưới đây, BBQV nằm ở khoảng giữa khi nói về carry time nhưng lại thuộc nhóm nhanh nhất về build time. Điều này là một điểm sáng khi triển khai BBQV trong các hệ thống AI có quy mô lớn, vì thời gian xây dựng index là rất quan trọng.

39:24 Ngoài ra, còn một bài nữa liên quan đến GUI trong Go. Mặc dù GUI trong Go không phải là một thế mạnh, em vẫn tìm thấy một số giải pháp GUI khá thú vị và muốn giới thiệu cho mọi người. Trong thời gian qua, cộng đồng Go đã cố gắng xây dựng các thư viện GUI có khả năng cạnh tranh với các giải pháp khác như Qt hay Electron. Tuy nhiên, phần lớn các giải pháp GUI này vẫn chưa thực sự hoàn thiện và thiếu tính năng so với những thư viện phổ biến từ các ngôn ngữ lập trình khác.

39:59 Đó là những gì mà bên team Dex đang dùng, Dex AI này đang xài cái đó, và nó cũng đã open-sourced rồi.

Biểu đồ này cho thấy rằng BBQV có carry time không phải là nhanh nhất nhưng rất ổn định. Tuy nhiên, về mặt build time, BBQV là một trong những giải pháp nhanh nhất. Vì nó là kiểu “selling point” của nó, là để build một cái index thì xài thằng này là nhanh nhất.

Còn về một bài nữa là GUI, mình không bỏ vào đây tại vì nhìn chung thì mình thấy bên Go GUI nó cũng hơi hạn chế. Nhưng mà mình kiếm được một thằng gọi là xịn nhất bên Go. Cái accessibility của nó, gallery của nó cũng đẹp, và nhìn chung là khá là mature. Mới đây có một ngôn ngữ mới tên là R, nó cũng viết bằng Go luôn, và nó cũng có một cái extension tích hợp với thằng GUI này. Nhìn chung nó trông như thế này thôi, ví dụ nó trông như thế này.

40:24 Ngoài ra, còn một bài nữa liên quan đến GUI trong Go. Mặc dù GUI trong Go không phải là một thế mạnh, em vẫn tìm thấy một số giải pháp GUI khá thú vị và muốn giới thiệu cho mọi người. Trong thời gian qua, cộng đồng Go đã cố gắng xây dựng các thư viện GUI có khả năng cạnh tranh với các giải pháp khác như Qt hay Electron. Tuy nhiên, phần lớn các giải pháp GUI này vẫn chưa thực sự hoàn thiện và thiếu tính năng so với những thư viện phổ biến từ các ngôn ngữ lập trình khác.

40:44 Hiện tại, team DEX AI bên mình đang sử dụng cái này. Nó là mã nguồn mở (open-source) nên rất tiện lợi khi tích hợp vào hệ thống của mình. Còn về mảng GUI, mình cũng tìm hiểu thêm về các thư viện (library) dành cho Go. Phải nói thật là GUI của Go vẫn còn khá hạn chế (tù túng), nhưng mình đã tìm được một thư viện gọi là Fyne. Đây là một trong những thư viện GUI tốt nhất hiện tại dành cho Go. Giao diện của nó (UI gallery) cũng rất đẹp và mature, nghĩa là nó đã khá hoàn thiện so với các thư viện khác.

41:45 Và gần đây, có một ngôn ngữ mới xuất hiện tên là Gio, cũng được viết bằng Go. Nó cung cấp một số extension có thể tích hợp trực tiếp với Fyne, tạo ra giao diện GUI như bạn thấy ở đây. Dường như xu hướng này đang phát triển khá nhanh trong cộng đồng Go. Về phần này, mình sẽ dừng ở đây để chuyển qua phần của Phát. Không biết Phát có muốn chia sẻ thêm không?

42:46 Ừm, theo quan sát của tôi thì thấy tên gọi BBQ đã trở nên phổ biến trong lĩnh vực vector database (vector DB). Nhiều dự án mới đều sử dụng BBQ vì tên nghe hay, nhưng thực ra các vector database như này đã vượt qua khái niệm đơn giản chỉ là dimensionality. Việc chọn vector DB nào phù hợp sẽ phụ thuộc nhiều vào yếu tố như hiệu năng và tính năng. BBQ tuy nghe vui, nhưng về tốc độ tìm kiếm (search speed) và hiệu quả tìm kiếm (recall), thì nó có thể không phải là nhanh nhất, nhưng vẫn đạt hiệu suất rất tốt. Nhanh nhất ở đây có lẽ phải kể đến thằng ‘HNSW,’ tuy nhiên BBQ vẫn là một sự lựa chọn ổn định.

44:03 Còn về các case study của những công ty lớn đang sử dụng Golang, chúng tôi đã thu thập được một số thông tin rất thú vị. Như đã đề cập, Google – đương nhiên không thể thiếu, vì họ là cha đẻ của Golang. Các doanh nghiệp lớn khác như Meta, Microsoft, và các công ty trong lĩnh vực tài chính như American Express, Monzo, và Paypal đều đã triển khai Go trong hệ thống của họ. Ở mảng streaming, Twitch cũng là một cái tên lớn đang sử dụng Go cho backend của mình. Trong mảng game, Riot Games cũng đã sử dụng Go trong một số dịch vụ. Tôi sẽ tiếp tục cập nhật thêm thông tin chi tiết về những case study này.

45:51 Đấy, bên bên bên bên Tom cái phần script chắc là thôi nhỉ, hơi basic hả? Ừ, cũng basic. Nếu còn thời gian thì demo nhanh được à. Rồi ok, thì mình nói về cái transcript YouTube. Thật ra là trước đó, trước đó team mình nó có một cái engine để xử lý cái phần này rồi, nhưng mà cái đó hình như bị hạn chế. Nó bị hạn chế bởi thời lượng 50 phút hay sao đó, nên mình mới viết lại một cái backend để process nó bằng cách sử dụng thằng Whisper API.

46:42 Thằng Whisper API này, nó có một cái gói free để transcribe audio. Một ngày nó cho phép mình transcribe khoảng 600 phút audio miễn phí, nhưng mỗi file chỉ có thể dài tối đa 2 tiếng. Mình tận dụng thằng Whisper API này để chuyển nội dung của video YouTube thành dạng văn bản. Quy trình cơ bản là khi mình đưa một link YouTube vào, hệ thống backend sẽ tự động tải về file video, sau đó chuyển đổi file đó thành định dạng MP3, rồi nén lại để kích thước file phù hợp với giới hạn của Whisper API (25MB mỗi file).

Thời gian nén và xử lý sẽ phụ thuộc vào độ dài của video gốc. Sau khi quá trình xử lý hoàn tất, hệ thống sẽ gửi từng đoạn audio đã nén lên Whisper API để tiến hành việc chuyển đổi từ âm thanh sang văn bản. Kết quả trả về từ API sẽ bao gồm thông tin chi tiết từng đoạn, từ thời gian bắt đầu đến kết thúc, và đoạn text tương ứng. Những đoạn này sau đó sẽ được combine lại và tiếp tục xử lý qua GPT-4 để tinh chỉnh, hiệu chỉnh câu chữ, đảm bảo văn bản đầu ra sát với ngôn ngữ gốc và chính xác hơn.

48:21 Dựa trên cái segment như vậy, mình combine nó lại rồi sử dụng GPT-4 để thực hiện việc hiệu chỉnh các tiểu tiết (tweak little details) ở đó. Thường thì tiếng Anh nó không bị sai gì hết. Nhưng mà tiếng Việt, nó lại có vấn đề với một số chỗ, ví dụ như ở miền Bắc, cách phát âm chữ dấu ngã thành dấu sắc, phát âm chữ ‘r’ thành ’d’. Khi mà ra được cái output như vậy, khi đọc thì nó sẽ bị sai về tay vô. Do đó, mình đưa cái content đó cho GPT-4 để nó chỉnh lại (correct) và kết quả là mình sẽ có một đoạn text hoàn chỉnh, đúng với bản gốc của video YouTube.

Sau khi ra được content như vậy, mình gửi lên cho D. Nó nhận được D này, cái app này nè, nó sử dụng một công cụ gọi tới cái backend hồi nãy và nó nhận được JSON như vậy. Từ đó, nó bật ra, và tiếp tục sử dụng một thư viện để render cái đoạn transcript như vậy. Nó trả về một đoạn nội dung như thế này, bao gồm full content.

49:55 Đó là cái mà mình đã làm được. Nếu mà mình sử dụng gói trả phí (subscription plan) của Whisper API luôn thì mình sẽ không bị giới hạn bởi việc cứ mỗi tiếng chỉ convert được khoảng hai tiếng audio. Tuy nhiên, có một giới hạn nữa là khi deploy lên server qua Heroku hay một số server khác, do quá trình xử lý audio này khá tốn thời gian, nên đôi khi gặp vấn đề timeout. Nhưng nếu mình chạy trực tiếp trên local thì mọi thứ sẽ mượt mà hơn rất nhiều.

Đó là lý do tại sao mình sử dụng công cụ này ở bên phía project OIP. Có cái phần chỉnh sửa transcript mà anh em xem lại, không biết là đang dùng con này hay dùng cái gì khác?

Hiện tại, mình đang chỉnh lại config để sử dụng công cụ này cho phù hợp hơn. Cái của Tom hình như cũng đang bị đứt rồi hay sao ấy. Vì phần OGIF của mình hiện tại rất là dài, cũng hơn tiếng mấy, cho nên để process hết đoạn đó thì có thể cần phải cải thiện lại performance của công cụ này để nó có thể hoạt động tốt hơn.

50:40 Hiện tại mình đang dùng free API bên nào? Có ba cái workflow, hai cái là free API, một cái là của em, cái của em bị YouTube chặn rồi. Hình như nó không ổn định đúng không? Ừ, cũng có lúc ổn định lúc không, hai cái đều bị chặn hết rồi. Còn một cái API còn lại là Note GPT bên phía em Mỹ đang dùng, nhưng transcript dài thì cũng có khả năng bị crash thôi.

52:18 Ok, đúng rồi, lúc ổn định lúc không. Thực ra thì nếu video dưới 10 phút thì luôn work, còn bắt đầu dài hơn chút xíu thì còn tuỳ thuộc. Vấn đề là resources của server miễn phí, không biết là nó có reset được hay không. Còn nếu dài thì cứ đem cái source về local chạy là được hết.

53:35 Mọi người cũng thấy trên phần AI comment trên Discord, mình đã có một số script từ Twitter rồi. Thì bên phía cái quy trình mình đang làm là làm một cái API từ model Python script. Sau đó mình deploy nó luôn, mô hình này có một cơ chế cho phép mình deploy thẳng như là một cái API.

54:53 Sau đó mình sử dụng API này để script thông tin từ bên phía mình. Nó sẽ là một cái script chạy như vậy, nó là một cái function nằm trên container, chạy một browser đó, xem trong viewport và lấy các selector và thông tin từ text đó comp từ container của mình. Sau đó mình sẽ expose ra một cái POST request.

POST request này chỉ cần URL, ví dụ như mình lấy Twitter, hoặc lấy từ sc.com chẳng hạn.

55:39 Mình muốn script data này thì mình có thể test trực tiếp bên phía Postman request, nhưng với Dify, mình có thể test trực tiếp trên này luôn. Và cái hay nhất là khi mình test xong, mình có thể convert cái workflow từ Dify sang một cái function call, cái này có thể áp dụng trên một cái agent hoặc một cái gì đó riêng cho bên phía Dify nữa.

56:38 Cái này có tích hợp bên phía Discord AI, cho nên có bạn nào muốn summarize lại từ Twitter thì chỉ cần post cái link vào, nó sẽ tự summarize. Hình như đang bị lag rồi. Chạy lại tiếp thử xem. Có vẻ như đang bị lag à? Nhưng cứ tưởng tượng là nó sẽ lấy được từ Twitter. Sau này sẽ dùng phương pháp này để script từ bên phía Facebook và bên phía Hoàng đang dùng phương pháp để upload một cái API qua mô hình để script và lấy dữ liệu từ Discord message.

57:53 Sở dĩ là khi mình gom lại thì Dify auto-convert thành một cái tool luôn. Bình thường mình có thể publish một cái app riêng, tương tác với nó. Hay hơn là mình tạo một cái workflow tool, nó sẽ sắp xếp như là một function call bên phía OpenAI.

58:37 Đây là cái Discord AI bot mọi người đang AI comment, mọi người đang dùng cho Discord của team mình. Hiện tại, nó có mấy cái tool mình tự làm như là Twitter script nằm ở trong này luôn. Một cái là lấy YouTube transcription của một dịch vụ bên phía tôi làm, một cái là query memo, nó là tooling mình làm để kéo data từ Memo của team mình. Còn lại là mấy cái tool có sẵn trên Dify. Lúc mình muốn add thì nó sẽ nằm ở trên cái list danh sách của workflow. Khi mình tạo workflow xong, sau đó deploy và configure nó, thì nó sẽ nằm hết ra ở trên này.

59:17 Thì chắc thử xem, “What are the latest notes added to the doors?” thì nó sẽ lấy Prompt Token ở trên description của tool và ở trên cái system prompt, nó sẽ biết là dùng tool nào cho phù hợp. Vậy là lấy data dựa vào hai yếu tố đúng không? Thứ nhất là cái system prompt của em, và thứ hai là cái description của tool. Dựa trên câu query ban đầu vào thì nó sẽ detect xem là nên sử dụng cái tool gì để process tiếp đúng không?

Dạ đúng rồi, nên ví dụ mình chọn cái này thì nó sẽ switch lại, xem cái nào phù hợp nhất, sau đó chạy cái tool cho mình. Sau đó nó có một cái agent chạy lấy data và gửi lại cho bên phía AI. Ở đây chắc là fail nhưng ý tưởng là như vậy thôi.

Ok, chắc phần của em xong rồi, chắc nhường lại cho người tiếp theo.

01:00:46 Demo nhanh về itool để hỗ trợ làm memo, cái transcript hiện tại. Hiện tại là nó là dưới dạng một con Discord bot như thế này. Discord như thế này thì em đang host ở trên máy, tại vì server thì tốn tiền. Sẽ có hai cái command chính. Một cái là cái list, thì tính năng của nó đơn giản là nó sẽ có một cái account collect newsletter. Có nghĩa là cái data source của em là những cái newsletter email đó, em dùng một cái email để subscribe khoảng 100 chỗ, nhưng mà tất cả thì nó sẽ về thằng này. Và đơn giản là kiểu có email nào mới mà chưa đọc thì em cào về thôi.

Thì backend thì em build bằng Python. Cái app này thì kiểu 90% là xài core standard code.

01:02:55 Thì cái functionality của nó đơn giản là như thế này. Khi em cào về thì nó sẽ có một cái table article như thế này. Nó sẽ có một cái table article như vậy. Em sẽ lấy title, description cụ thể. Mấy cái này thì em dùng trên BeautifulSoup để lấy. Để sau em sẽ show sau. Nhưng mà về tính năng thì nó đơn giản kiểu vậy thôi.

Ví dụ như em muốn lấy bảy cái bài về một kiểu category. Ờ tất cả trong vòng bảy ngày. Em lấy tất cả những bài thuộc tất cả các category trong vòng bảy ngày. Đó thì nó sẽ trả ra vậy, presentation list kiểu như vậy.

Thì đây là cái feature đầu tiên là kiểu list ra những cái article mà em collect được từ bên phía email inbox thôi. Cái command thứ hai là “lend draft cho memo”. Khi mà chạy, nó sẽ load lên kiểu như này.

01:03:33 Thì đây là cái feature đầu tiên là kiểu list ra những cái article mà em collect được từ bên phía cái email inbox thôi. Ờ một cái comment thứ hai là ờ lên draft cho Memo thì khi mà chạy á thì nó sẽ lên kiểu này. Ờ thì mấy cái như là mấy cái category, cái mấy cái main category mà giống như kiểu nếu mà mọi người có đọc mấy cái PR repo của em á thì mình chỉ có mấy cái kiểu mấy cái main stack của mình như thằng React hay là NestJS này thì nó sẽ wrap lên kiểu cũng giống như cái cấu trúc của bài Memo thôi.

01:04:14 Kiểu sẽ có 3 bài kiểu có điểm số cao nhất. Ờ rồi đây là sẽ năm bài, những cái bài relevant mà điểm số nó thấp hơn. Thì cái điểm số thì em có đánh theo kiểu nó là relevancy score. Kể vậy thì lúc mà em feed vào cho ChatGPT mini thì em sẽ yêu cầu con ChatGPT mini nó đánh, nó đánh score luôn. Ờ cụ thể cái prompt thì nó nằm ở đây. Đây là cái prompt cho ChatGPT mini kiểu vậy. Là ờ em sẽ cào hết cái email convert sang biotext giữ lại link rồi sau đó feed vô cho con ChatGPT mini với một list mấy cái criteria như thế này để cho

01:05:01 Nó đọc và nó extract, nó sẽ đánh relevancy score, nó extract article. Kiểu cái format nó giống kiểu ờ nó phải output format, cái format nó output à, dạ đây JSON array có title có description có link và cái danh sách criteria cùng với cái mớ relevancy score của nó thôi đó. Thì thì khi mà cào ra hết thì em bỏ vào cái database như vậy. Ờ cron job khi mà con bot này nó chạy á thì hiện tại em cron job cho nó chạy. Gọi sẽ có một cái job để nó chạy mỗi, nó chạy mỗi ngày thì sẽ vào lấy chỉ lấy những cái email mà chưa đọc thôi.

01:05:56 Cái thứ hai là kiểu dùng được ChatGPT Mini này là 3.5 Pro thì đang xài cũng miễn phí luôn. Thì thằng ChatGPT mini pro này nó đang cho phép mọi người lên xài miễn phí lấy API access token của nó, mỗi ngày nó sẽ cho 1 triệu token cứ muốn xài sao xài. Thì thấy cái này Ok. Ờ dạ một số cái vấn đề hiện tại với con bot này thì cái thứ nhất là

01:06:40 Một số vấn đề hiện tại với con bot này thì cái thứ nhất là em chưa có filter ra mấy cái quảng cáo. Em em lúc mà bắt filter ra mấy cái quảng cáo. Cái thứ hai là kiểu như tin rác khá là nhiều ở cái kiểu mấy cái newsletter, đôi khi nó nó include luôn những cái link như những cái description trên GitHub, những cái PR nào được merge. Cái kiểu có nhiều cái newsletter nó nó cũng khá là nhiều tin rác kiểu vậy. Em vẫn đang optimize cái prompt để cho nó relevant hơn cái use case của team mình thôi. Nhưng mà nói chung là về functionality thì hiện tại thì em nghĩ là ok rồi, giờ chỉ có

01:07:16 Nhưng mà nói chung là về functionality thì hiện tại thì em nghĩ là ok rồi, giờ chỉ có ****optimize cái prompt thôi, chắc là vậy với lại chắc optimize cái relevancy score. Ờ tại vì hiện tại xài free cho nên đang bị thiếu một cái bước là vào từng cái article để cào content đọc rồi mới đánh relevancy. Hiện tại là relevancy score nó đánh là nó đánh dựa trên cái description mà được cung cấp bên bên cái newsletter thôi. Cho nên nói chung nó vẫn củ chuối. Để coi sao để để tìm cái model nào mà nó free hoặc là chạy local đó cho nó chạy nó cào rồi nó đọc. Thế còn hiện tại thì ChatGPT mini 3.5 pro tới cào chừng 15 email là nó hết. Nó nó hết quota.

01:08:02 Mỗi ngày em chạy vô cào được mấy cái. Dạ thì chắc là game nó vậy thôi. Ok hôm trước anh có comment là cái vụ viết cái commentary về feature thì nó đang thiếu sao ta, mới chỉ đọc link với cả đọc title thì chưa đủ, phải vọc vào content vọc vào parse parse parse bên trong ấy ra. Nói chung là sẽ có thôi anh, chắc là chắc là sau cái này thì em sẽ tìm một cái model free local đó để nó handle cái vụ cào với lại parse content. Kiểu để đánh relevancy lúc đầu thật ra là lúc đầu là em xài vector cộng với similarity để match với lại

01:08:58 Kiểu để đánh relevancy lúc đầu thật ra là lúc đầu là em xài vector cộng với similarity để match với lại mấy cái category. Nhưng mà kiểu nó đánh đánh kiểu gì á em cũng không biết, do em set up sai hay sao. Tại vì cũng kêu con OpenAI nó generate embedding không à. Xong cái nó đánh cái kiểu gì mà kiểu không có match được cái article nào hết. Xong cái em mệt quá em kêu con ChatGPT làm luôn. Ừ ok rồi thì mấy anh em mấy anh em đang sort mấy cái link từ bên kia mấy cái stack khác ấy xem có tham khảo hay là crawl các thứ thì xem thử. Ừ Ok chắc test thêm. Còn về mặt hosting thì nếu mà cần thì thì nhắn Quang ấy. Hiện tại dừng này lên thôi mình mấy con bot

01:09:48 Hiện tại dừng này lên thôi mình mấy con bot của mình trên đó là hiện tại bây giờ có đang expose với webhook Discord bot không anh? Bảo em tạo cái có thể expose API ra ấy. Còn em em host một cái function nào đấy để run thì Discord nó hay xài, model còn không bảo bảo Quang host setup service host tự chọn host cho. Dạ à Quảng model cũng ok đấy model Ok free sao ấy. Ý là ở trên Discord phải nó đâu có cho mình host data đúng không anh? Tại vì hiện tại bây giờ là phải đi cào với lại lưu vào database mà. À đúng rồi nhỉ thấy cái tự setup rồi. Ừ anh chắc để em hoàn thiện hơn tí là cái gì em liên hệ anh Quang.

01:10:39 Nó chỉ là một cái bước nói là cái expose API để access data thôi còn anh em muốn lưu trữ hay là thành index các thứ gì thấy tự set up rồi ok. Ok bây giờ đang hỏi là có đâu rồi ta chạy rồi à. Bây giờ đang hỏi là có handle in-memory được không anh? Ờ nó nó nó nó. Ý là em em đang làm này là kiểu lưu về ý là batch với lại database, batch process ngay cái lúc mà cào á để lưu lại để mình cho requery thì những lần ý là mình chỉ cần cào dưới dưới. Dạ cron job thôi thì khi mà người ta query thì cái trả, cái phản hồi nó sẽ là realtime mình ý là nó trả, hồi nó nó

01:11:44 Cron job thôi thì khi mà người ta query thì cái trả, cái phản hồi nó sẽ là realtime mình ý là nó trả, hồi nó mình sẽ không cần phải, mình sẽ không cần phải làm mấy cái đó. Nếu như mà có làm in-memory này kia thì em nghĩ chắc chỉ thêm cái runtime inference thôi kiểu cho người ta query bằng ngôn ngữ tự nhiên chứ không có kiểu comment với param. Như hiện tại còn còn cái chuyện mà đi collect article thì em nghĩ em em nghĩ là vẫn nên cào rồi process rồi lưu trong database chứ chứ nếu không mỗi lần chạy đều phải cào mấy trăm article thì chết tiền à. Ủa hiện như thế nào ta? Crawl lại crawl lại được không ta?

01:12:44 Mình không set lại đâu. Thôi vì đây là một cái engineering solution nên là mình phải có cái gì cho dữ liệu back pressure thì phải cần storage. Nói chung là có cách là mình mình bơm thêm tiền thôi. Ừ trả tiền thì có nó run thôi ok rồi cảm ơn ạ. Ok check xem thử đi. Đang đang lúc này tin đang bảo là tuần sau là những cái buổi thứ tư thì hiện tại đang có cái cái cái này demo các thứ cũng đang còn tương đối đấy chắc là cũng phải 4, 5 bài nữa thì chắc mình schedule sang thứ tư rồi anh em demo sau đấy. Để tôi chấm điểm đánh giá luôn hả? Ok ý còn lại nếu không

01:13:55 Nếu không ai quất thêm mấy cái copilot còn lại thì mình sẽ làm hết đấy. Ăn hết tiền của mọi người đấy. Okay. Ơ mà chi phí đợt, tò mò tí chi phí đợt vừa rồi anh em chạy vẫn đang xài key của em đúng không hả Tô? Ờ có đúng chắc là mọi người không có tới 1 triệu token đâu vậy. Hả? Chưa tới. Chưa tới. Dạ chưa tới. Bao nhiêu đấy? Vậy hả? Giỏi ta thật! Anh em cũng test hết đấy không bằng không bằng em hoặc là đặt prompt clean deep đâu. Không bằng đâu. Ok nếu mà vẫn thì xài thử đi thôi.

01:15:08 Hẹn anh em thứ tư tuần sau. Chúc mọi người cuối tuần vui vẻ nhé.

English Transcript

00:00 Hello everyone, OK we’re good now. Is that Thanh speaking? Can’t hear you, please check your mic.

00:20 OK, we can hear you now. Let’s wait for Ngoc to join for a bit before we start. We’ll mainly discuss a few recent issues, probably 70% of the time will be spent on our internal matters.

00:40 We have 36 participants now, are we waiting for anyone else? If not, let’s begin. Let’s quickly go through some events from last month: We’ve returned to a hybrid work culture, encouraging everyone to come to the office a few days each week.

06:47 The purpose of coming to the office is to exchange knowledge and learn from each other more quickly compared to working online or just through OGIF sessions. After a few weeks of implementing this program, people seem quite enthusiastic. Additionally, there are several policies to support coming to the office, such as receiving ICY when checking in, and also for parking. Moreover, lunch for everyone will also be supported.

07:20 As you all know, our direction is to learn and implement as many AI and LLM-related projects as possible. I see that you’re quite interested in the prompting tutorial series from Tom or new knowledge. Thanh, please share more.

07:58 I noticed that we usually have OGIF at the end of Friday, but now we’ve added Tom’s demo session on Wednesday. In the coming time, we plan to maintain this cycle for about 1-2 more months. The purpose is to promote the use of AI tools, automation tools for work, and to learn more techniques related to applications.

08:40 Everyone should keep track to know the situation and update on current tools. Mainly, we’ll learn how to build up, use tools, such as defining workflows, writing prompts correctly to apply to coding work or development-related tasks. Tom will probably be in charge of this and update knowledge for everyone.

09:23 In addition, we currently have a few policies to encourage people to focus more on AI/LLM. For example, activities or demos related to LLM from this week, the amount of ICY reward will be multiplied by 3 or 4 times, depending on the quality of the article or output. This is an encouragement for those interested in AI.

10:13 For more specific goals, perhaps early next week there will be a detailed announcement about what to focus on and which tools to use. That’s it in summary, that’s the general situation.

10:58 OK, thank you Thanh. So, AI-related research activities will receive 3 or 4 times the reward. Someone asked if spamming AI-related links would earn more ICY? We’ll probably consider that further, each ICY is equivalent to $1.5.

11:56 To remind everyone, in our OGIF sessions, besides the demo parts, there will always be sections related to market commentary, updates from Go Weekly, AI, and soon we’ll add a product design section.

12:47 One last announcement, the ops team is arranging for a company trip this December in Penang, Malaysia. Detailed information will be shared on the alert channel or by Inno. Thanh, is there anything else, or does Bao want to share anything more with everyone before we move on to the next part?

13:42 Nothing more, everyone remember to complete the BP early. Provide information through Inno to prepare for the company trip. Alright, Thanh, let’s move on to the OGIF section.

14:56 Today, we plan to pick up a few demos about tool-building that you guys have done recently. Bao initiated it at the beginning of the month, so there are currently a few demos and commentaries.

15:56 First, let’s give the floor to the design side with Nam Bui’s part. Nam, are you ready?

16:44 Yes, I’m ready. Today, I’ll present on the topic of Product Design Commentary for 2024 - Part 1. I’ll talk about emerging, popular, and future domains in the Product Design industry. At the same time, I’ll also mention the pain points that these domains face. If our team develops in these areas, we can use that as a unique selling point.

16:56 I’ll cover 4 main domains:

VUI (Voice User Interface)
AR/VR (Augmented/Virtual Reality)
Modular Design Systems
AI tools supporting UI/UX workflow.

17:29 First, let’s talk about VUI. Currently, VUI is widely applied in the Smart Home industry, such as controlling smart home devices, smart cars. It’s predicted that by 2026, about 50% of the US population will use VUI on their devices.

17:44 In Vietnam, FPT.AI is currently the strongest in this field, with applications like Kiki App integrated into car devices for navigation. Worldwide, popular VUI applications like Amazon’s Alexa, Google Assistant, and Apple’s Siri are dominating the market.

17:44 Summarizing user feedback, Alexa has an advantage in NLP but is not strong in programming. Google Assistant integrates Google Search, so it has diverse but not deep knowledge. Siri is the weakest of the three, mainly using Bing, but its tone is not very friendly.

17:56 Moving on to PP (Predictive Programming), this technology is not yet widely applied to Chinese and Vietnamese. It mainly focuses on English and other popular languages, due to the lack of AI training data for complex languages. But in the future, with technological and data developments, I believe PP will become more popular with these languages.

18:13 Regarding Predictive Programming (PP), this technology is not yet widely applicable to languages other than English. Complex languages like Chinese or Vietnamese are not well supported. Usually, users need to be proficient in English to effectively utilize PP. In terms of flexibility, PP is not yet smart enough to understand every context we speak; it only understands when we follow exactly the pre-programmed command patterns. This is also a weakness that needs to be improved in the future.

19:00 Next, I’ll talk about AR/VR (Augmented Reality/Virtual Reality). This field is currently focusing mainly on industries like e-commerce, real estate, helping users to experience directly without having to be physically present. For example, they can preview a house through a VR application instead of visiting in person. In 2019, the market value of AR/VR was only about $0.44 trillion, predicted to reach $1.73 trillion by 2024, and potentially hit $40 trillion by 2027.

19:46 However, many businesses have tried to apply AR/VR to their websites, but most have withdrawn due to unstable performance issues. From early 2023 to late 2023, AR/VR was widely applied, but by early 2024, many businesses started to withdraw from websites due to poor user experience, especially when users access and encounter lag or slow loading speeds.

20:54 This frustrates users, causing them to quickly leave the website. Moreover, the cost to develop and maintain AR/VR is very high, so only large businesses with surplus budgets can invest in this technology. Small and medium-sized businesses often don’t want to spend too much on integrating AR/VR into their websites.

21:38 The next part is about Modular Data Systems, focusing on using reusable design components to help effectively coordinate between designers and developers. Currently, there are many popular design systems on the market, combining both Figma UI files and UI components supported by libraries.

22:17 The most popular example is the Ant Design System, however, the UI of Ant Design is now a bit outdated. In addition, there are more modern choices like Tailwind UI and Chakra UI. The way designers and developers collaborate is by using the same set of Figma files from the library, the designer will design based on that set, and the developer uses the corresponding components to develop.

23:00 For example, if a designer wants to create a table, they’ll choose the table component in Figma, and the developer will use that exact component to build in code. This ensures consistency between design and implementation, helping to minimize discrepancies between the design and the final product. Currently, many libraries also support responsive design, helping developers avoid having to redo for different devices.

24:09 Our team also has a team called Mochi that’s developing its own Design System. One issue when applying these libraries is that the product may lack uniqueness, the distinctive mark of each application. For example, if 10 applications use Ant Design, their interfaces will look very similar, with no differentiation.

24:56 Therefore, designers and developers need to coordinate very closely. If a designer wants to customize any component in Figma, they need to immediately notify the developer to update the corresponding code. This requires continuous communication between both sides to ensure consistency throughout the development process.

25:41 Regarding AI tools supporting UX/UI, AI tools help us analyze user behavior accurately and quickly. For UI, AI can help create components or styles suitable for different fields. Tools like ChatGPT, Claude AI, and Midjourney are doing very well in supporting UX/UI research and development.

26:32 Currently, for UI, it mostly supports creating images but can’t create vector or pixel formats that we can edit. However, some tools are trying to improve this. For example, when using Midjourney, we can generate images and import them into Figma, and now it has the ability to copy them into layouts with Figma’s auto layout, making editing easier.

27:24 But in general, AI’s output for UI is still mainly in image format, rarely able to generate vectors or components that can be used directly in design. This is a weakness and limitation of current AI technology in supporting UI design.

28:20 For UX, I notice AI is supporting much better. For example, when we receive a brief requirement from the client, we can input it into ChatGPT to get a suggestion about information architecture or suitable UX solutions. In fact, sometimes I don’t fully grasp all the requirements, but when I input them into ChatGPT, it provides very useful ideas that meet the client’s needs.

28:55 However, with UI, even if we use AI, it’s still difficult to create designs exactly as we want. Even if it can create them, the output is usually just in image format, not files that can be used directly like Figma or Sketch. Therefore, in the UI area, current AI still has many limitations and needs further improvement.

29:20 Do you agree with me? AI seems to be doing better with UX than UI.

29:45 Exactly. Especially when we work with information architecture requirements, AI often produces quite accurate and appropriate results, saving designers a lot of time. But with UI, human intervention is still needed to ensure aesthetics and accuracy.

30:30 If there are no other questions, I’d like to conclude my presentation. Thank you all for listening, and I hope you can apply some points from this presentation to your daily work.

31:00 Thank you, Nam Bui, for the very detailed and comprehensive presentation on Product Design Commentary 2024. The insights about AI supporting UX/UI are really useful and provide the team with new perspectives on applying AI in design. We hope to hear more interesting presentations from you in future OGIF sessions.

32:51 Last week, I saw two articles like this. Actually, there’s another one related to GUI, but I’ll talk about that later. First is the article about “register allocation” of the Golang compiler. This article is a bit complex, so I can’t include all the content here. Mainly, Go implements register allocation through the SSA (Static Single Assignment) step.

You can read more in the link I’ve put here. But in general, this article focuses on the process of optimizing compilation using SSA to manage register allocation.

37:43 To summarize, this process helps improve the compile time of Golang programs. Specifically, it focuses on optimizing two main steps: register allocation and stack allocation, thereby helping to reduce compile time by about 20%, especially useful for Go applications with complex logic or large applications.

This is a very detailed and thorough article, written by one of the experts in the Rust community. This article is very useful for those interested in the compiler process or wanting to learn more about Go’s performance.

38:17 Moving on to the second part related to AI. It’s a new solution called BBQV, a Vector Index developed by a group called Dexa in the US. BBQV focuses on its main strength of “scalable vector search.” The interesting point is that BBQV is neither the fastest solution nor the most accurate, but it has the ability to build indexes extremely quickly compared to other solutions. In a moment, I’ll show you the chart where the BBQV authors compared it with other ANN (Approximate Nearest Neighbor) solutions.

39:13 The outstanding feature of BBQV is its ability to build indexes very quickly, although its query time is only average compared to other solutions. To compare more specifically, on the chart below, BBQV is in the middle when it comes to query time but is among the fastest in build time. This is a bright spot when deploying BBQV in large-scale AI systems, as index building time is very important.

39:24 Additionally, there’s another article related to GUI in Go. Although GUI in Go is not a strength, I still found some interesting GUI solutions and want to introduce them to everyone. Recently, the Go community has been trying to build GUI libraries that can compete with other solutions like Qt or Electron. However, most of these GUI solutions are still not really complete and lack features compared to popular libraries from other programming languages.

39:59 That’s what the Dex team is using, Dex AI is using this, and it’s also been open-sourced.

This chart shows that BBQV’s query time is not the fastest but very stable. However, in terms of build time, BBQV is one of the fastest solutions. Because it’s kind of its “selling point”, to build an index, using this one is the fastest.

As for another article about GUI, we didn’t include it here because generally, we see that Go GUI is somewhat limited. But we found one that’s considered the best in Go. Its accessibility, its gallery is also beautiful, and overall it’s quite mature. Recently, there’s a new language called R, it’s also written in Go, and it also has an extension integrated with this GUI. Overall it looks like this, for example it looks like this.

40:24 In addition, there’s another topic related to GUI in Go. Although GUI is not a strong point in Go, I still found some interesting GUI solutions and want to introduce them to everyone. In recent times, the Go community has been trying to build GUI libraries that can compete with other solutions like Qt or Electron. However, most of these GUI solutions are still not fully developed and lack features compared to popular libraries from other programming languages.

40:44 Currently, our DEX AI team is using this. It’s open-source, so it’s very convenient to integrate into our system. As for the GUI aspect, I’ve also researched more about libraries for Go. To be honest, Go’s GUI is still quite limited (constrained), but I found a library called Fyne. This is one of the best GUI libraries currently available for Go. Its interface (UI gallery) is also very beautiful and mature, meaning it’s quite well-developed compared to other libraries.

41:45 And recently, a new language called Gio has emerged, also written in Go. It provides some extensions that can be directly integrated with Fyne, creating GUI interfaces as you see here. It seems this trend is developing quite rapidly in the Go community. For this part, I’ll stop here to move on to Phat’s section. I don’t know if Phat wants to share more?

42:46 Um, from my observation, I’ve noticed that the name BBQ has become popular in the field of vector databases (vector DB). Many new projects use BBQ because the name sounds good, but in reality, vector databases like this have gone beyond the simple concept of dimensionality. Choosing which vector DB is suitable will depend a lot on factors like performance and features. Although BBQ sounds fun, in terms of search speed and recall efficiency, it may not be the fastest, but it still achieves very good performance. The fastest here might be ‘HNSW,’ however, BBQ is still a stable choice.

44:03 As for case studies of large companies using Golang, we have gathered some very interesting information. As mentioned, Google - of course, can’t be missed, because they are the creators of Golang. Other big businesses like Meta, Microsoft, and companies in the financial sector like American Express, Monzo, and Paypal have all implemented Go in their systems. In the streaming sector, Twitch is also a big name using Go for their backend. In the gaming industry, Riot Games has also used Go in some of their services. I will continue to update more detailed information about these case studies.

45:51 There, on Tom’s side, the script part is probably basic, right? Yes, it’s quite basic. If there’s time, we can quickly demo it. Okay, so let’s talk about the YouTube transcript. Actually, before that, our team already had an engine to process this part, but it seemed to be limited. It was limited by a duration of 50 minutes or something, so I rewrote a backend to process it using the Whisper API.

46:42 This Whisper API has a free package for audio transcription. It allows us to transcribe about 600 minutes of audio for free per day, but each file can only be up to 2 hours long. We utilize this Whisper API to convert YouTube video content into text format. The basic process is when we input a YouTube link, the backend system automatically downloads the video file, then converts that file to MP3 format, and then compresses it to fit the file size limit of the Whisper API (25MB per file).

The compression and processing time will depend on the length of the original video. After the processing is complete, the system will send each compressed audio segment to the Whisper API to perform the conversion from audio to text. The results returned from the API will include detailed information for each segment, from start time to end time, and the corresponding text. These segments will then be combined and further processed through GPT-4 to refine and adjust the wording, ensuring the output text closely matches the original language and is more accurate.

48:21 Based on such segments, we combine them and use GPT-4 to tweak little details there. Usually, English doesn’t have any errors. But for Vietnamese, it has issues with some parts, for example, in the North, pronouncing the falling tone as rising tone, pronouncing ‘r’ as ’d’. When we get such output, when reading, it will be incorrect. Therefore, we feed that content to GPT-4 for it to correct, and as a result, we’ll have a complete text that matches the original YouTube video.

After getting such content, we send it up to D. It receives this D, this app, it uses a tool to call the backend from earlier and it receives JSON like this. From there, it pops up, and continues to use a library to render the transcript like this. It returns a content section like this, including the full content.

49:55 That’s what we’ve been able to do. If we use the subscription plan of Whisper API, we won’t be limited by only being able to convert about two hours of audio every hour. However, there’s another limitation when deploying to a server via Heroku or some other servers, because this audio processing is quite time-consuming, so sometimes there are timeout issues. But if we run directly on local, everything will be much smoother.

That’s why we use this tool on the OIP project side. There’s a part for editing transcripts that you guys review, I’m not sure if it’s using this one or something else?

Currently, we’re adjusting the config to use this tool more appropriately. Tom’s part seems to be broken or something. Because our current OGIF part is very long, also over an hour, so to process that entire segment, we may need to improve the performance of this tool to make it work better.

50:40 Which free API are we currently using? There are three workflows, two are free APIs, one is mine, mine has been blocked by YouTube. It seems unstable, right? Yeah, it’s stable sometimes and not at other times, both have been blocked. There’s one API left, Note GPT, which My’s side is using, but for long transcripts, it’s also likely to crash.

52:18 Ok, that’s right, sometimes it’s stable, sometimes it’s not. Actually, if the video is under 10 minutes, it always works, but once it gets a bit longer, it depends. The issue is with the resources on the free server; it’s uncertain whether it can reset or not. But if it’s long, you can just bring the source back and run it locally.

53:35 You all can see on the AI comment section on Discord, we’ve already got some scripts from Twitter. So, the process we’re working on is creating an API from the Python model script. After that, we deploy it directly; this model has a mechanism that allows us to deploy it directly as an API.

54:53 We then use this API to script information from our side. It acts like a script running like this, a function on a container that runs a browser, looks into the viewport, and takes the selectors and text information from that container of ours. Then, we expose it as a POST request.

This POST request only needs a URL. For example, if we want to fetch data from Twitter, or take it from sc.com, for instance.

55:39 If we want to script this data, we can test it directly on the Postman request, but with Dify, we can test it directly on here. And the best part is, after testing, we can convert the workflow from Dify into a function call, which can be applied on an agent or something else specific for Dify.

56:38 This is integrated with Discord AI, so if anyone wants to summarize from Twitter, they just need to post the link, and it will automatically summarize it. It seems to be lagging now, though. Let’s try running it again. It seems to be lagging, but just imagine that it’s fetching from Twitter. Later, we’ll use this method to script from Facebook, and Hoang is using this method to upload an API through a model to script and pull data from Discord messages.

57:53 This is when we consolidate it; Dify can auto-convert it into a tool. Normally, you can publish it as a standalone app and interact with it. What’s better is that you create a workflow tool, and it will arrange it like a function call on the OpenAI side.

58:37 This is the Discord AI bot that everyone is using for AI comments within our team Discord. Currently, it has several tools we’ve made ourselves, like the Twitter script that’s integrated here. Another is for obtaining YouTube transcriptions from a service that I made, and another is for querying memos, which is tooling I created to pull data from our team’s Memo. The rest are tools available on Diffy. When you want to add a tool, it will be listed in the workflow list. After creating a workflow, deploying, and configuring it, it will all be displayed here.

59:17 Let’s try, “What are the latest notes added to the doors?” It will take the Prompt Token from the tool’s description and the system prompt to determine the most appropriate tool to use. So, it fetches data based on two factors, right? The first is your system prompt, and the second is the tool’s description. Based on the initial query input, it detects which tool should be used for the next process, right?

01:00:46 Quick demo of the tool to support memo creation, specifically the current transcript. Right now, it functions as a Discord bot like this. I’m hosting it on my machine because servers cost money. It has two main commands. One is the list command, and its functionality is simple—it has an account that collects newsletters. This means the data source consists of newsletter emails. I use an email to subscribe to about 100 different sources, but everything comes to this one. It’s simple: any new email that hasn’t been read yet, I scrape it.

For the backend, I built it using Python. This app is 90% standard core code.

01:02:55 The functionality is straightforward. When I scrape, it will create a table of articles like this. It creates a table with the title and description in detail. I use BeautifulSoup to extract these, which I’ll show later. But in terms of functionality, it’s pretty simple.

For example, if I want to retrieve seven articles from a specific category, all within seven days, I fetch all articles that belong to all categories within seven days. Then it returns in this kind of presentation list.

This is the first feature—listing the articles I’ve collected from the email inbox. The second command is “lend draft to memo.” When running it, it loads up like this.

01:03:33 This is the feature that lists the articles collected from the email inbox. Another command is “lend draft to memo,” which, when executed, loads like this. For instance, if you’ve read my GitHub repositories, we have a few main stacks like React or NestJS. It structures it similarly to a Memo article.

01:04:14 It provides three articles with the highest scores. Then there are five relevant articles with lower scores. The scoring is based on relevancy. When feeding it into ChatGPT mini, I ask it to score as well. The prompt is located here. This is the prompt for ChatGPT mini.

I scrape all the emails, convert them to plain text, keep the link, then feed them to ChatGPT mini with a list of criteria like this.

01:05:01 It reads, extracts, and assigns a relevancy score, extracting articles. The format resembles a JSON array with the title, description, link, criteria list, and the relevancy score. After scraping everything, I store it in the database like this. A cron job is set to run every day, fetching only unread emails.

01:05:56 The second feature is using ChatGPT Mini 3.5 Pro, which is currently free. ChatGPT Mini Pro allows free API access tokens, giving 1 million tokens daily for free. So far, it works fine. Some issues with the bot are that I haven’t filtered out ads yet, and there’s quite a bit of spam in newsletters.

01:06:40 One of the current issues with this bot is that I haven’t filtered out ads. The second issue is spam in newsletters; sometimes, it includes links like GitHub descriptions, merged PRs, etc. Some newsletters contain a lot of spam. I’m still optimizing the prompt to make it more relevant for our team’s use case. Functionality-wise, it’s okay for now; I just need to optimize the prompt.

01:07:16 Optimizing the prompt is the main focus, and I need to optimize the relevancy score. Because it’s currently free, it lacks the step to scrape content from each article and read it before scoring relevancy. Currently, the relevancy score is based only on the description provided by the newsletter, which is still inadequate. I’ll look for a model that’s free or runs locally to handle scraping and reading content. Currently, ChatGPT Mini 3.5 Pro can handle scraping about 15 emails before it reaches its quota.

01:08:02 Every day, I scrape only a few. As for future enhancements, I’ll try to find a free local model to handle scraping and parsing content. Initially, I used vectors and similarity to match categories, but the scoring setup was somehow wrong. The embeddings generated by OpenAI weren’t matching any articles correctly, so I eventually let ChatGPT handle it.

01:08:58 Then the team can look at links from different stacks, consider references, or run their own tests. If hosting is needed, contact Quang. We have our bots running on our own servers.

01:09:48 If needed, you can expose APIs to Discord bots. I created one that can expose APIs, and you can host any function you need to run. Dify uses models or Quang hosts setup service; you choose what to host yourself. Dify’s model is quite okay and free to use. It doesn’t allow hosting data directly, so right now, we’re scraping and saving into a database. You might need to set up the system yourself.

01:10:39 It’s just an extra step for exposing APIs for accessing data. You decide on storage or indexing. Okay, now they’re asking, can it handle in-memory? I’m doing batch processing immediately when scraping, saving for requery purposes later. When someone queries, the response is real-time; you won’t need to run multiple times.

01:11:44 Cron jobs handle data collection; for querying, in-memory or local runtime inference can be added to enable querying through natural language rather than with parameters. I believe content collection should be processed and stored in a database; otherwise, scraping hundreds of articles every time would be costly.

01:12:44 You can’t avoid setting this up. As this is an engineering solution, storage is needed for data and backpressure. One option is adding more funding for it to run as required. Thanks. Let’s check later; Wednesday’s demo sessions have quite a lot already—maybe four to five more presentations. We might have to schedule for Wednesday.

01:13:55 If no one else wants to handle the remaining Copilot tasks, we’ll take them all. Eat up everyone’s money! Out of curiosity, the recent expenses, are they still using my API key, Tô? Yes, I believe everyone hasn’t reached 1 million tokens yet.

01:15:08 Anyway, see you all next Wednesday. Have a great weekend.