Xây dựng công ty AI-Native

xguru · 2024-07-01T11:22:02+09:00

Vào đầu thập niên 2020, sự chú ý đổ dồn rất nhiều vào AI tạo sinh Thảo luận chủ yếu xoay quanh việc các công cụ AI tạo sinh sẽ định hình chúng ta như thế nào, cũng như chúng sẽ ảnh hưởng ra sao đến cách viết lách, lập trình, làm hoạt hình và tiêu thụ thông tin Tuy nhiên, lại không có nhiều đề cập đến hình hài của chính các công cụ đó Vào cuối những năm 1960, các hệ thống thông tin phải đối mặt với vấn đề chi phí tìm kiếm thông tin liên quan ngày càng cao do khối lượng dữ liệu khổng lồ Trong thập niên 1980 và 1990, cơ sở dữ liệu quan hệ trở thành giải pháp thống trị Chúng cung cấp cơ chế lập chỉ mục trực quan và bảo đảm hiệu quả truy vấn Cơ sở dữ liệu quan hệ cho phép biểu diễn dữ liệu dưới dạng tập hợp các bảng có quan hệ có cấu trúc Chúng cho phép truy xuất dữ liệu nhanh hơn thông qua các ngôn ngữ truy vấn như SQL Trong quá trình kiến trúc cơ sở dữ liệu phát triển, một số công ty như IBM, Oracle, Sun Microsystems, MongoDB đã củng cố vị thế của mình ở từng thị trường mới nổi Dù Oracle dẫn đầu thế giới cơ sở dữ liệu quan hệ, cách con người lưu trữ và truy cập thông tin vẫn tiếp tục thay đổi Mỗi khi xuất hiện một loại công việc mới, con người lại nghĩ ra một kiến trúc mới để quản lý nó Sự tiến hóa gần đây của cơ sở dữ liệu bắt nguồn từ nhu cầu xử lý dữ liệu phi cấu trúc Trong hơn 50 năm qua, schema chủ yếu được xây dựng xoay quanh các quan hệ dữ liệu có cấu trúc Nhưng ngày càng nhiều người cần những công cụ có thể xử lý sự mơ hồ của dữ liệu tốt hơn nhiều Vì thế, cơ sở dữ liệu vector đã xuất hiện Các mô hình ngôn ngữ lớn (LLM) dựa trên transformer như GPT có thể nắm bắt các phụ thuộc dài hạn trong văn bản Tuy nhiên, việc duy trì khả năng hiểu văn bản dài có thể rất tốn kém về mặt tính toán Cơ sở dữ liệu vector có thể mở rộng cửa sổ ngữ cảnh của các mô hình này Dù cơ sở dữ liệu vector có thể rất mạnh trong các use case AI, chúng vẫn là hạ tầng ngốc chỉ vận hành dựa trên đầu vào và đầu ra Chúng thiếu khả năng hiểu hoặc diễn giải dữ liệu Chúng chỉ đóng vai trò như kho lưu trữ đơn thuần, lưu và truy xuất dữ liệu theo chỉ thị, chứ không có trí tuệ nội tại hay nhận thức ngữ cảnh Việc GPT-3 ra mắt vào năm 2020 đã mở đường để AI ngày càng được dùng như một thành phần cốt lõi thay vì chỉ là phần phụ trong sản phẩm doanh nghiệp Kiến trúc transformer, lượng dữ liệu tăng lên và hiệu năng được cải thiện đã đặt nền móng cho việc phát triển các sản phẩm dựa trên AI Khi số lượng công ty AI-Native (dựa trên AI) tăng lên và quy mô mở rộng, nhu cầu về các công cụ hỗ trợ use case dựa trên AI cũng gia tăng Làn sóng đầu tiên của các công ty cốt lõi về AI chủ yếu tập trung vào suy luận bằng các mô hình hiện có Tuy nhiên, nhờ các mô hình có hiệu năng cao hơn, đặc biệt là các mô hình mã nguồn mở dễ tiếp cận, doanh nghiệp có thể xây dựng năng lực sâu hơn như một doanh nghiệp dựa trên AI Khả năng mở rộng này đang mở ra cả một thế giới cơ hội về diện mạo của một AI-native tech stack Những công cụ định hình chúng ta (The Tools that Shape Us) Năm 1967, John M. Culkin, bạn của Marshall McLuhan, từng nói: "Chúng ta tạo ra công cụ, rồi sau đó công cụ tạo ra chúng ta" Việc xây dựng công nghệ cũng không khác gì Hạ tầng chúng ta dùng để xây dựng phần mềm đã liên tục tiến hóa để phù hợp với nhu cầu phát triển, và rồi chính cách chúng ta xây dựng lại bị định hình bởi hạ tầng mà mình dựng lên Vào đầu thập niên 2020, sự chú ý đổ dồn rất nhiều vào AI tạo sinh Đặc biệt, trọng tâm đặt vào các đầu ra như văn bản hoặc mã được tạo ra, hình ảnh được render, deepfake được sản xuất, hay âm nhạc được tổng hợp Thảo luận chủ yếu xoay quanh việc các công cụ này sẽ định hình chúng ta như thế nào, cũng như chúng sẽ ảnh hưởng ra sao đến cách viết lách, lập trình, làm hoạt hình và tiêu thụ thông tin Mọi người tranh luận về hiệu năng tương đối giữa các mô hình ngôn ngữ lớn mở và độc quyền, rủi ro hallucination, tranh luận platform so với feature, cũng như tranh luận giữa các công ty hiện hữu và startup Tuy nhiên, lại không có nhiều đề cập đến hình hài của chính các công cụ đó Về căn bản, cách chúng ta xây dựng công nghệ từ trước đến nay luôn bị định hình bởi hạ tầng được chuẩn bị cho việc xây dựng đó Sự phổ biến của SaaS được Internet thúc đẩy, phát triển di động trở nên khả thi nhờ smartphone phổ cập, và khả năng mở rộng của các thế hệ ứng dụng được đẩy mạnh bởi điện toán đám mây Mức độ phổ biến của AI trong ứng dụng phụ thuộc vào năng lực tính toán, khả năng của mô hình, và cách các mô hình đó được điều phối trong các use case kinh doanh Bài viết này sẽ tập trung vào yếu tố điều phối Một trong những yếu tố cốt lõi để điều phối mọi use case AI là cơ sở dữ liệu của doanh nghiệp Nơi dữ liệu được lưu trữ, thao tác và gọi ra là một phần quan trọng của bài toán Nhưng như sẽ thấy, lịch sử của cơ sở dữ liệu phần lớn là lịch sử của hạ tầng ngốc Để tối đa hóa tính hữu dụng của AI, chúng ta sẽ phải tạo ra cơ sở dữ liệu sao cho nó trở thành một phần của phương trình tạo sinh Nền tảng cho dữ liệu (A Base For Data) Vào tháng 5 năm 1959, CODASYL (Conference on Data Systems Languages) lần đầu được triệu tập với mục tiêu xây dựng một "ngôn ngữ đa dụng để xây dựng các ứng dụng kinh doanh" Vào cuối những năm 1960, các hệ thống thông tin phải đối mặt với vấn đề chi phí tìm kiếm thông tin liên quan ngày càng tăng do khối lượng dữ liệu khổng lồ Việc sử dụng máy tính mainframe nhìn chung đã dẫn đến chi phí MIPS (triệu lệnh mỗi giây) tăng lên khi mức độ tận dụng mainframe tăng cao, do các chi phí nâng cấp cần thiết cho bảo trì ứng dụng, vá lỗi và duy trì hiệu năng Do sự phức tạp của quản lý cơ sở dữ liệu, cấu trúc phân cấp cứng nhắc và việc ánh xạ cấu trúc điều hướng phức tạp, doanh nghiệp thường cần chuyên môn kỹ thuật để truy cập thông tin đã chọn, thậm chí một số nhà phát triển còn phải viết cả chương trình chỉ để truy cập thông tin liên quan Năm 1970, E.F. Codd công bố "A Relational Model of Data for Large Shared Data Banks", đề xuất một mô hình trong đó các bảng có thể được liên kết thông qua các thuộc tính chung (tức khóa chính để định danh bản ghi duy nhất và khóa ngoại để thiết lập quan hệ giữa các bảng) Điều này cho phép truy xuất dữ liệu từ các bảng không đồng nhất chỉ với một truy vấn duy nhất Cơ sở dữ liệu quan hệ của Codd dựa trên mối quan hệ giữa các mục dữ liệu, cho phép linh hoạt trong thao tác và sử dụng dữ liệu Năm 1973, một nhóm lập trình viên tại IBM San Jose Research Laboratory bắt tay vào dự án System R, chứng minh rằng hệ thống cơ sở dữ liệu quan hệ có thể tích hợp đầy đủ các tính năng cần thiết cho sử dụng trong môi trường production mà vẫn đạt hiệu năng cao Nhóm này đã phát triển một trình tối ưu hóa dựa trên chi phí để nâng cao hiệu quả cơ sở dữ liệu, và các phát triển bắt nguồn từ System R sau đó dẫn tới việc ra mắt SQL/DS, sản phẩm cơ sở dữ liệu quan hệ đầu tiên của IBM Trong những năm 1980 và 1990, cơ sở dữ liệu quan hệ trở thành giải pháp cơ sở dữ liệu thống trị Chúng cung cấp khả năng lập chỉ mục trực quan và đảm bảo hiệu quả truy vấn Cơ sở dữ liệu quan hệ cho phép biểu diễn dữ liệu dưới dạng tập hợp các bảng có quan hệ có cấu trúc Chúng cho phép truy xuất dữ liệu nhanh hơn thông qua các ngôn ngữ truy vấn như SQL Cơ sở dữ liệu quan hệ được xây dựng dựa trên giả định là sẽ chạy trên một máy duy nhất Tuy nhiên, việc Internet được áp dụng rộng rãi trong thập niên 1990 và 2000 đã tạo ra lượng dữ liệu đổ vào khổng lồ, dẫn tới khối lượng công việc vượt quá khả năng xử lý của một máy tính đơn lẻ Các cơ sở dữ liệu SQL truyền thống được thiết kế để chạy trên một máy chủ duy nhất, và người dùng phải mở rộng phần cứng vật lý theo nhu cầu lưu trữ, điều này trở nên rất tốn kém đối với các doanh nghiệp vận hành workload lớn hơn Trong thập niên 2010, dữ liệu và số lượng người dùng cho OLTP (online transaction processing) tăng theo cấp số nhân, dẫn tới sự gia tăng rộng khắp của cơ sở dữ liệu phân tán, data warehouse và OLAP (online analytical processing) Cơ sở dữ liệu quan hệ và SQL không còn phù hợp với quy mô và độ phức tạp ứng dụng cần thiết nữa, và cơ sở dữ liệu NoSQL nổi lên như một phương tiện để tăng hiệu năng (đánh đổi các tính năng ACID) Cơ sở dữ liệu quan hệ có thể lưu trữ và thao tác dữ liệu có cấu trúc, nhưng việc duy trì quan hệ giữa các dữ liệu trở nên khó khăn khi phải xử lý overhead của join và tính đến chi phí của các thao tác CRUD Cơ sở dữ liệu quan hệ phù hợp để xử lý dữ liệu quan hệ với các yêu cầu logic hoặc rời rạc, nhưng nhìn chung lại gắn với các hệ thống legacy được xây dựng riêng cho cấu trúc quan hệ NoSQL xuất hiện như một phương thức xử lý big data phi cấu trúc, cung cấp cho nhà phát triển khả năng lưu trữ bền vững dữ liệu thông qua cách tiếp cận phi quan hệ Thay vì sử dụng SQL làm ngôn ngữ truy vấn mặc định, NoSQL cung cấp truy cập thông qua API, nhờ đó đảm bảo khả năng mở rộng cao hơn, tính toán phân tán, giảm chi phí và tính linh hoạt về schema Các cơ sở dữ liệu NoSQL hoạt động với kiến trúc hiệu quả có thể mở rộng theo chiều ngang, vì vậy để tăng năng lực lưu trữ hoặc tính toán chỉ cần thêm nhiều máy chủ hoặc instance cloud hơn Đối với các doanh nghiệp có workload dữ liệu cần xử lý hoặc phân tích dữ liệu phi cấu trúc nhanh hơn, cơ sở dữ liệu NoSQL được ưu tiên Cuộc chiến cơ sở dữ liệu đời đầu Trong quá trình kiến trúc cơ sở dữ liệu tiến hóa, một số công ty nhất định đã củng cố vị thế ở từng thị trường mới nổi Ngay sau khi IBM phát hành System R, Larry Ellison khi đó 33 tuổi đã đọc chính bài báo của Codd về cơ sở dữ liệu quan hệ Ellison và hai đồng sáng lập đã cố gắng lập một công ty tương thích với System R, nhưng IBM khiến điều đó trở nên rất khó khăn Kết quả là bộ ba này đã xây dựng doanh nghiệp xoay quanh sản phẩm cơ sở dữ liệu chủ lực mới của mình, Oracle Databases Kể từ đó, cơ sở dữ liệu của Oracle đã trở thành sản phẩm dẫn đầu, và tính đến tháng 5 năm 2024 có thị phần khoảng 28,7% Trong vài năm trước đợt IPO năm 1986 của Oracle, một công ty khác đã gia nhập lĩnh vực cơ sở dữ liệu Sun Microsystems khởi đầu vào năm 1982 với việc bán nhiều thành phần máy tính khác nhau, nhưng trở nên nổi tiếng nhờ những đóng góp như ngôn ngữ lập trình Java, Network File System và hơn thế nữa Điều quan trọng là vào năm 2008, Sun Microsystems đã mua lại MySQL, một hệ quản trị cơ sở dữ liệu mã nguồn mở Chỉ 2 năm sau, Oracle đã mua lại Sun Microsystems (bao gồm cả MySQL) Gần 15 năm sau, tính đến tháng 5 năm 2024, các cơ sở dữ liệu dẫn đầu là Oracle (thị phần 28,7%) và MySQL (khoảng 17,3%) Dù Oracle dẫn dắt thế giới cơ sở dữ liệu quan hệ, cách con người lưu trữ và truy cập thông tin vẫn tiếp tục thay đổi Mỗi khi xuất hiện một loại công việc mới, con người lại nghĩ ra một kiến trúc mới để quản lý nó Từ các document store như MongoDB (2007), Databricks (2013) đến các cơ sở dữ liệu chuỗi thời gian như InfluxDB (2013), Prometheus (2012), và các cơ sở dữ liệu đồ thị như Neo4j (2007), Cosmos (2017), danh sách các cơ sở dữ liệu chuyên biệt vẫn đang tiếp tục dài ra Khi mức độ phổ biến của cơ sở dữ liệu quan hệ giảm dần một cách ổn định, nhiều giải pháp khác nhau đã xuất hiện để đáp ứng những nhu cầu ngách mới này Sự tiến hóa mới nhất của cơ sở dữ liệu bắt nguồn từ nhu cầu xử lý dữ liệu phi cấu trúc Trong hơn 50 năm qua, schema chủ yếu được tổ chức xoay quanh các mối quan hệ dữ liệu có cấu trúc Tuy nhiên, ngày càng nhiều người cần những công cụ có thể xử lý sự mơ hồ của dữ liệu tốt hơn nhiều Từ đó, cơ sở dữ liệu vector đã xuất hiện Sự trỗi dậy của cơ sở dữ liệu vector Với sự phổ biến rộng rãi của mô hình ngôn ngữ lớn (LLM) và AI tạo sinh, cơ sở dữ liệu vector đã nổi lên như một công cụ có thể xử lý dữ liệu đa phương thức phi cấu trúc Trong khi các cơ sở dữ liệu quan hệ truyền thống (Postgres, MySQL) phù hợp nhất với schema có cấu trúc, cơ sở dữ liệu vector phù hợp để lưu trữ và truy vấn vector embedding (biểu diễn số của dữ liệu chứa ý nghĩa tương ứng với trọng số của mô hình ngôn ngữ) Thay vì các hàng và cột thường dùng trong cơ sở dữ liệu quan hệ, cơ sở dữ liệu vector biểu diễn dữ liệu dưới dạng các điểm trong không gian đa chiều và khớp dữ liệu dựa trên độ tương tự thay vì giá trị chính xác Tùy theo mô hình embedding, dữ liệu có thể được biểu diễn trong các không gian vector khác nhau và với số chiều khác nhau Vector embedding nắm bắt ý nghĩa của các điểm dữ liệu, cho phép truy xuất các đối tượng tương tự bằng cách tìm các đối tượng gần nhất trong cơ sở dữ liệu vector Ví dụ, Word2Vec ánh xạ từ thành vector để giúp nắm bắt ý nghĩa, độ tương đồng ngữ nghĩa và quan hệ ngữ cảnh với văn bản khác Thuật toán này sử dụng mạng nơ-ron nông để suy ra ý nghĩa của một từ cụ thể từ một kho ngữ liệu văn bản rộng hơn và xác định từ đồng nghĩa thông qua logistic regression Cũng có những phương pháp giúp trích xuất embedding mà không phụ thuộc vào mạng nơ-ron sâu, chẳng hạn như singular value decomposition (SVD) và principal component analysis (PCA) Các thước đo khoảng cách giúp xác định "khoảng cách" tương đối giữa các điểm trong không gian vector; các phương pháp phổ biến gồm có khoảng cách Euclid, khoảng cách Manhattan, khoảng cách cosine và độ tương tự Jaccard K-nearest neighbors (KNN) và approximate nearest neighbors (ANN) giúp đơn giản hóa tìm kiếm tương tự cho hình ảnh, video hoặc các đầu vào đa phương thức khác, đồng thời cải thiện thời gian chạy Các cơ sở dữ liệu chuyên cho vector như Weaviate, Chroma, Qdrant và Pinecone giúp nhà phát triển xử lý dữ liệu ở quy mô lớn, đặc biệt là trong việc hỗ trợ tìm kiếm trên đầu vào phi cấu trúc Không giống cơ sở dữ liệu quan hệ hay NoSQL truyền thống, cơ sở dữ liệu vector được thiết kế riêng để xử lý vector embedding Trong khi cơ sở dữ liệu truyền thống lưu dữ liệu dưới dạng scalar, cơ sở dữ liệu vector chỉ lưu vector và tận dụng các kỹ thuật lập chỉ mục như lượng tử hóa và phân cụm để tối ưu hóa tác vụ truy xuất Các LLM dựa trên transformer như GPT có thể nắm bắt các phụ thuộc dài hạn trong văn bản Tuy nhiên, việc duy trì khả năng hiểu văn bản dài có thể rất tốn kém về mặt tính toán Các LLM hiện đại có thể nắm bắt phụ thuộc toàn cục giữa các cặp token trên toàn bộ đầu vào, nhưng độ phức tạp về thời gian và không gian gây ra vấn đề về tài nguyên tính toán, từ đó giới hạn độ dài văn bản đầu vào trong quá trình huấn luyện và cửa sổ ngữ cảnh hiệu quả trong suy luận Với các trường hợp đa chiều, mã hóa vị trí tương đối khó triển khai và phần lớn các cách tiếp cận mã hóa vị trí tương đối đòi hỏi cơ chế embedding vị trí mạnh, điều này góp phần làm suy giảm hiệu năng trong quá trình suy luận Ngay cả khi độ dài văn bản tăng lên, cơ sở dữ liệu vector vẫn có thể đóng vai trò quan trọng như bộ nhớ dài hạn của mô hình Sử dụng cơ sở dữ liệu vector có thể đơn giản hóa các tác vụ như hoàn tất văn bản hoặc tóm tắt, nơi toàn bộ ngữ cảnh câu có thể cần thiết để tạo ra kết quả chính xác Cơ sở dữ liệu vector có thể hỗ trợ retrieval-augmented generation (RAG), trong đó cơ sở dữ liệu vector có thể được dùng để tăng cường prompt được gửi tới LLM bằng cách bổ sung thêm ngữ cảnh cùng với truy vấn gốc LLM thường dựa vào mô hình tự giám sát, nên nhiều khi gặp khó khăn với các tác vụ đặc thù theo miền yêu cầu kiến thức chuyên biệt hoặc ngưỡng độ chính xác cao hơn RAG có thể giúp kiểm chứng, theo dõi hoặc giải thích cách một câu trả lời được suy ra, đồng thời giảm thiểu hiện tượng hallucination có thể phát sinh do thiếu ngữ cảnh cho truy vấn đang xét Nhà phát triển có thể kết hợp knowledge graph và tìm kiếm vector để mở rộng LLM vượt ra ngoài dữ liệu mà nó đã được huấn luyện Các công cụ như GraphRAG của Microsoft Research hỗ trợ tăng cường prompt khi thực hiện truy xuất trên các tập dữ liệu riêng tư RAG cơ bản thường gặp khó khăn trong việc hiểu một cách tổng thể các khái niệm ngữ nghĩa đã được tóm lược trên các bộ sưu tập dữ liệu lớn, vì vậy các công cụ như LlamaIndex và GraphRAG xây dựng knowledge graph dựa trên các tập dữ liệu riêng tư Tùy theo yêu cầu cụ thể hoặc trường hợp sử dụng, nhà phát triển có thể thấy dùng knowledge graph phù hợp hơn RAG Cơ sở dữ liệu vector phù hợp cho tìm kiếm tương tự và thích hợp nhất cho truy xuất tài liệu hoặc hình ảnh, cũng như tạo gợi ý, trong khi knowledge graph phù hợp cho suy luận (đặc biệt hữu ích khi thu thập dữ liệu, trích xuất thực thể cùng các quan hệ liên kết với nhau, và duyệt qua các quan hệ đó) Với các ứng dụng cần xử lý dữ liệu theo thời gian thực hoặc gần thời gian thực, cơ sở dữ liệu vector có thể được ưu tiên nhờ truy vấn có độ trễ thấp hơn Bằng cách thu thập và lưu trữ embedding, cơ sở dữ liệu vector hỗ trợ truy xuất nhanh hơn cho tìm kiếm tương tự bằng cách đối sánh prompt đầu vào với các embedding tương tự Xếp hạng độ tương tự giúp hỗ trợ nhiều tác vụ machine learning, từ hệ thống gợi ý, tìm kiếm ngữ nghĩa, nhận dạng hình ảnh cho đến các ứng dụng xử lý ngôn ngữ tự nhiên khác Cơ sở dữ liệu vector đóng vai trò quan trọng trong việc cải thiện hiệu năng của LLM bằng cách cho phép lưu trữ và truy xuất vector embedding hiệu quả Điều này cho phép tự động hiểu ngôn ngữ tự nhiên ở quy mô lớn Tuy nhiên, vector embedding đại diện cho đổi mới N+1 Đây là các định dạng dữ liệu trước đó như dữ liệu quan hệ hoặc dữ liệu chuỗi thời gian Các nhà cung cấp cơ sở dữ liệu legacy đã bắt đầu ra mắt các tính năng vector như Atlas Vector Search của MongoDB, cơ sở dữ liệu vector của SingleStore và chỉ mục tìm kiếm vector của Neo4J Mặc dù cơ sở dữ liệu vector có thể mạnh mẽ trong các trường hợp sử dụng AI, về bản chất nó vẫn là hạ tầng thụ động vận hành theo đầu vào và đầu ra Nó thiếu khả năng hiểu hoặc diễn giải dữ liệu Nó chỉ đóng vai trò như một kho lưu trữ và truy xuất dữ liệu theo chỉ dẫn, chứ không có trí thông minh nội tại hay nhận thức ngữ cảnh Đối với các ứng dụng AI hiện đại, chỉ như vậy sẽ không còn đủ Doanh nghiệp ngày càng xây dựng xoay quanh AI model như thành phần cốt lõi Vì vậy, nếu ứng dụng ngày càng thể hiện các năng lực thông minh hơn, hạ tầng cũng sẽ cần những năng lực thông minh tương tự Các công ty AI-Native thế hệ thứ nhất Kể từ khi giới học thuật lần đầu bắt đầu nghiên cứu trí tuệ nhân tạo tại Đại học Dartmouth vào năm 1956, các trường hợp sử dụng thực tiễn đã thúc đẩy lĩnh vực này phát triển Ví dụ, vào cuối những năm 1960, Joseph Weizenbaum đã tạo ra một chương trình máy tính tên là ELIZA, trong đó một cách tiếp cận đơn giản mô phỏng hội thoại bằng đối sánh mẫu đã được dùng cho các cuộc trò chuyện tương tự trị liệu ở mức sơ khai (chatbot đầu tiên) Trong phần lớn lịch sử ứng dụng AI vào các trường hợp sử dụng kinh doanh, những cải tiến của AI diễn ra theo hướng tiệm tiến Trước khi thuật ngữ AI trở nên thịnh hành, thuật ngữ machine learning thường được dùng nhiều hơn để chỉ cùng công nghệ này Tức là, “các thuật toán thống kê có thể học từ dữ liệu và khái quát hóa sang dữ liệu chưa từng thấy, từ đó có thể thực hiện tác vụ mà không cần chỉ dẫn tường minh” Về mặt nhận thức đại chúng, AI đã đạt đến bước ngoặt khi OpenAI ra mắt ChatGPT vào ngày 30 tháng 11 năm 2022, nhưng từ góc độ kỹ thuật, điểm chuyển mình đã diễn ra từ lâu trước đó Tháng 11 năm 2017, tổ chức điều phối quốc tế Financial Stability Board (FSB) đã soạn một bản tổng quan về tác động của machine learning đối với dịch vụ tài chính Các công ty dịch vụ tài chính ngày càng có thể dùng machine learning để thực hiện những tác vụ như “đánh giá chất lượng tín dụng”, qua đó “góp phần tạo ra một hệ thống tài chính hiệu quả hơn” Nói cách khác, nó có thể nâng cao hiệu quả, nhưng chưa cấu thành một yếu tố sống còn mang tính hiện sinh Trong khi đó, machine learning tiếp tục ngày càng tốt hơn, và vào tháng 5 năm 2018, OpenAI đã công bố một nghiên cứu về lịch sử lượng tính toán cần thiết để huấn luyện các mô hình quy mô lớn, cho thấy kể từ năm 2012 con số này đã tăng gấp đôi mỗi 3,4 tháng, tương đương mức tăng 300.000 lần về compute Tháng tiếp theo, vào tháng 6 năm 2018, OpenAI công bố phần giới thiệu đầu tiên về mô hình GPT Một cuộc tranh luận bắt đầu hình thành giữa hai phe Một mặt, nhiều người tin rằng sự tăng trưởng liên tục của các mô hình ngày càng lớn cuối cùng sẽ vấp phải quy luật lợi suất giảm dần Phe còn lại, trong đó có OpenAI, tin rằng hiệu năng sẽ tiếp tục cải thiện khi quy mô tăng lên Tháng 1 năm 2020, Jared Kaplan, nhà nghiên cứu của OpenAI đồng thời là giáo sư tại Đại học Johns Hopkins, cùng các cộng sự đã công bố “Scaling Laws for Neural Language Models”, trong đó nêu rõ: “Hiệu năng mô hình hóa ngôn ngữ được cải thiện một cách mượt mà và có thể dự đoán khi quy mô mô hình, dữ liệu và compute được mở rộng một cách phù hợp. Chúng tôi kỳ vọng các mô hình ngôn ngữ lớn hơn sẽ hoạt động tốt hơn và có hiệu quả mẫu cao hơn so với các mô hình hiện tại.” Tháng 5 năm 2020, OpenAI công bố bài báo “Language Models are Few-Shot Learners” về GPT-3, cho thấy hiệu năng mở rộng một cách trơn tru khi compute tăng lên OpenAI cũng phát hiện rằng việc tăng quy mô còn cải thiện khả năng khái quát hóa, và lập luận rằng “việc mở rộng quy mô các mô hình ngôn ngữ lớn cải thiện đáng kể hiệu năng few-shot không phụ thuộc tác vụ, đôi khi có thể cạnh tranh với các phương pháp fine-tuning tiên tiến nhất trước đó” Nhà nghiên cứu độc lập Gwern Branwen đã đặt ra giả thuyết scaling trong một bài blog, và nói rằng: “GPT-3, được OpenAI công bố vào tháng 5 năm 2020, là mạng nơ-ron lớn nhất từng được huấn luyện cho đến thời điểm đó, lớn hơn ít nhất một bậc độ lớn... Trái với kỳ vọng của nhiều người (bao gồm cả tôi), sự gia tăng quy mô khổng lồ này, đúng như OpenAI dự đoán, vẫn tiếp tục cho thấy lợi ích của quy mô và không đụng phải mức lợi suất giảm dần hay lợi nhuận âm như nhiều người từng dự đoán.” Sự ngạc nhiên mà Branwen cảm nhận chính là dấu hiệu của một sự thay đổi cục diện AI không còn chỉ là phần phụ lục của sản phẩm công ty, mà ngày càng có thể được dùng như phần cốt lõi Kiến trúc transformer, lượng dữ liệu gia tăng và mức hiệu năng được cải thiện đều đã đặt nền móng cho việc phát triển sản phẩm dựa trên AI Ngay sau khi GPT-3 ra mắt vào tháng 5 năm 2020, các công ty như Writer và Jasper đã tạo ra các sản phẩm copywriting lấy mô hình AI làm trung tâm của doanh nghiệp Các công ty như Harvey và EvenUp đã xây dựng legal tech xoay quanh AI Các công ty như DeepScribe và Freed đã xây dựng giải pháp phiên âm y tế xoay quanh AI Tuy nhiên, cũng như trong quá khứ khi các trường hợp sử dụng mới dẫn đến sự tiến hóa của cơ sở dữ liệu, sự ra đời của các sản phẩm dựa trên AI đồng nghĩa với việc hạ tầng phía sau stack công nghệ của từng công ty phải thay đổi và thích nghi Cơ sở dữ liệu AI-Native Khi số lượng doanh nghiệp dựa trên AI tăng lên và mở rộng quy mô, nhu cầu về các công cụ hỗ trợ các trường hợp sử dụng dựa trên AI cũng tăng theo Làn sóng đầu tiên của các công ty lấy AI làm cốt lõi chủ yếu tập trung vào suy luận với các mô hình sẵn có Họ có các công cụ workflow chuyên biệt cho ứng dụng, copywriting, phiên âm y tế và các nhu cầu tương tự Cốt lõi của sản phẩm là đầu ra như văn bản hoặc hình ảnh được mô hình tạo ra Sau DevDay của OpenAI vào tháng 11 năm 2023, meme “OpenAI đã giết chết startup của tôi” bắt đầu lan rộng Các GPT chuyên biệt hoặc AI agent cụ thể dường như đảm nhận vai trò của những startup AI đời đầu này vì chúng tập trung vào suy luận từ các mô hình hiện có OpenAI tình cờ trở thành nhà cung cấp cả mô hình lẫn ứng dụng Tốc độ đổi mới xoay quanh năng lực mô hình diễn ra quá nhanh đến mức bắt đầu tạo cảm giác như một mối đe dọa với startup Tuy nhiên, theo chiều ngược lại, các mô hình có hiệu năng cao hơn, đặc biệt là các mô hình mã nguồn mở dễ tiếp cận, lại giúp doanh nghiệp xây dựng năng lực sâu hơn như một doanh nghiệp dựa trên AI Xây dựng một stack công nghệ dựa trên AI không chỉ là thêm các thành phần xung quanh mô hình Ví dụ, một cơ sở dữ liệu được thiết kế riêng cho AI sẽ trông như thế nào? Nếu suy luận là đầu ra quan trọng, thì một cơ sở dữ liệu AI-Native không chỉ phải lưu trữ và truy xuất dữ liệu mà còn phải có khả năng tiếp nhận các chỉ dẫn theo ngữ cảnh về những gì cần làm với dữ liệu đang lưu trữ Một ví dụ có thể là cá nhân hóa mô tả sản phẩm cho thương mại điện tử Một vector database không chỉ lưu vector embedding cho SKU sản phẩm và mô tả, mà còn có thể lưu embedding cho persona người dùng Bằng cách dùng toàn bộ dữ liệu theo ngữ cảnh này trong cơ sở dữ liệu, hạ tầng có thể tận dụng một vòng phản hồi sinh tạo, nơi truy vấn mô tả sản phẩm cũng kích hoạt truy vấn về persona người dùng liên quan, rồi sau đó viết mô tả sản phẩm dựa trên persona phù hợp đó Tương tự, ngôn ngữ cũng có thể được dùng như một vòng phản hồi sinh tạo Ví dụ, người dùng có thể muốn tạo mô tả sản phẩm bằng nhiều ngôn ngữ khác nhau Có thể tạo ra mô tả sản phẩm không chỉ được cá nhân hóa cho người dùng mà còn được dịch sang ngôn ngữ mà người dùng chọn Loại chỉ dẫn này có thể được tích hợp trực tiếp vào cơ sở dữ liệu vì các trường hợp sử dụng như generative AI ngày càng trở thành chức năng trung tâm của ứng dụng Việc phát triển hạ tầng để phù hợp với trường hợp sử dụng không phải là điều mới Ban đầu, các nhà phát triển xây dựng ứng dụng trong trình duyệt bằng JavaScript để khiến website trở nên tương tác và động hơn Nhưng khi các nhà phát triển nhận ra họ có thể đưa điều đó vào backend, node.js đã ra đời Tiếp đó, khi nhà phát triển bắt đầu tạo nhiều ứng dụng di động hơn, JSON (JavaScript Object Notation) xuất hiện để hỗ trợ các ứng dụng động hơn, phản hồi tốt hơn và dựa trên dữ liệu nhiều hơn MongoDB là một công ty xuất hiện để giải quyết các nhu cầu hạ tầng đang tiến hóa, và hoàn toàn phù hợp với làn sóng đó Lịch sử đang lặp lại với AI Khi yêu cầu thay đổi, hạ tầng cũng phải tiến hóa để đáp ứng những yêu cầu đó Câu hỏi lớn nhất sẽ là mọi người muốn xây dựng loại công ty nào, và loại hạ tầng nào phù hợp nhất với những công ty đó Như Bob đã nói trong cuộc phỏng vấn với Matthew Lynley: “Tôi tin rất mạnh rằng mọi ứng dụng trong tương lai đều sẽ có AI. Một số ứng dụng sẽ được rắc thêm AI, và một số khác sẽ có AI ở vị trí trung tâm của ứng dụng. Nếu bỏ AI đi, chúng sẽ không còn tồn tại nữa. Nếu bạn muốn xây dựng một web app rồi rắc AI lên trên nó, hãy dùng MongoDB. Đặc biệt là nếu bạn đã dùng nó rồi... Nếu bạn muốn xây dựng một ứng dụng AI-native, nơi AI là cốt lõi của ứng dụng, thì đã đến lúc nên cân nhắc Weaviate.” Trong tương lai, các công ty sẽ phải quyết định liệu họ xây dựng sản phẩm với AI như một phần phụ trợ, hay như Bob nói là một thứ để “sprinkle”, hay biến nó thành cốt lõi của sản phẩm Stack công nghệ AI-Native Với các công ty muốn xây dựng AI như một thành phần cốt lõi của sản phẩm, hạ tầng hiện có nhiều khả năng sẽ không còn phù hợp Khi dùng các công cụ legacy, việc lưu trữ, xử lý và thực thi dữ liệu được xây dựng trong một silo, còn tự động hóa lại được xây dựng trong một silo khác Nhược điểm của cách tiếp cận này là ngữ cảnh bị mất đi trong những thứ như vòng lặp phản hồi sinh, vốn có thể giúp cung cấp thêm thông tin và cải thiện sản phẩm Với các công ty đến từ stack "AI-adjacent", suy luận của một mô hình cụ thể thường bị giới hạn bởi context window Một số người tin rằng khi dung lượng của context window tăng lên, nó có thể thay thế vector database Tuy nhiên, khả năng cao hơn là kịch bản ngược lại mới đúng: vector database có thể tiến hóa để thay thế context window Vector embedding là yếu tố cực kỳ quan trọng đối với mô hình sinh, và hạ tầng cho kết quả sinh cần coi vector embedding là công dân hạng nhất Thay vì chỉ đơn giản tăng kích thước context window, có thể ghép vector database vào mô hình để có được khả năng hiểu ngữ cảnh của context window cùng với độ tin cậy và khả năng mở rộng của cơ sở dữ liệu Đặc biệt, mô hình càng mang tính tổng dụng thì càng ít có khả năng được chế tác cho một tác vụ cụ thể Vector database dựa trên AI sẽ cho phép các chức năng cụ thể hơn Các mô hình tổng dụng như GPT-4 được xây dựng để cố ý khái quát hóa tri thức Nếu sản phẩm chỉ dựa vào một chút fine-tuning đơn giản, thì mô hình nền tảng sẽ không trở thành phần giá trị độc nhất của doanh nghiệp đó Việc xây dựng sản phẩm dựa trên AI, ngoài chuyện tận dụng mô hình, còn bao gồm xây dựng sản phẩm xoay quanh một stack được kết nối chặt chẽ hơn Stack này sẽ mang lại quy mô của cơ sở dữ liệu và năng lực của mô hình để tạo ra những sản phẩm có năng lực cao hơn

