OGIF Office Hours #28 - Golang sync.Map, Generative AI UX design patterns, Yelp's AI use cases, Design patterns in LLM application, and Dify github analyzer

Topic Highlights

• Go Weekly #16: Phat discussed concurrent data structures in Go, focusing on sync.Map. He explored its structure, use cases, and performance trade-offs in high-read, low-write scenarios. He also touched on garbage collection issues reported by the Go team.
• Generative AI UX Design Patterns: Nam presented on UX design patterns for AI integration, covering System Scope Relationship, Spatial Relationship, and Functional Relationship. He explained how AI can be incorporated at various levels in digital products and discussed different ways to present AI features in user interfaces.
• Yelp Usecase AI: Dat presented real-world AI use cases from Yelp, explaining how AI is used for recommendation systems, text editing, and image summarization. He explored AI applications in generating datasets, spam detection, and auto-generating short video reviews for restaurants.
• LLM Pattern: Hoang introduced design patterns for integrating LLMs (Large Language Models) into applications. Key patterns included in-context learning, data preprocessing, and multi-agent collaboration, highlighting their practical use in AI-powered systems.
• Dify Git Analyze: Cat demonstrated a Git repository analysis tool built using Dify. The tool scrapes content from repositories and supports diagram generation for code structure analysis, with a focus on optimizing the knowledge retrieval process in large datasets

Vietnamese Transcript

0:28 Chủ đề hôm nay vẫn có Go Weekly, và Nam đang thử nghiệm phần commentary về thiết kế hàng tuần. Chúng ta sẽ theo dõi trong vài tuần tới xem nội dung như thế nào.

11:19 Nam sẽ trình bày tiếp cho anh em, và sau đó sẽ có một vài bài của Hoàng, Cát, Đạt. Chúng ta đang nghiên cứu về các trường hợp sử dụng mà các công ty khác đang áp dụng, hoặc các công cụ mà dev đang sử dụng, và có thể sẽ mở một bài chia sẻ trong tuần này hoặc tuần sau. Bài hôm nay sẽ xoay quanh việc tạo một nút thiết kế UX. Trước đây, có rất nhiều câu hỏi về phạm vi mà AI đang áp dụng và vai trò của nó sẽ như thế nào – liệu nó chỉ đóng góp như một thành phần nhỏ riêng lẻ hay là cả một ứng dụng trong các sản phẩm số. Hôm nay, em sẽ giải đáp thắc mắc đó, tức là AI đang đóng vai trò như thế nào và cách thức hoạt động của nó ra sao.

12:11 Đầu tiên, em sẽ nói về “System Scope Relationship.” Hình ảnh này sẽ mô tả AI được tích hợp vào các hệ thống ở nhiều cấp độ khác nhau, từ một thành phần nhỏ lẻ đến một hệ sinh thái toàn diện hơn. AI có thể chỉ là một phần nhỏ trong một thành phần hoặc có thể phát triển thành các tính năng lớn hơn, giúp tự động hóa nhiều chức năng. Điều này sẽ giúp người dùng trải nghiệm ứng dụng dễ dàng hơn. AI có thể đóng vai trò trong bất kỳ phần nào của sản phẩm số – từ thành phần, luồng xử lý, tính năng cho đến toàn bộ ứng dụng, hoặc thậm chí là một nền tảng hoặc hệ sinh thái.

12:53 Ví dụ, trong một ứng dụng, AI có thể đóng vai trò một tính năng nhỏ, giúp người dùng thao tác nhanh hơn thay vì phải làm thủ công. Hoặc AI có thể là toàn bộ một ứng dụng như ChatGPT, nơi toàn bộ ứng dụng được xây dựng trên nền tảng AI, phục vụ cho một mục đích nhất định. Hoặc AI có thể là một nền tảng như Rewind AI, với nhiều tính năng hỗ trợ AI cho nhiều công việc khác nhau trong cùng một ứng dụng. Đây là phạm vi của AI trong các sản phẩm hiện nay.

13:39 Tiếp theo, về “Spatial Relationship,” phần này giúp chúng ta hiểu về cách tính năng AI được bố trí và sắp xếp trong giao diện người dùng (UI). Có nhiều cách để tích hợp AI vào thiết kế, và quan trọng là làm sao để bố trí chúng sao cho hợp lý, tối ưu trải nghiệm người dùng mà không gây rối mắt hay phức tạp giao diện. Spatial Relationship ảnh hưởng trực tiếp đến trải nghiệm người dùng. Ví dụ, AI có thể hoạt động độc lập hoặc song song với các tính năng khác, nhưng vẫn giữ không gian riêng của mình. Khi hiểu được các mối quan hệ này, chúng ta có thể chọn cách sử dụng và sắp xếp tính năng AI một cách tối ưu, không gây phân tâm cho người dùng.

15:11 Có sáu cách để trình bày tính năng AI, bao gồm:

1. Separate: AI hoạt động độc lập.
2. Alongside: AI được đặt bên cạnh các tính năng khác.
3. Layer: AI hoạt động dưới dạng lớp phủ.
4. Integrated Parent: AI đóng vai trò chính trong điều hướng hoặc quản lý nội dung chính.
5. Integrated Child: AI đóng vai trò nhỏ hơn, bổ trợ cho tính năng chính.
6. Point: AI chỉ xuất hiện như một biểu tượng nhỏ, giúp người dùng hiểu thêm về cách nó hoạt động.

16:41 Tiếp theo là “Functional Relationship,” phần này mô tả các mối quan hệ chức năng giữa AI và các tính năng khác trong hệ thống. AI có thể tồn tại độc lập nhưng vẫn adapt (thích nghi) với các nội dung và tính năng của hệ thống ở mức cao hơn. AI có thể tích hợp với các tính năng hiện có để cải thiện hiệu suất, thay vì người dùng phải thao tác thủ công. Khi hiểu rõ cách hoạt động chức năng của AI, chúng ta sẽ xác định rõ vai trò của nó trong ứng dụng và thiết kế để các hành động chức năng của nó không bị xung đột, cũng như không làm gián đoạn luồng sử dụng của người dùng.

17:28 Có sáu cách để mô tả mối quan hệ chức năng của AI:

1. Separate: AI hoạt động riêng biệt.
2. Aware Of: AI tách biệt nhưng có khả năng nhận biết các thay đổi trong tính năng chính.
3. Acting Up: AI tương tác qua lại giữa các tính năng.
4. Feature Incorporate: AI được tích hợp như một phần của một tính năng hiện có.
5. Usage: AI được sử dụng theo cách mà nó tương tác với các phần khác trong ứng dụng.
6. Usage Conventionally: AI tương tác hai chiều với các tính năng khác một cách trực tiếp.

18:14 Nó sẽ không ảnh hưởng trực tiếp đến tính năng chính, nhưng nó sẽ có tác động qua lại với AI và từ đó giúp cải thiện tính năng chính. Đây là một ví dụ cụ thể hơn về cách sử dụng của nó, chẳng hạn như trong code này có thể generate một panel bên phải.

Tiếp theo là Acting Up, nghĩa là hai bên sẽ có tác động qua lại, có thể trao đổi dữ liệu qua lại với nhau. Ví dụ, tính năng A có thể hiểu được dữ liệu từ tính năng B và ngược lại. Các dữ liệu này sẽ được trao đổi qua lại liên tục để cải thiện sự tương tác.

Tiếp theo là Feature Incorporate, nghĩa là AI được tích hợp trực tiếp vào các tính năng hiện có của ứng dụng. Cuối cùng là Usage Conventionally, nghĩa là AI sẽ tương tác theo cách thông thường với các tính năng khác, giống như cách các ứng dụng truyền thống hoạt động.

Ví dụ như khi bạn dùng một ứng dụng và có nhiều tính năng khác nhau, AI sẽ đóng vai trò trong các phần như feature, nhưng không phải lúc nào cũng là phần chính, mà sẽ đóng vai trò bổ trợ.

19:06 Ví dụ khác là ứng dụng Quora hay các ứng dụng khác, AI sẽ có nhiều tính năng nhỏ được tích hợp vào, như kiểu gợi ý trả lời câu hỏi, giúp người dùng thực hiện các tác vụ dễ dàng hơn. Vậy là nãy giờ em đã đi qua ba phần chính:

1. System Scope: Giới thiệu cách AI tích hợp vào sản phẩm.
2. Spatial Relationship: Giới thiệu cách sắp xếp AI trong giao diện người dùng.
3. Functional Relationship: Giới thiệu các mối quan hệ chức năng giữa AI và các tính năng khác.

Những phần này giúp tối ưu hóa sản phẩm, cải thiện trải nghiệm người dùng và nâng cao hiệu quả cho ứng dụng AI.

19:57 Điều này rất quan trọng bởi vì nếu mình hiểu rõ cách áp dụng AI, tính năng mình làm sẽ mang lại nhiều giá trị hơn cho người dùng. Ví dụ mà em quên chưa nhắc đến là phần “separate.” Em đã đưa ra một số ví dụ, nhưng để quay lại một chút về “separate” – tính năng AI hoạt động độc lập. Mình có thể xem xét trường hợp Microsoft có một cái slider để generate hình ảnh song song với tính năng khác. Hoặc với một ứng dụng như Shopee, AI sẽ đóng vai trò hỗ trợ bên cạnh tính năng chính của ứng dụng.

20:53 Đó là những ví dụ minh họa cho việc sắp xếp và bố trí AI trong giao diện và sản phẩm. Anh Thành có thấy phần này như thế nào? Em thấy nó giống với các patterns thông thường trong thiết kế.

22:01 Anh Thành: Đúng rồi, những cái này là các mẫu patterns mình hay dùng trong việc thiết kế ứng dụng AI, hoặc khi tích hợp AI vào một ứng dụng hoặc sản phẩm riêng biệt. Về cơ bản, nó là những cấu trúc quen thuộc để mình hiểu rõ hơn về cách áp dụng AI. Em có thể phân loại, chia nhỏ chúng ra thành những tính năng nhỏ hơn. Phần này rất rõ ràng.

23:31 Cảm ơn Nam. Ok, tiếp theo là bài của Hoàng và Đạt nhé.

Hôm nay, em sẽ giới thiệu một bài gọi là “AI Button trong các ứng dụng LLM.” Trước khi vào bài, em sẽ nói qua về nội dung và agenda. Đầu tiên là chúng ta sẽ tìm hiểu về các design patterns liên quan đến AI Button. Những cái pattern này được áp dụng trong nhiều ứng dụng khác nhau. Em sẽ lấy ra những cái phổ biến và dễ hiểu nhất để giới thiệu cho mọi người.

24:35 Bài này sẽ xoay quanh việc sử dụng ứng dụng AI trong các sản phẩm số. Ứng dụng này tận dụng sức mạnh của các mô hình AI để giải quyết các bài toán cụ thể hoặc hỗ trợ người dùng trong các tác vụ. Khi sử dụng LLM, nhiều người có thể gặp vấn đề là mô hình không đưa ra đúng kết quả như mong đợi. Điều này là do bản chất của các mô hình này chỉ dựa trên khả năng phản hồi dựa trên chuỗi dữ liệu. Có nhiều cách để giải quyết vấn đề này. Một trong những cách tốn kém nhất là phải điều chỉnh lại toàn bộ mô hình từ đầu. Điều này có thể mất nhiều thời gian và nguồn lực.

25:15 Mình có một cách gọi là in-context learning, có nghĩa là AI có thể học trực tiếp ngay trong ngữ cảnh hiện tại khi bạn đang sử dụng nó. Đây là một kỹ thuật như là few-shot learning hoặc zero-shot learning, giúp AI tự học mà không cần phải được huấn luyện lại từ đầu. Ví dụ, bạn chỉ cần cho AI một vài ví dụ nhỏ trong ngữ cảnh và nó sẽ tự điều chỉnh cách hoạt động của mình dựa trên những gì được cung cấp. Thay vì phải retrain toàn bộ mô hình, cách này giúp tiết kiệm thời gian và tài nguyên rất nhiều, và nó vẫn đảm bảo AI có thể học từ ngữ cảnh cụ thể mà bạn cung cấp.

