恭喜 2023 年 MongoDB 亞太地區創新獎得主

Sahir Azam
March 30, 2023

我很高興在此宣布 2023 年 MongoDB 亞太地區創新獎的九組優勝團隊。MongoDB 創新獎是為了表揚勇於挑戰的專案及人員，他們以前所未有的手法運用資料，建立非常實用的應用程式，而這些專業人士的創意，拓展了 MongoDB 技術的應用框架。今年比賽以區域做區分，是因為我們知道亞太地區有許多橫跨不同產業的公司，有的是新創、有的是業界領先企業，他們的共通點是勇於挑戰和創新，並努力交出更漂亮的成績單。以下是今年的創新獎得主：

2023 年 MongoDB 亞太地區創新獎得主：

正面影響 (Positive Impact)
Open Government Products

Open Government Products (OGP) 是新加坡政府內部的團隊，由一群工程師、設計師及產品經理組成。團隊負責為公眾福祉建構相關的技術。。OGP 使用 MongoDB 的開發者數據平台 MongoDB Atlas，建構了數位表格生成器 FormSG。新加坡政府及公共醫療單位透過使用 FormSG ，在安全的環境下，搜集民眾、店家及公司的資料，協助政府人員快速建立政府數位表單。FormSG 取代了過去可能會造成資料安全及隱私問題的紙本表單以及人工處理文件的過程。而在新冠疫情期間，因為有 FormSG，政府人員得以搜集每日超過十萬筆的全國每日體溫申報。現在有來自 155 個單位、超過 12 萬名的政府人員使用 FormSG，建立超過 50 萬份數位表單，幫助政府搜集來到新加坡的旅客的旅遊及健康申報，同時也應用在新冠肺炎檢驗和資金補助上。

組織轉型 (Organizational Transformation)
Bendigo and Adelaide Bank

Bendigo and Adelaide Bank 是澳洲最大的銀行之一，擁有約 7000 名員工，服務超過 220 萬位客戶，協助他們達成財務目標。班迪戈銀行目前正在執行多年的轉型計畫，透過 MongoDB 的開發者資料平台改善工作效率，滿足客戶要求，提供更好的使用體驗，以期望能成為澳洲銀行的第一選擇。

近期雲端團隊推出事件導向的架構 Ready-Set-MongoDB (RSM)，允許開發人員簡化內部或外部API的使用，並自動應用數據轉換和存儲到他們選擇的MongoDB叢集中。而有了 MongoDB Atlas Search，銀行的開發者可以從多雲部署中汲取洞見，找出可節約的成本，並提供帳戶所有人和技術資源相關資產庫存。

推出這項計劃的前 18 個月裡，自動化替組織的工程師省下了 1100 個工作天，同時也降低人工介入、移除過時資料，讓工程師可以關注在更重要的工作上。因為Bendigo and Adelaide Bank多雲上出現的新挑戰，而且 MongoDB 也推出了新產品，所以 Ready-Set-MongoDB 的研發仍是進行式，不斷調整及改善。這項應用可以體現班迪戈銀行資訊部門是如何應用現代技術、快速開發以及創新為導向的問題解決方法，推動組織轉型。

醫療英雄 (Heroes in Health)
Redcliffe Lifetech Private Limited

在過去幾年的時間裡，Redcliffe Labs 成為印度成長最快速的科技診斷服務供應商。瑞德克利夫實驗室的願景是在 2030 年透過融合技術和具世界規模等級的實驗室，服務五億印度人。他們已經在 180 座城市設立超過 73 間實驗室，以及約 1500 間的現場掛號中心，每天服務上千名的病患。

Redcliffe Labs仰賴 MongoDB Atlas 靈活的文件模型製作創新智慧健康報告，提供病患一系列指標及追蹤方式，了解整體健康狀況。MongoDB 開發者資料平台擁有等級最高的資料安全、合規性以及隱私管理，Redcliffe 團隊得以安心處理最敏感的病患資料。

MongoDB Atlas 可以自動處理許多傳統資料庫管理上的挑戰，因此開發者不需要花太多時間在管理資料庫，而是專注在為病患建立診斷。Redcliffe Labs 專注於診斷的領域，研究如何將下一代技術整合至 AI 平台，提供病患具互動性的診斷報告、進階的健康檔案及更詳盡的診斷及健康警示。

