OpenRAG: An open-source stack for RAG — Phil Nash

• RAG không "chết" mà trở nên phức tạp hơn, đặc biệt khi xử lý lượng lớn dữ liệu đa dạng và đáp ứng nhu cầu người dùng khác nhau; do đó, cần một cách tiếp cận "đã được giải quyết" hơn là một giải pháp đơn giản.
• OpenRAG là một nền tảng mã nguồn mở toàn diện, kết hợp Duckling để xử lý tài liệu, OpenSearch cho lập chỉ mục và tìm kiếm, cùng Langflow để điều phối trực quan các luồng AI và tác nhân.
• Nó cung cấp một khung làm việc mạnh mẽ và linh hoạt, hỗ trợ xử lý tài liệu phức tạp (đặc biệt là PDF), tìm kiếm vector và từ khóa lai, cùng cơ chế genetic retrieval thông minh, cho phép tùy chỉnh sâu rộng để phù hợp với từng trường hợp sử dụng cụ thể.

• RAG hiện đại gặp nhiều thách thức như xử lý tệp PDF, tối ưu hóa chiến lược chunking, quản lý sự tiến hóa của embeddings, và triển khai các kỹ thuật tìm kiếm nâng cao như viết lại query hoặc reranking.
• OpenRAG tích hợp Duckling để xử lý tài liệu đa dạng (HTML, Markdown, Word, PDF, âm thanh, video), sử dụng các pipeline chuyên biệt và dock tags để tạo cấu trúc phân cấp, hỗ trợ cả OCR cho tài liệu quét.
• OpenSearch được sử dụng làm cơ sở dữ liệu mạnh mẽ cho tìm kiếm vector và keyword lai, cung cấp khả năng lọc và tổng hợp cao cấp, đồng thời hỗ trợ multi-vector search và live indexing thông qua plugin JVector K&N.
• Hệ thống áp dụng genetic retrieval trong quá trình tạo phản hồi, nơi một agent do Langflow điều khiển sẽ tự động quyết định các tìm kiếm cần thực hiện và cách tổng hợp kết quả, thay vì chỉ dựa vào top-K chunks từ một truy vấn đơn lẻ.
• Langflow đóng vai trò trung tâm trong việc orchestration các AI flows thông qua giao diện kéo thả trực quan, cho phép người dùng dễ dàng cấu hình logic của agent, thiết lập guardrails, lựa chọn model provider, và điều chỉnh các thông số ingestion như chunk size và chunk overlap.
• OpenRAG có khả năng chạy offline với các model cục bộ (ví dụ qua Ollama), làm cho nó phù hợp với các môi trường air-gapped, đồng thời hỗ trợ các Claude connector (Google Drive, SharePoint) để đồng bộ hóa dữ liệu tự động.
• Nền tảng cung cấp quyền truy cập qua API, cho phép tích hợp các chức năng tìm kiếm và agent vào các ứng dụng bên ngoài, mở rộng khả năng sử dụng của hệ thống RAG.
• OpenRAG là dự án mã nguồn mở hoàn toàn (với frontend Next.js và backend Python), khuyến khích cộng đồng đóng góp và phát triển các component nền tảng như Duckling, OpenSearch, và Langflow để xây dựng một nền tảng RAG mạnh mẽ, linh hoạt.

• Retrieval-Augmented Generation (RAG) — Tạo sinh tăng cường truy xuất
• Context Window — Cửa sổ ngữ cảnh
• Chunking — Chia nhỏ/Phân đoạn (dữ liệu)
• Embeddings — Phép nhúng/Vector nhúng
• Vector Search — Tìm kiếm vector
• Agent — Tác nhân
• Genetic Retrieval — Truy xuất di truyền
• Orchestration — Điều phối
• Guardrails — Hàng rào bảo vệ (kiểm soát an toàn)
• Air-gapped — Cách ly mạng (không kết nối internet)

Mở đầu và Quan niệm sai lầm về RAG

Xin chào, tôi là Farnash và tôi là Kỹ sư Quan hệ Nhà phát triển tại IBM. Tôi đã làm việc với các tool liên quan đến AI và RAG trong vài năm qua và hôm nay tôi có một điều muốn giới thiệu với các bạn.