25:52 Với trường hợp này, in-context learning được sử dụng rất nhiều trong prompt engineering. Mọi người sẽ cung cấp các ví dụ có sẵn trực tiếp vào prompt và mô hình sẽ học từ những ví dụ đó để tạo ra các kết quả tiếp theo. Đó là ý tưởng chính của in-context learning. Về cơ bản, thiết kế sẽ hoạt động như thế này: bạn có một truy vấn, sau đó bạn xây dựng prompt với các ví dụ cần thiết và dữ liệu few-shot learning, rồi bạn đưa nó qua mô hình, mô hình sẽ trả về kết quả dựa trên các ví dụ đó. Tuy nhiên, nó không chỉ dừng lại ở các ví dụ, mà còn bao gồm rất nhiều yếu tố khác.

26:37 Nhìn rộng hơn, in-context learning liên quan đến việc cung cấp ngữ cảnh vào prompt bằng cách truyền vào các thông tin mà mô hình không có sẵn. Vì đây là một mô hình được huấn luyện trước, kiến thức của nó bị giới hạn, vì vậy bạn truyền thêm thông tin vào ngữ cảnh và prompt để mô hình học trong quá trình tạo ra kết quả. Ví dụ, trong chẩn đoán hình ảnh y khoa, mô hình có thể không có đủ kiến thức chuyên môn. Vì vậy, bạn cung cấp kiến thức đó vào ngữ cảnh và prompt để mô hình học trong quá trình tạo ra kết quả. Đó là cốt lõi của in-context learning.

Tiếp theo là nút thiết kế thứ hai quan trọng, được gọi là data preprocessing/ editing.

27:54 Phần này miêu tả quy trình chuẩn bị dữ liệu cho mô hình ngôn ngữ (LM). Như mọi người biết, LM hoạt động dựa trên các cơ sở dữ liệu vector, sử dụng so sánh vector để tìm các điểm dữ liệu tương tự. Quy trình này thường liên quan đến việc xử lý dữ liệu đa phương tiện và các loại thông tin khác nhau. Để đảm bảo đầu ra là tối ưu, việc áp dụng các bước xử lý trước dữ liệu là rất quan trọng. Ví dụ, bạn có thể xử lý trước văn bản bằng cách lọc ra các chi tiết không cần thiết để làm ngắn lại, hoặc với hình ảnh và âm thanh, bạn có thể loại bỏ nhiễu hoặc nén dữ liệu để giảm kích thước trước khi đưa qua mô hình ngôn ngữ.

29:19 Việc xử lý trước hoặc chỉnh sửa dữ liệu giúp mô hình hoạt động hiệu quả hơn. Có nhiều cách để xử lý trước, tuỳ thuộc vào loại dữ liệu hoặc ngữ cảnh. Bạn sẽ thực hiện điều này dựa trên các yêu cầu cụ thể. Nút thiết kế tiếp theo mà tôi muốn đề cập đến là một thiết kế thường được sử dụng, mặc dù có nhiều tên gọi khác nhau. Tôi gọi nó là example agent. Đây là một thiết kế thường thấy khi bạn muốn truy vấn của mình đi qua nhiều ngữ cảnh khác nhau. Ví dụ, nếu bạn có một ứng dụng đánh giá bài viết, bạn có thể cho bài viết đó đi qua một đường ống nơi mỗi agent đánh giá bài viết từ một góc độ khác nhau.

30:11 Một agent có thể đánh giá bài viết từ góc nhìn của một nhà văn, một agent khác có thể từ một góc nhìn khác. Sau khi đi qua tất cả các agent này, sẽ có một lớp tổng hợp cuối cùng để kết hợp hoặc xử lý các kết quả đó, và cuối cùng cung cấp cho người dùng một kết quả tổng hợp. Thiết kế này thường thấy trong các hệ thống đánh giá, nơi bạn đánh giá kết quả từ các mô hình khác nhau và chọn ra kết quả tốt nhất dựa trên các điều kiện đã được thiết lập trước.

30:55 Nút thiết kế tiếp theo, gọi là agentic button. Vậy agentic có nghĩa là gì? Trong ngữ cảnh của các mô hình ngôn ngữ (LMs), agentic LMs ám chỉ việc nâng cấp khả năng của mô hình. Vì mô hình chỉ biết những gì nằm trong dữ liệu huấn luyện của nó, chúng ta sẽ nâng cấp nó để tăng cường sức mạnh của nó và giảm thiểu sự can thiệp của con người. Thiết kế này giúp hệ thống tự động hoá nhiều hơn, cho phép nó hoạt động với ít sự can thiệp của con người hơn.

32:24 Thiết kế này có một số thành phần chính giúp bạn đạt được mức độ tự động hóa này. Có bốn thành phần chính: reflection, planning, execution, và multi-collaboration. Mỗi thành phần này đều giúp hệ thống của bạn trở nên tự động hóa hơn. Đầu tiên, chúng ta hãy nói về reflection. Reflection liên quan đến việc đánh giá kết quả ban đầu của mô hình dựa trên một tiêu chí hoặc một chỉ số cụ thể để xác định xem kết quả đó đã được tối ưu hóa chưa. Nếu chưa, hệ thống sẽ điều chỉnh và lặp lại quá trình này, tiếp tục tạo ra kết quả cho đến khi đạt được kết quả tối ưu.

33:06 Reflection giúp giảm thiểu sự can thiệp của con người vì thay vì tạo ra một kết quả ban đầu không đáp ứng mong đợi của bạn, hệ thống sẽ tinh chỉnh dựa trên các tiêu chí đã được thiết lập trước, cuối cùng đưa ra một kết quả chính xác hơn mà không cần điều chỉnh thủ công.

Reflection button này có nghĩa là nó sẽ đánh giá cái output ban đầu của một con AI, rồi nó sẽ đánh giá dựa theo một tiêu chuẩn nào đó hoặc là một cái chỉ số nào đó để xem là cái kết quả này đã tối ưu chưa. Nếu chưa tối ưu nó sẽ thêm thắt một chút và nó sẽ chạy vòng lại con AI đó để nó tạo ra kết quả khác cho tới khi nào đạt được kết quả tối ưu nó sẽ trả cho mình cái kết quả cuối cùng. cái này nó sẽ giúp giảm thiểu việc con người phải can thiệp vào quá trình làm việc, bởi vì nếu mà output đầu tiên không đúng ý mình, mình không cần phải tự chỉnh lại nữa mà nó sẽ tự tối ưu.

33:42 Button thứ hai là tool. Tool có thể là external, nó có thể là external API hoặc là những cái function mà mọi người code. Những cái tool này được sử dụng để cho model có thể lấy được những knowledge từ thế giới bên ngoài, những real-time knowledge, những external resource mà nó không được train sẵn. Như OpenAI hay là Claude đều có hỗ trợ. Khi đó, con model có thể tự biết khi nào cần gọi tool dựa vào cái description mà mọi người viết trên cái tool đó. Model sẽ tự biết cách lấy và extract thông tin từ tool, rồi trả về cho con LM để nó generate ra output.

34:30 Kế tiếp là planning. Planning button có nghĩa là mọi người cho con LM có khả năng lập kế hoạch, để tránh việc phải prompt đi prompt lại nhiều lần. Ví dụ, nếu có một task phức tạp, mình sẽ có một cái prompt lớn cho nó plan ra tất cả các step mà nó cần làm theo kiểu step by step. Cách này sẽ cho nó làm những việc nhỏ trước, rồi cuối cùng kết hợp lại thành một cái task lớn. Cái kiểu planning design này có nhiều biến thể, và đây là biến thể đơn giản nhất: lập kế hoạch xong rồi làm từng bước một.

35:10 Cuối cùng là multi-collaboration. Cái này em đã present cách đây một tháng rồi. Nói chung, nó giống như kiểu là AI giỏi việc nào làm việc đó. Mình có một cái context đúng không? mình chia nó ra, rồi đưa qua từng người. Người nào giỏi việc đó nó sẽ giải quyết việc đó, xong rồi pass qua con agent tiếp theo. Cứ thế, cuối cùng nó sẽ complete được cái requirement. Cái design này sử dụng tính chất divide and conquer khá nhiều. Chia việc lớn thành việc nhỏ, rồi đưa việc nhỏ cho người giỏi chuyên môn. Đây là một cái design button mà em thấy khá nhiều nơi bên ngoài sử dụng.

36:24 Đó là những design button mà em thấy nhiều nơi sử dụng và hiểu nhất. Em đã trình bày xong. Mọi người có câu hỏi gì không?

37:10 Hoàng, em nói lại cái phần planning, để confirm lại cái comment của anh Bảo. Nó giống như là kiểu đọc cái prompt đúng không? Nó sẽ hiểu cái prompt của anh trước, xong rồi nó sẽ chia cái prompt ra thành những cái nhỏ hơn, xong rồi nó sẽ có những con worker, có thể là những IDE worker hoặc là những cái prompt nhỏ để nó hoàn thành task đó. Đúng không?

37:40 Đúng rồi, anh có thể hiểu như vậy. Mình có thể chia prompt ra, ví dụ như là một task phức tạp, nó sẽ chia ra nhiều cái plan nhỏ. Những cái plan nhỏ này sẽ làm step by step. Ví dụ nó làm plan 1 trước, rồi làm plan 2, rồi làm plan 3. Sau khi hoàn thành tất cả các plan, nó sẽ tổng hợp lại ở một cái chỗ nào đó, hoặc là một cái component cuối cùng để nó ra được câu trả lời cuối cùng.

38:06 Ý là nó giống như cái con Zero mà hôm trước anh Tom present ấy. Con worker sẽ có thể làm một số task như đọc file, xóa file, sửa file, hay là talk với Internet, gửi email các thể loại. basically, agent các thứ như vậy.

38:52 Đúng rồi, bản chất của nó là thay vì làm một cục rất lớn để giải quyết hết cái task đó, mình phải đi prompt đi prompt lại nhiều lần để nó cho ra kết quả. Mình có một cái prompt trước, để chia nhỏ thành các task nhỏ, rồi sau đó có một cái pipeline để nó đi qua từng con worker, làm những việc nhỏ nhỏ cho mình.

39:23 Ok, kéo lên slide 14 đi Hoàng, slide 14. Anh cũng thấy là kiểu con này giống giống con Mule Automation mà Tom setup đúng không? Con Mule button mà Tom setup ấy. Em đã code xong rồi nhưng nhìn cái design này với cả cái button giống hệ nhau này.

39:46 Ừ, cái này là thằng Tpm nó chạy loop rồi, nhìn ra giống giống một tí. Nó giống planning mà anh Tom vừa nói, là nó break task ra từng phần, rồi xử lý từng phần một. Nó có iteration trong đó, giống như là nó có một list các step mà em đã mô tả ở trên. Back lại cái của em, chính là chỗ mà agent đang thấy. Cái của anh thấy nó giống planning hơn, là nó chia plan ra trước, rồi làm step by step từng plan một, đi qua mỗi vòng làm từng cái một. Còn cái này nó giống như là làm song song với nhau, nó parallel với nhau, để ra output xong rồi đánh giá lại output đó, rồi đưa ra kết quả cuối cùng. Chắc anh nhầm cái work rồi, đã correct lại.

42:28 Đúng rồi, thử đi. Nó là kiểu như vậy đó, nó chia ra thành nhiều việc khác nhau. Nó giống như là classify, nó chạy qua từng cái. Cái này giống multi-collaboration hơn, vì nó giống như question classifier, chỉ chạy một trong mấy cái này thôi. Mỗi agent làm việc đúng chuyên môn của nó, rồi combine lại.

43:33 Nhưng mà anh thấy mấy phần như reason với input analysis có đúng không? Của Tom, phần expert ấy. Riêng vụ pick domain ấy, nó có classifier ở đó, nhưng mà mấy phần reason với input analyzer là những agent khác nhau. Bên group đó là expert thôi, mình consider nó như là một group expert đúng không? Và nó combine với năm cái agent mình phía dưới.

45:33 Nếu mà làm tất cả mọi thứ trong cùng một cái prompt, em chắc chắn nó sẽ không ra được kết quả mình mong muốn đâu. Vì context quá nhiều và không có example cụ thể. Đầu tiên là accuracy chắc chắn sẽ giảm vì quá nhiều dữ liệu cùng lúc. Cái chính là phải chia ra nhiều layer, từng bước một. Thực tế mình cần output từ con LM, chứ không thể hardcode từ trước được. Mình chỉ muốn một cái prompt đơn giản nhất, để nó làm ra các câu trả lời nhỏ, rồi từ đó có một câu trả lời lớn.

