我的征尘是星辰大海。。。
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，从哈希表中取出文本和优先级，按优先级和距离排序。
英文翻译
Enterprise Virtual Customer Service RAG Solution Setup Memo. I. Core Objectives and Overall Approach. 1. The fundamental problem to solve: enterprise virtual customer service must accurately answer business questions while remembering historical conversations, avoiding the large model's tendency to fabricate information. The core solution adopts RAG, which retrieves from dual data sources—authoritative business FAQs and user historical conversations—to provide precise context for the large model. This replaces the traditional complex dialogue state maintenance layer. II. Core Logic of the Solution. Initialization: Convert enterprise authoritative FAQs into vectors, label them as high priority, and store them in the vector database. Query: When a user asks a question, first convert the question into a vector, use FAISS to retrieve high-priority authoritative FAQs and low-priority historical conversations, sort by priority and similarity, and return the top k results as context for the large model to store. After the large model generates a response, merge the user question and model response into a vector, label it as low-priority historical data, and store it in FAISS for use in subsequent dialogue retrieval. III. Key Design, Advantages, and Disadvantages of the Solution. 1. Key Design: Simplified architecture and priority differentiation. - Simplify the dialogue layer: Instead of maintaining a separate dialogue state, treat all historical conversations as RAG data sources, eliminating complex context tracking logic and reducing development costs. - Data priority labeling: High priority for enterprise authoritative FAQs, low priority for user historical conversations. - Context overflow strategy: Large models have context length limits. When historical conversations and retrieval results exceed the limit, early historical conversations need to be summarized, retaining core needs and compressing text length. 2. Advantages of the Solution: 1. High accuracy: Relies on enterprise authoritative FAQ retrieval to avoid the model fabricating business information and reduce error rates. 2. Low development cost: Eliminates the state maintenance layer of traditional dialogue systems, achieving a closed loop through just three core functions—retrieval, generation, and storage. 3. Smooth user experience: Historical conversations serve as retrieval data sources, allowing the large model to remember user past needs. 4. Strong extensibility: Supports adding new authoritative FAQs or adapting lightweight open-source models without rebuilding the overall architecture. 3. Potential Disadvantages: 1. Context overflow requires additional processing: When conversations become too long, a historical conversation summarization module must be developed, balancing summarization accuracy with text compression ratio. 2. Vector generation relies on external models: Requires integration of a text-to-vector tool. Although lightweight, semantic alignment with the large model must be ensured. 3. FAISS requires basic configuration: Index type must be selected based on data volume, and simple parameter tuning is needed. IV. Key Technical Selection Details. 1. Why choose FAISS for the vector database? FAISS's core value: Solves the problem of fast retrieval of high-dimensional vectors by reducing comparison times through index grouping. 1. Index principle: First, cluster all vectors into N groups using k-means, each group having a cluster center. 2. Retrieval logic: - Compare the user question vector with cluster centers to find the K most similar groups. - Compute vector similarity only within these 10 groups, reducing comparisons from 1 million to 10,000, achieving a 100x speed boost. FAISS's role: Only handles vector storage, index retrieval, and similarity computation; does not handle text-to-vector conversion, requiring an external tool. 2. Text-to-vector: Why choose Bert.cpp over ONNX Runtime? - Requirement matching: Enterprise customer service scenarios do not need complex large models; they need lightweight, dependency-free, and quick deployment. - Advantages of Bert.cpp: Pure C++ implementation, no additional runtime dependencies, small model size, fast vector generation, suitable for real-time customer service scenarios, supports generating 768-dimensional vectors compatible with FAISS. - Comprehension ability meets enterprise FAQ needs. - Alternative: If even lighter weight is needed, try MiniLM.cpp. 3. Large model selection: Targeting lightweight open-source models. - Core consideration: Enterprise deployment prioritizes localization, low resource consumption, and avoiding reliance on cloud APIs. - Candidate directions: Deepseek 1.3B, LLaMA 2 7B, Qwen 1.8B, and other lightweight open-source models require testing on two points: 1. Business adaptability: Can it understand the dialogue semantics of the customer service scenario? 2. Context compatibility: The length and semantic style of generated responses must match the retrieved FAQ and historical conversations. - Success likelihood: Lightweight open-source models currently perform quite maturely in vertical scenarios. - With RAG integration, accuracy further improves, leading to high deployment success. V. Core Process and Example Code Logic. 1. Overall Process Closed Loop: - Initialization function (import authoritative FAQ function): Convert enterprise authoritative FAQs into vectors, label them as high priority, and store in FAISS. 1. Load the BERT.cpp model. 2. Iterate over each FAQ's Q text, generate a 768-dimensional vector using Bert.cpp. 3. Call FAISS's `add_index` interface to store the vector and custom ID into FAISS. 4. Use a hash table to record FAISS IDs, FAQ text, and priority, for later retrieval to map back to text. - Query function (retrieve similar data function): After a user asks a question, retrieve high-priority FAQs and low-priority historical conversations, returning top K results. 1. Convert the user question into a 768-dimensional vector using Bert.cpp. 2. Call FAISS's `Search` interface, passing the question vector and top K number, obtaining the IDs and distances of similar vectors. 3. Based on the IDs returned by FAISS, retrieve the text and priority from the hash table, sorting by priority and distance.
back to top