Trước hết, tôi đã nghe rất nhiều lần rằng RAG (Retrieval-Augmented Generation) đã chết, và tôi chắc rằng các bạn cũng vậy. Các context window ngày nay rất lớn; bạn có thể chỉ cần đổ tất cả thông tin của mình vào đó. Tôi không quá coi trọng những tuyên bố kiểu này. Nếu mọi doanh nghiệp chỉ có dữ liệu trị giá chưa đến một triệu token, thì chắc chắn, RAG đã chết và có lẽ phục vụ tất cả những doanh nghiệp đó. Tất nhiên, không phải ai cũng sẵn lòng trả tiền cho một triệu token đầu vào mỗi khi bạn muốn đặt câu hỏi. Thay vì nghe những tuyên bố "RAG đã chết", chúng ta hãy nói "RAG đã được giải quyết". Chúng ta cho rằng mình hiểu quy trình và có thể áp dụng RAG khi cần: chỉ cần thu thập tất cả dữ liệu phi cấu trúc, trích xuất văn bản, phân đoạn (chunk) nó, nhúng (embed) nó, rồi đưa vào một cơ sở dữ liệu vector. Sau đó, khi bạn muốn hỏi agent của mình một câu hỏi, bạn chỉ cần nhúng câu hỏi đó. Tìm kiếm trong cơ sở dữ liệu, chọn các kết quả hàng đầu (top-K results), và chuyển chúng tới một model dưới dạng ngữ cảnh. Ngày nay, nó chỉ là một chú thích nhỏ trong context engineering.

Thách thức của RAG hiện đại

Nhưng hóa ra RAG thực sự khó, và khó vì những lý do khác nhau đối với các dự án khác nhau. Các tệp PDF là một nỗi đau. Các chiến lược chunking là một phiền toái; thay đổi và kiểm thử chúng rất khó khăn. Embeddings liên tục được cải thiện, điều này rất tốt cho ngành công nghiệp nhưng không thuận lợi lắm khi bạn đã sử dụng một thứ từ sáu tháng hoặc một năm trước. Luôn có các kỹ thuật tìm kiếm mới, và nhiều tinh chỉnh nữa mà bạn có thể thêm vào pipeline của mình để cải thiện kết quả, như thêm bản tóm tắt vào các chunk, thực hiện mở rộng chunk, sử dụng một crossing code để xếp hạng lại kết quả. Viết lại query—có rất nhiều thứ khác nữa. RAG khá phức tạp. Trên thực tế, tài liệu của mỗi người đều khác nhau. Mỗi hệ thống sẽ có những người dùng, câu hỏi, mẫu tương tác và kỳ vọng khác nhau. Mặc dù mỗi hệ thống RAG cuối cùng sẽ khác nhau, chắc chắn có một số thành phần cốt lõi cần thiết. Khi xây dựng một hệ thống RAG, việc có một nền tảng chất lượng cao để xây dựng là rất hữu ích. Đó là những gì chúng tôi đang phát triển tại IBM.

Giới thiệu OpenRAG: Giải pháp RAG toàn diện

Chúng tôi đã kết hợp ba dự án mã nguồn mở hiện có để tạo ra một RAG stack mạnh mẽ, dễ sử dụng và dễ mở rộng. Dự án đó có tên là OpenRAG. Nó sử dụng Duckling mã nguồn mở để xử lý tài liệu, OpenSearch để lập chỉ mục tìm kiếm và Langflow để orchestration trực quan và các agent. OpenRAG là một dự án mã nguồn mở mà bạn có thể dùng thử ngay hôm nay để xây dựng hệ thống RAG mạnh mẽ, tùy chỉnh và dễ sử dụng của riêng mình. Nhưng tôi muốn phân tích cấu trúc này để bạn hiểu rõ các thành phần và cách chúng hoạt động cùng nhau, cũng như cách chúng tạo ra một stack đủ linh hoạt cho các yêu cầu RAG hiện đại của bạn.

Phân tích Kiến trúc OpenRAG

Xử lý tài liệu và Nạp dữ liệu (Dockling)