46:59 Đúng rồi, khi làm nhỏ ra, mình sẽ biết vấn đề nằm ở đâu để debug. Như anh đã nói, specify kỹ, chia ra từng layer, nếu thấy sai ở đâu mình sửa ở đó. Còn nếu quăng một cục, mình sẽ không biết nó sai chỗ nào, rồi phải sửa rất nhiều lần.

48:43 Đúng rồi anh. Ví dụ như tạo một cái event trong calendar vào ngày mai, nếu không có sự kiện trong giờ đó tạo event, còn nếu có rồi thông báo. Nếu mình quăng một cục request đảm bảo nó sẽ rối ngay, vì nó phải thực hiện theo step by step. Nếu chia thành từng layer, test từng bước sẽ ổn hơn.

49:23 Nó sẽ em chắc là 99% là nó sẽ mù luôn á. Nếu mà còn nếu mình chia cái thành layer cơ, thành nhiều lớp layer á, làm test bài test nó sẽ ok hơn. Rồi, hô nào nên nữ, nên văn phòng là có Tôm ở đấy người chửi nhau. Anh không có hỏi nào chắc là cảm ơn Hoàng trước. À, đến Đạt nhé. Đạt nhờ. À, em không thị xem màn hình. Ok rồi, mọi người thấy màn hình của em chưa? Ừ, thấy rồi.

50:38 Hôm nay em nói về Yelp use cases. Từ từ Đạt, để anh giới thiệu context một chút. đợt này team mấy bạn sẽ focus vô đâu đó và đi search thử mấy cái phần use case ấy. Use case ở đây có nhiều dạng. Cái dạng mà Đạt đang sharing nó sẽ là mình xem thử các bên startup hay enterprise nó đang apply vào để giải quyết vấn đề gì. Là có thể là những cái green field, tức là những cái hoàn toàn mới. Hoặc là những cái mà nó optimize cho cái phần current workflow của chúng đó, kiểu vậy. Nó sẽ viết những use case và report lại hàng tháng, những cái phần update. Ngoài ra có một cái phần dạng use case khác nữa đó là những cái phần tuning mà để boost phần development của bên phía bên phía là tech các thứ. nó sẽ có những cái technique hay là có những cái phần editor mới, hay là mấy cái tool mới các thứ. đ cũng sẽ report cái phần đấy đâu đó trong tech. Đang testing thử trong khoảng hai tuần một đấy. đây là một cái bài đầu tiên chắc con Yelp này, nó đang dạng là con start-up phải không, chắc là. tiếp tục giới thiệu cho anh em một tí về cách mà bọn này đang apply AI là như thế nào?

52:01 Yelp là cái đơn vị nó đưa ra cái software, nó cung cấp cái software cho các store, các bên mà doanh nghiệp muốn làm các đơn vị nhỏ lẻ như kiểu là giao hàng nhanh, hay là nhà hàng, rồi các bánh dụng cụ cơ bản, kiểu như vậy. Yelp này nó bán cái software cho mọi người làm việc đó. em sẽ chia sẻ chút về thằng này, nó sử dụng AI vào trong cái tooling của nó như thế nào.

53:00 trước đó chúng nó có một cái machine learning system rồi, bây giờ nó app thêm AI vào để giúp cho cái việc recommendation nó đúng hơn. bọn Yelp này nó có trên hệ thống của chúng nó, nó có nhiều cái thể loại đánh giá như kiểu đánh giá nhà hàng nó không bị tốt chẳng hạn. dựa trên những cái review đó, chúng nó có làm cái trò là text editing để so sánh được những cái kết quả mà spam hay không á. nó sẽ sử dụng AI vào trong cái việc gì. Thứ nhất là chúng nó sẽ tạo, chúng nó sử dụng AI để làm cái việc làm dataset, để train được cái model đánh giá là nó đang spam hay nó đang review tốt hay xấu như thế nào á. nó sẽ sử dụng AI để tạo ra cái dataset dựa trên LinkedIn. ở trong đây, em đọc có thấy bảo là chúng có sử dụng số tính như Zero-shot và Few-shot để làm dataset. chúng nó chỉ sử dụng một số cái model ở trên Hugging Face, rồi xong chúng nó làm classify để đánh giá được là review tốt hay xấu. đây là một cái use case cho cái việc AI dùng để làm text editing.

54:18 À, sang cái use case thứ hai của chúng nó, là chúng nó có sử dụng Clip Model. Clip Model bản chất của nó là xử lý hình ảnh. Xử lý hình ảnh có nghĩa là sao? Có nghĩa là dựa trên review, dựa trên review… đợi em chút để em kiếm nè. À, Clip á, nó sẽ xử lý hai thứ. Một là cái caption của cái ảnh, và cái ảnh nó như thế nào. qua Clip này á, nó sẽ hiểu được cái context của cái ảnh là cái gì. chúng nó sử dụng Clip vào trong những cái công việc như là những cái người ta đi vào trong một quán ăn hay một cái quán nhậu á, chúng nó sẽ review, chụp ảnh để capture lại những cái thứ này. Và ví dụ như hình ảnh của một cái món sản phẩm đi, trước khi apply Clip nó không đánh giá được, nó không đánh giá được là nó có bánh quế không, nó chỉ đánh giá được mỗi gà rán thôi chẳng hạn. Sau khi apply Clip vào á, nó sẽ biết được là có gà rán và có bánh quế. bản chất, nó sử dụng cái Clip này là một phần của AI, là nó xử lý ảnh, xử lý ảnh và caption của ảnh, và hình ảnh thành vector để nó so sánh với nhau. đây là hai use case của nó. những cái use case này được áp dụng cho cái gì?

55:38 Hai cái use case trên nó sẽ áp dụng trong cái tình huống là khi mà mình có nhiều review á, mình có thể summarize nó lại thành một cái highlight review ở trên đây. dựa trên những cái thứ mà nó chuyển thành vector được á, nó có thể annotation được cái việc là những cái hình ảnh đang nói cái gì, nó support cho mình được cái gì ở trong đây. Đợi một chút, nó sẽ highlight cho mình luôn. nó sẽ biết được cho mình cái context của cái ảnh là gì, nó có thể annotation được cái việc này. đó là cái use case của cái việc mà AI dùng để làm image summarization.

56:15 Đầu năm nay nó có release thêm cái là Yelp Assistant. Dựa trên những cái nền tảng cũ của chúng nó, chúng nó có thể tạo ra chatbot rồi, xong nó có thể review lại cái highlight như thế này, mình cứ hỏi nó xong nó recommendation cho mình cái gì thôi. Đơn giản là như vậy. Ngoài ra em có thấy một cái use case cũng khá đặc biệt, có nghĩa là trong cái giai đoạn từ 2020 á, nó nổ ra cái câu chuyện là làm clip ngắn review các thứ á. chúng nó có một cái nguồn dataset nhất định cho cái việc đó. em thấy chúng nó bảo chúng nó sắp release một cái như anh Tom có đề cập, cái bọn đó có thể chuyển văn bản thành giọng nói á. dựa trên cái nguồn dataset review này á, có lẽ chúng nó support review thêm cái việc mà làm video clip ngắn để mô tả cái nhà hàng.

57:45 Dựa trên những cái review, những cái video mà người ta tới người ta review á, mình có thể tạo ra được một cái đoạn script, xong cho nó chạy qua AI, nó tự động làm ra một cái video về một cái nhà hàng như mình. đây là use case của bọn này, đơn giản nó có thế thôi. Ok, quay lại cái câu hỏi đầu tiên, cái này nó sẽ dạng là dùng AI để label data, đúng không?

58:35 Ok, vậy là check xem là cái comment là negative hay positive, đúng không? Kể kiểu đấy là một ví dụ. Cái thứ hai nữa là nó sử dụng cái clip model, đúng không? Chắc là sẽ dạng giống như Vision, nhưng mà live hơn, cũng để dán nhãn, đúng không? Để dán nhãn giống như cái của bên phía Plot, dán nhãn cho ảnh. hai cái use case đó, nó sẽ được ứng dụng trong cái việc gì?

59:18 Em nghĩ có một cái ý khá hay mà nó chưa nói tới, là câu chuyện là nó có nguồn dataset sẵn. Như là ai tới review, ai tới đánh giá các thứ, dựa trên những cái clip ngắn như thế này, nó có thể tạo ra được một cái video intro về cái nhà hàng đó. Nó sử dụng AI. Em nghĩ là nó sử dụng AI để viết kịch bản, rồi sau đó đưa kịch bản đó cho một con AI voice để nói. Nhưng mà hình ảnh nó lấy ở đâu? Như kiểu là video nó sẽ lấy từ đâu ra?

59:57 Từ trong cái review, ai tới review họ sẽ có một cái video để review. Ok, tự động tạo advertisement, đúng không? Dạ vâng, cho TikTok hay những nền tảng như TikTok các thứ, kiểu summarize từ review của user. Nghe cũng có vẻ sáng tạo đấy. Ừ, chắc anh em confirm mấy cái của anh bảo làm rồi đúng không?

01:00:07 Đang vậy, cái này ok là cái caption. Ok, đúng hầu như là đúng anh. Bạn nói đúng, là chúng nó sẽ, em nghĩ em nghĩ cái use case này bọn này ban đầu á, cái mục đích ban đầu của bọn này là làm recommendation. trước đó, trước khi có AI chúng nó đã có một cái hybrid recommendation model trước. Căn bản là nó sẽ… Em nghĩ là khi mà có cái này á, nó dẹp gần hết cái model cũ này luôn. Em nghĩ có một cái khá hay là cái business messaging mà chúng nó không có đề cập nhiều. Có nghĩa là em nghĩ là nó sẽ dựa trên là có review top 50 review chẳng hạn. Xong top 50 cái interaction, kiểu như rating như thế nào. Thứ nhất là review tốt, n rating tốt, cái business messaging của nó sẽ tốt. Mà Yelp không đề cập vấn đề này, mình không trách nó được.

01:00:51 Ok, anh em có câu hỏi cho Đạt không? Bài đầu tiên đấy. Đạt bảo đang thêm mấy cái, mình phải enterprise nữa, nhưng mà thầy thấy đang Viettel với cả FPT, với cả VNG các thứ, đang chưa biết thấy chúng nó thế nào. Đạt kêu mấy cái tool, cái tool gì coding của bên phía FPT hả, đang kêu cùi.

01:01:41 Hì, một bản for, một bản for của của continue à? Nó thế, nó thế không tốt. Nó hơi cùi, thô. Hai, chị hết rồi à? Chắc vậy. Đạt nhé. Hôm nay mấy bài về Yelp và Tech Linh chắc tuần sau, tuần sau, tuần sau nữa, nếu kịp.

01:02:01 Tí demo luôn đi, Đạt luôn. Để Đạt demo một tí cái gì nhỉ? Cá đang là một con bot, để có thể question với cả question một cái short code dưới dạng kiểu developer mà hiểu rõ hơn về code, hay là test kiểu như là một vai trò auditor đi kiểm tra chất lượng của code. Đạt đang demo dev cái workflow hay con bot dựa trên diff đó cho anh em xem thử nào. Mình bật hình rồi Đạt ơi.

01:03:01 đây là một cái project để em xin vào club ai nha. Trình em gọi là hơi ’newb’ nên project này mà có lem quá mọi người thông cảm. Workflow cơ bản là em sẽ lấy query, rồi trích xuất ra được cái URL của repo. Ở đây em có dùng lại cái scrapper của anh Tom, nhưng mà nó chưa đúng ý em, nên em có tạo một con scrapper ở local nó sẽ lấy được tất cả content của repo luôn. Nhưng mà cái đó nó quá lâu với quá lớn. Ờ, default hiện tại em chưa thấy làm cách nào mà bỏ vào con context được, trừ khi dùng cái knowledge retrieval, mà dùng knowledge retrieval em không có gọi là trực tiếp được mà phải bỏ vào trước. Mình không có chọn, không có chọn repo được.

01:05:45 Cái scraper này của anh Tom nó không có lấy content của file, cho nên em chưa vẽ diagram được. Vẽ diagram có thể em dùng, tí nữa em test thử. Cái này là em lấy được content của những file nè, ở root, ở những file doc. Những file đó không chắc câu hỏi của Huy vừa đưa ra chắc là cũng không trả lời được. Để em thử, em có sẵn cái full của em vô đây rồi, offline nhỉ. Bên phía in sẵn content rồi, chứ không online. Cái này em generate bằng luôn, cũng không có.