(research.contrary.com)

23 điểm bởi xguru 2024-07-01 | 1 bình luận | Chia sẻ qua WhatsApp

Vào đầu thập niên 2020, sự chú ý đổ dồn rất nhiều vào AI tạo sinh
- Thảo luận chủ yếu xoay quanh việc các công cụ AI tạo sinh sẽ định hình chúng ta như thế nào, cũng như chúng sẽ ảnh hưởng ra sao đến cách viết lách, lập trình, làm hoạt hình và tiêu thụ thông tin
- Tuy nhiên, lại không có nhiều đề cập đến hình hài của chính các công cụ đó
Vào cuối những năm 1960, các hệ thống thông tin phải đối mặt với vấn đề chi phí tìm kiếm thông tin liên quan ngày càng cao do khối lượng dữ liệu khổng lồ
Trong thập niên 1980 và 1990, cơ sở dữ liệu quan hệ trở thành giải pháp thống trị
- Chúng cung cấp cơ chế lập chỉ mục trực quan và bảo đảm hiệu quả truy vấn
- Cơ sở dữ liệu quan hệ cho phép biểu diễn dữ liệu dưới dạng tập hợp các bảng có quan hệ có cấu trúc
- Chúng cho phép truy xuất dữ liệu nhanh hơn thông qua các ngôn ngữ truy vấn như SQL
Trong quá trình kiến trúc cơ sở dữ liệu phát triển, một số công ty như IBM, Oracle, Sun Microsystems, MongoDB đã củng cố vị thế của mình ở từng thị trường mới nổi
Dù Oracle dẫn đầu thế giới cơ sở dữ liệu quan hệ, cách con người lưu trữ và truy cập thông tin vẫn tiếp tục thay đổi
- Mỗi khi xuất hiện một loại công việc mới, con người lại nghĩ ra một kiến trúc mới để quản lý nó
Sự tiến hóa gần đây của cơ sở dữ liệu bắt nguồn từ nhu cầu xử lý dữ liệu phi cấu trúc
- Trong hơn 50 năm qua, schema chủ yếu được xây dựng xoay quanh các quan hệ dữ liệu có cấu trúc
- Nhưng ngày càng nhiều người cần những công cụ có thể xử lý sự mơ hồ của dữ liệu tốt hơn nhiều
- Vì thế, cơ sở dữ liệu vector đã xuất hiện
Các mô hình ngôn ngữ lớn (LLM) dựa trên transformer như GPT có thể nắm bắt các phụ thuộc dài hạn trong văn bản
- Tuy nhiên, việc duy trì khả năng hiểu văn bản dài có thể rất tốn kém về mặt tính toán
- Cơ sở dữ liệu vector có thể mở rộng cửa sổ ngữ cảnh của các mô hình này
Dù cơ sở dữ liệu vector có thể rất mạnh trong các use case AI, chúng vẫn là hạ tầng ngốc chỉ vận hành dựa trên đầu vào và đầu ra
- Chúng thiếu khả năng hiểu hoặc diễn giải dữ liệu
- Chúng chỉ đóng vai trò như kho lưu trữ đơn thuần, lưu và truy xuất dữ liệu theo chỉ thị, chứ không có trí tuệ nội tại hay nhận thức ngữ cảnh
Việc GPT-3 ra mắt vào năm 2020 đã mở đường để AI ngày càng được dùng như một thành phần cốt lõi thay vì chỉ là phần phụ trong sản phẩm doanh nghiệp
- Kiến trúc transformer, lượng dữ liệu tăng lên và hiệu năng được cải thiện đã đặt nền móng cho việc phát triển các sản phẩm dựa trên AI
Khi số lượng công ty AI-Native (dựa trên AI) tăng lên và quy mô mở rộng, nhu cầu về các công cụ hỗ trợ use case dựa trên AI cũng gia tăng
- Làn sóng đầu tiên của các công ty cốt lõi về AI chủ yếu tập trung vào suy luận bằng các mô hình hiện có
Tuy nhiên, nhờ các mô hình có hiệu năng cao hơn, đặc biệt là các mô hình mã nguồn mở dễ tiếp cận, doanh nghiệp có thể xây dựng năng lực sâu hơn như một doanh nghiệp dựa trên AI
- Khả năng mở rộng này đang mở ra cả một thế giới cơ hội về diện mạo của một AI-native tech stack