Hãy bắt đầu bằng cách xem xét khía cạnh nạp dữ liệu (ingestion) của RAG. Hãy bắt đầu từ nơi mọi thứ bắt đầu: xử lý tài liệu. Việc nạp các tệp PDF, HTML, Word Docs, Slides và nhiều loại khác có thể rất phiền phức. Nhưng nỗi đau lớn nhất trong số đó, tất nhiên, là các tệp PDF. Duckling là một dự án mã nguồn mở được phát triển từ IBM Research tại Zurich, và nó xử lý cũng như phân tích tất cả các loại tài liệu từ HTML, Markdown, và Word Documents cho đến Slides và Spreadsheets, âm thanh và video, và thậm chí cả kẻ thù của mọi hệ thống RAG: PDF. Duckling có một số pipeline khác nhau xử lý các loại tệp khác nhau. Điều này cho phép nó linh hoạt trong cách tiếp nhận tài liệu và chính xác trong đầu ra. Vì vậy, có một simple pipeline xử lý các tài liệu văn bản khá đơn giản như Markdown, HTML và Word, pipeline này chỉ trích xuất văn bản, chuyển thành cấu trúc phân cấp và xuất ra document.

Đối với âm thanh và video, có một pipeline ASR (nhận dạng giọng nói tự động), và đối với các tệp PDF, có hai pipeline có sẵn. Standard pipeline có một số model nhỏ, tập trung thực hiện các tác vụ khác nhau như trích xuất văn bản, bảng và hình ảnh từ PDF. Bạn thậm chí có thể chọn một OCR back end để đọc văn bản, điều này đặc biệt hữu ích cho các tài liệu được quét không chứa văn bản thực sự. Vì vậy, tập hợp các model nhỏ này trong một pipeline thực hiện các tác vụ như phân tích bố cục (layout analysis), trích xuất bảng (table extraction), trích xuất hình ảnh (image extraction), mô tả (descriptions). Điều này mang lại cho bạn nhiều lựa chọn để khai thác tối đa từ các tài liệu đó. Ngoài ra còn có một pipeline VLM (vision language model), sử dụng vision model Granite Duckling 258 triệu để trích xuất tất cả trong một lần. Đây là một pipeline mới hơn, nhưng nó đơn giản hơn vì nó chỉ là một model duy nhất được huấn luyện đặc biệt cho tác vụ này. Duckling trích xuất văn bản và sau đó tạo ra một biểu diễn trung gian, một Duckling document, mô hình hóa cấu trúc của một tài liệu ở định dạng giống XML gọi là dock tags. Những dock tags này sau đó có thể được chuyển đổi sang một số định dạng bao gồm Markdown, HTML và JSON. Và Duckling cũng có một chunker sử dụng cấu trúc phân cấp được tạo bởi các parser và được tích hợp vào các dock tags đó để tạo ra các chunk văn bản được hiểu theo phân cấp.

Nhúng và Lập chỉ mục (OpenSearch)

Chuyển sang embeddings. OpenRAG thực sự không quá ràng buộc về embeddings. Nó hỗ trợ một số nhà cung cấp bên ngoài, bao gồm OpenAI, WatsonX.AI và Ollama cho các embeddings được lưu trữ cục bộ. Trên thực tế, toàn bộ OpenRAG có thể chạy offline bằng cách sử dụng các model được lưu trữ cục bộ. Bản thân Duckling có thể chạy offline, vì vậy nó có thể hoạt động trong các tình huống air-gapped; nó không cần các dịch vụ bên ngoài đó. Nhưng một khi bạn đã nhúng các chunk đó, chúng sẽ được lập chỉ mục trong OpenSearch. OpenSearch, tất nhiên, là phiên bản mã nguồn mở của Elasticsearch và là một cơ sở dữ liệu mạnh mẽ để thực hiện vector search và keyword search, cũng như có khả năng cấu hình cao. Nó cũng có khả năng lọc và tổng hợp (aggregation) có thể cấu hình cao. Ngay khi triển khai, OpenRAG sử dụng OpenSearch cho tìm kiếm vector và keyword lai và cung cấp khả năng lọc tinh vi đó để tìm kiếm mục tiêu hơn. Nó cũng hỗ trợ vector search trên nhiều embedding model. Điều này sẽ làm chậm vector search của bạn trong thực tế, nhưng rất hữu ích nếu bạn quyết định di chuyển các embedding model của mình như một phần của hệ thống. OpenRAG cũng thiết lập OpenSearch cho dự án mã nguồn mở thứ tư bí mật. Plugin nearest neighbors mặc định của OpenSearch cung cấp cho bạn các tùy chọn cho vector index HNSW hoặc IVF. OpenRAG sử dụng plugin JVector K&N theo mặc định. JVector là một vector index mã nguồn mở cung cấp cho bạn live indexing, và vì nó dựa trên disk K&N architecture, điều đó có nghĩa là toàn bộ chỉ mục của bạn không cần phải nằm hoàn toàn trong bộ nhớ, mang lại cho bạn nhiều tùy chọn hơn để mở rộng quy mô dữ liệu.

