当前位置：首页 > news >正文

AI助理技术拆解：用RAG打造企业知识库实战

news 2026/8/28 3:59:57

临近年底，各家大厂在“AI助理”上的动作明显提速。腾讯、字节、阿里几乎在同一时间段释放出面向办公场景的AI助理能力，从文档协作、代码生成到会议纪要、知识库问答，AI助理正在从一个“聊天玩具”变成打工人日常工作中真正用得上的工具。

本文不打算做产品发布会式的盘点，而是从技术视角拆解这波AI助理热潮背后的产品形态、核心技术和落地思路，并结合当前主流的RAG（检索增强生成）方案，给出一个可以在本地跑起来的企业知识库AI助理最小实战示例，帮助大家理解“大厂AI助理”背后到底是什么。

1. AI助理是什么：从“工具”到“数字同事”

1.1 一句话理解AI助理

AI助理，简单理解就是一个由大语言模型驱动、能理解自然语言、能调用工具、能访问业务数据、能自动完成任务的智能体。

它和传统的聊天机器人最大的区别在于：传统聊天机器人只能做“问答”，AI助理可以做“执行”。

举个例子：你在钉钉里问“把上周的项目周报整理成表格发给我”，传统机器人只能回复“好的，我帮你查一下”，然后跳转到一个固定页面；而AI助理会自己检索周报数据、用工具生成表格、找到你的会话并发送文件。

这个变化本质上是将“人与软件之间的交互”从“人去找功能”变成了“功能来找人”，AI助理成为一个聚合调度层，背后连接的是文档、代码、数据库、审批流、音视频会议等企业系统。

1.2 AI助理的分类

从产品形态上看，目前市面上的AI助理大致分为三类：

类型	代表产品	典型能力
办公软件内嵌AI	钉钉AI助理、飞书智能伙伴、腾讯文档AI	文档问答、会议纪要、日程处理、消息自动回复
独立AI助理应用	豆包、元宝、通义	通用问答、信息检索、创意生成
AI开发平台/框架	扣子（Coze）、百炼、腾讯云AI代码助手	可视化搭建AI助理、API调用、代码生成与补全

这三类产品不是互斥的。飞书的智能伙伴底层可以调用豆包的大模型能力；钉钉AI助理底层可以接入通义千问；腾讯的AI助理则同时覆盖了企业微信、腾讯文档、腾讯云IDE等多个入口。大厂本质上是在用“AI助理”串联自家的大模型能力和办公生态。

1.3 为什么现在集中爆发

这里有个技术背景需要理解：大模型已经从“单一模型”走向“模型+工具+数据”的综合体。

2023年大模型刚火起来的时候，大家做的事情是“聊天”，比拼的是谁能写出更长的文章、更优美的诗句。但很快发现，真正的商业价值不在于“会聊天”，而在于“能干活”。要想“能干活”，就必须让大模型具备以下三个能力：

访问实时数据：不能只靠训练时的知识，必须能检索最新的业务资料。
调用外部工具：需要能操作日程、发消息、查数据库、执行代码。
多步任务规划：面对复杂任务，要能拆解成多个子步骤并逐步执行。

这三个能力对应的技术方案分别是RAG、Function Calling/Tool Use、Agent/Plan-and-Execute。当这三项技术逐渐成熟，AI助理才真正从“概念演示”走向“开放给所有打工人使用”。

2. 腾讯、字节、阿里的AI助理产品全景

2.1 腾讯：以腾讯混元大模型为底座，覆盖文档、代码、会议

腾讯的AI助理布局主要依托“腾讯混元”大模型，落地形态集中在腾讯文档、企业微信、腾讯云开发工具等领域。

腾讯文档AI：支持文档内容生成、总结摘要、表格公式生成、PPT一键排版。对于经常写周报、做汇报材料的运营和产品同学来说，这个入口最直接。
企业微信智能机器人：基于混元模型提供智能问答、客户接待话术辅助、群聊信息摘要等能力。
腾讯云AI代码助手：面向开发者的辅助编程工具，支持代码补全、单元测试生成、代码解释、缺陷检测。
腾讯乐享/腾讯会议：会议中的实时转写、待办提取和纪要素材整理。

腾讯的思路很清晰：不单独做一个“AI助理App”，而是把AI能力嵌入到用户原本就在使用的办公工具中，让用户没有额外学习成本。

2.2 字节：飞书智能伙伴 + 豆包 + 扣子，三位一体

字节是目前AI助理产品体系最完整的公司之一。

