AI 的快速发展对世界产生了深远的影响，这是我们有目共睹的事实。如何利用好 AI ，在项目中赋能产生更多的价值不仅是领导需要考虑的，更是作为软件开发人员的我们需要思考的。
在我第一段实习经历中就遇到了 AI 相关的项目赋能问题。我们的项目本身是面向患者，吸引用户，为医院带来流量增长，提高医院的收入。那么如何实现这一目的呢？
领导认为，一方面是具体到每个科室，让患者主动填写自己的病状信息，由公司的运营部门同事持续跟进患者的就诊流程，引导客户实现高效的就医体验；另一方面可以大力推广医院的医生知名度，公众号、视频号的形式也好，海报展示的方式也罢，只要能推广医生所擅长的领域，让患者第一时间获取到有效信息是最重要的，做到精准投放。
因此，项目负责人打算开发一款名叫“××日记”的小程序，用户通过扫码或者链接、搜索等方式进入小程序，按照指引一步一步填写自己的信息，通过每日记录自己的指标数据实现陪伴式记录的效果。但是问题又来了，如果我只是单纯记录指标，用户凭什么用你的产品呢？市面上有那么多记录相关的产品。
也就是说，用户只记录自己的各项指标，虽然数据会以表格和曲线等形式直观展示给用户，但是产品本身没有自己的特色，虽然我们是在科室一线让用户填写使用，但是就诊完，用户就不会再使用了。
所以我们必须想出能吸引用户让患者买账的策略，实现产品赋能，冲出竞品之争行列。
我们将目光放到了内容解析上。用户所填内容只是单纯的数字，数字背后的含义涉及到医学等专业领域知识，患者并不能真正的了解自身状况，也就没办法做出符合自身情况的正确判断。
那么我们想到如果能为用户加入 AI 对话功能，AI 会获取你所填写的内容并提供给用户提问的机会，一问一答的形式既能解决用户的需求，也达到了我们的目的。这样一来实现逻辑上的闭环，有一定的商业价值。
领导在确定大方向后，开始为组内各开发人员分配相应任务。我有幸分到了 AI 对话功能模块开发的任务，接下来我将介绍一下我在整个开发过程中的所见所想所做的内容。
接到任务的当天下午，就开始对 AI 应用开发相关的技术栈进行调研。查资料还没十几分钟，项目领导就发来了一条链接，“小×，你看看这个 OpenSPG/Kag ，调研一下看看能不能用公司的服务器本地部署一下。”（相关链接我会贴在文章末尾）
对于一个刚来公司实习的小白来说，分到任务这件事本身就已经让我很兴奋了，现在鼠标还没点几下，领导就发来具体调研的方向了，还需要我本地部署，当时的内心又激动又害怕。
OpenSPG/Kag 这个开源项目是基于 python 实现的，他的目的是搭建自己的知识库 Kag ，通过外接大模型 API 实现一个企业级知识问答功能。官方文档也有说明内置的知识库适用于医疗图谱。确认好方案可行后，开始尝试部署。由于是第一次部署，我不希望因为自己的不熟练导致用公司服务器部署时出现问题，所以打算先在自己租的 2c2g 的轻量型服务器上试一试。不试不要紧，一试才知道问题有多大。首先我在调研 OpenSPG/Kag 没有第一时间去看它所需要的前置要求，官方文档上要求要在至少 8c32g 的服务器上才能启动
，我一个 2c2g 的轻量级服务器何德何能跑得起来。不出意外，意外就要发生了。拉取项目的 docker-compose.yaml 文件之后开始启动服务，Linux 可视化界面直接卡死，查看服务器后台管理页面，CPU 直接飙到 99% 。对于当时我来说，完全不知道该怎么做。冷静下来后查资料得知， top 命令可以把服务器占用 CPU 最高的一些服务列表动态打印出来，记下它们的进程号 PID，然后逐一 kill 掉直到服务器不卡顿为止。最终有惊无险的让 OpenSPG/Kag 停了下来。
之后我把 OpenSPG/Kag 相关的内容和涉及到的技术栈整理了一遍写成文档，然后在文档中着重强调当前公司的服务器硬件状态与文档要求的可能不太符合。如果部署，可能会对公司经费支出有一定影响，为后续的项目发展不利。
领导看后也觉得我的分析合理，决定弃用这个方案，让我继续调研。第二次调研，我找到了一个基于 Spring Boot 的开源依赖 deepSeek4j（官方链接在文章末尾），然后基于 deepSeek4j 我写了一个 Demo ，调用 DeepSeek 大模型实现一个简易的对话交互。下次汇报的时候向领导展示了一下，领导觉得效果可以，可以先保留，让我再继续调研调研。
第三次详细调研了字节的火山引擎相关产品。火山引擎的火山方舟不仅开放了 豆包 的一系列大模型还包括 DeepSeek 的 v3 和 r1 多个版本的调用接口。而且火山方舟的开发文档涉及到的内容很多，相对全面，包括单论对话、多轮对话、上下文缓存、图像识别等等功能调用方式。
领导得知后觉得字节的技术是可以信赖的，基于火山引擎开发确实可以快速出产品，功能也能得到保证，开发社区也很活跃。所以方案就这样定下来了。
在一周多的开发时间里，不断与开发同事交流，提需求、改需求，最终出了第一版测试。我在将测试版二维码链接发给领导的时侯，心里真的又兴奋又紧张。自己做的东西要交给领导过目，怎么不激动？后来又修改了几版，最终也得到了领导的认可。
目前实现的 AI 对话是完全基于大模型来做的，那么对于那些大模型没有学习过的数据，大模型是不会给出正确答案的，甚至会乱回答，出现”幻觉“现象。所以现在急需的是一种解决私域数据库的问题。
第四次调研考虑了 腾讯云的 LKE 大模型平台。在腾讯云 LKE 中，可以通过可视化页面来构建属于公司内部自己的私域知识库，结合大模型让 AI 对话回答的内容更细致、更精准。同时平台还提供了测试数据的召回率测试，我们整理了 100 条医疗相关的数据进行测试，发现正确率在 70% – 80% 之间。由于数据量的原因可能导致正确不够高，目前该功能我们还在测试阶段。
使用这种第三方的大模型管理平台最大的缺点就是数据泄露的问题。我们对接的是医院和患者，这些数据是需要保密的，那么放在第三方平台肯定是不安全的。所以依旧需要一种能够部署到本地的知识库技术。这部分内容依旧在持续调研中。
目前调研的结果主要是两个框架 Spring AI 和 LangChain4j ，它们都是 github 的开源项目，提供了一些拆箱即用的方法，目前版本都已更新到 1.0.0 ，开发团队还在持续迭代，包含的功能也在持续丰富。虽然对于企业来说，目前还处于玩具状态，但是有一定的跟进价值。
感谢您的观看~~
本文相关链接：
No responses yet