01:07:07 Cái này nó sẽ scrap full content, nó sẽ đầy đủ hơn. Để em thử đặt câu hỏi của bên Huy hay của Hoàng các em thử nào. Mình thử BC chat lên rồi đặt câu hỏi xem. Anh có không? À không. Maybe là cái context này quá lớn, cái phần knowledge retrieval này em chưa tìm được cách mà cho nó vào context tốt được.

01:09:19 Retrieve tối ưu lắm. Cái file text này cũng mấy chục ngàn dòng, mấy chục ngàn dòng á. Mở lên xem thử nà, đ đang dùng mini hả, đổi sang máy đ xịn hơn xem có ok hơn không. Đồ mini hơi cùi. 2 triệu từ như thế, từ làm sao mà nó còn xong được ta? Em nghĩ là phải có một cái server, cái dedicated server luôn nó mới ok. Anh đang tò mò tại sao nó chạy được ấy, bởi vì 29U word à, như vừa thấy à. Nhân với cả 4 này là số to. Kích cỡ đấy, Follow up xem thử. Ok, tức là em vẫn là từ cái context thôi đúng không, là mình cũng chỉ dạng là query kiểu query vb đúng không, chứ không phải mình nhập hết tất cả cái đấy vào context.

01:10:57 Ok, đúng rồi anh. em chưa nắm được là cái retrieval của thằng dify nó sẽ chạy như thế nào. Không biết nó chạy có đúng không, nó retrieve có đúng không. Em chưa tracing được nó mà em có cái tool tracing ở phía trước nữa, có thể test lại thử xem như thế nào. Nhưng mà ý là nếu mà kiểu retrieval như này chắc là kết quả nó sẽ không đúng được đâu anh. Anh cũng đang chưa biết là nó sẽ run bao nhiêu data ấy. Kiểu nó chỉ prefer 2-300 thôi, kiểu data không thể nào đủ mà để làm mấy cái task kiểu này. Cái này ít nhất cũng phải vài trăm tương đối data ấy. Dạ cái này còn work in progress.

01:11:35 Đùa đấy, cứ lên công ty là có AI Club rồi. À, là của full version hay là fix được cái vụ này demo với bọn anh ở trên office nhé, mà try em để lại cho anh. OK, để em xem nó vẫn không build ra chắc mọi người coi đỡ. Cái chắc build bị gì đó, mọi người thấy màn hình không ạ?

01:13:08 Dạ tuần này như em nói tuần trước em sẽ up cái bài sync.Map này. Em thấy nó hay với chi tiết để mọi người mà xài Go có cái nhìn tổng quan hơn về map nói chung. Và cái thằng sync map này đi qua trước là phần context. khi mọi người viết map đúng không, mà mình nếu mà mình viết concurrent map hay operation đó, mình làm concurrent á, về bản 1.16 trước nó sẽ không báo đâu, nhưng mà nó vẫn không safe nha. Còn bản từ 1.16 trở đi á nó sẽ error như thế này đó. Cho nên là để mà solve được problem này bình thường mọi người có thể viết map kèm với tại package sync, viết manual đó được.

01:13:56 Bên cạnh đó nó có một cái option khác đó là thằng sync.Map này. chút nữa đến cuối mình sẽ sẽ nói tại sao nó lại được đề ra xài và cái usecase của nó như thế nào. thằng này nó được đề ra để mà mình không cần quan tâm lắm về cái việc mà mình phải xài mutex để lock lại cho việc synchronize. Tức là mình chỉ có việc xài thôi. Xài nó trông đơn giản như thế này nha, nó friendly như là mình viết map kiểm tra value vậy. Ví dụ như mình load một cái key lên có value ok nó sẽ giống như là việc map value bình thường thôi. Trong như này, nếu có là ok true, còn nếu không có false của y chang.

01:14:38 Còn có một số cái function mà mình có thể xài rất handy. Đây là bảng 12.23 sẽ có clear, clear hết. Ví dụ như load là để lấy value, store là để update hoặc store cái key. Update vậy. Delete các thứ. ngoài cái việc mà mình viết concurrent đó đi đó, bên cạnh đó khi mà mình range, tức là mình loop một cái map nó cũng bị race condition nữa. thằng sync map này nó có cái hàm range này, mình xài mình sẽ không quan tâm nó là ấy, nó sẽ không bị nhưng mà như hàm range bình thường thôi. nó sẽ không cho mình cái cái snapshot mà gọi là consistent nhất, là khi mà mình vừa mới vô cái snapshot nó không được update là.

01:15:28 Mà mình range, tức là mình loop một cái map, nó cũng bị race condition nữa. thằng sync.Map này nó có cái hàm Range, mình xài, mình sẽ không quan tâm nó là cái gì, nó sẽ không bị như bình thường đâu. Nhưng mà như hàm Range bình thường thôi, nó sẽ không cho mình cái snapshot mà gọi là consistent nhất, là khi mà mình vừa mới vào cái snapshot nó không được update. trong lúc đó mình sẽ phải thay đổi cách viết, nhưng ít nhất là nó sẽ không bị phải error như thế này.

01:16:06 Đến cái phần bên dưới nó work như thế nào á. mọi người, nếu mà mọi người viết khi mà xem CH và definition cái map nó được cấu trúc như thế này: nó sẽ bao gồm hai cái map. Đó, nghe đến đây là mọi người sẽ thấy hơi kinh, nghe hơi thốn RAM với memory. Nó có một cái Read Only map và một cái Dirty map. nghe như thế mọi người có thể đoán được là nó sẽ làm việc theo kiểu là những cái value mà nếu mà được write nó sẽ được viết vào cái thằng Dirty map này hết. Cứ viết update vào đây, update vào đây, con này nó sẽ giống như là.

01:16:46 Cái Read Only map này nó sẽ là những cái khi mà mình đọc vào á, mình sẽ luôn đọc ở đây. Còn write sẽ luôn write mới vào thằng Dirty map. Còn cái flow bên dưới nó làm việc như thế nào chút xíu nữa mình sẽ nhìn cái chart flow mình sẽ thấy. À, cả hai cái map này có một điểm chung: nó đều có một cái con trỏ entry nha mọi người, để ý để dễ hiểu cái flow. Ví dụ, ở đây mình thêm một cái entry mới, đúng không? nó sẽ thêm vào Dirty map và nó đều trỏ đến entry này. Cái này nó sẽ giống như là một cái flag để đánh dấu rằng là cái map này đã được thay đổi rồi. Tức là cái thằng Read Only map này nó không phải là mới nhất nữa. Khi này bên dưới nó sẽ nhìn và hiểu rằng là thằng Dirty map mới là cái nên đọc vào.

01:17:27 Hình này thể hiện rằng là ví dụ như mình update một cái value nào đó, do bên dưới nó là con trỏ đúng không, mình chỉ việc update cái con trỏ đó thôi, không cần phải update từng cái value như là mình làm với map truyền thống. để làm được điều này á, bên dưới nó để ra một cơ chế là ba cái trạng thái (state) cho cái con trỏ entry này. State thứ nhất là normal state, đúng không? Normal state tức là những cái value cũ của map, nó đang có đủ và có thể xài được, không có bị gì hết. Còn trạng thái amended là khi mà entry đã bị sửa lại. Còn delete state là khi một entry nào đó đã được delete khỏi map, nhưng nó chưa được remove hoàn toàn nha. Tức là nó sẽ được…

01:18:59 …assign cái con trỏ entry vào new entry, chứ chưa remove ra. Còn cái expired state là xóa hoàn toàn, giống như là hard delete là mất khỏi map luôn. Để hình dung rõ hơn, mọi người có thể nhìn cái flow như thế này nha: ví dụ ban đầu cái map của mình đang có một cái key1 và value1 đúng không? bên Dirty map chưa có gì cả, tức là chưa được thêm bớt gì. Sau đó, mình thêm một cái key2 nào đó, đúng không? nó sẽ được thêm vào Dirty map, và khúc này là thằng map đã amended rồi, nó đã có một cái flag amended ở đây.

01:19:40 Sau đó, khi mình xóa (delete) một cái key, map này sẽ bị gán new entry, đúng không? Bên này cũng sẽ được tương tự gán new entry, giống như cái hình trước. Tức là mình chỉ cần cập nhật con trỏ thôi, không cần phải cập nhật value. Rồi, sau khi delete xong, đúng không, để promote được cái Dirty map này, mình phải cập nhật lại qua bên Read Only map, để Dirty map trở về new state, giống như đưa về trạng thái ban đầu.

01:20:18 Tương tự, thêm một key3 nữa, khi thêm cái key3 này á, cái state này nè, sau khi nó đã trở về new state rồi đúng không, mình thêm key3 vào á, nó xác định rằng thằng này đã được delete rồi, nó sẽ là delete hoàn toàn. Điều này có nghĩa là lần sau, khi nó so sánh với Dirty map, nó biết rằng bên này cái value1 đã bị xóa rồi, không còn nữa. cái Read Only map lúc này chỉ còn lại key2 và key3.

01:20:51 Cho nên chính vì lý do này, sync.Map không có hàm len cho mọi người xài. Tại vì nếu như mọi người dùng hàm len ở đây, sẽ không biết được value của nó, tại vì lúc đó nó sẽ đếm cả những cái value đã expired hay deleted. Mọi người có thể thấy, chính vì cái cấu trúc của sync.Map được build như thế này, use case của nó được recommended là nên dùng cho những use case mà đọc (read) nhiều hơn ghi (write). Tức là nếu mà write hoặc delete nhiều, mọi người tưởng tượng chỗ này nó xài con trỏ liên tục, và có một cái issue bên Go team đã report là thằng này không bao giờ được garbage collected.

01:21:36 Sau đó Go team họ confirm rằng cái sync.Map này được sinh ra chủ yếu để support mấy cái bên trong Go Library thôi. Nếu mọi người thấy nó handy vì có những function dễ xài có thể xài, nhưng nếu use case của mọi người mà cần lưu trữ (store), hoặc là update, delete nhiều không nên xài, vì nó sẽ làm chậm hệ thống.

01:22:24 Dạ chắc chỉ vậy thôi ạ. Em có code lại cái bài bên này là cái bác này hay share mấy bài cũng khá chi tiết, mọi người có thể follow theo dõi. Ủa, cái này là topic gì Phát? Cho anh coi lại cái bài kịch bản đúp đầu r. À, cái sync map à? Ừ, sync map á. Ủa, nó có khác gì với lại cái anh vừa pass vô không vậy? Khác ở cái gì? Hình như là khác á anh. Ý là cái này em nhớ không nhầm là kiểu như cộng đồng tùy. Anh ví dụ use case họ muốn viết một cái gì đó mà họ thấy. Đó, anh nhìn thấy, họ ghi cái trong cái bên đấy, link mà nhìn thấy cách nó chạy mà lý do tụi nó làm thêm cái gì ấy nhỉ?

01:23:30 Anh nhìn thấy nè, họ thêm một cái lớp nữa để họ xài. Ví dụ như là họ sẽ có những cái use case đúng không? Ví dụ như họ muốn implement generic trên sync.Map đó. Cái này cũng có ảnh hưởng do cái vụ link nãy em nói, do thằng này nó không được garbage collected nè. Đó, kiểu vậy. ví dụ như bên này Go team ở dưới, họ đã confirm chốt xong cái này là cái sync.Map này họ kêu là cái này là intended, intentional choice rồi, cho nên họ sẽ không sửa. Họ sẽ không đổi đúng không? Bây giờ cộng đồng làm gì mình chỉ biết là họ tự xài thôi. Ý là họ thích cái việc sync.Map này được để ra dễ xài, có mấy cái function ngon lành, họ ráng thêm một tầng nữa, rồi chế những cái mà họ cảm thấy là ok, mình có thể xài được. Kiểu vậy.

01:24:07 Ủa mà sao cái clip này cũng lâu mà bữa nay lại chọn à? Ờ, thế kiểu insight thôi, insight cho mọi người xài. Ý là cái use case này cũng có thể được apply cho bên mình. Ví dụ như bên enterprise đúng không? ví dụ mình xài map, mà mình xài concurrency đúng không? mọi người sẽ tự viết một cái struct, xong rồi mọi người sẽ nhét một cái mutex vào, rồi tùy người sẽ ngồi bắt đầu viết lại. Đủ các kiểu. Trong khi đó thằng sync.Map rất handy, như nãy em show anh, là mấy cái function này là nó luôn follow cái chuẩn, là anh muốn load anh phải gọi hàm này. Kiểu vậy, nó chuẩn hơn.

