回忆下 之前做agent demo时的代码流程。接收消息内容、补充上下文、转成词向量、遍历数据库数据、做余弦相似度匹配、把查询到的知识库数据汇总到消息中、调用LLM模型得出自然语言输出。重复循环处理几次。项目一人力智能问答对比于上面的流程。有主要变化的几个点1词向量的数据来源汇总了多个表的多个字段并转成json格式化的数据结构。2是余弦相似度的匹配方式升级了用onnx模型并用第三方api做词向量匹配。重点对数据的操作2个点1是定时任务加载所有词向量到缓存中2是数据匹配通过建4个工具先对数据根据权限过滤、userid等做精准过滤再通过依次for循环余弦相似度匹配。需求已有的人力项目要添加ai助手问答功能。要在不修改已有代码、表结构的前提下完成可以新增代码。以案例为导向思考怎么解决这些问答介绍下张三 主要来源是基本信息维度张三在哪个部门 也是有明确的答案的评价下张三 属于比较模糊问题要从多个维度回答需要打分、权重介入找跟张三类似的员工给同上财务部有哪些人也是有明确答案的思考1.其实还是做RAG。只是要求不能改变已有的功能。2.主要是在kimi的帮助下反复沟通需求把项目代码丢给kimi分析让kimi给出一个完整的设计方案并自动生成代码。需求的主要内容是做员工画像、人才推荐。定义输出规则不要有废话做关键字输出即可、不要无中生有、要基于知识库回答比如说查人必须要先根据人名查出在知识库中的人的userid再去查其他的基本信息。3.思考需要什么工具。首先要有自然语言模型这个有公司公共的大模型接口因为不能影响已有功能所有要加表、加接口主要是词向量的生成、匹配、存储。采用生成词向量生成工具要复用已有的项目代码的方法做人员、部门、标签等信息的查询。重点要在已有代码和agent之间建一个层把二者粘起来方案kimi生成的方案技术栈原项目是java8springboot2 .LLM由接口提供应该是qwen323embedding词向量使用beg-base-zh-v1.5.onnx文本向量化模型 300M左右以及三个操作向量模型的jar包向量化怎么生成词向量词向的内容怎么设计呢我们是基于文本问答所以要把相同维度的数据放在一起按人分开。把人拆分为多个维度基本信息、教育、所在部门、员工标签、能力、年度事件等。词向量表字段一个人划分为多个维度每个维度是一条数据。所以表结构字段有维度名、userid、权重、embedding、md5时间向量生成定时任务触发人员信息很少变化所有就先只加全员检查变更内容。分为每日更新和每年更新。通过md5字段判断词向量是否需要变更。存储放到es中查询快。支持余弦相似度查询数量级人力就几千人也就百兆左右查询秒级别工具4个工具1是把人名、部门名、公司名、转移成知识库中的id2是查询筛选枚举值3是结构化条件筛选4是语义找人能力、经历、推荐类模糊需求这个工具重点说一下这是模糊查询的重要工具可以做推荐类功能。所有有对标签的打分。在项目启动阶段会根据提示词把es数据库中的人员、部门等数据转成根据不同维度打分后的结果放到内存中。比如说能力特长型就把能力标签的权重提高、教育型就把学历标签提高。循环处理上下文在经过一轮的tool处理、余弦相似度匹配、自然语言模型处理后会再进行一轮同样的处理并加入再次一次循环的上下文。知道模型不再输出不同于上次的内容为止。整个过程的上下文有很多有 角色信息、用户问题、上下文、系统固定信息、tool工具附带的上下文、提示循环处理的上下文等。最后说明代码基本都是kimi生成的程序员主要是做提示词、调试打通。整个代码很复杂尤其是tool工具的处理、条件过滤、实施回查富化 需要考虑到的字段很多、很麻烦如果只是靠人的思维一点点优化试错、需要大量的时间或者根本不可能实现。项目二基于接口的项目知识库助手也是在已有的项目上改造。对原项目基本上一点改动都没有。原理项目已有的接口能够满足项目的所有相关知识问答。模型要做的就是调用大模型弄清用户意图、汇总查询参数、精准调用对应接口、汇总查询结果、调用大模型转结果为自然语言输出。要求需要项目接口说明、请求参数说明、返回字段说明都要很详细。类似的需求要做出语言上的区分。需要反复调试对每个功能点都要测试一遍以防调错接口。做成可配置的对于有争议的接口调用方式要通过人为的修改注册表通过语义调用到配置的的接口其实也就是固定提示词。缺点相对于在原项目上调用方法调接口会比较慢而且会返回一些无用的信息。二是权限处理麻烦。因为大部分权限配置是基于前端菜单配置的。并没有对接口做权限管理。这样就导致用户问看不到的菜单内容也会有相应。至今没有很好很便捷的处理方式。
回忆下 之前做agent demo时的代码流程。接收消息内容、补充上下文、转成词向量、遍历数据库数据、做余弦相似度匹配、把查询到的知识库数据汇总到消息中、调用LLM模型得出自然语言输出。重复循环处理几次。项目一人力智能问答对比于上面的流程。有主要变化的几个点1词向量的数据来源汇总了多个表的多个字段并转成json格式化的数据结构。2是余弦相似度的匹配方式升级了用onnx模型并用第三方api做词向量匹配。重点对数据的操作2个点1是定时任务加载所有词向量到缓存中2是数据匹配通过建4个工具先对数据根据权限过滤、userid等做精准过滤再通过依次for循环余弦相似度匹配。需求已有的人力项目要添加ai助手问答功能。要在不修改已有代码、表结构的前提下完成可以新增代码。以案例为导向思考怎么解决这些问答介绍下张三 主要来源是基本信息维度张三在哪个部门 也是有明确的答案的评价下张三 属于比较模糊问题要从多个维度回答需要打分、权重介入找跟张三类似的员工给同上财务部有哪些人也是有明确答案的思考1.其实还是做RAG。只是要求不能改变已有的功能。2.主要是在kimi的帮助下反复沟通需求把项目代码丢给kimi分析让kimi给出一个完整的设计方案并自动生成代码。需求的主要内容是做员工画像、人才推荐。定义输出规则不要有废话做关键字输出即可、不要无中生有、要基于知识库回答比如说查人必须要先根据人名查出在知识库中的人的userid再去查其他的基本信息。3.思考需要什么工具。首先要有自然语言模型这个有公司公共的大模型接口因为不能影响已有功能所有要加表、加接口主要是词向量的生成、匹配、存储。采用生成词向量生成工具要复用已有的项目代码的方法做人员、部门、标签等信息的查询。重点要在已有代码和agent之间建一个层把二者粘起来方案kimi生成的方案技术栈原项目是java8springboot2 .LLM由接口提供应该是qwen323embedding词向量使用beg-base-zh-v1.5.onnx文本向量化模型 300M左右以及三个操作向量模型的jar包向量化怎么生成词向量词向的内容怎么设计呢我们是基于文本问答所以要把相同维度的数据放在一起按人分开。把人拆分为多个维度基本信息、教育、所在部门、员工标签、能力、年度事件等。词向量表字段一个人划分为多个维度每个维度是一条数据。所以表结构字段有维度名、userid、权重、embedding、md5时间向量生成定时任务触发人员信息很少变化所有就先只加全员检查变更内容。分为每日更新和每年更新。通过md5字段判断词向量是否需要变更。存储放到es中查询快。支持余弦相似度查询数量级人力就几千人也就百兆左右查询秒级别工具4个工具1是把人名、部门名、公司名、转移成知识库中的id2是查询筛选枚举值3是结构化条件筛选4是语义找人能力、经历、推荐类模糊需求这个工具重点说一下这是模糊查询的重要工具可以做推荐类功能。所有有对标签的打分。在项目启动阶段会根据提示词把es数据库中的人员、部门等数据转成根据不同维度打分后的结果放到内存中。比如说能力特长型就把能力标签的权重提高、教育型就把学历标签提高。循环处理上下文在经过一轮的tool处理、余弦相似度匹配、自然语言模型处理后会再进行一轮同样的处理并加入再次一次循环的上下文。知道模型不再输出不同于上次的内容为止。整个过程的上下文有很多有 角色信息、用户问题、上下文、系统固定信息、tool工具附带的上下文、提示循环处理的上下文等。最后说明代码基本都是kimi生成的程序员主要是做提示词、调试打通。整个代码很复杂尤其是tool工具的处理、条件过滤、实施回查富化 需要考虑到的字段很多、很麻烦如果只是靠人的思维一点点优化试错、需要大量的时间或者根本不可能实现。项目二基于接口的项目知识库助手也是在已有的项目上改造。对原项目基本上一点改动都没有。原理项目已有的接口能够满足项目的所有相关知识问答。模型要做的就是调用大模型弄清用户意图、汇总查询参数、精准调用对应接口、汇总查询结果、调用大模型转结果为自然语言输出。要求需要项目接口说明、请求参数说明、返回字段说明都要很详细。类似的需求要做出语言上的区分。需要反复调试对每个功能点都要测试一遍以防调错接口。做成可配置的对于有争议的接口调用方式要通过人为的修改注册表通过语义调用到配置的的接口其实也就是固定提示词。缺点相对于在原项目上调用方法调接口会比较慢而且会返回一些无用的信息。二是权限处理麻烦。因为大部分权限配置是基于前端菜单配置的。并没有对接口做权限管理。这样就导致用户问看不到的菜单内容也会有相应。至今没有很好很便捷的处理方式。
