【知识库特性增量】 DeepSeek-R1 模板支持 bge-m3 embedding model

图片

图片

为什么知识库需要

 Embedding Model?

通过询问 DeepSeek-R1 得到如下回答:

Embedding 模型的核心价值在于将非结构化文本转化为数值向量,解决语义理解与计算效率问题:

语义编码:通过向量空间捕捉上下文关联,区分多义词、同义词;如:

问题:用户搜索“苹果”,需区分“水果”还是“品牌”。

Embedding 作用:

  -“苹果手机”的向量会接近“iPhone”“智能手机”;

   -而“红苹果”的向量会接近“水果”“香蕉”“维生素”。

结果:搜索“苹果”时,优先展示手机或水果,取决于用户历史行为(如点击电子产品)。

高效检索:支持近似最近邻(ANN)算法,降低海量数据匹配复杂度;

场景:某电商平台有 1 亿商品描述,需实时匹配用户查询“适合露营的轻便帐篷”。

传统方法:关键词匹配“露营+轻便+帐篷”,可能漏掉“户外超薄遮阳篷”。

Embedding 方案:

    -将查询和商品描述转为向量;

    -使用 ANN 库(如 FAISS )在毫秒级返回

Top100 相关商品,覆盖语义相似但关键词不匹配的结果。

 AI 基础设施:支撑 RAG 、多模态搜索、迁移学习等任务,替代传统关键词匹配与人工规则。

场景:客服机器人回答“如何清洁帐篷上的污渍?”

流程:用 BGE-M3 将问题编码为向量;

 -从向量数据库检索《户外用品保养指南》中相关段落;

 -将检索结果输入大模型(如DeepSeek-R1),生成步骤清晰的回答。

优势:避免大模型虚构答案,提升可信度。

与传统方式相比具备优势

图片

图片

为什么选择 

bge-m3 Embedding 模型?

根据了解,BGE-M3 模型是当前领先的多语言 Embedding 模型,在 MIRACL、MKQA 等基准测试中排名第一,支持 100+ 语言,具备三大特性:

1.多语言性:覆盖 194 种语言训练,跨语言检索效果显著;

2.多功能性:统一支持密集、稀疏、多向量三种检索模式;

3.多粒度性:支持最长 8192 tokens 输入,适配长短文本。其训练采用知识蒸馏与高效批处理技术,结合 1.2 亿文本对与合成数据优化性能。

并且腾讯云其他 AI 应用中该模型使用的也较为广泛。本次,Cloud Studio 在DeepSeek-R1 模板中内置了 BAAI/bge-m3。希望给知识库玩家带来更加准确的召回效果,让工具更加实用。

图片

图片

如何在 

CloudStudio DeepSeek-R1 模板中设置 bge-m3

步骤一 :

进入 Cloud Studio DeepSeek CPU 模板,唤起内置 Open-WebUI 或 AnythingLLM 组件。进入网站:

https://ide.cloud.tencent.com/dashboard/

点击任意 DeepSeek CPU 模板进入工作空间, 唤起 Open-WebUI 或 AnythingLLM, 即刻拥有完全属于个人的知识库。相对于本地搭建 RAG 知识库,体验门槛直线降低!

图片

进入工作空间后,默认唤起 AnythingLLM  (4001端口),点击图中 icon ,进入浏览器全屏模式

图片

点击左下角【设置】

图片

进入【人工智能提供商】-【Embedder首选项】,在【嵌入引擎提供商】处选择“Ollama”,随后在下方【Ollama Embedding Model】处选择“bge-m3:latest”。

选择完毕后点击【保存更改】

图片

步骤二:

创建【工作区】即可开始进一步构建知识库进行对话。这里重复介绍一下如何创建和设置知识库进行对话。

上传文档

在聊天界面中,用户可以创建多个工作区。每个工作区可以独立管理文档和 LLM 设置,并支持多个会话(Thread),每个会话的上下文也是独立的。

图片

点击上传图标,可以管理当前工作区的知识库。以本地文档上传为例,用户可以管理已上传的文档,并通过下方的上传按钮或拖拽方式上传新文档。

图片

导入完成后,用户可以在 【Documents】 界面选中文件,并点击 【Move to Workspace】 将其添加到工作区。

图片

