我的征尘是星辰大海。。。

The dirt and dust from my pilgrimage forms oceans of stars...

-------当记忆的篇章变得零碎，当追忆的图片变得模糊，我们只能求助于数字存储的永恒的回忆

作者:黄教授

手机视频列表

大模型RAG简单方案备忘录

视频

音频

原始脚本

企业虚拟客服 RAG 方案搭建备忘录。
一、核心目标与整体思路。
一、解决的根本问题，企业虚拟客服需实现精准回答业务问题，加记住历史对话，避免大模型一本正经胡说八道。
核心方案采用 RAG，通过权威业务 FAQ 加用户历史对话双数据源检索，为大模型提供精准上下文。
替代传统复杂的对话状态维护层。
二、方案核心逻辑。
初始化，将企业权威 F A O Q 转成向量，标注高优先级存入向量数据库。
查询，用户提问时先将问题转成向量，用 F A I S 4检索高优先级权威 F A Q 加低优先级历史对话，按优先级加 相似度排序，返回 top k 结果作为大模型上下文存储。
大模型生成回答后，将用户问题加模型回答合并转成向量，标注低优先级历史数据，存入 FAIS，供后续对话检索使用。
二、方案关键设计与优势、缺点。
一、关键设计，简化架构加优先级区分。
简化对话层，不单独维护对话状态，将所有历史对话作为 RAG 数据源，省去复杂的上下文跟踪逻辑，降低开发成本。
数据优先级标注，高优先级企业权威，F，A，K，低优先级用户历史对话。
上下文超限策略，大模型存在上下文长度限制，当历史对话加检索 结果超出限制时，需对早期历史对话做摘要，保留核心需求，压缩文本长度。
二、方案优势。
一、准确性高，依赖企业权威 FAQ 检索，避免大模型编造业务信息，降低回答错误率。
二、开发成本低，省去传统对话系统的状态维护层，仅通过检索加存储三个 核心函数实现壁画。
三，用户体验连贯，历史对话作为检索数据源，大模型能记住用户过往需求。
四，扩展性强，支持新增权威 FAQ 或适配轻量级开源模型，无需重构整体架构。
三，潜在缺点。
一、上下文超限需额外处理，对话过长时需开发历史对话摘要模块，需平衡摘要准确性与文本压缩率。
二、向量生成依赖外部模型，需集成文本转向量工具，虽轻量但需确保与大模型语义匹配。
三、F A I S 需基础配置，需根据数据量选择索引类型，需简单调参。
三，技术选型关键细节。
一，向量数据库为什么选 FAISS？FAISS 的核心价值，解决高维向量快速检索问题，通过索引分组减少比对次数。
一，索引原理，先将所有向量用 k means 聚类成 N 个组，每个组有一个聚类中心。
二，检索逻辑。
用户问题向量先比对聚类中心，找到最相似的 K 个组，仅在这10个组内计算向量相似度，比对次数从100万次降至1万次，速度提升100倍。
Sees 的定位，仅负责向量存储、加索引检索、加相似度计算，不负责文本转向量，去搭配外部工具。
二、文本转向量，为什么选 选 Bert 点 CPP，不选 ONNX Runtime。
需求匹配，企业客服场景无需复杂大模型，需轻量、无依赖、快部署。
Bert 点 CPP 优势，纯 C 加加实现，无额外 Runtime 依赖，模型小，生成向量速度快，适合客服实时场景，支持生成768维向量，与 Feasx 适配。
理解能力满足企业 F E Q 需求。
替代选项，若需更轻量，可尝试 O Mini L M 点 C P P 三大模型选型，瞄准轻量级开源模型。
核心考量，企业部署优先本地化、低资源消耗，避免依赖云端 API 。
候选方向， Deepseek 1.3B、 LLaMA 27B。
 Qwen 1.8B等轻量级开源模型，需测试两点。
一、业务适配性，能否理解客服场景的对话语义。
二、上下文兼容性，生成的回答长度、语义风格需与检索到的 FAQ 历史对话匹配。
成功可能性，目前轻量级开源模型在垂直场景的表现已较成熟。
搭配 RAG 后，准确性进一步提升，落地成功率高。
四、核心流程与示例代码逻辑。
一、整体流程闭环，初始化函数，导入权威 FAQ 功能，将企业权威 FAQ 转成向量，标注高优先级存入 IVAS。
一、加载 BERT CTP 模型。
二、便利每条 FAQ。
 Q 文本，用 Bird 点 CPP 生成768维向量。
三、调用 FAS 的 Edwards IDS 接口，将向量加自定义 ID 存入 FAS。
四、用哈希表记录 FAS 的 ID，FIQ 文本加优先级，供后续检索后找回文本。
查询函数，检索相似数据功能。
用户提问后，检索高优先级 FAQ 加低优先级历史对话，返回 TOP K 结果。
一、用 BERT 点 CPP 将用户问题转成768维向量。
二、调用 FaaS 的 Search 接口，传入问题向量加 TOP K 数量，获取相似向量的 ID 加距离。
三、根据 AS 返回的 ID，从哈希表中取出文本加优先级，按优先级加距离排序。

