解決失業問題：DWP Digital 和 MongoDB 如何攜手合作，以增強開發人員的能力，並應付英國面臨的一些巨大挑戰

MongoDB
July 29, 2021
#Community

技術和企業是為了維持社會正向發展而存在。我們都有帳單要付，家庭要養，但除此之外，它遠比企業盈利更加重要。我也相信，開發人員尤其對一個組織所能取得的成績，包括社會影響和盈利水準，有著巨大的影響。英國就業與養老金部門的數位團隊 (DWP Digital) 是完美典範的團隊，該團隊理解並接受開發者人員在解決重大問題上可以發揮的重要作用。今年，我們有幸與 DWP Digital 及其開發人員合作，最終希望能夠應付英國面臨的一些巨大挑戰。

就業與養老金部門 (DWP) 是英國最大的公共服務部門。該部門負責向有需要的人提供政府援助，其中包括一系列福利，例如國家養老金、殘疾津貼等。超過 2200 萬位公民依靠 DWP 每年發放的 1680 億英鎊維持生計。

DWP Digital 團隊負責建置並支援使這一切成為可能的各種應用程式。他們運作 1,000 多個應用程式，並且據估計，他們已經為這些應用程式撰寫了超過 5,000 萬行程式碼。目前，DWP Digital 正在發生重大轉變，因為大部分最重要的工作已逐漸轉回到內部運作，而開發人員正在採用更敏捷的交付方法。其目標是提供更優質、更高效且更以客為尊的服務；如果沒有一支敬業、熟練和富有創造力的開發人員團隊，他們就無法做到這一點。

Hack the North:Hack the North：MongoDB 贊助 DWP Digital 的曼徹斯特基地黑客松 (Hackathon)

Hack the North

對於那些不明就理的人來說，黑客松(Hackathon)是一項讓開發人員有機會嘗試新技術、解決新問題和試驗新方法的活動。基本上，您會想從黑客松(Hackathon)中獲得三樣東西：學習新知、玩得開心，以及努力回饋社會。然而，在我們進入黑客松(Hackathon)之前，有些統計資料表示：曼徹斯特城及其周邊地區有超過 75,000 名失業者在此生活 (資料來源：DWP 的丘吉爾申請，2017 年 6 月)，整體失業率高於全國平均水準，居民失業率為 5.5% (資料來源： Nomis，官方勞動力市場統計資料)。科學、研究、工程和技術專業等領域的工作，僅佔曼徹斯特總勞動力的 4.69%。然而，該類別的職位空缺占公布的職位空缺總數的 18% (資料來源：2016/2017 年第一季度市議會經濟儀表板 )。

因此，當 DWP Digital 決定在 2018 年初曼徹斯特數位中心開業之前舉辦一場黑客松(Hackathon)時，他們想要解決的重大挑戰是顯而易見的。Hack the North 是一場為期兩天的公共黑客松(Hackathon)，專注於尋找解決方案，以協助解決該市的失業問題。它通常在場外進行，以便讓使參與者脫離日常活動的思維空間。那裡通常有很多食物 (披薩)、飲料和競爭性的玩笑。

The project board at Hack the North

Hack the North 的計畫委員會 由於 DWP Digital 是 MongoDB 在歐洲最重要的使用者之一，而且我們的開發人員宣傳團隊擁有舉辦黑客松(Hackathon)的經驗，因此我們的一些團隊與其他贊助商 ThoughtWorks 及 TechHub Manchester 一起支援這項活動。過去這幾年以來，我參加過好幾次黑客松(Hackathon)，老實說，這是我參加過最精彩的一次。所有參與者的想法、執行力和熱情，都非常的蓬勃煥發。

我們在現場有 70 多人，分為 10 個不同的團隊，每個團隊的任務就是在短短兩天內利用 Churchill (DWP 的公共資料儲存庫 – 也是建立在 MongoDB 上) 等公共來源的可用資料，開發出一個全新的就業解決方案。

最終的解決方案面面俱到、富有創意，並且令人印象深刻。我們擁有一切，從協助新失業者入職過程的引擎，到將簡歷和能力測試遊戲化的平台。然而，最終獲勝者是一支名為 UpSkill 的團隊。UpSkill 採用 MongoDB Atlas 建置了一個應用程式，可以將求職者的技能與雇主的要求配對，還有一個 API 允許求職者存取各種資源來提高他們的技能。這是一個非常靈巧、執行順暢的最終產品，在眾多創意中獨樹一幟。

誠然，我們還沒有完全解決曼徹斯特的失業問題，但在我看來，為期兩天的活動取得了巨大的成功，開發人員學到了很多東西，並建立了一些強而有力的概念驗證。如果想要瞭解更多資訊，請查看 #HackTheNorth Twitter 新聞 ，或我的評委同事 Dan Tanham (DWP Digital 的副主任) 撰寫的這篇優秀部落格貼文。

教學相長

直到您可以把所學傳授給別人，才是真正學會了這一課。除了黑客松(Hackathon)之外，DWP Digital 使其團隊保持在開發最佳作法前沿的另一種方式，就是讓他們在開發人員大會上進行演講。我們很高興有數十個 DWP Digital 團隊參加了去年 11 月在倫敦舉行的 MongoDB Europe 2017 ，但真正特別的是 DWP Digital 的首席技術官 Rob Thompson 發表了一整個上午的主題演講。