Những công cụ định hình chúng ta (The Tools that Shape Us)

Năm 1967, John M. Culkin, bạn của Marshall McLuhan, từng nói: "Chúng ta tạo ra công cụ, rồi sau đó công cụ tạo ra chúng ta"
- Việc xây dựng công nghệ cũng không khác gì
- Hạ tầng chúng ta dùng để xây dựng phần mềm đã liên tục tiến hóa để phù hợp với nhu cầu phát triển, và rồi chính cách chúng ta xây dựng lại bị định hình bởi hạ tầng mà mình dựng lên
Vào đầu thập niên 2020, sự chú ý đổ dồn rất nhiều vào AI tạo sinh
- Đặc biệt, trọng tâm đặt vào các đầu ra như văn bản hoặc mã được tạo ra, hình ảnh được render, deepfake được sản xuất, hay âm nhạc được tổng hợp
- Thảo luận chủ yếu xoay quanh việc các công cụ này sẽ định hình chúng ta như thế nào, cũng như chúng sẽ ảnh hưởng ra sao đến cách viết lách, lập trình, làm hoạt hình và tiêu thụ thông tin
- Mọi người tranh luận về hiệu năng tương đối giữa các mô hình ngôn ngữ lớn mở và độc quyền, rủi ro hallucination, tranh luận platform so với feature, cũng như tranh luận giữa các công ty hiện hữu và startup
Tuy nhiên, lại không có nhiều đề cập đến hình hài của chính các công cụ đó
- Về căn bản, cách chúng ta xây dựng công nghệ từ trước đến nay luôn bị định hình bởi hạ tầng được chuẩn bị cho việc xây dựng đó
- Sự phổ biến của SaaS được Internet thúc đẩy, phát triển di động trở nên khả thi nhờ smartphone phổ cập, và khả năng mở rộng của các thế hệ ứng dụng được đẩy mạnh bởi điện toán đám mây
Mức độ phổ biến của AI trong ứng dụng phụ thuộc vào năng lực tính toán, khả năng của mô hình, và cách các mô hình đó được điều phối trong các use case kinh doanh
- Bài viết này sẽ tập trung vào yếu tố điều phối
- Một trong những yếu tố cốt lõi để điều phối mọi use case AI là cơ sở dữ liệu của doanh nghiệp
- Nơi dữ liệu được lưu trữ, thao tác và gọi ra là một phần quan trọng của bài toán
- Nhưng như sẽ thấy, lịch sử của cơ sở dữ liệu phần lớn là lịch sử của hạ tầng ngốc
- Để tối đa hóa tính hữu dụng của AI, chúng ta sẽ phải tạo ra cơ sở dữ liệu sao cho nó trở thành một phần của phương trình tạo sinh