Điều phối dòng chảy (Langflow)

Tất cả những điều này sau đó được kết nối với Langflow. Langflow là một trình chỉnh sửa trực quan dạng kéo và thả cho các luồng AI (AI flows), và nó tích hợp Duckling, OpenSearch, cũng như tất cả các embedding model này, cùng với việc làm giàu dữ liệu (data enrichment) sâu hơn như một phần của ingestion process và pipeline đó. Chúng ta sẽ quay lại và xem xét sâu hơn về Langflow sau. Như vậy là về ingestion và indexing.

Tạo phản hồi RAG với Genetic Retrieval

Còn về phía tạo phản hồi (generation side) của RAG thì sao? Về phía tạo phản hồi, chúng ta thường không cần lo lắng về việc nạp tài liệu, và chúng ta đã biết rằng OpenSearch đang xử lý multi-vector hybrid search cho chúng ta. Nhưng chúng ta cần lưu ý rằng OpenRAG sử dụng genetic retrieval để thực hiện tìm kiếm. Điều này cũng được thực hiện trong Langflow và một lần nữa, cho phép bạn truy cập vào tất cả các loại model mà Langflow cung cấp. Vì vậy, ngay khi sử dụng, đó chính là OpenAI, Anthropic, Ollama, hoặc WatsonX.AI. Genetic search có nghĩa là gì? Thông thường, generation pipeline của RAG truyền thống sẽ lấy một query của người dùng, nhúng nó, sử dụng nó để thực hiện nearest neighbor search trên các chunk, và trình bày top K chunks cho LLM với hy vọng rằng câu trả lời nằm trong đó và model đủ thông minh để trích xuất. Với genetic retrieval, thay vào đó, chúng ta cung cấp query của người dùng cho một agent cùng với các hướng dẫn và tool mà nó có thể sử dụng để thực hiện nhiều tìm kiếm tùy theo yêu cầu. Model thực sự chịu trách nhiệm quyết định những tìm kiếm nào cần thực hiện và phải làm gì với kết quả. Vậy hãy cùng xem điều này hoạt động như thế nào.

Trải nghiệm thực tế với OpenRAG

Tôi có OpenRAG đang chạy trên máy tính xách tay của mình, và chúng ta sẽ cùng xem nhanh những gì nó có thể làm.

Giao diện Chat và Tool Calling

Sau khi bạn hoàn tất quá trình onboarding với OpenRAG và thiết lập nó, bạn sẽ được đưa vào một cuộc trò chuyện, và điều đầu tiên bạn có thể hỏi là, "OpenRAG là gì?" Và như bạn thấy ở đây, nó đã có câu trả lời, nhưng bạn cũng có thể thấy rằng nó đã thực hiện một số tool calling. Hóa ra câu trả lời cho "OpenRAG là gì?" đã có sẵn trong agent's prompt theo mặc định, vì vậy nó thực sự không cần thực hiện bất kỳ truy vấn tìm kiếm nào. Nhưng nó cũng đã lấy ngày hiện tại đề phòng, điều này khá tốt. Vì vậy, chúng ta có thể thấy chúng ta nhận được một câu trả lời từ nó, nhưng chúng ta cũng nhận được những gợi ý về các bước tiếp theo. Đó là những lời nhắc nhỏ (nudges). Điều đó cũng được cung cấp bởi Langflow. Và nếu chúng ta hỏi về điều đó để khám phá vai trò của Langflow trong việc xây dựng AI agent, thì bản thân agent sẽ tự đi tìm kiếm tài liệu đó và đưa ra câu trả lời. Và như vậy, bạn thấy, model, agent, đã sử dụng một số tool một lần nữa. Nó đã đưa ra câu trả lời. Nó cũng đưa ra thêm nhiều nudges.

Quản lý Tri thức