01:24:50 Mọi người sẽ tự viết một cái struct như thế, xong rồi mọi người sẽ nhét một cái mutex vào, tùy người sẽ ngồi bắt đầu viết rồi đú các kiểu. Trong khi đó sync.Map rất là handy. Sync.Map này như em show anh nãy đó, những cái function của nó, nó luôn follow cái chuẩn này hết. Anh muốn load anh phải gọi hàm này, kiểu vậy nó sẽ chuẩn hơn. Nhưng mà như cái bài này là mình phải để ý những cái trade-off của nó, xài cho đúng quy. Ok, hiểu rồi, tức là quy chuẩn cái cách mà sử dụng map hả? Với lại workflow hả?

01:25:26 Cảm ơn Phát. Rồi để tranh thủ, mấy cái Thành ơi, nhất là xin anh em thêm 10 phút nữa nhé. Nó sẽ hơi tốn thời gian thêm xíu. Nhất là anh nhận được tổng cộng 11 cái submission cho cái bài test của mình. Có ít bài hình ở trên, mấy anh em nhìn ở trên tí. Deadline của mình là đến ngày 20, tức là tuần sau nhé. Bữa trước anh thông báo như là 27 ha, phải không? 26, 27 gì đó là deadline, mấy anh em coi tranh thủ còn một tuần nhìn bài đó rồi làm ha. Cái bài đó nó sẽ quan trọng, có một số cái mà chi tiết của từng bài đó anh chưa có nhìn kỹ. Chỉ có bài của Tôm bữa trước, Tôm nó quăng nhanh lên trên lobby quá, thành ra là có nhìn sơ qua xíu. Nhưng mà còn của mấy anh em chưa nhìn rồi. Nhưng mà cái ý chính là mọi người xem thử nha, cái chất lượng bài của mình á, tập trung ở chuyện là đợt này khi mà market nó thay đổi nhiều vậy, cái demand của thị trường cho cái nghề làm software nó có sự thay đổi lớn á.

01:26:15 Tất nhiên những cái nhu cầu nó vẫn sẽ còn ở đó thôi, nhưng mà cái số lượng đó nó giảm xuống. Thành ra đó anh gọi là cái sự thay đổi về cái nhu cầu thị trường gần như với góc nhìn của anh trải qua nó là giống như 2014, nhưng mà on-over-again, vậy là sự thay đổi công nghệ mới ra, mọi thứ mới ra, thị trường mới rồi những cái tiềm năng mới nó sẽ xuất hiện trên đó. cái bài test nó sẽ quan trọng với việc là giúp cho mình, nhất là test về văn hóa, nhìn lại trong cái lúc mà tụi anh muốn check lại cái team á, muốn là hai cái đội: đội làm research study với cả đội làm consulting nó có một cái sự phân hóa rõ ràng.

01:27:36 Nó có một cái sự phân hóa rõ ràng. Như trong cái bài viết anh post lên notion cách đây khoảng hai tuần hả, sẽ có sự phân hóa rõ ràng. Tương lai nó sẽ có thêm một số những cái policy mới cho chính sách về lợi ích khác nhau giữa hai đội nữa. Nhưng mà hiện nay là, như mình thấy đó, mọi người thấy OGIF dần dần nó được chuyển qua gần như thành cái buổi là report lại tất cả những cái study. Cái phần mà anh em đang coi mới và report lại trên này. Có thể những bài đó do được add, có thể những bài đó là do mọi người bắt đầu anh nhìn thấy, có một vài thành viên trong team mình thật sự là thấy cái kiến thức mới đó, xong rồi pick up những kiến thức mới đó để mà coi.

Từ từ thấy rõ ràng là tụi anh muốn cái sự phân hóa đó nó diễn ra càng ngày càng rõ hơn. Và cũng có chính sách rõ ràng cho cái chuyện đó. Tức là ai mà thích coi mấy cái phần topic nhiều hơn, xong rồi ra ứng dụng ở tới mức là MVP, hay là ứng dụng vô những cái dự án nếu có, hoặc là đi deep dive thêm về kiến thức á, sẽ có một cái benefit khác. Những anh em nào mà không nhất thiết để phải ngồi coi những cái phần liên quan tới phần study như vậy, cứ ngồi làm dự án bình thường thôi. Nhưng mà nó sẽ có một số vấn đề khác đi kèm mà anh cũng có list ra trong cái link notion cách đây hai tuần. mọi người xem nhìn lại cái link đó một tí, để biết là vì cái định hướng như vậy nên là cái bài test này nó mang ý nghĩa là xem thử coi là cái mức độ của mọi người trong chuyện bắt kịp kiến thức mới, hoặc là cái độ tương thích với lại văn hóa trong cái giai đoạn mà tất cả mọi thứ nó thay đổi như vậy tới mức nào ha.

01:29:20 Để hiểu vì cái mục tiêu là như vậy, nên là cái lúc mà chấm cái bài á, anh sẽ là người duy nhất chấm cái bài đó. Team mấy anh chị khác không có chấm đâu. Tất cả mọi người sẽ phải làm mà, nên là anh nghĩ rằng anh set cái standard cho chuyện đó. Nên là mấy bạn chịu khó làm bài đó tự làm là một chuyện. Thứ hai nữa là bài nào mà chất lượng thấp thật ra cũng không có vấn đề gì hết, chấm điểm thấp một xíu thôi, nhưng mà vừa làm hết vẫn sẽ được đủ điểm để mà coi như là pass cái đó. Chỉ là sau đó cái kết quả trước mắt thể hiện được á, là anh sẽ phân cụm thành hai cụm khác nhau.

Đội Foundation hay là đội Lab á, vẫn là đội core của mình từ năm nay, ha. Đó là cái thông báo chính. Nên là trên 11 cái bài này, nếu bạn nào làm xong rồi mà cảm thấy là mình có thể làm tốt hơn được cho cái chuyện mà anh vừa mới nói đó, đội mình thật ra là cái team Foundation và cái team Lab á vẫn sẽ được ưu tiên nhiều hơn trong những vấn đề khác nhau. Được ha. Nên là nếu mà anh em cái bài đó mà đang kiểu làm qua loa á, tập trung ngồi làm kỹ lại tí. Check hai thứ ha: văn hóa trên đó là một, thứ hai nữa là kiến thức.

01:29:56 Sau đó cái kết quả trước mắt thể thấy được á, là anh sẽ ân cụm thành hai cụm khác nhau, cái đội Foundation hay là đội Lab á vẫn là sẽ đội core của mình từ từ từ 8-9 năm nay ha. đó là vậy, đó là cái thông báo chính. Nên là trên 11 cái bài này, nếu bạn nào làm xong rồi mà cảm thấy là mình có thể làm tốt hơn được cho cái chuyện là anh vừa mới stay ra, là đội mình thiệt ra là cái team Foundation, cái team Lab á vẫn sẽ được ưu tiên nhiều hơn trong những vấn đề khác nhau. Được ha. Nên là nếu mà anh em cái bài đó mà đang kiểu làm qua loa á, tập trung ngồi làm kỹ lại tí, check hai thứ ha: văn hóa trên đó là một, thứ hai nữa là kiến thức cho cái cụm thông tin cái cụm gần nhất mà nó đang có vẻ hot nhất là LLM thôi.

Nhưng thực ra team mình vẫn cover rất là nhiều mảng khác nhau, vẫn đang có xem về design, mấy bạn cũng đang xem đúng không. Vẫn có đội đang xem đúng không. Go vẫn đang xem. Blockchain có vẻ nó qua trend tí rồi, thị trường nó đang sideways thôi, nhưng mà về demand của consulting nó vẫn yêu cầu những cái đó rất là nhiều.

01:31:46 Mấy cái mini app cho telegram, họ mua về rồi clone nhanh lên, thấy góc nhìn của mấy bạn làm business logic (BL) và tech (TCH) bây giờ nó khác một xíu rồi, không còn như ngày đầu nữa. Nhưng mà với consulting mình vẫn có thể sử dụng thôi, bình thường. Hoặc là mình có thể nhìn theo một góc nhìn khác, theo dạng là nó như một cái asset class mới xuất hiện. Với vai trò là developer, mình phải nhìn nó theo góc nhìn làm sao để nó ảnh hưởng đến cái workflow của mình như thế nào, quản lý tài sản ra sao.

01:32:29 Đó là vấn đề về bài test nhé. Mấy anh em chú ý cái đó. Thứ hai, nãy có nhắc tới cái định hướng về team và số lượng nhân sự. Trong đó có nhắc lại cái link notion hôm trước anh có gửi nhé. Đội Foundation, đội chính khi start lại lần nữa như vậy. Lúc trước team tụi anh bắt đầu chỉ có ba người thôi, sau đó dần dần tăng lên bốn người, rồi lên năm người. Có thêm Quan, có thêm Hiếu, có thêm mấy bạn khác. Nhưng mà ban đầu start với ba người, giờ đội hình xịn hơn rồi. Bây giờ 40 người toàn là thứ dữ, chắc chắn sẽ đi nhanh hơn. Câu chuyện chung là vậy, đánh giá chung cũng là như thế, nên mấy anh em nắm tình hình nha.

01:33:12 Cái thứ ba nữa có liên quan là Huy Nguyễn, nếu mà xong rồi, chắc tuần sau xem lại thống kê con số về ICY giùm anh nha. Hôm trước em cũng báo là số lượng bắt đầu chạy hơi nhiều, nên mình phải xem lại, cân lại con số cho nó hợp lý. Riêng phần này nhờ Huy và Thành chủ động làm giùm, xử lý giùm anh, xem lại cân số cho nó hợp lý. Thành có một công việc phụ là phần benefit cho thành viên team Lab, xem thử đề xuất như thế nào. Nó có thể được coi là một cái payon, nhưng mình sẽ không trả qua kênh bình thường, mà sẽ có cái cơ chế khác.

01:33:52 Nhưng mà mấy thành viên team Lab sẽ có cái đó, mọi người quen với cái đó rồi. Cuối cùng là, riêng phần về LLM hiện tại, trong cái list câu hỏi có một câu hỏi quan trọng là làm sao để sử dụng, tìm hiểu bên ngoài sử dụng LLM như thế nào và adapt ra sao. Nhấn mạnh lại câu đó, vì nó là một câu mang ý nghĩa trong việc làm knowledge discovery. Câu hỏi này liên quan đến việc test là không chỉ đơn thuần là dùng, mà là tất cả các công cụ mà mấy anh em thấy được trong team hiện tại. Khi có người sử dụng hiệu quả, có người sử dụng kém hiệu quả hơn, RT (retrieval technology) nó thành một spectrum rất rõ ràng, những người thấp là thấp, những người cao rất cao.

01:34:38 Tụi anh muốn nâng cái standard đó lên. Spectrum đó tụi anh muốn rút ngắn lại, càng cô động lại càng tốt. Bây giờ nó đang rất dài. Câu này ngoài việc dùng tool để làm discovery, nó còn mang ý nghĩa xem ngành nghề của mình sẽ như thế nào trong việc ứng dụng đó để nâng cao competency của mình, làm việc có năng suất hơn. Đó là toàn bộ vấn đề, và mọi người xác nhận lại xem cái mình làm có đúng chưa, nó có tầng ý nghĩa sâu xa hơn vậy.

01:35:20 Cuối cùng để kết thúc buổi này, Thành ơi, mấy buổi OGIF sau, những phần mà Tom đã làm liên quan đến việc xây dựng structure của một cái LLM app, có thể lấy cái đó ra phân tích thử nhé. Phân tích lấy cái đó để làm sâu hơn luôn nhé.

01:35:56Toàn bộ mọi người hy vọng là tất cả anh em đều pass hết để đi chơi cho nó vui vẻ. Tuần sau sẽ có một cái bài khác. Tuần sau request là bên chỗ của Minh L. Minh ơi, chắc là lên làm một cái demo nha, tiếp tục về cái finite state machine, FSM á. Vì trong định hướng những công nghệ nền tảng như blockchain, AI, nhưng phần chính vẫn sẽ là các anh em làm engineer sẽ có một ngách khác để đi, đó là hiểu rõ các hệ thống lớn vận hành thế nào. Tương lai, nếu mình không phải là người sinh ra để làm data manipulation AI sẽ làm giùm mình, mình không cần tự thiết kế hay làm mấy việc của junior nữa.