飞书智能伙伴：飞书内的AI能力中心，用户可以直接在飞书里创建自定义AI助理。例如，市场团队可以创建一个“活动策划助理”，把往期活动资料作为知识库，AI助理能直接帮忙产出提案大纲。
豆包：面向C端的AI助理应用，也是字节大模型“云雀”的直接载体。豆包支持照片生成、语音对话、文档上传解读等。
扣子（Coze）：这是一个AI应用开发平台，普通人可以通过拖拽方式创建Bot，并发布到飞书、微信等渠道。扣子的核心价值是把“AI助理开发”的门槛降到了产品经理都能操作的程度。

字节的打法是“C端入口 + B端办公 + 低代码平台”并行，既保证了大模型有真实的使用场景和数据反馈，也降低了企业接入AI助理的难度。

2.3 阿里：通义千问 + 钉钉AI助理 + 百炼平台

阿里是国内最早把大模型与办公场景结合的公司之一。

通义千问：阿里自研的通用大模型，目前已经演进到千问系列，支持文本、图片、代码、音频等多模态输入。
钉钉AI助理：钉钉依托通义千问推出了AI助理功能，用户可以在对话中完成创建待办、查询审批记录、生成项目总结等操作。钉钉还推出了“AI助理市场”，允许企业上传自己的知识库来训练专属助理。
阿里云百炼：面向开发者和企业的AI应用开发平台，提供模型调用、Prompt工程、知识库管理、Agent编排等能力，本质上和字节的扣子对标。

阿里的优势在于“云+大模型+办公软件”的联动能力。企业在阿里云上数据本来就有，百炼可以直接接入这些数据源，构建更安全的企业级AI助理。

2.4 三家的共同技术路线

从产品形态看，三家的AI助理有高度相似的技术路线：

底层使用自研大模型。
中间通过RAG连接企业私有数据。
上层提供对话界面以及API/低代码开发平台。
最终嵌入到高频办公软件中。

这也意味着，如果你现在掌握了RAG、Agent、知识库构建、AI应用开发这些技术，无论未来大厂的产品怎么迭代，你都能快速迁移和适配。这也是本文后半部分要重点讲技术实战的原因。

3. AI助理的五大技术底座

3.1 大语言模型（LLM）

AI助理的大脑是大语言模型。大模型负责理解用户意图、生成自然语言回复、规划任务步骤。

当前国内主流的大模型包括：

腾讯混元（Hunyuan）
字节云雀（Doubao）
阿里通义千问（Qwen）
以及其他开源模型，如Qwen系列、DeepSeek、GLM系列等

在实际工程中，大模型的选择主要考虑三个维度：

效果：指令遵循能力、推理能力、中文理解能力。
成本：token消耗费用，尤其是企业级高频调用场景。
部署方式：公有云API调用、私有化部署、混合部署。

对于个人开发者和中小企业，建议优先使用云端API，关注模型的“上下文长度”和“Function Calling”支持情况。

3.2 检索增强生成（RAG）

RAG是目前AI助理落地最核心的技术，没有之一。

原因很简单：大模型的知识截止日期是固定的，无法知道你的内部制度、项目进度、私有代码。RAG的思路是：

先把企业文档（Word、PDF、飞书文档、在线网页）切分成片段。
将片段向量化后存入向量数据库。
用户提问时，先从向量库中检索最相关的片段。
将“用户问题 + 检索片段 + 指令模板”一起交给大模型生成答案。

这样AI助理的回答就自带“私有知识”，既准确又可溯源。

RAG的优势在于：

不需要重新训练大模型，成本低。
知识库可以随时更新。
回答可以附引用来源，便于追溯和排错。

3.3 函数调用与工具使用

AI助理不能只“动嘴”，还要“动手”。动手能力来自Function Calling。

典型的工具包括：

日程管理工具：创建会议、添加待办。
消息工具：发送消息、@某人。
数据查询工具：查数据库、调用API。
文件操作工具：读取附件、生成表格。

实现思路是：定义好一组JSON Schema，告诉模型“你有这些工具可用，参数格式是什么”。模型根据用户问题判断应该调用哪个工具，并生成参数，再由程序执行实际调用。

3.4 Agent任务规划

当任务比较复杂时，单轮调用大模型是不够的，需要Agent模式。

Agent让模型像人一样，先拆解问题，再逐步执行。例如用户说“帮我做一份竞品分析报告”，AI助理会先规划：