Nền tảng cho dữ liệu (A Base For Data)

Vào tháng 5 năm 1959, CODASYL (Conference on Data Systems Languages) lần đầu được triệu tập với mục tiêu xây dựng một "ngôn ngữ đa dụng để xây dựng các ứng dụng kinh doanh"
- Vào cuối những năm 1960, các hệ thống thông tin phải đối mặt với vấn đề chi phí tìm kiếm thông tin liên quan ngày càng tăng do khối lượng dữ liệu khổng lồ
Việc sử dụng máy tính mainframe nhìn chung đã dẫn đến chi phí MIPS (triệu lệnh mỗi giây) tăng lên khi mức độ tận dụng mainframe tăng cao, do các chi phí nâng cấp cần thiết cho bảo trì ứng dụng, vá lỗi và duy trì hiệu năng
- Do sự phức tạp của quản lý cơ sở dữ liệu, cấu trúc phân cấp cứng nhắc và việc ánh xạ cấu trúc điều hướng phức tạp, doanh nghiệp thường cần chuyên môn kỹ thuật để truy cập thông tin đã chọn, thậm chí một số nhà phát triển còn phải viết cả chương trình chỉ để truy cập thông tin liên quan
Năm 1970, E.F. Codd công bố "A Relational Model of Data for Large Shared Data Banks", đề xuất một mô hình trong đó các bảng có thể được liên kết thông qua các thuộc tính chung (tức khóa chính để định danh bản ghi duy nhất và khóa ngoại để thiết lập quan hệ giữa các bảng)
- Điều này cho phép truy xuất dữ liệu từ các bảng không đồng nhất chỉ với một truy vấn duy nhất
- Cơ sở dữ liệu quan hệ của Codd dựa trên mối quan hệ giữa các mục dữ liệu, cho phép linh hoạt trong thao tác và sử dụng dữ liệu
Năm 1973, một nhóm lập trình viên tại IBM San Jose Research Laboratory bắt tay vào dự án System R, chứng minh rằng hệ thống cơ sở dữ liệu quan hệ có thể tích hợp đầy đủ các tính năng cần thiết cho sử dụng trong môi trường production mà vẫn đạt hiệu năng cao
- Nhóm này đã phát triển một trình tối ưu hóa dựa trên chi phí để nâng cao hiệu quả cơ sở dữ liệu, và các phát triển bắt nguồn từ System R sau đó dẫn tới việc ra mắt SQL/DS, sản phẩm cơ sở dữ liệu quan hệ đầu tiên của IBM
Trong những năm 1980 và 1990, cơ sở dữ liệu quan hệ trở thành giải pháp cơ sở dữ liệu thống trị
- Chúng cung cấp khả năng lập chỉ mục trực quan và đảm bảo hiệu quả truy vấn
- Cơ sở dữ liệu quan hệ cho phép biểu diễn dữ liệu dưới dạng tập hợp các bảng có quan hệ có cấu trúc
- Chúng cho phép truy xuất dữ liệu nhanh hơn thông qua các ngôn ngữ truy vấn như SQL
Cơ sở dữ liệu quan hệ được xây dựng dựa trên giả định là sẽ chạy trên một máy duy nhất
- Tuy nhiên, việc Internet được áp dụng rộng rãi trong thập niên 1990 và 2000 đã tạo ra lượng dữ liệu đổ vào khổng lồ, dẫn tới khối lượng công việc vượt quá khả năng xử lý của một máy tính đơn lẻ
- Các cơ sở dữ liệu SQL truyền thống được thiết kế để chạy trên một máy chủ duy nhất, và người dùng phải mở rộng phần cứng vật lý theo nhu cầu lưu trữ, điều này trở nên rất tốn kém đối với các doanh nghiệp vận hành workload lớn hơn
Trong thập niên 2010, dữ liệu và số lượng người dùng cho OLTP (online transaction processing) tăng theo cấp số nhân, dẫn tới sự gia tăng rộng khắp của cơ sở dữ liệu phân tán, data warehouse và OLAP (online analytical processing)
Cơ sở dữ liệu quan hệ và SQL không còn phù hợp với quy mô và độ phức tạp ứng dụng cần thiết nữa, và cơ sở dữ liệu NoSQL nổi lên như một phương tiện để tăng hiệu năng (đánh đổi các tính năng ACID)
- Cơ sở dữ liệu quan hệ có thể lưu trữ và thao tác dữ liệu có cấu trúc, nhưng việc duy trì quan hệ giữa các dữ liệu trở nên khó khăn khi phải xử lý overhead của join và tính đến chi phí của các thao tác CRUD
- Cơ sở dữ liệu quan hệ phù hợp để xử lý dữ liệu quan hệ với các yêu cầu logic hoặc rời rạc, nhưng nhìn chung lại gắn với các hệ thống legacy được xây dựng riêng cho cấu trúc quan hệ
- NoSQL xuất hiện như một phương thức xử lý big data phi cấu trúc, cung cấp cho nhà phát triển khả năng lưu trữ bền vững dữ liệu thông qua cách tiếp cận phi quan hệ
- Thay vì sử dụng SQL làm ngôn ngữ truy vấn mặc định, NoSQL cung cấp truy cập thông qua API, nhờ đó đảm bảo khả năng mở rộng cao hơn, tính toán phân tán, giảm chi phí và tính linh hoạt về schema
- Các cơ sở dữ liệu NoSQL hoạt động với kiến trúc hiệu quả có thể mở rộng theo chiều ngang, vì vậy để tăng năng lực lưu trữ hoặc tính toán chỉ cần thêm nhiều máy chủ hoặc instance cloud hơn
- Đối với các doanh nghiệp có workload dữ liệu cần xử lý hoặc phân tích dữ liệu phi cấu trúc nhanh hơn, cơ sở dữ liệu NoSQL được ưu tiên

