role-db

角色数据库

前言

角色数据库主要为提供角色的描述的信息，或作为角色的知识点的补充，其中潜在的解决该部分的方案有:

实体抽取/知识图谱
向量数据库

备注：

在进行诸多尝试后，可行方案的实现已经由其他工程处理，本工程只作为一个思路的记录

当前需要参考的内容

已经确认失败的方向

萌娘百科 datasets(尝试解析 - 数据格式混乱): https://huggingface.co/datasets/milashkaarshif/MoeGirlPedia_wikitext_raw_archive
langchain 中的 webloader - 对于前后端分离的站点无法支持: https://python.langchain.com/en/latest/modules/indexes/document_loaders/examples/web_base.html
langchain 中的 bilibililoader - 爬取的信息缺失严重：https://python.langchain.com/en/latest/modules/indexes/document_loaders/examples/bilibili.html
baiduspider - 接口失效: https://github.com/BaiduSpider/BaiduSpider
通过直接从群聊对话中获取实体摘要 - 由于知识缺乏准确度，会严重受模型幻觉影响
直接使用开源小模型来做实体提取(shibing624/bert4ner-base-chinese) - 对群聊中的实体提取效果极差，需要额外训练且其训练需要的自定义数据集较为繁琐
https://huggingface.co/IDEA-CCNL/Randeng-T5-77M-MultiTask-Chinese 在做 summary 时的效果也极差
直接从用户在群聊的零散信息对话中获取实体摘要(相当于在群聊中学习) - 1v1 的对话模式学习效果不错，但是群聊场景由于发言较为发散，实体摘要效果很差
wiki 的本地化中使用 chroma 的方案 - chromadb 的写入性能太差，完成 wiki 的导入需要以百天的时间，在工程实践中得不偿失
langchain 中默认推荐的 all-MiniLM-L6-v2 与 paraphrase-multilingual-MiniLM-L12-v2 对中文处理的效果非常差，基本是不可用的

备注:

nlp 领域参数量小于 3b 的模型是工程陷阱(解决特定领域的处理时完全可以被普通db以及通用的相似度查询处理，基本没有泛用特性)
失败的尝试放入到 ban-list 中

虽然可行但是工程性能太差的方向

使用 langchain 中的 Wikipedia loader 作为数据来源(实体数据信息): https://python.langchain.com/en/latest/modules/indexes/document_loaders/examples/wikipedia.html

备注：

wiki 官方虽然提供了便捷的接口，但是改接口的查询速度较慢，且有频率限制
这里推荐改用将 wiki 数据存储到本地数据库然后对实体名称做向量化查询的方案

已确认可进行工程化实施的方向

wiki 本地化并配合 mongodb
llm(newbing, gpt3.5) 处理实体提取和内容汇总(效果极好)
准确的背景知识补充可以极大的提升模型的表现力
openai 的 embedding 效果极佳
基于 luotuo-bert 做成自定义的 langchain embedding func 效果极佳

备注：

可以参考维基百科数据本地化
wiki 接口方式获取的数据较为规范，但是其 summary 信息不一定准确，可以考虑额外使用 llm 做 summary 辅助
wiki 中获取的内容可能为繁体，可以使用繁转简方案处理：https://pypi.org/project/opencc-python
wiki 在 mongodb 中的资源占用汇总:

总实例数 236,3237
dataSize(数据库中的数据大小): 3.2g
storageSize(数据库中存储的数据的物理大小): 1.97g
indexSize(索引的总大小): 165m
totalSize(数据库的总体大小): 2.13g

建议: 
1. 对于中文 wiki 内容，至少为 mongo 留足 4g 以上内存作为缓存空间  
1. mongodb 缓存大小规则与配置可以参考：https://www.mongodb.com/docs/manual/reference/configuration-options/ 中的 storage.wiredTiger.engineConfig.cacheSizeGB  
1. 对于之后的英文 wiki 内容，则至少需要留足 40g 以上内存作为缓存空间  

一些延申问题: 
1. 单体大服务模式在未来的机器配置日益增加的背景下，将是工程上更适合的选择  
1. wiki 的资源消耗远远低于预期

待确认的点

知乎数据集(需要依据实际业务方向做定向筛选清洗): https://huggingface.co/datasets/wangrui6/Zhihu-KOL
知识图谱存储方案：https://zhuanlan.zhihu.com/p/83893713
采用 lora + chatglm 的模式进行训练可能比传统方式要更好
使用后置处理模式的相似度搜索配合双prompt模式实现群聊模式下的定制化性格偏移
向量数据库的 embedding 选型这块也可以参考 text2vec-large-chinese（作为备选项

wiki 的数据也有打包下载的方式，可以参考这个站点：https://dumps.wikimedia.org/zhwiki/latest/ 对其相关数据的解析可以参考：https://cloud.tencent.com/developer/article/1564349

memory 组织方式

目前先采用将实体名称喂给 chroma 辅助信息查询，但是否有必要投喂 entity 摘要有待商榷

langchain - chroma: https://python.langchain.com/en/latest/modules/indexes/vectorstores/examples/chroma.html

wujohns/role-db