检索竞品相关的内部资料。
通过搜索工具获取最新行业动态。
汇总资料生成报告提纲。
调用文档工具创建云端文档。
最终把文档链接发送给用户。

每一步都可能触发一次大模型调用，并记录中间结果。常用的Agent实现框架有LangChain、LangGraph、字节的Coze、阿里的百炼Agent等。

3.5 安全与权限治理

企业级AI助理和C端AI聊天机器人的根本区别在于：企业级场景必须做权限隔离。

一个AI助理可以使用知识库，但不同角色能看到的知识范围不同。低权限员工不应该通过AI助理问出高权限数据。研发架构上要做到：

知识库访问落地到文件权限模型。
模型交互过程记录审计日志。
敏感信息脱敏。
第三方模型调用链路加密。

这部分的工程复杂度和重要程度，往往高于模型效果本身。

4. 一个AI助理的工作全链路

为了更直观理解AI助理，我们以“钉钉AI助理查询项目进度”场景为例，模拟一次完整的请求链路。

用户提问 ↓ 多轮对话管理模块 ↓ 意图识别：查询项目进度 ↓ RAG检索：从知识库检索项目文档/周报 ↓ Function Calling：调用项目管理系统查询接口 ↓ 信息汇总模板 ↓ 大模型生成自然语言回复 ↓ 权限过滤 + 审计日志 ↓ 返回用户

需要注意的是，实际生产环境中这个流程并非固定顺序。通常会有路由层判断：“这个问题是查知识库还是查数据系统？是需要调用工具还是纯问答？”路由判断的目的，是减少不必要的模型调用，降低延迟和成本。

5. 实战：从零构建一个企业知识库AI助理

理论部分讲完，下面进入动手环节。我们构建一个“企业知识库AI助理最小可用版本”，它具备以下能力：

解析本地Markdown文档。
构建知识库索引。
用户提问后触发RAG检索。
在本地环境中不依赖外部大模型API，用规则生成可演示的回答。

为了让代码可以直接运行，这个版本不依赖OpenAI、通义等外部API，也不使用重量级向量数据库，而用本地的TF-IDF向量化方式做检索。核心目的是帮助理解RAG全流程。生产环境再替换为更高效的向量化方案。

5.1 项目结构

创建项目，目录如下：

ai-assistant-demo/ ├── data/ │ ├── 产品文档.md │ └── 项目周报.md ├── assistant/ │ ├── __init__.py │ ├── loaders.py │ ├── retriever.py │ └── generator.py ├── main.py └── requirements.txt

文件说明：

data/：存放知识库原始文档。
assistant/loaders.py：文档加载与切分。
assistant/retriever.py：检索器。
assistant/generator.py：答案生成器。
main.py：主入口，命令行交互。

5.2 准备知识库文档

在data/目录下创建两个示例文档。

data/产品文档.md：

# 企业IM工具产品文档 ## 1. 产品定位 企业IM工具是一款面向中小企业的内部沟通协作平台， 支持组织架构管理、即时消息、音视频会议、文件共享等功能。 ## 2. 消息功能 - 支持单聊和群聊。 - 消息支持已读回执。 - 支持消息撤回（2分钟内）。 - 文件传输单个最大支持200MB。 ## 3. 会议功能 - 支持最高500人同时参会。 - 主持人可以控制发言权限。 - 支持屏幕共享和会议录制。 - 录制文件自动转存到云空间。

data/项目周报.md：

# 项目管理周报（第45周） ## 一、本周进展 1. 完成了IM工具2.0版本的消息模块重构。 2. 会议功能新增“虚拟背景”能力。 3. 修复了文件传输超过200MB时的上传失败问题。 ## 二、风险与问题 - 2.0版本在低端安卓机上存在内存占用偏高问题，正在排查。 - 海外节点消息延迟有待优化。 ## 三、下周计划 - 推进文件传输断点续传功能。 - 完成会议录制转存方案的评审。 - 发布2.0版本内测版本。

这两个文档模拟了企业知识库中的两类常见内容：产品说明类文档和内部项目文档。

5.3 实现文档加载与切分

打开assistant/loaders.py，写入以下代码：