Vậy hãy cùng xem mục Knowledge section. Đây là nơi bạn thực sự tải lên dữ liệu, tài liệu của mình. Và bạn có thể làm như vậy bằng cách thêm toàn bộ một tệp hoặc toàn bộ một thư mục. Cũng có một nút sync ở đây. Chúng ta sẽ thấy điều đó trong một phút. Và bạn cũng có thể kiểm tra các đối tượng và tài liệu của mình ở đây, cũng như các chunk. Vì vậy, bạn có thể thấy rằng chúng đang được chunking như bạn mong đợi. Đây cũng là nơi bạn có thể tạo knowledge filters. Điều này tận dụng tính năng lọc trong OpenSearch. Bạn có thể tạo filter dựa trên nhiều tùy chọn khác nhau xung quanh dữ liệu bạn có trong hệ thống của mình. Và sau đó, điều đó cho phép bạn trong cuộc trò chuyện sử dụng các filter đó để chỉ nói chuyện với các tài liệu cụ thể. Đó là knowledge section.

Tùy chỉnh Cấu hình

Và sau đó, trong settings, chúng ta có thể đi sâu vào khả năng tùy chỉnh thực sự của nó. Ngay phía trên, có các Claude connector, nhưng để sử dụng Claude connector, bạn cần một user model, một số xác thực. Hiện tại chúng tôi thiết lập điều đó với Google OAuth. Vì vậy, bạn cần biết OAuth client và secret của mình ở đó. Sau khi đã thiết lập, bạn có thể kết nối với Google Drive, SharePoint, OneDrive. Và điều này cho phép người dùng của bạn kết nối với các thư mục tài liệu của riêng họ và cho phép OpenRAG đồng bộ trực tiếp. Tôi nghĩ điều đó thực sự mạnh mẽ. Nó giúp bạn không phải tải lên mọi thứ nhiều lần. Bạn chỉ cần đồng bộ hóa với kho tài liệu bên ngoài này và nó sẽ luôn được cập nhật. Chúng ta có thể thấy các model provider của mình. Bạn có thể cấu hình các API-based hoặc Ollama. Như tôi đã nói, đó là để chạy mọi thứ cục bộ. Và tôi đang chạy Ollama, và bạn có thể thấy tôi hiện đang chạy Granite4 3B, đó là một trong các model của IBM. Vì vậy, đây là language model của chúng tôi, và bạn cũng có thể thấy các agent instructions thực tế. Vì vậy, bạn có thể thiết lập system prompt của mình ở đó. Và sau đó, trong ingest section, bạn có thể thấy, tôi đang chạy Queen3 Embedding, 0.6B cho embedding model của mình. Cũng trên Ollama. Và bạn có thể đặt chunk size và chunk overlap. Và sau đó, những phần cuối cùng này là cài đặt Duckling, nơi chúng ta có thể quyết định: chúng ta có muốn capture table structure không? Vâng, hiện tại là có. Chúng ta có muốn chạy OCR không? Hiện tại thì không, hãy tắt nó đi. Và chúng ta có muốn extract picture descriptions không? Hiện tại thì tắt, nhưng đó là một tính năng hữu ích nếu bạn muốn trích xuất thông tin từ hình ảnh. Bởi vì việc thêm nhiều model vào pipeline sẽ làm mọi thứ chậm hơn một chút. Vì vậy, chúng hiện đang tắt.

Sức mạnh của Langflow trong Tùy chỉnh

Và sau đó, ngay phía dưới cùng có các API keys. Và đây là nơi bạn có thể thiết lập quyền truy cập vào OpenRAG dưới dạng API. Vì vậy, bạn có thể triển khai, bạn có thể sử dụng tìm kiếm hoặc agent của mình trong ứng dụng riêng. Nhưng hãy cùng đi sâu hơn nữa, nơi chúng ta có thể tùy chỉnh mọi thứ nhiều hơn. Bạn có thể nhấn nút "Edit in Langflow". Và điều đó sẽ đưa bạn vào việc triển khai thực tế của agent của bạn. Và vì vậy, hãy cùng phóng to. Chúng ta có thể thấy đây là agent của chúng ta.

Luồng Tạo Sinh và Công Cụ của Tác Nhân

Đây là luồng tạo sinh và trò chuyện. Tác nhân của chúng tôi nhận thông tin từ đầu vào trò chuyện này, đi qua một mẫu lời nhắc nhanh chóng, thêm vào các yếu tố về bộ lọc kiến thức, nếu bạn đã sử dụng chúng. Sau đó, tác nhân có một loạt công cụ. Các công cụ đó bao gồm: một máy chủ MCP để URL ingesta, đây thực chất chỉ là một luồng khác trong Langflow. Có một máy tính vì tôi nghĩ rằng các tác nhân và mô hình không nên thực hiện các phép tính số học. Chúng là các mô hình ngôn ngữ, không phải các mô hình toán học. Vì vậy, một máy tính luôn hữu ích. Và cuối cùng, công cụ cuối cùng là tính năng nhúng đa phương thức của OpenSearch. Tất cả các nhà cung cấp nhúng đều ở đây. Chúng ta có thể chỉnh sửa nó nếu bạn vào đây và chỉ cần mở khóa luồng rồi lưu lại, chúng ta có thể làm nhiều hơn với nó.