修正脚本

企业虚拟客服 RAG 方案搭建备忘录。
一、核心目标与整体思路。
（一）解决的根本问题，企业虚拟客服需实现精准回答业务问题，还要记住历史对话，避免大模型一本正经胡说八道。
核心方案采用 RAG，通过权威业务 FAQ 和用户历史对话双数据源检索，为大模型提供精准上下文。
替代传统复杂的对话状态维护层。
二、方案核心逻辑。
初始化，将企业权威FAQ转成向量，标注高优先级存入向量数据库。
查询，用户提问时先将问题转成向量，用FAISS检索高优先级权威 FAQ 和低优先级历史对话，按优先级和相似度排序，返回 top k 结果作为大模型上下文存储。
大模型生成回答后，将用户问题和模型回答合并转成向量，标注低优先级历史数据，存入 FAISS，供后续对话检索使用。
三、方案关键设计与优势、缺点。
一、关键设计，简化架构和优先级区分。
简化对话层，不单独维护对话状态，将所有历史对话作为 RAG 数据源，省去复杂的上下文跟踪逻辑，降低开发成本。
数据优先级标注，高优先级为企业权威FAQ，低优先级为用户历史对话。
上下文超限策略，大模型存在上下文长度限制，当历史对话和检索结果超出限制时，需对早期历史对话做摘要，保留核心需求，压缩文本长度。
二、方案优势。
一、准确性高，依赖企业权威 FAQ 检索，避免大模型编造业务信息，降低回答错误率。
二、开发成本低，省去传统对话系统的状态维护层，仅通过检索、生成、存储三个核心函数实现闭环。
三、用户体验连贯，历史对话作为检索数据源，大模型能记住用户过往需求。
四、扩展性强，支持新增权威 FAQ 或适配轻量级开源模型，无需重构整体架构。
三、潜在缺点。
一、上下文超限需额外处理，对话过长时需开发历史对话摘要模块，需平衡摘要准确性与文本压缩率。
二、向量生成依赖外部模型，需集成文本转向量工具，虽轻量但需确保与大模型语义匹配。
三、FAISS 需基础配置，需根据数据量选择索引类型，需简单调参。
四、技术选型关键细节。
一、向量数据库为什么选 FAISS？FAISS 的核心价值，解决高维向量快速检索问题，通过索引分组减少比对次数。
（一）索引原理，先将所有向量用 k means 聚类成 N 个组，每个组有一个聚类中心。
二、检索逻辑。
用户问题向量先比对聚类中心，找到最相似的 K 个组，仅在这10个组内计算向量相似度，比对次数从100万次降至1万次，速度提升100倍。
FAISS 的定位，仅负责向量存储、索引检索、相似度计算，不负责文本转向量，需搭配外部工具。
二、文本转向量，为什么选 Bert.cpp，不选 ONNX Runtime。
需求匹配，企业客服场景无需复杂大模型，需轻量、无依赖、快部署。
Bert.cpp 优势，纯 C++ 实现，无额外 Runtime 依赖，模型小，生成向量速度快，适合客服实时场景，支持生成768维向量，与 FAISS 适配。
理解能力满足企业 FAQ 需求。
替代选项，若需更轻量，可尝试 MiniLM.cpp。
三、大模型选型，瞄准轻量级开源模型。
核心考量，企业部署优先本地化、低资源消耗，避免依赖云端 API 。
候选方向， Deepseek 1.3B、 LLaMA 2 7B、 Qwen 1.8B等轻量级开源模型，需测试两点。
一、业务适配性，能否理解客服场景的对话语义。
二、上下文兼容性，生成的回答长度、语义风格需与检索到的 FAQ 历史对话匹配。
成功可能性，目前轻量级开源模型在垂直场景的表现已较成熟。
搭配 RAG 后，准确性进一步提升，落地成功率高。
五、核心流程与示例代码逻辑。
一、整体流程闭环，初始化函数，导入权威FAQ功能，将企业权威 FAQ 转成向量，标注高优先级存入 FAISS。
一、加载 BERT.cpp 模型。
二、遍历每条 FAQ。
Q 文本，用 Bert.cpp 生成768维向量。
三、调用 FAISS 的 add_index 接口，将向量和自定义 ID 存入 FAISS。
四、用哈希表记录 FAISS 的 ID，FAQ 文本和优先级，供后续检索后找回文本。
查询函数，检索相似数据功能。
用户提问后，检索高优先级 FAQ 和低优先级历史对话，返回 TOP K 结果。
一、用 Bert.cpp 将用户问题转成768维向量。
二、调用 FAISS 的 Search 接口，传入问题向量和 TOP K 数量，获取相似向量的 ID 和距离。
三、根据 FAISS 返回的 ID，从哈希表中取出文本和优先级，按优先级和距离排序。