前言

        这周也是杂七杂八的一天（高情商：我是一块砖，哪里需要往哪里搬），首先是接触了jemter这个压力测试工具，然后帮公司的AIGC项目编写使用手册和问答手册的第一版，并通过这个平台的智能体实现知识库问答的功能展示，以及部分个人扩展和思考（NEO4J创建知识图谱的GraphRAG）。

Jmeter

        Jmeter是一个压力测试工具，一开始导师叫我熟悉的时候我还说这和postman差不多吗，但实际用下来，Jmeter的压力测试提供了很多自定义的请求内容和方法，和postman差别是很大的。虽然说因为公司这边和学校是有对接项目的，所以开学这段时间，有些项目他们那边的运维搞不定就又到我们这边了，虽然我感觉再给我压力跑跑也没什么太大的实际上的有用。。。

        jmeter去官网下载后，如果你的本地的java环境已经部署好的话，是可以直接跑的比较全的教程，包含配置环境 如果想尝试的，其实可以通过本地部署若依的网站进行测试（强烈建议不要在部署环境运行jmeter的测试），当然你也可以用其他的网站实现。

        在很多的网站中，其实在用户登入的过程中，不仅后台要忙前忙后，不知道呆在哪的数据库也有的慢，通常同一时间的并发实现登入过程，是对整个体系很大挑战，同理像学生选课需要频繁与数据库沟通也是如此，但一般情况下不会有这么大的同一时间访问量，但我相信大家都经历过四六级和选课。此时一般来说暂时的增加算力和流量都是一个不错的方法。

        在若依的网站中，通过登入界面来测试这个过程其实是一个不错的方法，首先摆在我们面前的就是验证码，其实这也是一个很好的保护措施，你也不想未来有一天你的网站数据库因为别人的自动化工具跑暴力解密跑死或者泄密吧。

        通过对项目内查询该网页的组件可以找到相应的功能模块https://blog.csdn.net/Li_Ning21/article/details/136713227 关停验证码功能

        我们在ruoyi-admin\src\main\java\com\ruoyi\web\controller\common\CaptchaController.java文件里面看到验证码的生成过程，是先生成验证码，再通过验证码生成图片，图片再通过流传输发送信息给前端。所以想要压力测试登入界面，就得关停验证码功能。

其他相关测试（JSEncrypt加密登录，类似的思路可以测试RAS，就是之前提到的若依的数据监控密码）

        【jmeter参数化--json格式非扁平化(存在嵌套)

        注意我们可能会在测试时发现，大量的sql请求可能使数据库反应不过来，因为超出了设置的最大请求数和缓存量等，这就需要更改相关的配置（conf）。（csdn很多相关教程，这里不再赘述）

通过LLM利用RAG实现知识库问答

        讲实话，其实并不是通过自己所写代码实现的（当然不），而是利用公司这个项目中的AIGC功能实现该项目自身使用手册进行装载，实现平台使用小助手的功能。

        其实该功能类似于coze以及文擎毕昇（就是用它的开源），一开始首先是通过简单将文档载入实现知识库的创建，以及知识的分片。但实际效果并不理想，回复不可控，容易出现不相关内容，容易胡说，失忆给定限定和角色。

        对于这些问题，尝试通过知识库增加提取限定关键词，预防胡说，对问题语义分析，实现检索召回对用户输入的问题生成3-4个含义相同但表述有差别的问题，再对这几个问题分别进行检索，实现回答内容的更大相关性和准确性，通过加入记忆器，存储之前的对话，尽可能避免出现失忆，限定token量。

        但实际情况下token量仍然不小，对后台的压力也不小，大量的访问估计很能顶住，而且模型的不同，对效果的实现也有不同，虽然通过多次限定和调整，但4o的能力仍然比其他国内大模型更强。原先通过构建智能体实现网页平台小助手的挂件功能估计也不会最后在未来的正式版中出现，可能以功能展示的方式展示。

        

 题外话：NEO4J创建知识图谱的GraphRAG

        这东西说来也奇妙，上面这些东西和主管交流后，主管说这些情况也比较正常，现在能比较好实现效果的也是微软开源的GraphRAG。

        说来也奇妙，看完相关的博客和文章后，有一种深深的熟悉感，在前几个月的课设，我的舍友拿着他不知道拿来的py项目问我会不会搞，没办法，当时确实不会搞，但是现在拿出来把这个项目自己过一遍，发现居然是思路相仿的基于知识图谱的NLP，其实GraphRAG就是利用了LLM的模型，以及embedding模型将原有的知识库转换为知识图谱，在网络社区和现有知识图谱中检索资料。

        因为这是别人的项目，我也不好直接放出。我只能说一下思路。

        加载（技能类别和职责类别的）特征词，并构建用于匹配这些特征词的 AC 自动机（Aho-Corasick automaton）。AC 自动机来识别问题中的特征词，并构建一个包含这些特征词及其类型的字典。

比如说，职位招聘公告问答流程NLP的知识图谱检索

1. 用户输入问题：

   用户通过界面提出关于职位招聘的问题，例如“信息工程师需要哪些技能？”或“信息工程师的主要职责是什么？”

2. 系统通过分类器识别问题类型：

   利用自然语言处理技术，系统识别问题中的关键字和意图。例如，通过识别“技能”、“职责”等词汇，系统可以判断问题关注的是职位的技能要求还是工作内容。

3. 分析器构建查询语句：

   根据问题类型，系统构建相应的查询语句。在知识图谱中，这可能涉及到构建针对特定实体（如“信息工程师”）及其属性或关系的查询。

4. 在数据库中检索答案：

   使用构建的查询语句在知识图谱数据库中检索信息。知识图谱存储了丰富的实体和关系数据，使得系统能够快速找到相关的信息。

5. 格式化答案并呈现给用户：

   检索到的信息需要被格式化，以清晰、易于理解的方式呈现给用户。这可能包括整理数据结构、优化语言表达等。

知识图谱（KG）的应用

        与普通的RGA不同点在于，图的关系，在我们熟悉的E-R图中，圆圈为属性，方块为实体，而知识图谱则是着重体现每个实体之间的关系，他们之间的关系用有方向的线链接，知识图谱强调实体之间的关系，这使得它在处理复杂的、关系密集的数据时更为有效。如果图中信息工程师是一个实体，它连接着技能和职责两个实体，在职位招聘的场景中，知识图谱可以快速的锁定所需要回答答案，他不会因为像普通的RGA一样将大量的文本片段向量化去寻找关键词，而是确定关键词，分析所提问的是该关键词的下沿哪一个实体，然后再去询问数据库，不会产生大量的token数，也不会让LLM在大量的文本中迷失。

        比如下图的person是所有职位的关系，我们通过查询所有职位关系，会到后端处理，也可以像搜索公平奖罚的从属类型关键字，通过对于的查询语句，可以通过数据库得到有指向关系的数据，让回答更加准确。同样的GraphRAG也是基于这一点，先构建各个实体的知识图谱，让实体关系更加准确。

可以看看这个（本地部署加上本地大模型和embedding模型，通过vllm和xinference实现。）

这个这个

（镇帖图）