人工智能技术和医疗保健系统的持续融合带来了许多引人注目的进步。让我们来设置一下场景。如果您与 ChatGPT 等动态模型进行过交互，您可能会像我们许多人一样，开始使用您独特的数据集设想其应用程序。假设在医疗保健领域，您希望将此技术与电子健康记录 (EHR) 或电子病历 (EMR) 链接起来，或者您的目标是使用 FHIR 的资源来增强互操作性。 这一切都归结为我们如何与市场上可用的法学硕士传输/接收上下文数据。
更准确的技术包括微调、仅使用上下文数据集训练法学硕士。不过，今天要实现这一目标需要花费数百万美元。另一种方法是通过一次性或几次查询向法学硕士提供上下文并获得答案。实现此目的的一些方法包括：生成 SQL 查询、生成查询/解析代码、使用 API 规范中的信息进行调用等。但是，存在代币消耗高的问题，其中一些答案可能并不总是准确的。
这里没有一种解决方案适合所有魔法，但了解这些技术的优缺点有助于制定自己的策略。此外，利用良好的工程实践（如缓存、辅助存储）并专注于解决问题可以帮助在可用方法之间找到平衡。这篇文章试图分享一些策略并在不同指标下对它们进行比较。
首先，我们有更常规的方法——通过LangChain加载并解析SQL数据库结构和示例内容并执行GPT查询。这种方法在促进与我们的医疗保健系统进行高效、动态的沟通方面有着良好的记录，使其成为我们行业中经过验证的技术。
有些解决方案仅传递数据库结构（例如表架构），而其他解决方案则传递一些经过编辑的数据以帮助 LLM 生成准确的查询。前一种解决方案具有固定令牌使用和可预测成本的优点，但由于不完全上下文感知，准确性受到影响。后一种解决方案可能更加密集，并且需要特别注意匿名化技术。 这些解决方案可能非常适合某些用例，但是否存在更优化的策略？
另一种复杂的技术是让法学硕士生成代码将问题分解为多个查询或 API 调用。这是解决复杂问题的一种非常自然的方式，并释放了自然语言和底层代码相结合的力量。
此解决方案需要良好的提示工程并微调模板提示，以便适用于所有极端情况。由于令牌使用、安全代码生成以及控制生成的代码可访问和不可访问的边界等方面的不确定性，将此解决方案融入企业环境可能具有挑战性。但总的来说，这种技术自主解决复杂问题的能力是令人着迷的，并且该领域的进一步进展值得期待。
我们的团队希望尝试一种不同的方法来控制令牌的使用，同时也利用可用的上下文来获得准确的结果。使用LangChain来加载和解析FHIR的OpenAPI规范怎么样？ OpenAPI 是一个有影响力的替代方案，配备自适应和标准化程序，验证了 FHIR 综合 API 标准的重要性。其独特的优势在于促进不同系统之间轻松的数据交换。这里的控制在于能够修改规范本身，而不是 LLM 的提示或生成的输出。
想象一下场景：POST API 在将数据添加到数据库之前执行所有必需的验证检查。现在，设想利用相同的 POST API，但使用自然语言方法。它仍然执行同样严格的检查，确保一致性和可靠性。 OpenAPI 的这种性质不仅简化了与医疗保健服务和应用程序的交互，还增强了 API 的可理解性，使它们易于理解和预测。
我们知道该解决方案并不具备与自动分解任务或生成代码相同的能力，但这是为了找到一个更实用的解决方案，可以快速适应大多数用例。
虽然所有这些技术都展示了独特的优势和服务于不同目的的潜力，但让我们根据一些指标来评估它们的性能。
1. 可靠性 - 考虑到我们与 AI 的联盟，优先考虑可靠性，OpenAPI 由于使用标准化 API 而具有优势。这可确保限制未经授权的访问和对特定数据的精确用户身份验证，与通过 AI 生成的 SQL 进行数据库访问相比，提供增强的数据安全性 - 这种方法可能会引起可靠性问题。
2. 成本 - FHIR 定义的 API 过滤功能的效率在降低成本方面发挥着作用。这仅允许通过密集的即时工程简化的必要数据进行交易，这与传统数据库不同，传统数据库可能会返回超出所需的记录，从而导致不必要的成本激增。
3. 性能 - OpenAPI 规范对数据的结构化和标准化表示通常有助于 GPT-4 模型的卓越输出结果，从而提高性能。但是，对于直接查询，SQL DB 可以更快地返回结果。由于定义的参数多于查询所需的参数，因此必须考虑到开放 API 可能会过度告知。
4. 互操作性 - OpenAPI 规范在互操作性方面表现出色。它们独立于平台，与 FHIR 的使命完美契合，即提高医疗保健领域的互操作性，营造与其他系统无缝同步的协作环境。
5. 实施和维护 - 虽然分离数据库并为 AI 提供查询上下文可能相对更容易，使得 SQL 数据库加载方法及其精益控制层看起来更容易实现，但 OpenAPI 规范一旦掌握，其带来的好处包括标准化和更容易维护，这些好处超过了最初的学习和执行曲线。
6. 可扩展性和灵活性 - SQL 数据库需要严格的模式，可能无法轻松实现可扩展性和灵活性。与 SQL 不同，OpenAPI 提供了更具适应性和可扩展性的解决方案，使其成为面向未来的替代方案。
7. 道德与担忧 - 鉴于人工智能的快速发展，这是一个需要考虑的重要但复杂的因素。即使使用过滤器和身份验证，您是否愿意向客户提供直接数据库访问？反思数据去识别器在确保医疗保健领域隐私方面的重要性。尽管 OpenAPI 和 SQL 数据库都有解决这些问题的机制，但 OpenAPI 提供的固有标准化增加了额外的安全层。
虽然本讨论提供了一些需要考虑的关键因素的见解，但必须认识到 SQL、代码生成和 OpenAPI 之间的选择是多方面的，并且取决于您的项目和组织的具体要求。
请随意分享您对此主题的想法和观点 - 也许您还有其他要点要建议，或者您想分享一些最适合您的用例的示例。
以上是使用法学硕士而不烧钱——不同的数据库查询策略的详细内容。更多信息请关注PHP中文网其他相关文章！