Cuộc chiến cơ sở dữ liệu đời đầu

Trong quá trình kiến trúc cơ sở dữ liệu tiến hóa, một số công ty nhất định đã củng cố vị thế ở từng thị trường mới nổi
- Ngay sau khi IBM phát hành System R, Larry Ellison khi đó 33 tuổi đã đọc chính bài báo của Codd về cơ sở dữ liệu quan hệ
- Ellison và hai đồng sáng lập đã cố gắng lập một công ty tương thích với System R, nhưng IBM khiến điều đó trở nên rất khó khăn
- Kết quả là bộ ba này đã xây dựng doanh nghiệp xoay quanh sản phẩm cơ sở dữ liệu chủ lực mới của mình, Oracle Databases
- Kể từ đó, cơ sở dữ liệu của Oracle đã trở thành sản phẩm dẫn đầu, và tính đến tháng 5 năm 2024 có thị phần khoảng 28,7%
Trong vài năm trước đợt IPO năm 1986 của Oracle, một công ty khác đã gia nhập lĩnh vực cơ sở dữ liệu
- Sun Microsystems khởi đầu vào năm 1982 với việc bán nhiều thành phần máy tính khác nhau, nhưng trở nên nổi tiếng nhờ những đóng góp như ngôn ngữ lập trình Java, Network File System và hơn thế nữa
- Điều quan trọng là vào năm 2008, Sun Microsystems đã mua lại MySQL, một hệ quản trị cơ sở dữ liệu mã nguồn mở
- Chỉ 2 năm sau, Oracle đã mua lại Sun Microsystems (bao gồm cả MySQL)
- Gần 15 năm sau, tính đến tháng 5 năm 2024, các cơ sở dữ liệu dẫn đầu là Oracle (thị phần 28,7%) và MySQL (khoảng 17,3%)
Dù Oracle dẫn dắt thế giới cơ sở dữ liệu quan hệ, cách con người lưu trữ và truy cập thông tin vẫn tiếp tục thay đổi
- Mỗi khi xuất hiện một loại công việc mới, con người lại nghĩ ra một kiến trúc mới để quản lý nó
- Từ các document store như MongoDB (2007), Databricks (2013) đến các cơ sở dữ liệu chuỗi thời gian như InfluxDB (2013), Prometheus (2012), và các cơ sở dữ liệu đồ thị như Neo4j (2007), Cosmos (2017), danh sách các cơ sở dữ liệu chuyên biệt vẫn đang tiếp tục dài ra
- Khi mức độ phổ biến của cơ sở dữ liệu quan hệ giảm dần một cách ổn định, nhiều giải pháp khác nhau đã xuất hiện để đáp ứng những nhu cầu ngách mới này
Sự tiến hóa mới nhất của cơ sở dữ liệu bắt nguồn từ nhu cầu xử lý dữ liệu phi cấu trúc
- Trong hơn 50 năm qua, schema chủ yếu được tổ chức xoay quanh các mối quan hệ dữ liệu có cấu trúc
- Tuy nhiên, ngày càng nhiều người cần những công cụ có thể xử lý sự mơ hồ của dữ liệu tốt hơn nhiều
- Từ đó, cơ sở dữ liệu vector đã xuất hiện