Ví dụ, chúng ta có thể lấy đầu vào trò chuyện này và có thể muốn đặt một số guardrails (hàng rào bảo vệ) vào vị trí. Vì vậy, chúng ta có thể lấy guardrails từ bộ components (thành phần) của mình ở bên trái. Sau đó, chúng ta cần phân tích kết quả của nó. Vì vậy, chúng ta có một parser (bộ phân tích). Nếu nó pass (vượt qua), chúng ta sẽ chuyển nó qua parser, lấy văn bản ra, đó là văn bản gốc đã được gửi vào. Sau đó, chuyển nó cho mẫu lời nhắc của chúng ta. Tôi đoán nếu nó fail (thất bại), chúng ta có thể gửi một thông báo lỗi đến đầu ra trò chuyện. Và như vậy là ổn. Và bây giờ chúng ta đã thêm guardrails vào hệ thống của mình. Chúng ta cũng có thể sử dụng các LLM và mô hình của mình ở đó. Và vì vậy, điều này có thể mở rộng tùy theo cách Langflow có thể hỗ trợ bạn.

Giới thiệu OpenRAG: Một Framework Nguồn Mở Mạnh Mẽ

Còn một điều nữa. Có một máy chủ MCP khả dụng cho OpenRAG cũng như một API. Vì vậy, bạn có thể sử dụng nó và chuyển nó cho các tác nhân khác của mình. Vậy RAG đã được giải quyết chưa? Chà, điều đó phụ thuộc vào dữ liệu và người dùng của bạn. Nhưng OpenRAG được xây dựng để giúp đỡ. Nó là một quan điểm về stack agentic (tác nhân) và open source (nguồn mở) bản địa cho RAG. Như đã nói trước đây, nó kết hợp Duckling, OpenSearch và Langflow để tạo ra một hệ thống RAG cơ bản mạnh mẽ được tạo thành từ các component nguồn mở. Và nó cung cấp nhiều không gian để tùy chỉnh trong stack đó để bạn có thể xây dựng RAG tốt nhất cho dữ liệu của mình và cung cấp ngữ cảnh tốt nhất cho các tác nhân của mình.

Hiện tại, OpenRAG đang ở phiên bản 0.4.0 và sẵn sàng để bạn trải nghiệm. Liên kết này hoặc mã QR sẽ đưa bạn đến dự án và chúng tôi rất mong bạn thử OpenRAG, để lại star trên GitHub và cho chúng tôi biết suy nghĩ của bạn.

Lời Kêu Gọi Cộng Tác và Kết Luận

OpenRAG cũng là nguồn mở. Front end là một ứng dụng Next.js. Mọi thứ khác là một ứng dụng Python. Vì vậy, nếu bạn thích giao diện của OpenRAG, chúng tôi cũng sẽ đánh giá cao phản hồi và đóng góp của bạn cho chính dự án. Các component của OpenRAG tất nhiên cũng là mã nguồn mở. Vì vậy, bạn có thể tham gia cùng Duckling, OpenSearch hoặc Langflow. Và cùng nhau, chúng ta có thể xây dựng một nền tảng RAG hoạt động hiệu quả cho mọi người. Nó cung cấp cho bạn các lựa chọn khi bạn cần và đưa ra các quyết định tốt cho bạn khi có ý nghĩa. Chúng ta có thể làm điều đó với các component nguồn mở một cách công khai. Đó là điều tôi muốn thấy.

Cảm ơn rất nhiều vì đã lắng nghe. Một lần nữa, tên tôi là Faunash. Tôi là kỹ sư quan hệ nhà phát triển tại IBM, đang cố gắng giúp xây dựng OpenRAG và hệ sinh thái ứng dụng agentic nguồn mở này. Và chúng tôi rất nóng lòng muốn thấy những gì bạn xây dựng với OpenRAG. Cảm ơn rất nhiều.