您可以在下面看到他演講的完整影片，您不會被他的論點所震驚。在概述了 DWP Digital 之後，Rob 談到了 MongoDB 和敏捷開發如何成為協助英國最大的公共服務部門轉變其資料基礎架構，並在養老金、健康、福利和分析方面建置許多旗艦級數位服務的關鍵工具。Rob 堅信，在大多數計畫中，開發人員是決定成敗的關鍵。

在分組討論中，Rob 的同事 David Parry 更詳細介紹了 DWP Digital 如何在雲端中使用敏捷開發、Java 和 MongoDB 來建立微服務架構。這種架構使得從概念驗證快速重複到數百個服務成為可能，因為它們在全國範圍內推出。遺憾的是，我們無法拍攝每場會議，因此如果您想觀看這種類型的演示，您只能親自參加今年稍晚舉辦的 MongoDB Europe。

與 DWP 數位團隊如此緊密合作的幾個月，是一段十分愉快的時光。他們不僅以令人難以置信的強大方式使用 MongoDB，而且更重要的是，我親眼見證了該組織是如何以開發人員為中心的。您可能很難相信大型政府部門會成為開發人員創新的孵化器，但值得慶幸的是，他們確實可以。事實證明，DWP Digital 與矽谷的精英一樣具有前瞻性、敏捷性和以一般使用者為中心的理念，而社會也因此變得更加美好。

在 DWP Digital Jobs Twitter 帳戶上瞭解有關 DWP Digital 職位空缺的更多資訊，或瀏覽careers.dwp.gov.uk。如果您想更深入瞭解 MongoDB 的開發人員重點和我們舉辦的活動，請跟隨我的帳號 @jdrumgoole。

← Previous

Intern Series: From MongoDB User to Return Intern - Meet Andy Mina

Andy Mina is a rising senior at the City University of New York. Last summer, Andy interned with us during the COVID-19 pandemic and impressed us enough to receive a return intern offer. He is currently working on the Node.js Driver Team, where he’s partnering with a fellow intern to revamp the program’s error system. Despite working remotely, Andy has made the most of his experience at MongoDB by engaging in meaningful work and forging lasting connections with his teammates. In this interview, you will hear about everything Andy has taken away from his two summers at MongoDB. Natalie Chwalk: Hey, Andy! I know you've been programming for a long time. Is that how you first learned about MongoDB? Andy Mina: I started programming in high school. I would make websites for school programs, local businesses, and every idea that popped into my head. The size of my projects began to grow, and the need for a database became very clear. MongoDB Atlas was unveiled around that time, and I gave it a shot. Since then, MongoDB has become my best friend for any programming adventure I embark on. While searching for summer internships my sophomore year of college, I wondered if MongoDB had any open positions — and, to my delight, it did. I was excited to give back to the community and product that had helped me so much already. NC: That's awesome! Why did you decide to intern with us? AM: As a programmer who has used MongoDB in my personal projects, I was stoked at the opportunity to contribute to the community. I enjoyed using MongoDB for projects, and I knew I’d enjoy working at MongoDB too. When I interviewed on-site for the final round, the future was clear: I wanted to intern here. I fell in love with the consistently welcoming people, the impact interns can make with their projects, and the company values because they mirrored my own. The office atmosphere and MongoDB’s work-life balance were also really appealing. I interned at MongoDB last summer and fell even more in love with the company, so I knew I had to return this summer. What's your favorite thing you've done at MongoDB? AM: I’m currently working on revamping the error system in the Node.js Driver. Previously, the driver threw only one general-purpose error with a message detailing where things went wrong. Warren, a fellow intern on the team, and I were tasked with coming up with a better error system for the entire driver. I really appreciate the independence the project has given us because the decisions we’re making contribute to the future of the driver. We’ve introduced new errors and we’re still refining everything so developers who use the driver can quickly identify and resolve issues in their code. NC: Wow! I'm so glad to hear you've felt empowered to do such meaningful work. Can you tell me a bit more about your team? AM: I’m interning on the Node.js Driver team, and I love it. The Node.js Driver is the official interface for JavaScript developers to take advantage of MongoDB. I used the Node.js Driver pretty regularly before joining MongoDB, so it’s a full-circle experience to come work on the product I’ve used. My current mentor, Neal, is amazing. He’s the best thing since sliced bread, and he’s one of the best mentors I’ve ever had. Plus, the team is super friendly and extremely passionate about the work they do, so it's a win-win. NC: What is the culture like at MongoDB? AM: In three words: exciting, inspiring, and, most importantly, really fun. It's so good to hear you've had a positive experience here. To close, what is your favorite part about interning at MongoDB? AM: MongoDB really cares about its interns. I’ve never felt like I was doing “intern work” or like I was a fly on the wall during team meetings. One of MongoDB’s core values is, “Make it matter,” and that definitely shines throughout the intern program. My favorite part about working at MongoDB is that interns are just as valued as full-time employees. I’ve been given impactful work that can make change. MongoDB’s summer intern events are also the best! I’ve made some good friends through intern events such as a virtual escape room, arts and crafts, and even a chocolate-making class. Besides the events, the speaker series MongoDB holds throughout the summer is super insightful. Everyone who has spoken so far has shared great career and even life advice. It’s also especially cool to hear that many full-time employees were previously interns! Interested in interning at MongoDB? Our 2021/2022 Software Engineering Summer Internship for the US is now live and accepting applications for students

July 27, 2021
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