產業改革者 (Industry Disruptor)
國泰航空 (Cathay Pacific)

國泰航空是香港本土的航空公司，目前在全球航行超過 60 據點。這間航空公司正在努力成為第一間真正執行駕駛艙無紙化的航空公司。直到最近，一班從香港飛往紐約的班機，機組人員還需要在飛行之前，看超過 150 張印刷文件和航圖，並在航行過程中不停更新資料。

2019 年時，國泰航空進行首次無紙化飛行，節省重達 50 公斤的手冊、航圖、地圖和班機簡報文書工作。這項壯舉是透過一個高度客製化的 iPad 應用程式：Flight Folder。Flight Folder 是以MongoDB Atlas 建構而成，為的是改善飛航簡報體驗，MongoDB 協助將數十種資訊來源整合至一個平台，讓機組人員可以輕鬆與彼此分享體驗。應用程式中同時包含電子化加油功能，幫助機組人員在加油策略上更有效率，節省大量的飛行時間和成本。而 MongoDB Device Sync 功能則可進行無縫同步，就算應用程式在飛航過程中斷線也不會遺失資料。

自從發布 Flight Folder 之後，國泰航空駕駛艙內完全無紙化的班機已經超過 34 萬班次，除了大大改善機組人員的工作體驗之外，飛行時間也跟著減少，數位加油平均節省了 8 分鐘停留在地面的時間，同時也幫助公司減低了 1.5 頓的碳排放。

從批次走到即時 (From Batch to Real-Time)
阿達尼數位實驗室 (Adani Digital Labs)

基地位在印度的數位創新公司阿達尼數位實驗室，是極具規模性的阿達尼集團的一部分。這間實驗室團隊宗旨在於建立一個單一的平台－稱為 AdaniOne 的超級應用程式，為印度眾多的故事發聲。

為了滿足不同的使用案例，加上這個超級應用程式的規模龐大，阿達尼數位團隊選擇MongoDB Atlas 作為主要的交易式資料庫，進一步增強 AdaniOne 的功能。

這個應用程式的重要任務是集中分散的資料，提供單一活動檢視頁面。在第一階段，開發者得以批次取出資料，再送進資料庫中。不過這麼做的速度太慢，而且就業務需求也無法預測狀況。除此之外，整合客戶歷史、訂單、庫存及供應鏈網絡的單一檢視畫面，可能會影響客戶的營收能力。

為了找到更好的解決方案，阿達尼數位實驗室建構與 MongoDB 相符、更現代的架構。有了MongoDB's Change Streams 和資料平台的原生 Kafka Connect，他們建構出事件導向的架構，取得可進行分析的即時資料。阿達尼數位實驗室的超級應用程式仍在草創的階段，而 MongoDB 的開發者平台可以繼續幫助公司成長並即時產出洞見。

產業 4.0 (Industry 4.0)
東華 (Dongwha)

東華集團創立於 1948 年，已經由專注於木材產業，發展成為橫跨建築材料、化學品和媒體等多個領域的全球領頭公司。

東華的數位轉型計畫其中一部分是工廠智慧化，改善並提升生產效率。東華透過建立創新的智慧工廠軟體平台，搜集並分析資料，提升品質及生產管理能力。

最初，該平台是使用 MongoDB 的社區版本構建的。 不過為了擴大規模及提升應用程度，團隊近期遷移至雲中的 MongoDB Atlas。這一改變可以用最快的速度及最高的安全性儲存大量資料，優化時間序列資料的解決方案，並更容易運用資料進行機器學習。

東華的遷移過程非常順利，沒有發生任何工廠中斷或停機，目前已經應用在五間不同的工廠。在去年一整年，該應用程序的可用性和可靠性顯著提高，而且工廠業績已經成長六倍。 東華展望未來，計劃在國外的工廠應用這個平台。

數位原住民 (Digital Native)
myBillBook

