解锁本地 AI：构建你自己的 Salesforce LLM 助手以提升生产力
我构建了一个 Salesforce Lightning Web Component，它允许您在 Salesforce 内的计算机上直接运行强大的 AI 语言模型 (LLM)。它使用 Pico LLM 技术在本地处理数据，确保您的信息安全并快速响应。您可以使用它来生成电子邮件、撰写内容、分析客户数据等，所有这些都不依赖外部服务。请查看演示视频和 GitHub 存储库 了解更多信息！
我一直在试验 Salesforce 内部的本地 LLM，并想向您介绍我由此开发的组件。它具有已经熟悉的聊天界面，该界面使用 Salesforce 记录作为上下文。它在您的计算机上本地运行，并且处理后的数据不会发送到任何第三方服务。
在 Agentforce 推出期间，它对我的组件产生了影响。Agentforce 使用代理——可以做出决策并执行各种操作的系统。相比之下，助手仅被动地处理信息。即使我相信可以使用 Pico LLM 构建本地代理，也需要付出巨大的努力。这就是我决定开发助手的原因。
功能
正如您期望 LLM 的工作方式一样，它会根据大量预先训练的数据生成关于任何主题的响应。此外，它还能够使用 Salesforce 记录来获取额外上下文。
- 适用于不同的模型。 您可以使用 Pico 网站上提供的任何开源模型，从 Gemma 到 Llama 和 Phi。这里唯一的限制是您的计算机拥有的 RAM 量。模型的重量越大，它消耗的 RAM 就越多。
- 适用于单个记录。 当该组件放置在记录页面上时，它能够访问该记录以获取上下文。例如，在客户记录详细信息页面上，它可以根据其字段值生成响应。
- 适用于相关记录。 可能会出现当前记录具有相关记录的情况。该组件可以查询任何类型的相关记录，并生成考虑到它们的响应。
- 可配置。 该组件可以使用配置弹出窗口动态配置。它允许更改生成选项，例如完成标记限制、温度和 top P。
工作原理
从最终用户的角度来看，一切都非常简单。您上传一个模型，选择一个系统提示，选择记录，编写一个用户提示，然后查看生成的最终结果。
什么是 Pico LLM？
在浏览器中运行 LLM 是一项资源密集型任务，这要归功于模型的大小、带宽要求和 RAM 需求。因此，Pico 团队开发了他们的 picoLLM 压缩技术，这使得在本地使用 LLM 对计算机来说更加高效。他们提供了 picoLLM 推理引擎，作为一个 JavaScript SDK，允许前端开发人员在浏览器中本地运行 LLM。它支持所有现代浏览器，包括 Chrome、Safari、Edge、Firefox 和 Opera。要了解有关 picoLLM 推理引擎如何工作的更多信息，您可以阅读 他们的文章。
LWC 部分
该组件充当用户和 PicoLLM 界面之间的桥梁。该组件的核心是一个以 iframe 形式存在的 visualforce 页面。该页面加载 PicoLLM SDK 并与 LWC 通信，允许后者通过 post 消息使用 SDK。所有元素的组合处理以下内容：
- 加载模型。 LWC 有一个按钮，允许您加载您选择的模型。它会触发 iframe 内部隐藏的文件输入元素。加载模型后，Pico SDK 会创建 Web Worker，并且该组件已准备好处理用户输入。
- 设置系统提示。 您不必每次都编写系统提示，只需将其保存为
System_Prompt__c对象的记录即可轻松选择。按下按钮后，它会显示一个弹出窗口，其中包含现有的系统提示供您选择。 - 接受用户输入。 有一个可调整大小的文本区域用于收集用户输入。收集后，它将作为有效负载发送到 iframe 并添加到对话历史记录中。
- 访问 Salesforce 记录。 有两个按钮：选择字段和选择相关记录。第一个按钮收集 LWC 所在的记录页面的记录的字段值。第二个按钮允许选择一个相关对象并查询其记录以及所选字段值。此信息也会作为有效负载发送到 iframe。
- 更改生成选项。 如果需要，可以通过组件中的专用按钮更改完成标记限制、温度和 top P 选项。此信息也会作为有效负载发送到 iframe。
- 生成结果。 当 iframe 收到有效负载时，它使用 Pico SDK 来利用已加载的模型并生成结果。如果提供了生成选项，则会考虑这些选项。此外，对话框正在更新，因此 LLM 将记住它的历史记录。
- 呈现聊天消息。 LWC 能够呈现传出的消息，这些是用户提供的消息。传入的消息（包含生成的响应）在组件对用户说任何内容后会动态呈现。例如生成的最终结果或信息和错误消息。
一点 Apex 代码
在后端方面，没有什么特别的。Apex 代码完成了所有与使用记录页面中的记录 ID 检测对象之间的关系相关的繁重工作。此外，它执行了几个 SOQL 查询，它的职责到此结束。
开发挑战
Web Worker
以前，我使用 unpkg 工具在 LWC 组件中执行来自节点模块的代码。这种方法导致了额外的配置步骤，并且是一种不太安全的工作方式。这一次，我希望直接从 Salesforce 执行 PicoLLM 模块，不仅从 Experience Cloud 站点，而且从 Lightning Experience 界面执行。
在后台，PicoLLM 使用 Web Worker 进行并行处理，这是主要问题，因为它不允许从 LWC 运行它们。幸运的是，没有人拒绝让我们从 visualforce 页面运行 Web Worker，这就是我使用的方法。
我下载了原始的 PicoLLM 代码，并将其添加为 visualforce 页面的静态资源。在 LWC 中，我使用了一个包含 visualforce 页面的 iframe。LWC 和 iframe 内的页面之间的通信允许我使用 Web Worker。该页面允许从 lightning web 组件触发与 PicoLLM 相关的代码。
使用 Salesforce 记录作为上下文
复制并粘贴 JSON 或 CSV 格式的 Salesforce 记录，将其输入到任何在线 LLM 中，然后观察。它将使用这些记录，将它们用作额外的上下文并生成响应。事实证明，在使用压缩模型进行本地处理时，这并非易事。
起初，我只是将记录以 JSON 格式直接放入用户提示中。然后，我期望它足够智能，能够区分提示本身和我提供的额外上下文。我使用了不同大小的不同模型，但无法理解为什么它没有使用 JSON 来生成响应。它大多拒绝响应我的提示，或者生成与我要求它做的事情无关的虚构数据。我开始尝试使用不同格式的上下文数据。我使用了 CSV 和 JSON，使用了提示分隔符来严格区分提示和上下文——但没有任何帮助。
由于主要功能不起作用，我准备放弃整个想法。几个月后，我突然有了一个愚蠢而简单的想法。如果我只是颠倒提示部分的顺序呢？从用户提示在前、上下文在后，到上下文在前、提示在后。令我惊讶的是，它奏效了，我使用的任何模型都立即开始理解用于上下文的 Salesforce 记录。
性能
该组件的功能在以下机器上进行了测试：
- 配备 AMD Ryzen 9 9900X 处理器和 32GB RAM (5600 MT/s) 的 PC。
- 配备 Snapdragon X-Elite ARM 处理器和 16 GB RAM (8448 MT/s) 的 Microsoft Surface Laptop 7。
模型加载速度——一切都与内存有关
使用该组件最耗时的部分是初始模型加载。您可能期望 9900X 轻松超越 Snapdragon X-Elite，但您错了。令我惊讶的是，后者更快。由于它具有更快的内存，我推测您的 RAM 越快，模型加载速度就越快。
响应生成速度
响应生成速度也是如此。据我了解，您需要拥有 CPU 和 RAM 的快速组合才能获得最快的生成速度。由于对于相同的用户提示，生成结果并不总是相同的，因此我没有测试其速度。
使用 GPU 如何？
确实，使用 GPU 生成响应会更有效。虽然可以使用 GPU 与 PicoLLM，但我自己还没有测试过这种配置。这有几个原因。首先，我相信它使用 WebGPU 功能，该功能在大多数浏览器中默认未启用（Edge 除外）。其次，它可能需要几千兆字节的 VRAM 来加载模型，而我没有。
结论
开发这个助手是一个引人入胜的探索之旅。从努力解决 web worker 的限制到发现提示顺序在提供上下文中的关键作用，这些挑战既具有刺激性又具有回报性。结果是一个 Lightning Web 组件，它提供了一种独特的方法，可以在 Salesforce 生态系统中利用大型语言模型的力量。
虽然初始模型加载时间可能是一个考虑因素，特别是对于较大的模型，但能够本地处理数据在数据安全性、响应能力和成本效益方面提供了显着的优势。潜在的用例，从自动化内容生成到提供智能帮助，是巨大的，等待被探索。
查看 GitHub 存储库。