Sự trỗi dậy của cơ sở dữ liệu vector

Với sự phổ biến rộng rãi của mô hình ngôn ngữ lớn (LLM) và AI tạo sinh, cơ sở dữ liệu vector đã nổi lên như một công cụ có thể xử lý dữ liệu đa phương thức phi cấu trúc
- Trong khi các cơ sở dữ liệu quan hệ truyền thống (Postgres, MySQL) phù hợp nhất với schema có cấu trúc, cơ sở dữ liệu vector phù hợp để lưu trữ và truy vấn vector embedding (biểu diễn số của dữ liệu chứa ý nghĩa tương ứng với trọng số của mô hình ngôn ngữ)
- Thay vì các hàng và cột thường dùng trong cơ sở dữ liệu quan hệ, cơ sở dữ liệu vector biểu diễn dữ liệu dưới dạng các điểm trong không gian đa chiều và khớp dữ liệu dựa trên độ tương tự thay vì giá trị chính xác
Tùy theo mô hình embedding, dữ liệu có thể được biểu diễn trong các không gian vector khác nhau và với số chiều khác nhau
- Vector embedding nắm bắt ý nghĩa của các điểm dữ liệu, cho phép truy xuất các đối tượng tương tự bằng cách tìm các đối tượng gần nhất trong cơ sở dữ liệu vector
Ví dụ, Word2Vec ánh xạ từ thành vector để giúp nắm bắt ý nghĩa, độ tương đồng ngữ nghĩa và quan hệ ngữ cảnh với văn bản khác
- Thuật toán này sử dụng mạng nơ-ron nông để suy ra ý nghĩa của một từ cụ thể từ một kho ngữ liệu văn bản rộng hơn và xác định từ đồng nghĩa thông qua logistic regression
- Cũng có những phương pháp giúp trích xuất embedding mà không phụ thuộc vào mạng nơ-ron sâu, chẳng hạn như singular value decomposition (SVD) và principal component analysis (PCA)
Các thước đo khoảng cách giúp xác định "khoảng cách" tương đối giữa các điểm trong không gian vector; các phương pháp phổ biến gồm có khoảng cách Euclid, khoảng cách Manhattan, khoảng cách cosine và độ tương tự Jaccard
- K-nearest neighbors (KNN) và approximate nearest neighbors (ANN) giúp đơn giản hóa tìm kiếm tương tự cho hình ảnh, video hoặc các đầu vào đa phương thức khác, đồng thời cải thiện thời gian chạy
Các cơ sở dữ liệu chuyên cho vector như Weaviate, Chroma, Qdrant và Pinecone giúp nhà phát triển xử lý dữ liệu ở quy mô lớn, đặc biệt là trong việc hỗ trợ tìm kiếm trên đầu vào phi cấu trúc
- Không giống cơ sở dữ liệu quan hệ hay NoSQL truyền thống, cơ sở dữ liệu vector được thiết kế riêng để xử lý vector embedding
- Trong khi cơ sở dữ liệu truyền thống lưu dữ liệu dưới dạng scalar, cơ sở dữ liệu vector chỉ lưu vector và tận dụng các kỹ thuật lập chỉ mục như lượng tử hóa và phân cụm để tối ưu hóa tác vụ truy xuất
Các LLM dựa trên transformer như GPT có thể nắm bắt các phụ thuộc dài hạn trong văn bản
- Tuy nhiên, việc duy trì khả năng hiểu văn bản dài có thể rất tốn kém về mặt tính toán
- Các LLM hiện đại có thể nắm bắt phụ thuộc toàn cục giữa các cặp token trên toàn bộ đầu vào, nhưng độ phức tạp về thời gian và không gian gây ra vấn đề về tài nguyên tính toán, từ đó giới hạn độ dài văn bản đầu vào trong quá trình huấn luyện và cửa sổ ngữ cảnh hiệu quả trong suy luận
Với các trường hợp đa chiều, mã hóa vị trí tương đối khó triển khai và phần lớn các cách tiếp cận mã hóa vị trí tương đối đòi hỏi cơ chế embedding vị trí mạnh, điều này góp phần làm suy giảm hiệu năng trong quá trình suy luận
- Ngay cả khi độ dài văn bản tăng lên, cơ sở dữ liệu vector vẫn có thể đóng vai trò quan trọng như bộ nhớ dài hạn của mô hình
- Sử dụng cơ sở dữ liệu vector có thể đơn giản hóa các tác vụ như hoàn tất văn bản hoặc tóm tắt, nơi toàn bộ ngữ cảnh câu có thể cần thiết để tạo ra kết quả chính xác
Cơ sở dữ liệu vector có thể hỗ trợ retrieval-augmented generation (RAG), trong đó cơ sở dữ liệu vector có thể được dùng để tăng cường prompt được gửi tới LLM bằng cách bổ sung thêm ngữ cảnh cùng với truy vấn gốc
- LLM thường dựa vào mô hình tự giám sát, nên nhiều khi gặp khó khăn với các tác vụ đặc thù theo miền yêu cầu kiến thức chuyên biệt hoặc ngưỡng độ chính xác cao hơn
- RAG có thể giúp kiểm chứng, theo dõi hoặc giải thích cách một câu trả lời được suy ra, đồng thời giảm thiểu hiện tượng hallucination có thể phát sinh do thiếu ngữ cảnh cho truy vấn đang xét
Nhà phát triển có thể kết hợp knowledge graph và tìm kiếm vector để mở rộng LLM vượt ra ngoài dữ liệu mà nó đã được huấn luyện
- Các công cụ như GraphRAG của Microsoft Research hỗ trợ tăng cường prompt khi thực hiện truy xuất trên các tập dữ liệu riêng tư
- RAG cơ bản thường gặp khó khăn trong việc hiểu một cách tổng thể các khái niệm ngữ nghĩa đã được tóm lược trên các bộ sưu tập dữ liệu lớn, vì vậy các công cụ như LlamaIndex và GraphRAG xây dựng knowledge graph dựa trên các tập dữ liệu riêng tư
Tùy theo yêu cầu cụ thể hoặc trường hợp sử dụng, nhà phát triển có thể thấy dùng knowledge graph phù hợp hơn RAG
- Cơ sở dữ liệu vector phù hợp cho tìm kiếm tương tự và thích hợp nhất cho truy xuất tài liệu hoặc hình ảnh, cũng như tạo gợi ý, trong khi knowledge graph phù hợp cho suy luận (đặc biệt hữu ích khi thu thập dữ liệu, trích xuất thực thể cùng các quan hệ liên kết với nhau, và duyệt qua các quan hệ đó)
Với các ứng dụng cần xử lý dữ liệu theo thời gian thực hoặc gần thời gian thực, cơ sở dữ liệu vector có thể được ưu tiên nhờ truy vấn có độ trễ thấp hơn
Bằng cách thu thập và lưu trữ embedding, cơ sở dữ liệu vector hỗ trợ truy xuất nhanh hơn cho tìm kiếm tương tự bằng cách đối sánh prompt đầu vào với các embedding tương tự
Xếp hạng độ tương tự giúp hỗ trợ nhiều tác vụ machine learning, từ hệ thống gợi ý, tìm kiếm ngữ nghĩa, nhận dạng hình ảnh cho đến các ứng dụng xử lý ngôn ngữ tự nhiên khác
Cơ sở dữ liệu vector đóng vai trò quan trọng trong việc cải thiện hiệu năng của LLM bằng cách cho phép lưu trữ và truy xuất vector embedding hiệu quả
- Điều này cho phép tự động hiểu ngôn ngữ tự nhiên ở quy mô lớn
Tuy nhiên, vector embedding đại diện cho đổi mới N+1
- Đây là các định dạng dữ liệu trước đó như dữ liệu quan hệ hoặc dữ liệu chuỗi thời gian
Các nhà cung cấp cơ sở dữ liệu legacy đã bắt đầu ra mắt các tính năng vector như Atlas Vector Search của MongoDB, cơ sở dữ liệu vector của SingleStore và chỉ mục tìm kiếm vector của Neo4J
Mặc dù cơ sở dữ liệu vector có thể mạnh mẽ trong các trường hợp sử dụng AI, về bản chất nó vẫn là hạ tầng thụ động vận hành theo đầu vào và đầu ra
- Nó thiếu khả năng hiểu hoặc diễn giải dữ liệu
- Nó chỉ đóng vai trò như một kho lưu trữ và truy xuất dữ liệu theo chỉ dẫn, chứ không có trí thông minh nội tại hay nhận thức ngữ cảnh
Đối với các ứng dụng AI hiện đại, chỉ như vậy sẽ không còn đủ
- Doanh nghiệp ngày càng xây dựng xoay quanh AI model như thành phần cốt lõi
- Vì vậy, nếu ứng dụng ngày càng thể hiện các năng lực thông minh hơn, hạ tầng cũng sẽ cần những năng lực thông minh tương tự