01:37:35 Cách duy nhất để lên senior là hiểu rõ vấn đề và làm kiến trúc thôi. Phần finite state machine đóng vai trò tương đối quan trọng, liên quan đến chuyện scale mà trước giờ tụi mình đã nói nhiều. Trước đó Minh có đọc và hiểu đúng góc nhìn mà anh đang muốn hướng tới. Nên là xem thử làm bài phân biệt các loại general server của nó nhé. Server state machine và event-based server. Rồi làm một cái sample để biểu diễn và implement nó luôn bằng Erlang nha. Erlang có sẵn hết các framework rồi.

01:39:01 Bài này chắc là khi nào Minh Lưu. ready, nếu tuần sau không kịp có thể là hai tuần. Đề nghị mấy bạn backend và mấy bạn sen team mình gom lại, có gì confirm trước nhé. Vì bài này rất quan trọng trong chuyện phân tích thiết kế phần mềm. Bài này rất quan trọng. Trước giờ mọi người chỉ nói tới modeling và làm C4 thôi, nhưng Erlang là ngôn ngữ đi sát cái này nhất rồi, thường mọi người sẽ không biết hết. Chúng ta không nhất thiết phải học Erlang nhưng có thể nhìn cách thiết kế và build của họ để làm phần đó rất chuẩn, giống như là họ có framework sẵn, mình chỉ cần gắn vào để sử dụng thôi.

01:39:37 Tranh thủ, ngày 20 tháng 10 là chủ nhật, Mỹ với Ngọc và Giang có post rồi. Hôm đó là các chị em đi chơi, còn không ở Sài Gòn đại diện team sẽ chúc mọi người phát tài. Chúc mọi người phát tài chắc hợp lý nhất trong trường hợp này. Một chút chúc khác có vẻ không liên quan lắm. Rồi vậy nha, anh em tham gia được đăng ký với Mỹ để book bàn và đi cho hợp lý.

01:41:19 Nhờ Thành những buổi sau cấu trúc lại thành mấy cái talk nhé. Rồi làm goal đó, team mình có thêm Builder-club nữa, đội đó chắc để xem mấy anh em lúc trước làm Super Bit ổn định lại hoặc làm console ổn định lại anh sẽ cấu trúc lại sau nhé. Đợt này chắc là nghỉ ngơi đầy đủ rồi. Rồi ok, anh em có câu hỏi gì cho bài test không kết thúc ở đây nhé. Rồi tạm biệt mấy anh em, hẹn gặp lại tuần sau. Cảm ơn Thành, cảm ơn tất cả mọi người.

English Transcript

0:28 The topic still includes Go Weekly, and Nam is currently testing the weekly design commentary. Let’s see how it goes over the next few weeks.

11:19 Nam will continue to present to the team, and there are a few topics from Hoang, Cat, and Dat. We’re currently researching various use cases that other companies are applying and some of the tools being used by developers. There will likely be a presentation this week or next about these findings. The focus will be on generating a UX design button. In the past, there have been questions about where AI is applied and how it plays a role, whether it serves as a small, standalone component or as part of a broader application for digital products. Today, I will address how AI contributes and how it functions.

12:11 First, I will talk about system scope relationships. This diagram illustrates how AI is integrated into systems at different levels, from a small component to a comprehensive ecosystem. AI can be a small part of a component or evolve into a larger function, automating features to improve user experience (UX). Here, AI plays a crucial role in digital products, and when integrated, it can fit into various parts—from components to flows, to features, or even as an entire application. It can be part of a platform or ecosystem.

12:53 For example, as a feature within an app, AI can help users interact with the app more easily, saving time by automating tasks that would otherwise be done manually. As a standalone application, there are many examples like ChatGPT, which serves a specific purpose, or as a platform like Rewind AI, which offers multiple features supporting AI in different tasks within the same app. These are examples of the scope of AI’s current operations.

13:39 Next, regarding the spatial relationship, this helps us understand how AI features are placed and organized within the user interface (UI). There are several ways to integrate AI into design, and it’s important to know how to position them in the app so that they optimize user experience without causing confusion or making the interface too complex. Spatial relationships directly affect user experience. For example, AI can operate independently or alongside other features while still maintaining its own space. When you understand these relationships, you can choose how to place and use AI features in a way that enhances usability without overwhelming the user.

15:11 There are six different methods for presenting AI: it can be entirely separate, alongside other features, layered, integrated with the parent feature, or in small points such as icons. These methods include:

• Separate: AI operates as a separate feature.
• Alongside: AI is placed next to other features.
• Layer: AI overlays with another feature.
• Integrated Parent: AI serves a major role in navigating and managing core content.
• Integrated Child: AI operates as a secondary, smaller feature.
• Point: AI is a small icon or widget that helps the user understand its function.

16:41 Moving on to the functional relationship, this describes the functional interactions between AI and other features in the system. AI can exist separately but still adapt to the overall content and functionality of the app at a higher level. AI can integrate with existing features to improve performance, replacing manual tasks. Understanding how AI works functionally allows us to define its role clearly in the app and design in a way that ensures the functional actions don’t conflict with one another and don’t disrupt the user flow.

17:28 There are six methods to describe this functional relationship, which are similar to the spatial relationships I mentioned earlier:

1. Separate: AI operates independently.
2. Aware Of: AI exists separately but is aware of how it affects the main feature.
3. Acting Up: AI interacts back and forth with other features, adapting data between them.
4. Feature Incorporate: AI is incorporated as a part of an existing feature.
5. Usage: AI adapts based on how it’s used within the app.
6. Usage Conventionally: AI communicates directly with other features in a two-way interaction.

I will provide an example of this functional relationship in the code I am about to show, where AI generates a panel on the right side of the screen.

19:06 For example, the acting-up relationship means AI can be aware of and react to changes made by other features, like data syncing between two systems. In contrast, feature incorporation would mean AI is integrated as part of the overall functionality of a specific feature.

19:57 That covers the main aspects I’ve discussed so far, with three key elements for integrating AI into product design: optimizing product features, improving user functionality, and enhancing the overall effectiveness of the AI-powered system. It’s important to understand how to apply AI properly to provide clear value to the user. If we understand how to apply AI effectively, it becomes easier to design a system that brings value to the user by integrating AI in a meaningful way.

20:53 I realized I missed an example earlier, so let me go back and explain. I’ll share a few examples that I think will clarify the functional relationships we discussed. For instance, in Microsoft, there’s a tool that generates images—this operates alongside other features in a parallel fashion. There’s also a feature that sits beside the main functions of the app but doesn’t serve as a core part of the experience.

22:01 Yes, that’s a good example. The functional actions and spatial relationships you presented seem to be similar to common patterns. These are just standard patterns for AI design—how to integrate an AI feature into an app or design an AI-driven app, depending on how it’s categorized.

22:31 Yes, these are patterns we often use when designing AI applications or integrating AI into a separate application or product. Essentially, they are familiar structures to help us better understand how to apply AI. You can categorize and break them down into smaller features. This part is very clear.

23:31 Thank you, Nam. Ok, next will be Hoàng and Đạt’s presentation.

Today, I will introduce a topic called “AI Button in LLM Applications.” Before diving in, let me briefly cover the content and agenda. First, we will explore design patterns related to the AI Button. These patterns are applied in various applications. I’ll pick out the most common and understandable ones to introduce to everyone.

24:35 This presentation will revolve around using AI in digital products. These applications leverage the power of AI models to solve specific problems or assist users in tasks. When using LLMs, many may encounter the issue where the model does not provide the expected result. This happens because the model operates based on its ability to respond using the data it has been trained on. There are multiple ways to address this issue. One of the most expensive ways is to retrain the entire model from scratch, which can take a lot of time and resources.

25:15 We have a technique called in-context learning, which means AI can learn directly within the current context while you are using it. This technique includes few-shot learning or zero-shot learning, allowing the AI to learn without needing to be retrained from scratch. For example, you only need to provide the AI with a few small examples in the context, and it will adjust its behavior based on what is provided. Instead of retraining the entire model, this method saves a lot of time and resources while still ensuring the AI can learn from the specific context you give it.

25:52 In this case, in-context learning is widely used in prompt engineering. People provide available examples directly into the prompt, and the model learns from those examples to generate subsequent results. That’s the main idea of in-context learning. Essentially, the design works like this: you have a query, then you build a prompt with the necessary examples and few-shot learning data, and you pass it through the model, which returns a result based on those examples. However, it doesn’t stop at just examples; many other factors are involved as well.

26:37 Broadly speaking, in-context learning involves feeding the context into the prompt by providing information that the model doesn’t inherently have. Since this is a pre-trained model, its knowledge is limited, so you provide additional information in the context and prompt for the model to learn during the result generation process. For instance, in medical image diagnosis, the model may not have enough specialized knowledge. Therefore, you provide that expertise into the context and prompt so the model can learn during the result generation process. That’s the core of in-context learning.

Next, we have another important design button, which is data preprocessing/editing.

27:54 This section describes the process of preparing data for the language model (LM). As you know, LMs operate based on vector databases, using vector comparisons to find similar data points. This process often involves handling multimedia data and various types of information. To ensure optimal output, applying data preprocessing steps is crucial. For example, you can preprocess text by filtering out unnecessary details to shorten it, or with images and audio, you can remove noise or compress the data to reduce size before passing it through the language model.

29:19 Data preprocessing or editing helps the model operate more efficiently. There are many ways to preprocess, depending on the type of data or context. You perform this based on specific requirements. The next design button I want to mention is a commonly used one, though it goes by different names. I call it the example agent. This design is commonly seen when you want your query to pass through multiple contexts. For example, if you have a content review application, you can let that content pass through a pipeline where each agent evaluates the content from a different perspective.

30:11 One agent might evaluate the content from a writer’s perspective, and another agent might do so from a different angle. After going through all these agents, there will be a final synthesis layer to combine or process those results, ultimately providing the user with a comprehensive output. This design is often seen in evaluation systems where results from different models are evaluated, and the best outcome is chosen based on predefined conditions.

30:55 The next design button is called agentic button. So, what does agentic mean? In the context of language models (LMs), agentic LMs refer to enhancing the model’s capabilities. Since the model only knows what’s in its training data, we upgrade it to increase its power and minimize human intervention. This design helps the system become more automated, allowing it to operate with less human interference.

32:24 This design has several key components that help you achieve this level of automation. There are four main components: reflection, planning, execution, and multi-collaboration. Each of these components helps make your system more automated. First, let’s talk about reflection. Reflection involves evaluating the initial results of the model based on a specific criterion or metric to determine if the result has been optimized. If it hasn’t, the system adjusts and repeats the process, continuing to generate results until it reaches an optimal outcome.

33:06 Reflection helps reduce human intervention because, instead of producing an initial result that doesn’t meet your expectations, the system refines itself based on pre-established criteria, eventually delivering a more accurate result without manual adjustment.

The Reflection button means that it will evaluate the initial output of an AI, then assess it according to a certain standard or metric to see if the result has been optimized. If not, it will adjust slightly and run the AI again to generate another result until the optimal result is achieved. This helps reduce the need for human intervention, as if the first output is not what you expected, you don’t need to manually adjust it—the system will optimize itself.

33:42 The second button is the tool. Tools can be external, such as external APIs or functions that people code. These tools are used to allow the model to access knowledge from the outside world, real-time knowledge, or external resources that it hasn’t been pre-trained on. For example, OpenAI or Claude both support this. The model can know when to call the tool based on the description you write for the tool. The model will know how to retrieve and extract information from the tool and then return it to the LM to generate an output.

34:30 Next is planning. The planning button means that you give the LM the ability to plan, preventing the need to prompt multiple times. For example, if you have a complex task, you provide a large prompt for the LM to plan out all the steps it needs to take in a step-by-step manner. This allows it to perform smaller tasks first, which are eventually combined into a larger task. This planning design has many variations, and this is the simplest version: planning and then executing step by step.

35:10 Finally, multi-collaboration. I presented this about a month ago. Essentially, it’s like having the AI excel at a particular task. You have a context, right? You divide it and pass it through to different agents. Each agent is good at its specific task, and after they complete their tasks, it passes on to the next agent. In this way, it can complete the requirement. This design heavily utilizes the divide-and-conquer principle—breaking a large task into smaller tasks and assigning each to a specialized agent. This is a design button I’ve seen being used in many places.

36:24 Those are the design buttons that I’ve seen used in many places and understand the most. I’ve finished my presentation. Does anyone have any questions?