# assistant/loaders.py import os import re def load_documents(data_dir="data"): """加载 data 目录下所有 .md 文件""" documents = [] for filename in os.listdir(data_dir): if filename.endswith(".md"): filepath = os.path.join(data_dir, filename) with open(filepath, "r", encoding="utf-8") as f: content = f.read() documents.append({"source": filename, "content": content}) return documents def split_text(text, chunk_size=200, overlap=20): """ 将长文本切分成多个chunk。 chunk_size：每个块目标长度。 overlap：前后块重叠长度，防止上下文断裂。 在实际项目中，可以使用递归字符切分器。 """ # 先按段落粗分，避免把列表截断 paragraphs = re.split(r"\n{2,}", text) chunks = [] current_chunk = "" for para in paragraphs: if len(current_chunk) + len(para) <= chunk_size: current_chunk += "\n" + para if current_chunk else para else: if current_chunk: chunks.append(current_chunk.strip()) current_chunk = para # 如果单个段落超过 chunk_size，需要继续内部切分 while len(current_chunk) > chunk_size: split_point = current_chunk.rfind(" ", 0, chunk_size) if split_point == -1: split_point = chunk_size chunks.append(current_chunk[:split_point].strip()) current_chunk = current_chunk[split_point:] if current_chunk.strip(): chunks.append(current_chunk.strip()) return chunks def prepare_chunks(data_dir="data"): """加载文档并切分，返回带来源信息的chunk列表""" docs = load_documents(data_dir) all_chunks = [] for doc in docs: chunks = split_text(doc["content"]) for chunk in chunks: all_chunks.append({"source": doc["source"], "content": chunk}) return all_chunks

这段代码里，split_text函数是核心。它先按空行切分文档，再根据chunk_size和overlap生成可控长度的文本块。

为什么需要切分？

大模型的输入长度有限，且企业文档动辄几十页，直接全部塞进去不现实。切分之后，我们只需要把与问题最相关的几个块检索出来，拼进Prompt就能得到高质量回答。

5.4 实现检索器

打开assistant/retriever.py，写入以下代码：

# assistant/retriever.py import math import re from collections import Counter class TfidfRetriever: """ 简化版TF-IDF检索器。 生产环境建议替换为向量数据库+Embedding模型。 """ def __init__(self, chunks): self.chunks = chunks self.tf_vectors = [] self.df = Counter() self.doc_count = len(chunks) self._build_index() def _tokenize(self, text): # 简单分词：中文按字切分（生产环境建议使用jieba） text = text.lower() tokens = re.findall(r"[\w\u4e00-\u9fff]+", text) return tokens def _build_index(self): for chunk in self.chunks: tokens = self._tokenize(chunk["content"]) tf = Counter(tokens) self.tf_vectors.append(tf) for term in set(tokens): self.df[term] += 1 def _tfidf(self, tf, term): tf_val = tf.get(term, 0) if tf_val == 0: return 0 idf = math.log((self.doc_count + 1) / (self.df.get(term, 0) + 1)) + 1 return tf_val * idf def search(self, query, top_k=2): query_tokens = self._tokenize(query) scores = [] for idx, tf in enumerate(self.tf_vectors): score = 0.0 for term in query_tokens: score += self._tfidf(tf, term) scores.append((idx, score)) # 按得分降序排序，取前 top_k scores.sort(key=lambda x: x[1], reverse=True) results = [] for idx, score in scores[:top_k]: results.append({ "source": self.chunks[idx]["source"], "content": self.chunks[idx]["content"], "score": round(score, 4) }) return results

这个检索器实现了“训练”和“查询”两个阶段。

_build_index构建每个块的词频TF，以及全局的文档频率DF。
search对用户查询分词，计算每个块与查询的相关性得分。
返回最相关的top_k个文本块作为“背景知识”。

如果你之后想升级为真正的向量检索，只需把TfidfRetriever替换为langchain_community.vectorstores.FAISS或Pinecone，接口可以保持不变。

5.5 实现生成器

打开assistant/generator.py，写入以下代码：

# assistant/generator.py class RuleGenerator: """ 基于规则+检索结果的答案生成器。 生产环境中，这一步应替换为LLM调用， 例如： response = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": prompt}, {"role": "user", "content": user_query} ] ) """ def __init__(self): pass def generate(self, query, contexts): # 如果没有检索到相关内容，直接返回提示 if not contexts: return { "answer": "抱歉，我没有在知识库中找到相关的内容。", "sources": [] } # 这里基于规则做简单的答案拼接。 # 实际项目中，应该将 query + contexts 交给大模型， # 让大模型对检索结果进行归纳总结。 answer_parts = [] sources = set() for ctx in contexts: sources.add(ctx["source"]) # 简单提取第一段作为“答案片段” first_line = ctx["content"].strip().split("\n")[0] answer_parts.append(first_line) answer = "\n".join(answer_parts) return { "answer": answer, "sources": list(sources) }