添加到工作区后,点击 【Save and Embeded】,将文档内容转换为向量检索所需的嵌入数据结构。

图片

聊天模式

将文档添加到工作区后,用户可以通过设置聊天模式调整 DeepSeek-R1 的回复方式,在【工作区LLM提供者】处可选用 DeepSeek-R1模型类型,比如 7b 。

聊天模式:聊天 将提供 LLM 的一般知识 和 找到的文档上下文的答案。

查询模式:查询将仅提供找到的文档上下文的答案。

图片

在聊天窗口中,用户可以直接提问。deepseek-r1 会基于文档内容生成答案,并标注答案来源。

最后,我们来看看效果。

以 AnythingLLM 为例,在传入《微短剧行业深度分析报告》、与《 AIGC 与微短剧的结合》两份资料后,模型通过识别后者给出了相应的总结。

图片

图片

加入 Cloud Studio 自媒体特权计划

我们推出针对为 Cloud Studio 宣传的自媒体特权计划,招募长期合作的内容创作者,创作者将永久被授予 20000 分钟/月的基础版 GPU 使用配额。

20000分钟(333小时) 8+TFlops 算力、16GB+显存 的使用配额!什么概念!

可以系统化地利用 DeepSeek R1 模型实现从模型优化到实际落地的完整闭环。可生成数十万 10 万条营销文案、可提供稳定的高并发实时 API 服务。

心动吗?

还等啥呢?!

快来体验吧!!

参与方式

扫码联系工作人员进行登记初审:

图片

入选标准

- 拥有自媒体账号,且输出稳定

- 过往具备 Cloud Studio 相关分享经验,且具备干货内容

- 长期使用 Cloud Studio 进行工作、学习

希望创作者

1.  在 ide.cloud.tencent.com 平台上使用 DeepSeek 相关模板

2.  将实践经验以视频或文章的方式发布到任意媒体渠道(包括但不限于B站、抖音、小红书、个人博客等)。实践内容包含但不限于模型推理、创建知识库、构建个人应用等。每月至少分享两次。

注意:我们鼓励原创和真实,请不要抄袭、搬运他人内容。