37:10 Hoàng, can you repeat the part about planning to confirm Bảo’s comment? It’s like it reads the prompt, right? It understands your prompt first, then breaks it down into smaller tasks, and then there are workers—perhaps IDE workers or smaller prompts—to complete the task. Is that correct?

37:40 Yes, you can think of it that way. You can split the prompt, for example, in a complex task, into several smaller plans. These smaller plans will be done step by step. For instance, it executes plan 1 first, then plan 2, then plan 3. Once all the plans are completed, they are compiled somewhere or in a final component to produce the final answer.

38:06 It’s like the Zero you presented last time, right? The worker can do tasks like reading files, deleting files, modifying files, or interacting with the Internet, sending emails, and so on. So basically, agents work in this way.

38:52 Exactly. Instead of handling a massive task all at once, which requires repeated prompting, you start with a prompt that breaks the task into smaller tasks, and then a pipeline runs through each worker, handling small tasks for you.

39:23 Ok, pull up slide 14, Hoàng. Slide 14. I also see this is kind of like the Mule Automation setup that Tom created, right? The Mule button that Tom set up. I’ve finished the code, but this design and the button look exactly the same.

39:46 Yes, this is a looping process with Tom, which looks somewhat similar. It’s like planning, as Tom mentioned, where it breaks down the task into parts and handles each part. It has iterations within it, like a list of steps you described earlier. Referring back to yours, the agents can see that. What I’m seeing looks more like planning: it splits the plan upfront and then works step by step on each plan, moving through each round one by one. This one, though, works more in parallel, where they run simultaneously, produce the output, evaluate it, and then return the final result. I think I got the workflow mixed up; it’s now corrected.

42:28 Exactly, give it a try. It works like that, breaking down into different tasks. It’s more like a classification, running through each one. This is closer to multi-collaboration because it’s like a question classifier, where only one agent runs for each task. Each agent works on its specific expertise, then combines everything.

43:33 But do you think the parts like reasoning and input analysis are correct? Tom’s expert part. Specifically, for picking domains, there’s a classifier, but reasoning and input analyzers are separate agents. In that group, they’re experts, right? We consider them a group of experts, and they combine with the five agents underneath.

45:33 If we try to do everything within a single prompt, I’m certain it won’t give us the desired result. The context is too large and lacks specific examples. The main issue is that accuracy will definitely decrease because there’s too much data at once. The key is to split it into multiple layers, step by step. In reality, we need the output from the LM; we can’t hardcode it all in advance. We just want the simplest prompt so it can generate small answers that ultimately lead to a large answer.

46:59 Exactly, by breaking it down, we can identify where the problem lies and debug it. Like you mentioned, specify clearly and break it down into layers. If something goes wrong, we can fix that part. If you throw everything in at once, you won’t know where the error is, and you’ll have to fix it repeatedly.

48:43 Exactly. For example, creating an event in the calendar for tomorrow—if there’s no event at that time, it creates the event, but if there is already one, it sends a notification. If we throw in a large request at once, it will get confusing because it has to execute step by step. Breaking it into layers and testing each step will make it work better.

49:23 I’m almost certain that 99% of the time, it will get lost if it’s done in one go. However, if we split it into layers, into multiple layers, and do the tests, it will work much better. Ok, let’s go. If anyone’s at the office, Tom’s probably there to argue with. If no one has any more questions, thanks to Hoàng first. Now, Đạt, you’re up. Đạt, are you sharing your screen? Ok, can everyone see my screen? Yes, we can.

50:38 Today, I’m going to talk about Yelp use cases. Wait a second, Đạt, let me introduce some context first. So this time, the team will focus somewhere and search for some use cases. There are different types of use cases. The type Đạt is sharing is where we look at how startups or enterprises are applying AI to solve specific problems. It could be something completely new, like a greenfield, or it could be optimizing the current workflow of their system. They will write use cases and report updates monthly. In addition, there’s another type of use case, which involves tuning to boost the development on the tech side. They will also report that part somewhere in tech. We’re testing this for about two weeks. This is the first report, and it’s about Yelp. Yelp is a startup, right? Now, Đạt, introduce how they are applying AI.

52:01 Yelp is a company that provides software to stores and businesses that want to offer services like fast delivery, restaurants, or basic utilities. Yelp sells the software for those tasks. I’ll share a bit about how they use AI in their tools.

53:00 Before this, they had a machine learning system, but now they’ve added AI to improve the accuracy of their recommendations. Yelp has many types of reviews on its system, like restaurant reviews, which may not always be good. Based on those reviews, they do some text editing to compare whether the results are spam or legitimate. AI is used here in several ways. First, they use AI to create datasets to train a model to assess whether a review is spam or a good/bad review. They use AI to generate datasets based on LinkedIn. From what I’ve read, they use techniques like Zero-shot and Few-shot learning to create these datasets. They use some models from Hugging Face and then classify the reviews as good or bad. This is one use case where AI is applied in text editing.

54:18 Now onto the second use case—they use the Clip Model. The Clip Model primarily processes images. What does that mean? It means that based on reviews… wait a minute, let me find the reference… Ah, Clip processes two things: one is the caption of the image, and the other is the image itself. Through Clip, it can understand the context of the image. Yelp uses Clip for tasks such as when someone goes into a restaurant or pub and posts reviews or captures images of the place. For example, before applying Clip, it couldn’t identify if there were waffles in a dish; it could only identify fried chicken. After applying Clip, it can now recognize both fried chicken and waffles. Essentially, it uses Clip as part of AI to process images, captions, and convert images into vectors to compare them. So, these are the two use cases for Yelp.

55:38 These two use cases are applied in situations where you have many reviews, and you can summarize them into a highlight review. Based on the information converted into vectors, it can annotate what the images are conveying, and what they are supporting. Just give it a moment, it will highlight it for you. It understands the context of the image and can annotate it accordingly. This is the use case for how AI is used in image summarization.

56:15 Earlier this year, Yelp released the Yelp Assistant. Based on their existing platform, they were able to create a chatbot that reviews highlights like this. You simply ask, and it recommends something for you. It’s as simple as that. Additionally, I noticed a use case from 2020 when the trend of short review clips started becoming popular. Yelp had a dataset specifically for that purpose. They mentioned that they are about to release something, as Tom referred to, that can convert text to speech. Based on the review dataset, they might support creating short video clips to describe a restaurant.

57:45 Based on reviews or videos posted by people, Yelp could generate a script and run it through AI to automatically create a video about a restaurant. That’s the use case. It’s simple as that. Ok, going back to the first question, this use case is essentially using AI to label data, right?

58:35 Ok, so it checks whether the comment is negative or positive, right? That’s one example. The second one is using the Clip Model, correct? It’s similar to Vision but more live, also for labeling, right? Like with Plot, labeling for images. So, these two use cases are applied for what?

59:18 I think there’s an interesting point that hasn’t been mentioned yet, which is the story about having a ready-made dataset. For instance, when someone leaves a review or gives a rating, based on these short clips, Yelp could generate an intro video for the restaurant. It uses AI for that. I think they use AI to write the script and then pass that script to an AI voice to narrate. But where do they get the images from? How do they get the video content?

59:57 From the review, when someone comes to review, they will have a video to review. Ok, so it’s automatically generating an advertisement, right? Yes, for TikTok or similar platforms, summarizing user reviews. Sounds pretty creative. Yeah, I guess you guys have confirmed what Bảo mentioned, right?

01:00:07 Yeah, this one is about the caption, and it’s mostly correct. You’re right, I think the initial purpose of this use case was for recommendation. Before they had AI, they already had a hybrid recommendation model in place. Basically… I think with this new AI, they will likely replace the old model. One interesting point that wasn’t mentioned much is business messaging. I think it’s based on, say, the top 50 reviews or top 50 interactions—how are the ratings, and if the reviews are good and the ratings are good, then the business messaging will also be good. But Yelp didn’t bring up this topic, and we can’t blame them for that.

01:00:51 Does anyone have any questions for Đạt? This is his first presentation. Đạt mentioned he’s working on adding more, probably for enterprise too. But I’ve seen Viettel, FPT, and VNG, and I’m still not sure how they are doing things. Đạt said some of FPT’s coding tools are kind of lame.

01:01:41 Haha, is it just a continuation of a previous version? Yeah, it’s not great. It’s a bit rough and underdeveloped. Are we done with that? I guess so. Ok, Đạt. Today we’ve covered Yelp and Tech Linh, so maybe next week or the week after that, if time permits.

01:02:01 Let’s do a demo real quick, Đạt. Could you demo something for us? What about a bot that can handle questions or understand short code from a developer’s perspective? Or something like an auditor checking the code quality? Could you demo the workflow or the bot you’re working on with that diff you mentioned? Please turn on the screen, Đạt.

01:03:01 So this is a project I’m working on for joining the AI Club. I’m pretty new at this, so if the project looks rough, please bear with me. The basic workflow is that I take a query and extract the URL of a repository. Here, I reused Tom’s scraper, but it didn’t fully meet my needs, so I created my own local scraper to fetch all the content from the repo. However, that takes too long and generates too much data. As of now, I haven’t found a way to add it to the context unless I use knowledge retrieval. But to use knowledge retrieval, I have to prepare it in advance; I can’t select the repo directly.

01:05:45 Tom’s scraper doesn’t capture the content of the files, so I haven’t been able to draw a diagram yet. I might use it for the diagram later, I’ll test it out. This scraper only fetches the content from the root directory and some doc files. Those files might not answer Huy’s question accurately. Let me try it; I have my full setup ready offline. The content is already prepared, not online. This was generated directly, so it doesn’t have it either.

01:07:07 This scraper fetches the full content, so it’s more complete. Let me try asking questions like Huy’s or Hoàng’s. Let’s try BC chat and ask a question there. Do you have it? Ah no. Maybe the context is too large, and I haven’t figured out how to integrate it properly into the knowledge retrieval part.

01:09:19 The retrieval process is very optimized. This text file has tens of thousands of lines, tens of thousands! Let’s open it and see. Are you using a mini machine? Try switching to a more powerful machine to see if it runs better. The mini machine is a bit weak. Two million words… how is it even handling that? I think you’d need a dedicated server to run it efficiently. I’m curious how it’s even running; we’re talking about 29U words, as we saw. Multiply that by 4, and the number is huge. The size… Let’s follow up and see. Ok, so you’re working directly from the context, right? You’re querying like a typical query vb, rather than feeding all the data into the context.

01:10:57 Right, exactly. I’m not sure how the retrieval in this diffy system works. I don’t know if it’s retrieving the correct data or if it’s retrieving at all. I haven’t been able to trace it, but I have a tracing tool that I can test later to see how it works. But the idea is that if the retrieval works like this, it probably won’t give accurate results. You’re unsure about how much data it’s running, right? It seems to only prefer 2-300 items, and that’s not enough data for these kinds of tasks. This requires at least several hundred data points. So yeah, this is still a work in progress.

01:11:35 Just joking—there’s always the AI Club at the company! Oh, so is this the full version, or is it the fixed one? If it’s fixed, demo it for us in the office, and try to leave it for me. OK, let me see. It still hasn’t built, so people are just watching for now. The build seems to have some issues—can everyone see the screen?

01:13:08 So, this week, as I mentioned last week, I will upload the sync.Map article. I think it’s really useful, with details that give people using Go a general overview of maps. Regarding sync.Map, let’s first go over the context. When writing maps, especially concurrent maps or concurrent operations, before version 1.16, it wouldn’t show any errors, but it wasn’t safe either. From version 1.16 onward, it throws an error like this. So to solve this issue, people usually write maps with a sync package, like using manual sync.RWMutex.

01:13:56 Besides that, there’s another option called sync.Map. Later, I’ll explain why this option exists and what its use case is. This sync.Map was created so that you don’t have to worry much about using mutexes to lock data for synchronization. You just use it. It’s as simple as this, and it’s friendly—just like using a map to check values. For example, when you load a key with a value, if it’s available, it returns true; otherwise, it returns false, just like a regular map.

01:14:38 Additionally, it has several handy functions. For example, version 12.23 has clear to clear everything, load to get a value, store to update or store a key, and so on. Besides writing concurrently, when you range (loop) over a map, race conditions can also occur. However, with sync.Map’s range function, it handles that, so you don’t have to worry about it. It doesn’t behave like a typical range function. However, it doesn’t give you a fully consistent snapshot. When you first enter, the snapshot may not be updated. So, during this, you have to change your writing method, but at least it won’t error like this.