这里用规则生成器是为了演示“检索+生成”的关系。生产环境中，真正的工作方式是：

# 生产环境示意：使用大模型API（以OpenAI兼容接口为例） from openai import OpenAI client = OpenAI( api_key="YOUR_API_KEY", base_url="https://your-llm-api.example.com/v1" ) def generate_with_llm(query, contexts): context_text = "\n\n".join([c["content"] for c in contexts]) system_prompt = f""" 你是一个企业知识库AI助理。请根据以下资料回答用户问题。 如果资料中没有答案，请直接说明“没有找到相关信息”，不要编造。 资料： {context_text} """ response = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": query} ] ) return response.choices[0].message.content

注意，实际对接通义千问、腾讯混元、豆包等国内模型时，各家都有对应的接口文档，但绝大多数兼容OpenAI格式。你只需要修改base_url、api_key和model即可。

5.6 编写主入口

打开main.py，写入以下代码：

# main.py from assistant.loaders import prepare_chunks from assistant.retriever import TfidfRetriever from assistant.generator import RuleGenerator def main(): print("正在初始化知识库...") chunks = prepare_chunks("data") retriever = TfidfRetriever(chunks) generator = RuleGenerator() if not chunks: print("知识库为空，请先在 data 目录下添加文档。") return print(f"知识库加载完成，共 {len(chunks)} 个文本块。\n") while True: query = input("请输入你的问题（输入exit退出）：").strip() if query.lower() == "exit": break if not query: continue contexts = retriever.search(query, top_k=2) result = generator.generate(query, contexts) print("\n【回答】") print(result["answer"]) print("【参考来源】", ", ".join(result["sources"])) print("-" * 50) if __name__ == "__main__": main()

5.7 运行验证

在项目根目录执行：

python main.py

预期交互效果如下：

正在初始化知识库... 知识库加载完成，共 6 个文本块。 请输入你的问题（输入exit退出）：文件上传支持多大？ 【回答】 文件传输单个最大支持200MB。 【参考来源】 产品文档.md -------------------------------------------------- 请输入你的问题（输入exit退出）：本周完成了什么？ 【回答】 完成了IM工具2.0版本的消息模块重构。 【参考来源】 项目周报.md -------------------------------------------------- 请输入你的问题（输入exit退出）：exit

从结果可以看到，AI助理能够根据问题找到最相关的文档块，并给出带来源的回答。这就是RAG的核心链路。

5.8 升级到真实大模型

如果你希望让回答更自然、更有总结性，把RuleGenerator替换成大模型即可。以通义千问为例：

# assistant/generator.py 升级版（示意） import os from openai import OpenAI # 通义千问兼容OpenAI格式 client = OpenAI( api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1" ) class LLMGenerator: def generate(self, query, contexts): if not contexts: return {"answer": "抱歉，我没有在知识库中找到相关内容。", "sources": []} context_text = "\n\n".join([c["content"] for c in contexts]) sources = list(set([c["source"] for c in contexts])) system_prompt = f""" 你是一个企业知识库AI助理。请根据以下资料回答用户问题。 要求： 1. 回答要基于资料，不要编造。 2. 如果资料不足，明确说出不知道。 3. 回答简洁，直接给出结论。 资料： {context_text} """ response = client.chat.completions.create( model="qwen-plus", messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": query} ], temperature=0.3 ) answer = response.choices[0].message.content return {"answer": answer, "sources": sources}

其他大厂的模型接口也类似，腾讯混元、字节豆包都提供了兼容OpenAI的HTTP接口。生产环境建议通过环境变量管理API Key，不要硬编码在代码中。

6. 从Demo到生产：AI助理落地的常见问题

6.1 检索质量差，答非所问

现象：用户问“文件大小限制”，结果检索出“会议录制转存”等不相关内容。

常见原因：

切分粒度不合理，chunk太大导致噪音过多。
检索算法不匹配场景，TF-IDF对语义相似（如“容量”和“200MB”）检索能力弱。
文档中关键词与用户口语不一致。

解决思路：

改用向量检索，使用Embedding模型（如text2vec、bge系列）编码文本和查询。
尝试混合检索（BM25 + 向量召回 + 重排序）。
对文档标题和正文做加权处理，标题命中给予更高的分数。
设置相关性阈值，得分过低时不返回结果。

6.2 回答幻觉问题

