教训

山城的秋老虎回山，凉爽不期而至。随着一阵阵凉风，新开发计划正式启动。

新计划功能很多，挑战也远大于以往的项目。尽管有心里准备，我还是没料到，第一天就碰上一座大山。

知识图谱，是新计划里的关键组成部分。内容生成方面，遇到很多内容失真，幻觉严重的情况。五月份的ai沙龙，让我认识到知识图谱的重要性。打个比方，知识库好比是药品库房，有海量的药品，知识图谱好比是处方，没有处方去药房抓药，效果可想而知。只有拿着处方，去抓药，药才有针对性。

后端一般的开发环境部署完成之后，马上着手知识图谱部署。neo4j部署非常顺利，采用容器化部署方式，几分钟便成功上线。看着眼前的页面，我内心深处掀起一阵狂喜，像是探险者发现一片新大陆。知识图谱原来我也只是听说过，并没有用过，没想到部署如此方便。后面便可以按图索骥、按方抓药，应该算是技术上的一次重大突破。

狂喜如同海面上的掀起的巨浪，到达顶峰后，瞬间又平息下来。部署完成llm-graph-builder后，连接图谱数据库，始终提示网络错误。看下官方文档，结果是全英文，看了几行，头就有些痛，再也看不下去。干脆去问大模型，大模型很快给出答案，进入容器内部，修改一番NGINX代理配置，重启容器。

依然失败，只不过错误代码更加详细。按我以往的理解，应该是跨域问题。再次去问大模型，大模型又给出解决方案。按照大模型给的方法，完成修改后，重启容器，结果照旧，还是无法访问。

万事通大模型的方法都无效，看来问题比较严重。不愿意去看官方文档，选择继续和大模型沟通。我把大模型当做专家，一步步拆分任务，一直聊到下午，问题还是没有解决。

临近下班时，大模型突然提出一个很复杂的方案，需要进入容器内部修改源码。看到方案，我心里嘀咕起来，作为一款成熟的开源软件，不应该让用户去修改源代码，有点违背常识。不敢轻易去修改源码，我带着遗憾下班回家。

回到家，也没闲下来。我换了个大模型接着聊部署的问题，一直聊到晚上十点，脑子里也没得到一个明确的答案。

第二天一大早，跑到办公室。什么也不想做，我直接打开业内公认编程能力最强的大模型，把报错日志发过去。果然术业有专攻，编程大模型三下五除二，就找到问题本源，两个容器不在一个网络中，无法跨网络访问。按照大模型给的方法，修改llm-graph-builder的网络，加入neo4j所在网络，终于连接成功。

连接成功后，我迫不及待地上传一个文件，测试知识图谱提取。看着处理进度条启动，我兴奋不已，这一步走通，便可以实现动态知识图谱抽取，更进了一大步。进度条刚走没多长，忽然弹出一条信息——提取失败。有编程大模型在，我没有慌张。照例把日志扔过去，没能拿到想要的答案，只得到一条今日试用额度已满的信息。无奈只有，转去用一般的大模型，几个大模型像是医生开会般，各种方法都有，来回一直折腾，始终无法成功。

“会哥，走吃饭。”门口传来一个声音，才让我认识到又是半天过去了。

索然无味中吃过午饭，回到办公室，面对着七嘴八舌的一群大模型，我一筹莫展。

专家太多，意见太多，也不是好事，反倒不知道怎么做了。

偶然间，鼠标一晃，停留在桌面ai编程工具图标上。看到编程工具，我顿时来了主意。干脆当做一个开发项目，让编程工具来调试。

编程工具调试，有很多好处。它能够看到整个项目的工程文件，而且还可以自动修改文件，省去很多复制粘贴的麻烦。说干就干，一切从零开始，删掉所有资料，重新部署。

可以读取全部文件，修改起来果然不一样。不到一个小时时间，编程工具就完成了修改。再次上传文件测试，进度条一阵滚动后，终于出现success的绿色字样。

总结下来，以后部署开源工具，遇到问题，不能去直接问大模型，最好用ai编程工具来调试。