01:16:06 Now, let’s go over how it works. When you write and define the map, it’s structured with two maps. At this point, you might be thinking, “Wow, this sounds like it’s heavy on RAM and memory!” There’s a Read-Only map and a Dirty map. From this, you can infer that values, when written, will be updated in the Dirty map. It just keeps updating there, while the Read-Only map.

01:16:46 The Read-Only map will always be used when you’re reading. Meanwhile, the writes will always be made to the Dirty map. As for the underlying flow, we’ll look at the chart in a moment to better understand it. Both of these maps have a common point: they both use a pointer called an entry. Pay attention to this part to make the flow easier to follow. For example, when you add a new entry, it will be added to the Dirty map, and both will point to this entry. This works as a flag that indicates the map has been changed. So, at this point, the Read-Only map is no longer the most up-to-date version. The system will know that the Dirty map is the one to read from.

01:17:27 This diagram shows that, for example, when you update a value, since it’s using a pointer underneath, you only need to update the pointer itself, not each value as you would in a traditional map. To achieve this, the system implements a mechanism that defines three states for the entry pointer. The first state is the normal state, meaning that the old values in the map are still intact and can be used, without any issues. The second state is amended, meaning that the entry has been modified. And the third state is the delete state, where an entry has been deleted from the map, but it hasn’t been completely removed. It’s still held in a transitional state, and the entry pointer is moved to a new position, but it hasn’t been fully removed yet.

01:18:59 The pointer entry is assigned to the new entry, but it hasn’t been removed yet. The expired state refers to complete deletion, like a hard delete, meaning the entry is completely removed from the map. To help visualize this, you can refer to this flow: for example, at the beginning, the map has a key1 and value1, and at this point, the Dirty map has nothing, meaning nothing has been added or changed yet. Then, if you add a key2, it will be added to the Dirty map, and at this point, the map is marked as amended because a flag indicating amended is set here.

01:19:40 Afterward, when you delete a key, the map will be assigned a new entry, right? The same thing happens on the other side, as it is also assigned a new entry, similar to the previous diagram. In essence, you’re only updating the pointer without having to update the values themselves. Then, after completing the deletion, to promote the Dirty map, you must update it through the Read Only map so that the Dirty map returns to a new state, like resetting it to the original state.

01:20:18 Similarly, when adding a new key3, after the state has returned to the new state, and you add key3, the system identifies that the previous entry has been deleted entirely. This means that next time when it compares with the Dirty map, it knows that the value1 has been deleted and no longer exists. At this point, the Read Only map will only contain key2 and key3.

01:20:51 Due to this, sync.Map does not have a len function for users to utilize. This is because, if you used the len function here, it would not account for the actual values, as it would count even those that have been expired or deleted. As you can see, because sync.Map is structured this way, its use case is recommended for scenarios that require more reading (read) than writing (write). If you perform a lot of write or delete operations, just imagine the pointer being used continuously, and there’s even an issue reported by the Go team that this map is never garbage collected.

01:21:36 Later, the Go team confirmed that this sync.Map was designed primarily to support some of the internal Go Library processes. If you find it handy because of its user-friendly functions, you can use it, but for use cases that involve storing (store), updating, or deleting often, it’s not recommended, as it may slow down the system.

01:22:24 That’s about it. I’ve written some code based on this topic, and there’s a blogger who shares detailed posts on this subject, so you might want to follow them. Oh, what’s the topic, Phát? Show me the post again. Ah, sync.Map, right? Sync.Map. Does it differ from what you just passed in? What’s different? I think it does. The point is that I remember, depending on the community, people might have different use cases. For instance, if someone wants to implement something specific, they can adapt it as needed.

01:23:30 You can see that some people add an extra layer on top for their own use cases. For example, some want to implement generics on sync.Map. This is partly because of the linking issue I mentioned earlier, where the map isn’t garbage collected. That’s the problem. The Go team has already confirmed that this behavior is intentional, and they won’t fix it. They’re not going to change it, right? So now, what the community does is figure out how to work around it. They like how easy sync.Map is to use, with those nice functions, so they just add another layer to customize it further, making it usable for their specific needs.

01:24:07 Why are we discussing this old clip now? Oh, it’s just an insight for people to use. This use case can be applied to enterprise environments too. For example, in enterprise projects, if we use map and need concurrency, typically, people would write a custom struct, add a mutex, and then write everything themselves. But sync.Map is handy, as I showed earlier, with functions that follow certain standards. If you want to load, you have to call a specific function, and everything is structured that way, making it more reliable.

01:24:50 People usually write a custom struct, then add a mutex, and start writing all the necessary logic themselves. Meanwhile, sync.Map is really handy. As I showed you earlier, it has several functions that adhere to a specific standard. If you want to load, you must call a specific function. This structure ensures consistency. However, you still need to be aware of the trade-offs when using sync.Map, making sure to apply it correctly in the right context. Right, so you have to understand the proper workflow and map usage.

01:25:26 Phát: Yes, about Map. Ok, thanks, Phát. Now, let’s quickly get through a few things. Thành, I need about 10 more minutes from the team. It’ll take a bit more time because I’ve received a total of 11 submissions for the test. Not many have attached images, so some of you can review them. Our deadline is set for the 20th, which is next week. I think earlier, I mentioned the 27th, or was it 26th or 27th? Anyway, that’s the deadline. So, please review everything this week and get the submissions ready. This test is important because the market is shifting significantly, and there’s a big change in the demand for software roles.

01:26:15 Of course, the demand is still there, but the volume has decreased. That’s why I refer to it as a shift in the market demand, similar to what happened around 2014, where it’s like things are changing all over again. New technology is coming out, new opportunities, new markets, and emerging potentials. So, this test will be essential in helping us assess, especially when it comes to team culture. We’re taking this opportunity to evaluate the team, particularly to see how the research study team and the consulting team are becoming more distinct.

01:27:36 There’s a clear distinction between the two teams now. Like I mentioned in the post on Notion about two weeks ago, this distinction is becoming more pronounced. In the future, there will be more specific policies related to different benefits between these two teams. But for now, as you can see, OGIF is gradually becoming a session where we report on all the studies that the team has been reviewing and reporting back on. Some of those reports might be added later, and you can see that some team members have been picking up new knowledge and sharing it.

01:27:36 Gradually, it’s becoming clearer that we want this differentiation to become more distinct over time. And there will be clear policies around this. So, those who enjoy diving deep into topics and taking them to the level of MVP, or applying them in actual projects, or going deeper into knowledge, they will get different benefits. Those who don’t necessarily want to focus on study-related topics can continue working on projects as usual, but there will be other issues involved, which I’ve listed in the Notion link from two weeks ago. Everyone should review that link to understand the direction we’re going in. This test is designed to assess how well you can keep up with new knowledge and how aligned you are with the culture during this time of significant changes.

01:29:20 Because of these goals, I’ll be the only one grading this test. None of the other team members will be grading. Everyone has to do it, and I’ve set the standard for this. So, the important thing is that everyone does the test themselves. Even if the quality isn’t the best, it’s fine. I’ll just give it a lower score, but as long as it’s completed, you’ll pass. The immediate outcome I see from this is that I’ll group the results into two clusters.

The Foundation team and the Lab team, they’re still the core teams we’ve had for the past eight or nine years. This is the main announcement. If you’ve finished your test and feel like you can improve based on what I’ve just said, the Foundation team and the Lab team will still be prioritized in various aspects. So, if you feel like you did the test carelessly, please take some time to do it thoroughly. Focus on two things: the culture aspect and the knowledge.

01:29:56 The immediate result you’ll see is that I’ll group the results into two clusters. The Foundation team and the Lab team will remain the core of our team from now until the next eight or nine years. That’s the main announcement. Out of these 11 submissions, if anyone feels they can improve after hearing what I’ve said, please focus on making it better, especially since the Foundation and Lab teams will be prioritized more in different areas. So, if you feel like you’ve done it hastily, take the time to refine it. Check two things: the culture aspect and the latest, hottest topic cluster, which right now is LLM.

But in reality, our team still covers many different areas. We still have people focusing on design, and others still working on Go, right? Blockchain might have moved a bit out of the spotlight, and the market is going sideways, but consulting still demands a lot of expertise in those areas.

01:31:46 Regarding mini apps for Telegram, they quickly clone them, and now the business logic (BL) and tech (TCH) approaches have shifted a bit from the early days. But for consulting, we can still use them as usual, or we can view them from a different angle, where they become a new asset class. As developers, we should look at how these affect our workflow and how we manage assets.

01:32:29 That’s the matter concerning the test. Pay attention to that. Second, as mentioned earlier, regarding team direction and numbers, I mentioned the Notion link I sent earlier. The Foundation team, which started over again, initially had just three people, and then gradually it grew to four, then five. We added Quan, Hiếu, and others. Initially, it was just three of us, but now the team is much stronger. With 40 people, all highly skilled, we’ll certainly move faster. That’s the general overview, so everyone should be aware of the current situation.

01:33:12 Third, Huy Nguyễn, once you’re done, next week please take a look at the ICY numbers. Earlier, you mentioned the numbers were starting to grow, so we’ll need to review and balance those out. For this task, Huy and Thành, please take charge and ensure it’s handled properly. Thành also has an additional task, which is to review benefits for the Lab team members and propose something. It could be considered as a payon, but it won’t go through the normal channels, as there will be a different mechanism for this.

01:33:52 But the Lab team members will have that, and everyone’s familiar with it. Lastly, regarding the LLM, in the current question list, there’s an important question about how to use LLM externally and how to adapt it. Emphasize that question, as it’s about knowledge discovery. The test question is not only about using it but about all the tools our team currently uses. When some people use them effectively and others less so, it creates a very clear spectrum—those who are weaker remain weaker, and those who are stronger stand out much more.

01:34:38 We want to raise the standard. We want to shorten that spectrum, to make it as compact as possible. Right now, the gap is too wide. Beyond using tools for discovery, this question also asks us to look at how our field of work can apply these tools to elevate our competencies and make us more productive. That’s the whole issue, so everyone should confirm whether what they’ve done is correct or not. It has a deeper meaning than it seems.

01:35:20 Lastly, to wrap up today’s session, Thành, for the next OGIF meetings, apart from diving deeper into use cases, there are things Tom has done related to building the structure of an LLM app. We could take that and analyze it. Let’s break it down and dive deeper into it.

01:35:56 Hopefully, everyone passes the test so we can all have a good time. Next week, there will be another test. Next week, Minh L., can you do a demo? Continue with the finite state machine, FSM. As part of our focus on foundational technologies like blockchain and AI, the key point is that engineers will have a different path forward. The goal is to understand how large systems operate. In the future, if you’re not the one handling data manipulation—AI will do that for us, we won’t need to design things ourselves or do junior-level tasks anymore.

01:37:35 The only way to become senior is to understand the issues and work on architecture. The finite state machine plays an important role, especially in scaling, something we’ve talked about a lot. Minh has read through it and understood the direction we’re aiming for. So, we need to do a comparison between the types of general servers it covers. State machine-based servers versus event-based servers. Then create a sample to show how it’s modeled, implemented using Erlang. Erlang already has the frameworks for it.

01:39:01 This topic will proceed when Minh Lưu is ready. If it’s not next week, it could be in two weeks. I suggest that the backend team and the senior team gather together, and if there’s anything, confirm it beforehand. This topic is critical for software analysis and design. It’s a very important session. Up until now, we’ve only talked about modeling and doing C4 diagrams, but Erlang is the language that goes deepest into this area. Most people don’t know it entirely. We don’t necessarily need to learn Erlang, but we can look at how they design and build systems to handle this area properly, as they already have frameworks available. We just need to plug them in and use them.

01:39:37 Speaking of which, October 20th is a Sunday, and Mỹ, Ngọc, and Giang have already posted about it. The ladies are going out on that day, and for those not in Saigon, the team representatives will wish everyone prosperity. It seems like wishing prosperity is the most appropriate thing to say in this situation. Any other wishes might not fit as well. Alright, so if anyone wants to join, register with Mỹ to book a table and plan accordingly.

01:41:19 Thành, in the upcoming meetings, structure things into talks. Then set the goal for that. Our team now has a Builder Club as well. I’ll look into how the team members who used to work on Super Bit and console are stabilizing things, and I’ll restructure afterward. This time, it seems like we’ve had a good rest. Alright, does anyone have any questions about the test? If not, we’ll wrap up here. Alright, goodbye everyone, see you next week. Thanks, Thành, and thanks to everyone.