Các công ty AI-Native thế hệ thứ nhất

Kể từ khi giới học thuật lần đầu bắt đầu nghiên cứu trí tuệ nhân tạo tại Đại học Dartmouth vào năm 1956, các trường hợp sử dụng thực tiễn đã thúc đẩy lĩnh vực này phát triển
- Ví dụ, vào cuối những năm 1960, Joseph Weizenbaum đã tạo ra một chương trình máy tính tên là ELIZA, trong đó một cách tiếp cận đơn giản mô phỏng hội thoại bằng đối sánh mẫu đã được dùng cho các cuộc trò chuyện tương tự trị liệu ở mức sơ khai (chatbot đầu tiên)
Trong phần lớn lịch sử ứng dụng AI vào các trường hợp sử dụng kinh doanh, những cải tiến của AI diễn ra theo hướng tiệm tiến
Trước khi thuật ngữ AI trở nên thịnh hành, thuật ngữ machine learning thường được dùng nhiều hơn để chỉ cùng công nghệ này
- Tức là, “các thuật toán thống kê có thể học từ dữ liệu và khái quát hóa sang dữ liệu chưa từng thấy, từ đó có thể thực hiện tác vụ mà không cần chỉ dẫn tường minh”
Về mặt nhận thức đại chúng, AI đã đạt đến bước ngoặt khi OpenAI ra mắt ChatGPT vào ngày 30 tháng 11 năm 2022, nhưng từ góc độ kỹ thuật, điểm chuyển mình đã diễn ra từ lâu trước đó
Tháng 11 năm 2017, tổ chức điều phối quốc tế Financial Stability Board (FSB) đã soạn một bản tổng quan về tác động của machine learning đối với dịch vụ tài chính
- Các công ty dịch vụ tài chính ngày càng có thể dùng machine learning để thực hiện những tác vụ như “đánh giá chất lượng tín dụng”, qua đó “góp phần tạo ra một hệ thống tài chính hiệu quả hơn”
- Nói cách khác, nó có thể nâng cao hiệu quả, nhưng chưa cấu thành một yếu tố sống còn mang tính hiện sinh
Trong khi đó, machine learning tiếp tục ngày càng tốt hơn, và vào tháng 5 năm 2018, OpenAI đã công bố một nghiên cứu về lịch sử lượng tính toán cần thiết để huấn luyện các mô hình quy mô lớn, cho thấy kể từ năm 2012 con số này đã tăng gấp đôi mỗi 3,4 tháng, tương đương mức tăng 300.000 lần về compute
Tháng tiếp theo, vào tháng 6 năm 2018, OpenAI công bố phần giới thiệu đầu tiên về mô hình GPT
Một cuộc tranh luận bắt đầu hình thành giữa hai phe
- Một mặt, nhiều người tin rằng sự tăng trưởng liên tục của các mô hình ngày càng lớn cuối cùng sẽ vấp phải quy luật lợi suất giảm dần
- Phe còn lại, trong đó có OpenAI, tin rằng hiệu năng sẽ tiếp tục cải thiện khi quy mô tăng lên
Tháng 1 năm 2020, Jared Kaplan, nhà nghiên cứu của OpenAI đồng thời là giáo sư tại Đại học Johns Hopkins, cùng các cộng sự đã công bố “Scaling Laws for Neural Language Models”, trong đó nêu rõ:
- “Hiệu năng mô hình hóa ngôn ngữ được cải thiện một cách mượt mà và có thể dự đoán khi quy mô mô hình, dữ liệu và compute được mở rộng một cách phù hợp. Chúng tôi kỳ vọng các mô hình ngôn ngữ lớn hơn sẽ hoạt động tốt hơn và có hiệu quả mẫu cao hơn so với các mô hình hiện tại.”
Tháng 5 năm 2020, OpenAI công bố bài báo “Language Models are Few-Shot Learners” về GPT-3, cho thấy hiệu năng mở rộng một cách trơn tru khi compute tăng lên
OpenAI cũng phát hiện rằng việc tăng quy mô còn cải thiện khả năng khái quát hóa, và lập luận rằng “việc mở rộng quy mô các mô hình ngôn ngữ lớn cải thiện đáng kể hiệu năng few-shot không phụ thuộc tác vụ, đôi khi có thể cạnh tranh với các phương pháp fine-tuning tiên tiến nhất trước đó”
Nhà nghiên cứu độc lập Gwern Branwen đã đặt ra giả thuyết scaling trong một bài blog, và nói rằng:
- “GPT-3, được OpenAI công bố vào tháng 5 năm 2020, là mạng nơ-ron lớn nhất từng được huấn luyện cho đến thời điểm đó, lớn hơn ít nhất một bậc độ lớn... Trái với kỳ vọng của nhiều người (bao gồm cả tôi), sự gia tăng quy mô khổng lồ này, đúng như OpenAI dự đoán, vẫn tiếp tục cho thấy lợi ích của quy mô và không đụng phải mức lợi suất giảm dần hay lợi nhuận âm như nhiều người từng dự đoán.”
Sự ngạc nhiên mà Branwen cảm nhận chính là dấu hiệu của một sự thay đổi cục diện
AI không còn chỉ là phần phụ lục của sản phẩm công ty, mà ngày càng có thể được dùng như phần cốt lõi
Kiến trúc transformer, lượng dữ liệu gia tăng và mức hiệu năng được cải thiện đều đã đặt nền móng cho việc phát triển sản phẩm dựa trên AI
Ngay sau khi GPT-3 ra mắt vào tháng 5 năm 2020, các công ty như Writer và Jasper đã tạo ra các sản phẩm copywriting lấy mô hình AI làm trung tâm của doanh nghiệp
Các công ty như Harvey và EvenUp đã xây dựng legal tech xoay quanh AI
Các công ty như DeepScribe và Freed đã xây dựng giải pháp phiên âm y tế xoay quanh AI
Tuy nhiên, cũng như trong quá khứ khi các trường hợp sử dụng mới dẫn đến sự tiến hóa của cơ sở dữ liệu, sự ra đời của các sản phẩm dựa trên AI đồng nghĩa với việc hạ tầng phía sau stack công nghệ của từng công ty phải thay đổi và thích nghi