现象：知识库里没有的信息，AI助理一本正经地编造答案。

常见原因：

Prompt没有约束“只能基于资料回答”。
检索结果为空但模型仍然硬答。
模型温度参数设置过高。

解决思路：

在System Prompt中强制加入“知识库未覆盖的内容，请回答不知道”。
检索结果为空时直接拦截，不调用生成模型。
调低temperature，推荐0.1~0.3。
开启引用溯源，回答内容关联原始文档片段。

6.3 权限越权问题

现象：普通员工通过AI助理问出了涉密数据。

常见原因：

知识库向量化时没有继承文件权限。
检索阶段没有做用户权限过滤。
向量数据库的collection对所有用户共享。

解决思路：

每个文档写入索引时标注allowed_roles、allowed_users字段。
检索时按当前用户身份填充过滤条件。
对无法判断权限的数据默认不返回。
留存完整审计日志。

6.4 多轮对话丢失上下文

现象：第一轮问“会议功能有哪些”，第二轮问“那文件功能呢”，AI助理不理解“那”指的是什么。

常见原因：

没有维护会话历史。
每次请求都是无状态单轮调用。

解决思路：

将历史消息拼接到请求上下文中。
控制历史轮数，建议保留最近10~20条。
对长会话做摘要压缩，避免超出模型上下文窗口。

6.5 成本暴涨

现象：AI助理上线后每天消耗大量token，费用失控。

常见原因：

系统Prompt过长，每个请求都携带大量固定内容。
检索片段过多，默认加载几十个chunk。
没有设置缓存机制。

解决思路：

将System Prompt设计为“精简指令 + 动态检索内容”。
限制生成的max_tokens。
相同问题在短时间段内直接返回缓存结果。
对高频问题做预设答案（FAQ覆盖）。

问题现象	常见原因	解决思路
答非所问	检索质量差	换向量检索，混合召回，加Rerank
编造答案	Prompt不约束、温度过高	强制基于资料回答，空结果拦截
越权泄露	权限模型未落地	文档级权限过滤、审计日志
多轮混乱	无会话上下文	拼接历史、摘要压缩
成本爆炸	上下文太长、过期缓存	精简Prompt、设置缓存

7. 企业级AI助理落地最佳实践

7.1 先选场景，不要盲目铺开

做AI助理，最忌讳的就是“想做一个大而全的助理，一句话指挥所有系统”。前期应该聚焦1~2个高频、低风险、见效快的场景。

推荐优先级排序：

知识库问答：例如企业制度咨询、产品FAQ、项目文档查询。数据都是静态的、明确可授权的、回答错了影响有限。
会议纪要与待办提取：利用语音转写+大模型总结，效率和直观收益都很高。
代码辅助：面向研发团队，典型收益是提升编码效率。
自动化流程类：例如审批、排班、报表生成。这类场景涉及系统对接，建议放在后期。

7.2 数据先行：知识库质量决定上限

AI助理效果的上限不取决于模型多强，而取决于你的知识库多干净。

建议建立如下数据治理规范：

文档必须有明确的负责人和更新时间。
过期文档要及时下线或标记为“已失效”。
文档标题要语义明确，便于检索命中。
同一主题避免多个版本并存。

一个实用的小技巧是：在文档开头用一段话进行摘要。这样检索时能被召回，生成时也能作为信息源。很多团队直接要求周报必须包含“本周核心结论”，这部分内容天然适合被AI助理检索。

7.3 权限隔离必须前置

在构建知识库索引前，就要设计好权限模型。

推荐的最小方案：

为每个知识文档打标签：公开、部门内、仅项目组。
在向量数据库中每个chunk的metadata中写入权限标签。
检索阶段根据用户身份生成过滤条件。

7.4 建立评估闭环

AI助理不是上线后就完事了。你需要在真实使用中不断发现badcase。

比较可行的方案是：

用户对话后提供“回答是否有帮助”的点赞/点踩按钮。
对点踩样本每周做一次复盘。
将badcase加入回归测试集，模型或Prompt更新后统一验证。

这里推荐维护一个test_cases.json：

{ "test_cases": [ { "query": "文件传输大小限制是多少？", "expected": "200MB", "source": "产品文档.md" }, { "query": "本周项目风险有哪些？", "expected": "低端安卓内存占用、海外节点延迟", "source": "项目周报.md" } ] }

每次更新Prompt、调整切分策略、更换模型后，都跑一遍回归测试，避免“修了bug引了新bug”。