印度擁有 6000 萬間中小型企業，但其中只有非常小一部分進行電子化，大多數依舊用最原始的方式做生意。除此之外，許多印度企業目前也仍深受不穩定的網路服務、電力中斷及延遲所困擾。FloBiz 的任務就是與 myBillBook 一起改善這個狀態。myBillBook 是一款一站式解決方案，幫助中小企業建立商業發票、管理股票、收取費用、透過智慧銀行進行自動化提示、與客人互動、管理人員出席及工資，還可以匯出超過 25 種不同的會計及決策商務報告。這款應用程式的設計是以行動裝置為導向，因此企業主只要透過手機和平板就能使用，而且不管是線上和線下的環境都能進行帳單和庫存管理。

myBillbook 是由 Mongo DB Atlas 技術支援，為企業提供靈活性及擴展性，可方便建立新功能及複雜的分析查詢。除此之外，資料平台中的行動資料庫 MongoDB Realm，支援線下使用及同步，確保不會因為網路訊號不好，造成資料遺失或是功能無法使用。這款應用程式成功支援客戶進行重要的商業營運，現在在印度有超過 6500 萬企業主使用 myBillbook 進行建立帳單、會計、收款以及促使業務成長。

客戶導向 (Customer Focused)
開泰商業科技集團 (KASIKORN Business-Technology Group)

開泰銀行(KBank)成立於 1945 年，是泰國規模最大且最古老的銀行之一。其任務為提供最佳服務，盡力滿足每一位客戶在生活和商務上的需求。開泰銀行其中一間子公司，開泰商業科技集團(KBTG)研發了一款行動金融應用程式，MAKE by KBank。MongoDB 的靈活性及方便開發的特性，讓 MAKE 研發部門可以依照任務選擇最適合的資料庫，也能使用 Atlas Online Archive 自動化進行資料分層，降低日常維護的工作時間，團隊因此有了更多時間專注在推出創新且獨特的功能，像是 Cloud Pocket，使用者可以無限客製化不同的資金用途，自己進行分配；另一個功能是 Pop Pay，使用者可以點擊位在附近的朋友大頭照，直接匯錢過去；另外是分析消費的功能 Expense Summary，幫助提醒及管理使用者的資金使用習慣。時至 2023 年 1 月，MAKE 已經擁有超過一百萬用戶，而過去一年，MAKE 上的交易數量已經從 90 萬筆成長至 750 萬。

大型規模 (Massive Scale)
中國移動 (China Mobile)

中國移動透過其橫跨全國的行動通訊網絡，提供行動語音及多媒體服務，服務地區包含中國和香港。以總用戶數計算的話，是目前是全世界最大的行動網路業者。

這個行動通訊龍頭使用 MongoDB 支援其最大且最重要的推播服務，每個月向超過十億的用戶，寄送帳單明細。在應用 MongoDB 之前，技術團隊使用的是 Oracle 的服務，但用戶開始增加，服務性能卻開始走下坡。雖然投入了大量的資金，但是在像是完成及送出帳單這類的簡單請求，所需時間還是過長。在 2019 年時，中國移動進行全方面的測試之後，決定遷移至 MongoDB。MongoDB 的原生資料分片帶來的優勢，讓整體性能提升了 80%，而且同樣的工作量原本是由 50 台 Oracle 機器進行，現在降為 12 台。目前服務專注在當前需求上，並可以隨著未來增長進行擴展。

中國移動在 MongoDB 的支援下，穩定增加超過 1.68 億每月用戶，也成為中國移動集團中，擁有最高客戶滿意度的公司之一。

← Previous

Three Ways Retailers Use Search Beyond the Ecommerce Store