Cơ sở dữ liệu AI-Native

Khi số lượng doanh nghiệp dựa trên AI tăng lên và mở rộng quy mô, nhu cầu về các công cụ hỗ trợ các trường hợp sử dụng dựa trên AI cũng tăng theo
Làn sóng đầu tiên của các công ty lấy AI làm cốt lõi chủ yếu tập trung vào suy luận với các mô hình sẵn có
- Họ có các công cụ workflow chuyên biệt cho ứng dụng, copywriting, phiên âm y tế và các nhu cầu tương tự
- Cốt lõi của sản phẩm là đầu ra như văn bản hoặc hình ảnh được mô hình tạo ra
Sau DevDay của OpenAI vào tháng 11 năm 2023, meme “OpenAI đã giết chết startup của tôi” bắt đầu lan rộng
- Các GPT chuyên biệt hoặc AI agent cụ thể dường như đảm nhận vai trò của những startup AI đời đầu này vì chúng tập trung vào suy luận từ các mô hình hiện có
- OpenAI tình cờ trở thành nhà cung cấp cả mô hình lẫn ứng dụng
Tốc độ đổi mới xoay quanh năng lực mô hình diễn ra quá nhanh đến mức bắt đầu tạo cảm giác như một mối đe dọa với startup
Tuy nhiên, theo chiều ngược lại, các mô hình có hiệu năng cao hơn, đặc biệt là các mô hình mã nguồn mở dễ tiếp cận, lại giúp doanh nghiệp xây dựng năng lực sâu hơn như một doanh nghiệp dựa trên AI
Xây dựng một stack công nghệ dựa trên AI không chỉ là thêm các thành phần xung quanh mô hình
- Ví dụ, một cơ sở dữ liệu được thiết kế riêng cho AI sẽ trông như thế nào?
- Nếu suy luận là đầu ra quan trọng, thì một cơ sở dữ liệu AI-Native không chỉ phải lưu trữ và truy xuất dữ liệu mà còn phải có khả năng tiếp nhận các chỉ dẫn theo ngữ cảnh về những gì cần làm với dữ liệu đang lưu trữ
Một ví dụ có thể là cá nhân hóa mô tả sản phẩm cho thương mại điện tử
- Một vector database không chỉ lưu vector embedding cho SKU sản phẩm và mô tả, mà còn có thể lưu embedding cho persona người dùng
- Bằng cách dùng toàn bộ dữ liệu theo ngữ cảnh này trong cơ sở dữ liệu, hạ tầng có thể tận dụng một vòng phản hồi sinh tạo, nơi truy vấn mô tả sản phẩm cũng kích hoạt truy vấn về persona người dùng liên quan, rồi sau đó viết mô tả sản phẩm dựa trên persona phù hợp đó
Tương tự, ngôn ngữ cũng có thể được dùng như một vòng phản hồi sinh tạo
- Ví dụ, người dùng có thể muốn tạo mô tả sản phẩm bằng nhiều ngôn ngữ khác nhau
- Có thể tạo ra mô tả sản phẩm không chỉ được cá nhân hóa cho người dùng mà còn được dịch sang ngôn ngữ mà người dùng chọn
- Loại chỉ dẫn này có thể được tích hợp trực tiếp vào cơ sở dữ liệu vì các trường hợp sử dụng như generative AI ngày càng trở thành chức năng trung tâm của ứng dụng
Việc phát triển hạ tầng để phù hợp với trường hợp sử dụng không phải là điều mới
- Ban đầu, các nhà phát triển xây dựng ứng dụng trong trình duyệt bằng JavaScript để khiến website trở nên tương tác và động hơn
- Nhưng khi các nhà phát triển nhận ra họ có thể đưa điều đó vào backend, node.js đã ra đời
- Tiếp đó, khi nhà phát triển bắt đầu tạo nhiều ứng dụng di động hơn, JSON (JavaScript Object Notation) xuất hiện để hỗ trợ các ứng dụng động hơn, phản hồi tốt hơn và dựa trên dữ liệu nhiều hơn
- MongoDB là một công ty xuất hiện để giải quyết các nhu cầu hạ tầng đang tiến hóa, và hoàn toàn phù hợp với làn sóng đó
Lịch sử đang lặp lại với AI
- Khi yêu cầu thay đổi, hạ tầng cũng phải tiến hóa để đáp ứng những yêu cầu đó
- Câu hỏi lớn nhất sẽ là mọi người muốn xây dựng loại công ty nào, và loại hạ tầng nào phù hợp nhất với những công ty đó
- Như Bob đã nói trong cuộc phỏng vấn với Matthew Lynley:
  - “Tôi tin rất mạnh rằng mọi ứng dụng trong tương lai đều sẽ có AI. Một số ứng dụng sẽ được rắc thêm AI, và một số khác sẽ có AI ở vị trí trung tâm của ứng dụng. Nếu bỏ AI đi, chúng sẽ không còn tồn tại nữa. Nếu bạn muốn xây dựng một web app rồi rắc AI lên trên nó, hãy dùng MongoDB. Đặc biệt là nếu bạn đã dùng nó rồi... Nếu bạn muốn xây dựng một ứng dụng AI-native, nơi AI là cốt lõi của ứng dụng, thì đã đến lúc nên cân nhắc Weaviate.”
Trong tương lai, các công ty sẽ phải quyết định liệu họ xây dựng sản phẩm với AI như một phần phụ trợ, hay như Bob nói là một thứ để “sprinkle”, hay biến nó thành cốt lõi của sản phẩm

Stack công nghệ AI-Native

Với các công ty muốn xây dựng AI như một thành phần cốt lõi của sản phẩm, hạ tầng hiện có nhiều khả năng sẽ không còn phù hợp
- Khi dùng các công cụ legacy, việc lưu trữ, xử lý và thực thi dữ liệu được xây dựng trong một silo, còn tự động hóa lại được xây dựng trong một silo khác
- Nhược điểm của cách tiếp cận này là ngữ cảnh bị mất đi trong những thứ như vòng lặp phản hồi sinh, vốn có thể giúp cung cấp thêm thông tin và cải thiện sản phẩm
Với các công ty đến từ stack "AI-adjacent", suy luận của một mô hình cụ thể thường bị giới hạn bởi context window
- Một số người tin rằng khi dung lượng của context window tăng lên, nó có thể thay thế vector database
- Tuy nhiên, khả năng cao hơn là kịch bản ngược lại mới đúng: vector database có thể tiến hóa để thay thế context window
- Vector embedding là yếu tố cực kỳ quan trọng đối với mô hình sinh, và hạ tầng cho kết quả sinh cần coi vector embedding là công dân hạng nhất
Thay vì chỉ đơn giản tăng kích thước context window, có thể ghép vector database vào mô hình để có được khả năng hiểu ngữ cảnh của context window cùng với độ tin cậy và khả năng mở rộng của cơ sở dữ liệu
- Đặc biệt, mô hình càng mang tính tổng dụng thì càng ít có khả năng được chế tác cho một tác vụ cụ thể
- Vector database dựa trên AI sẽ cho phép các chức năng cụ thể hơn
Các mô hình tổng dụng như GPT-4 được xây dựng để cố ý khái quát hóa tri thức
- Nếu sản phẩm chỉ dựa vào một chút fine-tuning đơn giản, thì mô hình nền tảng sẽ không trở thành phần giá trị độc nhất của doanh nghiệp đó
- Việc xây dựng sản phẩm dựa trên AI, ngoài chuyện tận dụng mô hình, còn bao gồm xây dựng sản phẩm xoay quanh một stack được kết nối chặt chẽ hơn
- Stack này sẽ mang lại quy mô của cơ sở dữ liệu và năng lực của mô hình để tạo ra những sản phẩm có năng lực cao hơn

1 bình luận

savvykang 2024-07-01

Mong sẽ có thêm nhiều ví dụ thực tế về việc tạo vector embedding và các trường hợp sử dụng vector DB để hình thành một quy trình làm việc chuẩn. Không biết phải đợi khoảng 1 năm nữa chăng?