<think>嗯,用户在使用Ollama部署了deepseek-R1模型,并且用AnythingLLM添加了本地知识库,但遇到了检索不精准的问题。首先,我需要分析可能的原因。本地知识库的检索问题通常涉及多个方面,比如文档处理、嵌入模型、分块策略、检索参数或者模型本身的限制。 用户可能已经正确加载了模型,但知识库的处理可能有问题。首先应该检查文档预处理。比如,文档是否被正确分割?分块的大小和重叠是否合适?如果分块太大,可能导致信息冗余;太小则可能丢失上下文。另外,是否清除了噪音数据,比如特殊字符或无关内容?这些都会影响检索效果。 接下来是嵌入模型的选择。AnythingLLM默认可能用了某个嵌入模型,但不同的模型在不同类型数据上表现不同。用户是否需要更换更适合自己数据类型的模型?比如,sentence-transformers里的模型可能更适用于特定语言或领域。另外,嵌入模型的维度是否匹配,如果维度不匹配,检索效果也会差。 然后是检索策略。AnythingLLM可能使用了余弦相似度或欧氏距离,用户是否调整过相似度阈值?提高阈值可以过滤掉不相关的结果,但可能漏掉部分相关。检索返回的结果数量是否足够?太少的话可能错过正确答案,太多则引入噪音。 模型本身的限制也可能导致问题。deepseek-R1作为基座模型,可能在处理长上下文或复杂查询时有局限。用户是否在查询时提供了足够的上下文?或者需要调整提示词,让模型更明确地依赖知识库内容。 另外,知识库内容的覆盖范围是否全面?如果知识库中的数据不够或与查询不相关,检索自然不准确。测试时是否尝试过简单查询验证基础功能?比如直接引用知识库中的内容,看是否能正确检索到。 还有版本和配置问题。Ollama和AnythingLLM的版本是否最新?有时候软件更新会修复已知问题。配置文件中是否有参数需要调整,比如top_k或温度参数? 用户可能没有详细说明具体症状,比如是完全检索不到还是部分不准,或者返回无关结果。可能需要建议用户检查日志,看看检索过程中是否有错误,或者观察分块后的内容是否符合预期。 最后,如果所有步骤都正确,可能需要进一步优化,比如微调嵌入模型或调整模型推理参数。或者考虑其他工具如LangChain进行更灵活的流程控制。</think>在使用本地知识库结合大模型(如deepseek-R1)时遇到检索精度问题,可能涉及多个环节的配置或数据质量问题。以下是逐步排查和优化的方向: --- ### **1. 检查知识库预处理环节** - **文档分块策略** - 分块大小(chunk_size):建议根据内容类型调整(如技术文档适合512-1024字符,对话记录适合200-400字符)。 - 分块重叠(overlap):保留10-15%的重叠内容避免上下文断裂(例如分块大小1024时,重叠约150字符)。 - 尝试使用智能分块工具(如`langchain.text_splitter.RecursiveCharacterTextSplitter`)替代基础分块。 - **元数据标注** - 为每个分块添加标题、关键词、文档来源等元数据,可显著提升后续检索匹配度。 - **数据清洗** - 移除HTML标签、乱码、页眉页脚等噪音数据。 - 对PDF文档需检查OCR识别错误(尤其是扫描版PDF)。 --- ### **2. 优化嵌入模型(Embedding Model)** - **模型选择** - 默认的`all-MiniLM-L6-v2`适合英文,中文建议换用: - `paraphrase-multilingual-mpnet-base-v2`(多语言高精度) - `text2vec-base-chinese`(专为中文优化) - 通过[HuggingFace MTEB排行榜](https://huggingface.co/spaces/mteb/leaderboard)选择适合任务的模型。 - **本地部署嵌入模型** ```python # 示例:在AnythingLLM中替换嵌入模型 from sentence_transformers import SentenceTransformer embedder = SentenceTransformer(&#39;paraphrase-multilingual-mpnet-base-v2&#39;) ``` --- ### **3. 调整检索策略** - **相似度算法** - 测试余弦相似度(cosine) vs 欧氏距离(L2),通常余弦更适合文本。 - **混合检索(Hybrid Search)** - 结合关键词检索(如BM25)与向量检索,缓解语义模糊问题: ```python # 伪代码示例 keyword_results = bm25_search(query) vector_results = vector_db.search(query_embedding) fused_results = fuse_results(keyword_results, vector_results) ``` - **重排序(Reranking)** 使用交叉编码器(如`bge-reranker-base`)对Top100结果重新排序: ```python from FlagEmbedding import FlagReranker reranker = FlagReranker(&#39;BAAI/bge-reranker-base&#39;, use_fp16=True) scores = reranker.compute_score([[query, chunk] for chunk in candidates]) ``` --- ### **4. 验证知识库与查询的匹配性** - **测试基础案例** 构造一个完全匹配知识库内容的查询(如直接复制某段文字的前半句),观察是否能返回正确分块。 - **分析Bad Cases** 记录失败案例,检查: - 问题是否在知识库中有明确答案 - 分块是否丢失关键信息(如表格被拆散) - 相似分块是否过多导致干扰 --- ### **5. 调整模型交互提示词** - **强制引用知识库** 在prompt中明确要求模型优先基于知识库回答: ```markdown 你是一个专业助手,请严格根据提供的知识库内容回答问题。 如果知识库中没有相关信息,请回答“根据现有资料无法确定”。 知识库内容: {context} 问题:{question} ``` - **增加拒绝机制** 当检索置信度低于阈值时,让模型主动拒绝回答而非猜测。 --- ### **6. 技术栈替代方案** 如果问题持续存在,可尝试: - 用**LlamaIndex**替换知识库组件,其提供更灵活的数据连接器和检索逻辑。 - 使用**ChromaDB**或**Qdrant**替代默认向量数据库,支持元数据过滤等高级查询。 - 对关键业务场景微调嵌入模型(需准备正负样本对)。 --- ### **关键日志检查点** 1. 观察知识库加载日志,确认文档解析无误。 2. 检查检索阶段返回的相似度分数分布(是否普遍低于0.6)。 3. 在Ollama启动命令中添加`--verbose`参数查看推理过程细节。 通过逐步验证每个环节的数据流转,通常可以定位到具体瓶颈。建议从一个小型精准知识库(如10个文档)开始测试,逐步扩展到全量数据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值