When consumers think of retail search, the first thing that comes to mind is typically the search bar of an ecommerce website. This is for a good reason: a Salesforce commerce study shows that 87% of shoppers begin their shopping journey in the search bar, and Forrester has found that as many as 68% of shoppers would not return to a site that provided a poor experience. But retailers that exclusively focus on search capabilities in the context of ecommerce are missing out on huge benefits in customer experience and workforce efficiency. To drive fast application experiences, the querying and indexing of data sets is vitally important, and can be a game changer for easy performance optimization. Let’s explore some of the innovative ways that retailers are using search indexes to super-power their application experiences. Why search is important across retail organizations Large retail data sets, like product and customer data, are used by both customer-facing ecommerce or loyalty applications and internal use cases: inventory management, stock management, customer care, purchasing, supplier and vendor management, marketing and more. Customers using ecommerce search bars typically have an excellent “Google-like” experience with auto-complete, faceting, fuzzy matching, etc., but the retail workforce and back office staff often aren't given the same luxury. These internal teams are trying to work efficiently, but they are stuck using front ends powered by a traditional operational database with no search indexing capabilities. These teams are missing out on a search engine that is optimized for unknown or unpredictable workloads. Search indexing will speed up queries where the input is user-defined or might be searching across multiple fields. Let’s look at a comparison: FIgure 1: Database Query vs. Search Query For these under-served and often overlooked use cases, retailers need a quick and cost-effective solution to adding search, like MongoDB Atlas Search. Adding a search index to an application can be done in minutes, without creating operational complexity. MongoDB manages the spin up and management of the backend Apache Lucene search engine, and the complex data and index synchronization activity. Figure 2: MongoDB Atlas: Integrated database and search The three most common use cases for retail The easy addition of search can optimize application performance and usability in the retail industry in three important areas: In-store workforce applications Back office inventory and assortment Customer servicing Figure 3: Example Search use cases in three retail industry areas In-store workforce applications Speed is important in workforce applications, because these interactions happen in real time. Think of an in-store customer spelling out a name in full at checkout for a grocery purchase to be added to a loyalty account. This could add five minutes to a checkout experience, disincentivizing the customer to engage with the loyalty program. Now imagine that the same checkout attendant can identify the customer by any number of data points, not only loyalty number, but also name, first line of address, email, etc., with faster lookup through auto-complete and fuzzy matching. A retailer that MongoDB works with does this auto-lookup in store with Atlas Search in 200-300 milliseconds for optimum customer satisfaction. Customers and staff also can have difficulty remembering or correctly identifying products. A DIY amateur or a new employee can’t be expected to know the exact name or product ID. This is a great use case for search indexing as we do not know the field in the document or the product attribute that we are querying against. MongoDB has customers that stock more than 150 million products. Strong typo tolerance makes life easier for everyone. Back-office inventory and assortment Flawless purchasing and stock management ensures brick and mortar and online stores get the right inventory at the right time to maximize sales and reduce wastage or deadstock. An operator responsible for distributing products into categories will define in which store shelf a product needs to be and adjust this depending on customer behavior and contractual changes with the supplier. Inventory applications will be used on a daily basis by every operator. These are small internal applications that can have a huge impact on the overall business, but are often overlooked by large IT programs for budget or have a smaller IT team. These teams are adopting Atlas Search because they can get it up and running in as few as three weeks and fully integrated into their application without taking on more operational overhead. Customer servicing Long call center or chat conversations wait times have high operational costs and cause customer churn. It is vital to identify the customer as quickly as possible by the data they provide: order or customer ID, phone number, store address, etc. Retailers who have created a “Customer 360” across their customer relationship management and loyalty systems have created a large complex pool of data. The ability to run a single query to search across all available attributes makes it much faster to identify a customer. Search can also be used to optimize speed and accuracy of results for chat applications and chat bots who have to answer a large volume and variety of questions. This is a perfect use case for search with unpredictable user inputs. If answers to the questions can be searched across the entire knowledge base, speed and relevancy can be improved. MongoDB has retailer customers building chatbot applications for internal use cases like an IT team answering common questions, and external ones. For example, on the ecommerce homepage, a chatbot needs search functionality to be able to quickly do product lookup, customer identification, or make a suggestion. Quick and easy search implementation will add to the customer experience and reduce staff operations. Where your company could add search functionality It’s time to think beyond the ecommerce search bar. What are the search workloads within your company’s retail estate? Are there internal applications that have your frontline or back-office staff frustrated with inefficient lookups? Is the reason you’re not implementing search today the fact that it's a heavy lift to add an additional technical component to your architecture? These are the types of conversations that are driving adoption of Atlas Search across the retail industry, as businesses persevere in a tough macro-economic climate to do more with less. Adding vital functionality to applications without adding complexity is a win for the retailer, the workforce and the consumer. Want to learn about how MongoDB has integrated Search into the Atlas Developer Data Platform? Head to the Search solution page to explore more technical and in-depth resources.

March 29, 2023
Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024