摘要：在当今数字化转型浪潮中，企业对知识管理的需求日益增长，而AI技术的融入为企业知识库的构建带来了新的机遇。本文将深入剖析企业RAG（检索增强生成）知识库项目的全生命周期设计，从项目启动到落地实施，详细解读如何从零开始构建知识库，如何提升知识库的召回率与准确率，以
在当今数字化转型浪潮中，企业对知识管理的需求日益增长，而AI技术的融入为企业知识库的构建带来了新的机遇。本文将深入剖析企业RAG（检索增强生成）知识库项目的全生命周期设计，从项目启动到落地实施，详细解读如何从零开始构建知识库，如何提升知识库的召回率与准确率，以及如何通过数据处理和系统设计实现知识的有效管理和应用。
在AI项目中分为几种不同类型的应用，例如AI原生应用（各种端到端的平台）、AI垂类项目（基于RAG和知识库的行业知识库项目、各种基于知识库和智能体的搭建的应用）
这些项目类型中，知识库产品落地是较为简单的，所以本次从知识库项目的起始到结束全部给大家讲明白，在企业内一个知识库项目从部署大模型到落地输出成果都需要哪些步骤，从接到需求到项目落地，产品经理又都需要做什么？
虽然本次是以项目视角描述构建过程，但无论是企业内部自建团队，还是外包给供应商，都可以遵循这套生命周期。
看完本篇文章你可以了解：
如何从0-1构建知识库？如何提升知识库召回率、准确率？常见问题如何定位解决？如何做数据处理？构建知识库后还可以在这个基础上做什么？项目构建流程整个项目的落地流程如下，我们也将会按照这个大致的步骤分析和落地本项目
方案评估AI+知识搜索/问答是企业内最好落地的场景之一，且价值较高，作为企业的底层建筑，通常是第一个落地，但是构建和维护高质量的知识库（包括数据收集、处理、向量化、索引创建等）是一个成本较高的过程，所以企业通常更愿意找专业的公司完成此类工作。
业务痛点分析
不同公司在沉淀资料构建知识库的需求是不一样的，首先收集企业痛点才好根据痛点需求设计方案，常见企业痛点如下
信息检索效率低：企业知识散落在多处（在线文档、本地文件、纸质资料），员工或客户查找信息耗时耗力。重复性咨询成本高：客服、HR、IT支持等部门需要花费大量精力回答重复性问题。知识传承困难：核心员工离职易造成知识断层，新员工上手周期长。合规与准确性风险：在金融、法律、医疗等领域，确保输出信息的准确性和合规性至关重要。通用大模型的“幻觉”问题在此类场景下是不可接受的。内部数据隐私：企业核心数据（如财务、战略、研发资料）高度敏感，不能依赖公开的在线大模型服务。指标拆解
看完上面的痛点，肯定能发现，虽然确实有这个问题，但还是不够准确，无法指导落地与实施。
我们产品经理就是要将模糊的业务痛点转化为清晰、可量化的业务目标与评估指标，并设定项目目标，这样才能把一个空洞模糊的指标落地下来。
指标拆解法一：公式法
假设北极星指标是 “节省人力成本”。
节省成本 = (AI处理的会话数) * (人工处理单次会话的平均时长) * (客服时薪)
为了提升“节省成本”，你可以：
提升 AI处理的会话数：这又可以拆解为 总会话数 * AI应答率。降低 人工处理单次会话的平均时长：如果AI作为助手赋能人工，可以通过提供高质量信息来达到此目的。指标拆解法二：因素拆解法
假设北极星指标是 “用户自助问题解决”。
为了让用户自助解决问题，必须满足：
1）用户愿意用
系统入口是否明显？ -> 触达率
2）AI能听懂用户的问题
AI是否能正确理解用户意图？ -> 意图识别准确率用户是否需要反复换说法？ -> 平均会话轮次3）知识库里有相关知识
用户提问后，系统是否能找到知识？ -> 知识召回率有多少问题系统完全找不到答案？ -> 零结果率4）AI给出的答案是优质的
答案是否准确无误，没有幻觉？ -> 答案准确性答案是否解决了用户的问题？ -> 答案采纳率系统响应速度快不快？ -> 平均响应时长系统设计需求细化与确认
1）细化需求：现在需要深入现场，和真正使用系统的一线用户以及管理知识源的专家进行交流。细化并确认中的需求，尤其是智能问答的应用场景、对话流程、知识库的具体内容和结构，设计出项目架构。
2）开展调研：列出调研明细，双方分别需要如何配合，原则就是根据你的目标列出你要做什么，你需要对方（客户）什么人员、怎么配合你、提供什么资料，调研方法通常是以下这些：
（1）用户访谈：
对象：挑选典型用户，包括新手、专家、高频使用者和偶尔使用者。
问题清单 (半结构化)：准备问题提纲，观察客户现有工作流程中的问题，根据问题挖掘痛点，发现隐性知识和求助路径，探索期望功能和交互方式。
（2）现场观察：
内容：如果条件允许，直接坐在用户旁边，观察他们如何工作。这能发现很多用户在访谈中因习以为常而忽略的细节。
（3）问卷调查：
优势：当用户群体庞大时，可以通过问卷快速收集量化数据。
内容：可以调查最常查询的知识类型、对当前信息查找方式的满意度评分、最希望优先解决的问题等。
3）收集资料：客户各种数据都需要提供，且需要明确资料收集的方式。
企业内部数据：如历史纸质资料、各个系统的历史资料、扫描件、各种在线文档……外网公开数据：各种公开资料，通常使用爬虫的方式收集，不过如果是信创项目，爬虫可能存在风险，这也是需要提前与客户沟通的内容。付费外采数据：内部资料不足或者不够优质，如各种公司的资料、行业报告等，就需要付费了。4）数据整理：与客户的业务专家共同设计知识结构，定好全部数据的储存框架、策略，否则后续的维护和查重工作也非常头大。
5）对接方式：不同的数据对接方式是不一样的，比如客户有数据中台，那我们直接对接数据中台，客户纸质文件是需要落地转为电子文件的。
需求验证
1）数据范围界定：明确知识来源，如内部Wiki、PDF/Word文档库、数据库、付费外采的行业报告等。
2）POC产品选择：市面上可以选择的知识库、智能体搭建产品有 fastgpt、n8n、coze、dify、AppBuilder等等，后续会专门出一篇关于产品评测选择的文章。
3）技术路径：
是否需要知识库 (RAG)：对于需要依据特定、私有、高时效性知识进行回答的场景，RAG是必选项，它可以有效解决LLM的知识局限和幻觉问题。是否需要微调 (Fine-tuning)：当需要模型模仿特定风格（如客服语气）或掌握特定领域的复杂指令时，可以考虑微调。但微调成本高，对数据质量要求苛刻，需谨慎评估。判断是否需要微调：微调的成本是非常高的，判断方式主要基于以下几点
1）数据模块
-数据偏移：微调提供的数据和模型原始数据差异过大，模型在新任务上表现反而不会好
-数据质量差：微调需标注准确、覆盖全面，噪声数据会大大影响模型性能
2）训练模块
-过拟合：训练方式不当或者数据量不够，泛化能力下降，过度专注单一任务
-数据遗忘：训练可能导致原预训练数据被遗忘，所以一定要选择合适匹配的模型进行训练
3）成本模块
-人力/时间成本：微调需足够高质量数据（如数千条标注数据），项目预算是否可以覆盖
4）验证目的：先收集测试数据，通过测试数据就可以知道，这个过程能够更深层的梳理出本次项目可能存在的风险
技术预研：要判断客户目前积累的数据和我们沉淀的算法，是否可以达到业务需求，任何项目都是尽可能采取更小成本的方式落地，初期产品大多会以最简单的方式，比如Prompt工程初步做验证，整体评估下来如果数据不满足，产品需要协助算法在客户内部获取数据评估算力资源：需要评估项目所需的GPU型号和显存，取决于模型的参数量以及采用的操作方式，如下表是常见的部署方式和所需资源，通常由产品经理、算法工程师和研发工程共同完成需求详细定义
功能需求: 比如AI Agent的对话能力、意图识别、多轮对话、上下文理解、知识推荐、任务执行（如开单、查询）集成需求：与客户内部系统，如CRM、ERP、单点登录系统、用户权限信息等知识库需求: 知识的来源、具体格式、采集、清洗、结构化、标签化、版本控制、权限管理、更新机制、检索效率、召回率、准确率等非功能需求: 性能（并发数、响应时间）、可用性（易用性、UI/UX）、安全性（数据加密、访问控制、合规性）、可扩展性、可维护性AI模型需求: 模型适配（除了已经适配的模型，客户可能采了别人的模型需要做适配）、领域微调需求（通常不做微调）、模型评估指标、持续学习能力（badcase优化、抓取实时数据、数据集持续优化）产出: 详细需求规格说明书、用例、需求调研报告，这部分的内容是非常宝贵的，在深入客户现场调研清楚需求后，后续可以抽象需求形成产品的标准化功能，推广至更多客户系统架构与功能设计
如图，我们需要对整个产品的架构进行设计，包括你后续的计划（最终要做成的样子），示例图中因为有后续建设Agent的部分，仅给大家做个参考
数据埋点规划
“没有测量，就没有优化”，有数据才能知道如何优化，所以有数据是必须的。前面拆解完指标，在设计整体方案时产品经理还需要设计数据采集方案且融入到知识库本身的解决方案中，后期给客户、给研发做宣贯。
需要采集的数据：
后端日志：每次请求的用户ID、问题、时间戳、召回的知识源、生成的答案、响应时长等。前端埋点：用户点击了哪个入口、会话开始/结束时间、是否点击“赞/踩”、是否复制了答案、是否在得到答案后很快关闭了窗口。用户主动反馈：在每个答案后提供明确的反馈按钮（如 👍/👎，或“已解决”/“未解决”）。离线评估数据：建立人工评测流程，定期抽样问题进行“准确性”、“相关性”等维度的打分。知识库构建知识库构建流程
整个知识库建设的流程如下，他是属于我们解决方案的一个部分，能够大大提升通用领域大模型在专有领域的落地效果和可靠性，降低模型幻觉。
数据收集:
从多源（文档、FAQ、数据库、API）收集知识，为后续进行清洗、抽取、转换、标注做准备，通常数据来源以下渠道：
对于在线系统 ：编写脚本，利用API定期拉取更新的文档。不过同时需要注意处理权限问题。对于文件服务器：编写脚本（如Python的os和shutil库），定期扫描指定文件夹，同步新增或修改的文件。对于数据库：编写SQL查询，从业务数据库中导出结构化的知识（如FAQ对）。手动上传：为无法自动采集的零散文件（如邮件附件、本地Word），提供一个统一的知识管理后台上传入口（前面推荐的平台都会有这个入口）。注意事项：
忽视数据源的动态性：未建立自动化同步机制，导致知识库信息严重滞后于源头。低估非文本内容的处理难度：对于扫描件、图片、复杂表格，若没有合适的OCR或版面分析方案，会造成大量关键信息丢失。规划知识库结构
良好的结构便于后续的权限管理和应用调用，在项目中，通常需要客户的业务专家支持一起规划结构。
按业务领域：如“产品知识库”、“HR政策知识库”、“销售话术知识库”。按数据敏感度：如“公开信息知识库”、“内部核心知识库”。按部门：如“市场部资料库”、“研发部文档库”。1）清理格式：在上传前，手动打开Word/PDF文档，删除不必要的页眉页脚、封面、目录。修正文档中的错别字和格式错误。
2）优化结构：对于长文档，尽量使用清晰的标题层级（如Word的标题1, 标题2）。这能帮助平台的自动分段功能更好地理解文档结构。
3）转换格式：如果平台对某些格式（如扫描版PDF）支持不佳，需要在平台之外先用OCR工具将其转换为纯文本或格式化的Word文档。
4）图文处理：有些复杂文档不光格式复杂，甚至还有图文同时存在的情况，图片的处理跟文字相比会麻烦点，可能涉及的方法有以下三种：
OCR提取图中文字：调用OCR服务，获取图片中的所有文字图像描述生成：将图片输入到这些模型中，让模型生成一段描述性文字上下文关联描述 (实际工作中最有效)：紧邻图片上方和下方的文本段落，切片时与图片切分到一个chunk里数据去重
对清洗后的文档内容或初步切分的chunk进行哈希计算，去除完全重复的部分。这一步成本低，效益高，建议先做。
哈希检测：通过计算文本的哈希值（如MD5, SHA256），将文本映射为唯一的、定长的指纹，从而实现快速、精准的内容比对。
精确切分
不同的文本类型切分的策略也不一样，针对性设计切分的方式
1）固定长度切分：最基础，但容易割裂语义。通常配合重叠（Overlap）来缓解（也就是每一个片段的开头和结尾跟上下切片有重叠）。
2）递归/分隔符切分：更智能，优先寻找自然的语义边界（如段落、句子）进行切分，是目前的主流方法。
3）语义切分：基于Embedding向量的相似度来判断语义连贯性，效果更佳但计算成本更高。
4）元数据附加：为每个chunk打上丰富的“标签”信息（来源、标题、日期、类别）。
5）注意事项：
“One-Size-Fits-All”的切分策略：对不同类型（如代码、财报、对话记录）的文档使用相同的切分参数，效果一般都不行。Chunk尺寸的极端化：切分太小，导致上下文信息不足，LLM难以理解；切分太大，导致包含过多无关噪声，降低了检索的信噪比。索引方式：通常是平台默认的向量索引，但FastGPT等平台还支持全文索引，可以开启以增强关键词匹配能力。文本补全/内容增强
原始知识可能很简洁或缺乏上下文，很可能导致后续召回率低，所以针对这种情况就要单独做文本补全和内容增强。
1）假设性问题生成：利用LLM为知识“答案”反向生成多个可能的“问题”，极大地扩展了召回的入口。
2）内容摘要与关键词提取：利用LLM生成精炼的摘要作为原文的补充或元数据，增强语义表示。
3）注意事项：
LLM生成内容的质量失控：未对LLM的生成进行有效约束（通过Prompt Engineering），可能导致生成的问题与原文偏离，引入噪声。成本与收益失衡：对知识库中的所有内容都进行LLM增强，成本极高。应考虑优先对高价值、查询频率高的知识进行增强。索引入库
如果使用的是在线平台，通常会自动对数据进行入库，若自己搭建可以参考下列方法：
1）向量数据库选型：根据数据规模、并发需求、运维能力和成本，选择合适的向量数据库（如Milvus, Qdrant, Pinecone等）。
2）索引构建：在数据库中选择并配置合适的索引算法（如HNSW, IVF-PQ），在检索速度和准确率之间取得平衡。
3）批量写入：采用批量方式将数据写入数据库，以获得最佳的写入性能。
4）注意事项/关键陷阱：
索引配置与应用场景不匹配：例如，对需要100%精确召回的场景使用了牺牲精度的近似索引。元数据索引缺失：未对附加的元数据字段（如日期、类别）创建索引，导致基于这些条件的过滤查询速度极慢，无法在生产环境中使用。忽视可扩展性：初期选择了无法水平扩展的轻量级方案，当数据量和用户量增长时，系统性能迅速成为瓶颈。知识库项目常见问题
AI知识库（尤其是在 RAG 检索增强生成框架中）在应用和落地过程中存在一些痛点，比如：
另外还要注意：在企业环境中，不同部门、不同级别的员工能看到的知识是不同的。数据安全和权限隔离是B端产品的红线。 比如普通员工看到了公司财务机密；销售A组看到了销售B组的客户资料。产品设计之初就要深度集成企业的权限体系（如LDAP/AD域）。在知识入库时就要打上权限标签，在检索和生成时进行严格的权限过滤，确保用户只能看到其权限范围内的信息。
评测我们将测试与优化分为两大核心指标：召回率 和准确性。这两个指标有时会相互制约，优化的过程就是在它们之间找到最佳平衡。
检索召回率
对于一个用户问题，系统能否从知识库中找到所有相关的知识片段。召回率低是“答非所问”或“我不知道”的首要原因。
1）构建测试集
与业务专家合作，手动创建一份高质量的测试集（建议至少100-200个问题）。最关键的是，对于每个问题，需要人工标注出它在知识库中对应的正确答案源（一个或多个文档/知识片段ID）。
2）离线批量评测
编写一个评测脚本，遍历测试集中的所有问题。对于每个问题，只执行检索步骤，而不进行生成。记录下系统实际召回的知识片段ID列表。
3）失败案例分析
找出所有召回率低（
优化方案
一：优化知识切分
问题表现：一个完整的答案被切分到两个不相邻的chunks里，导致只能召回其中一个。
优化方案：
调整Chunk Size和Overlap：增加chunk_overlap，让上下文信息在相邻chunks之间有更多重叠。适当增大chunk_size，但要注意不要引入太多噪声。
调整切分方法：从固定长度切分切换到语义切分或按标题结构切分，确保语义单元的完整性。
二：Query重写
同义词扩展：识别出Query中的关键词，并用同义词词典将其扩展。
子问题分解：对于复杂问题，让LLM将其分解为多个更简单的子问题，然后对每个子问题分别进行检索。
历史对话融合：在多轮对话中，用户的后续问题往往省略了上下文。需要将当前问题与历史对话内容结合，生成一个完整的、无歧义的新问题。
LLM生成式重写：让LLM根据用户的原始问题，先生成一个它想象中的“完美答案”（一个假设性文档）。然后，不用这个生成的答案，而是将这个假设性文档进行向量化，用它的向量去知识库里搜索最相似的真实文档。
三：更换或微调Embedding模型
对于特定领域的术语或近义词，当前Embedding模型无法准确理解其相似性。：查阅MTEB排行榜，选择一个在你的语言和领域上表现更好的预训练模型。
微调 (Fine-tuning)：如果预算和数据充足，可以基于你自己的数据（特别是badcase）对Embedding模型进行微调，让它更懂行业术语。
四：采用混合检索（多路召回）
向量检索 ：强大的语义理解能力，能处理同义词、近义词和不同措辞。
稀疏向量/关键词检索 精准匹配关键词，对于包含专业术语、产品型号、人名的查询非常有效。
图谱检索：如果你的知识库构建了知识图谱，可以直接查询实体及其关系。
结构化数据查询 ：直接查询数据库中的表格数据。
答案相关性
在“找对”的基础上，评估排序模型（Re-ranker）“排得好不好”。它是否把最相关的“关键证物”放在了最前面，供LLM优先“审阅”
归一化折损累计增益
检索出的文档与问题的相关程度（可以由人工标注，如：非常相关=3，相关=2，不相关=1）。越靠前的结果权重越高。
对比分析 (A/BTest)
将经过Re-ranker排序后的上下文，和未经排序的上下文，分别喂给同一个LLM生成答案。然后由人工判断，哪一组生成的答案质量更高。这是一种非常直观的端到端评测方法，能直接体现Re-ranker带来的价值。
问答准确率
在召回了相关信息的前提下，LLM最终生成的答案是否正确、忠实于原文且没有幻觉
端到端（End-to-End）评测
使用“黄金测试集”，但这次运行完整的“检索+生成”流程，获取最终的AI回答。
人工评估 (Human Evaluation)：这是目前最可靠的准确性评估方式。邀请评估员（最好是业务专家）对每个回答，从以下几个维度进行打分（例如1-5分制）：
忠实度 (Faithfulness)：答案是否完全基于提供的上下文？有没有捏造信息（幻觉）？答案准确性 (Answer Correctness)：答案本身的事实是否正确？完整性 (Completeness)：答案是否全面地回答了用户的问题？简洁性 (Conciseness)：答案是否简洁明了，没有多余的废话？自动化评估
操作：对于大规模测试，可以借助自动化评估框架，如 RAGAS。RAGAS可以计算出一些量化指标，作为人工评估的补充。
RAGAS核心指标：
Faithfulness：通过LLM判断答案是否忠于上下文。Answer Relevancy：答案与问题的相关性。Context Precision：检索到的上下文的相关性。Answer Correctness：答案与标准答案（ground truth）的语义相似度。1.优化Prompt (最直接有效)
加强上下文控制：在Prompt中用更强硬的措辞（如“禁止”、“绝不允许”）来约束LLM，强制它只使用提供的上下文。
明确降级策略：清晰地告诉LLM，当知识不足时应该如何回应（例如，回复“我不知道”）。
使用Few-Shot示例：提供一两个高质量的“问题-上下文-完美回答”的示例，让LLM模仿。
2.调整检索参数 (Top-K & Score Threshold)
调整Top-K：减小K值（例如从5减到3），只将最相关的几个知识片段提供给LLM，减少噪声。
设置相似度阈值：过滤掉那些虽然在Top-K内，但本身相关性得分就不高的chunks。
3.更换或优化LLM
不同的LLM在遵循指令和逻辑推理能力上有巨大差异。通常，更强大的模型（如GPT-4, Claude 3 Opus）能更好地理解和总结上下文，从而提高准确性。
微调 (Fine-tuning)：对于需要遵循特定、复杂格式或逻辑的场景，可以考虑对生成模型进行微调。但这是最后的手段，成本较高。
进阶建设落地还缺失了什么？
仅做知识库其实还有很大的局限，真实业务场景中的问题往往是复杂的、多轮的、需要澄清的，而不是简单的“一问一答”。 用户问“A项目的方案和B项目的预算对比如何？”，简单的知识库无法处理这种需要整合多个信息点的复杂查询。这就需要引入Agent的概念。设计能够拆解复杂问题、规划执行步骤、甚至在信息不足时主动向用户追问的智能体，将知识库从一个被动的“数据库”变成一个主动的“工作助理”。
场景扩展
知识库和Agent是相辅相成的，有了专业性的知识，又有了更合适的思考方式，生成的内容采用率会大大提升。我们可以一起看看都有什么场景可以让我们落地，最大化利用知识库：
智能客服 / 企业内问答机器人：客户/员工的大量重复性问题，耗费人力，响应不及时；领域专家助理：销售、法务、研发等专业人员，需要快速从海量资料中找到精准信息来支持工作；报告/文案自动生成：撰写周报、专业性报告、会议纪要、营销文案等格式化文档，费时费力；竞品情报智能分析：市场信息庞杂，人工分析竞品动态和用户反馈效率低、不全面；合同/标书风险审查：人工审查上百页的合同或标书，容易遗漏关键风险点；复杂工单/故障归因分析：复杂的系统故障，需要资深工程师查阅大量日志和文档才能定位根因；那么在Agent搭建上我们要关注什么？
意图识别
意图识别是非常重要的，大模型只有理解了用户需要的是什么，才能更好的回答，借助agent的思考规划能力，能够将落地回答采纳率大大提升。
方法一：基于关键词与规则
预先定义一套关键词或正则表达式规则。将每个规则与一个特定的意图（或工具）绑定。当用户输入时，用这些规则去匹配。匹配成功，则触发对应的意图。
方法二：传统NLU分类模型
为每个意图，收集并标注大量的用户语料。使用这些标注好的数据，训练一个文本分类模型，当用户输入时，用训练好的模型来预测其最可能的意图类别。
方法三：基于LLM的零/少样本分类
设计一个Prompt，将用户输入和所有意图的描述一起发给LLM，让LLM来判断用户输入最符合哪个意图。无需训练数据，迭代极快：增加一个新意图，只需要在Prompt的工具列表中增加一项描述即可，极大地提升了灵活性。
工具实现与封装
首先要准备好有哪些是需要在智能体中调用的工具，比如数据库查询能力、天气日期查询等。主要有两种方法，Function call和MCP，如何选择？
如果你的项目工具集相对稳定，对安全性和稳定性要求极高，优先选择Function Calling。如果你的项目需要频繁地增删工具，或者你想在自己的小模型上快速实现工具调用能力，或者你的目标是部署在端侧设备上，MCP是一个非常值得考虑的、更轻量灵活的方案。Function call
这个方式就像是给工具设计一个精确的API接口
精准、可控、安全： 因为函数和参数都是你预先严格定义的，模型只能在你的“白名单”里做选择，不会胡乱调用。复杂参数支持： 能处理复杂的、结构化的参数，如嵌套的JSON对象。主流支持： OpenAI、Google Gemini等主流模型API都原生支持，使用方便。不够灵活： 每次新增或修改工具，都需要重新定义Schema并修改代码，不够灵活。依赖模型能力： 强依赖大模型自身的工具调用意图识别能力。直接用自然语言描述你的工具，就像写一份简单的说明文档。
极其灵活： 增删改查工具，只需要修改“说明文档”文本即可，无需修改代码和复杂的Schema。轻量高效： 对于小模型（如端侧模型）非常友好，因为其实现方式更简单，开销更小。符合直觉： 用自然语言描述工具，更符合人的思维习惯。安全性、可控性稍弱： 因为是弱结构化的，理论上模型输出的格式可能会有偏差（虽然MCP通过校准技术很大程度上解决了这个问题）。复杂参数处理能力： 对于深层嵌套的复杂参数，可能不如JSON Schema那样明确和稳定。生态和标准化： 目前主要是MiniCPM系列模型在主推，生态和标准化程度不如Function Calling。提示词撰写
产品经理和用户撰写的提示词最大的不同，就是有没有“目标”。作为产品，写出来的提示词一定是能够解决问题、可定位、可优化的，所以我们的提示词一定要遵循一定的框架，再配合高阶用法实现目标，可参考如下方法：
提示词的基本框架-RTF
RTF框架是一种非常实用、普适性极强的Prompt结构，包含Role（角色）、Task（任务）、Format（格式）。一个好的Prompt，特别是用于复杂任务的Prompt，一般都包含这三个要素。
R – Role (角色)：为LLM设定一个具体、专业的身份。这个身份就像给演员一个剧本，让他能立刻进入状态，知道该用什么样的知识、语气和视角来回应。T – Task (任务)：清晰、无歧义地描述LLM需要完成的具体工作。这是Prompt的核心和骨架。F – Format (格式)：明确规定LLM输出结果的结构、样式和组织方式。这是一个基础框架，要想更好的实现目的，也要配合其他的方法比如CoT，可以显著提升提示词效果。
思维链法（CoT）
强迫LLM将一个复杂问题分解为多个更简单的子问题，并逐步解决。这个过程本身有助于模型更深入地思考，调动更多的计算资源来处理每一步，从而减少直接跳到错误结论的概率。这种方法我们在很多地方都能见到，比如manus、deep research、模型推理框架。
提升准确性：在算术、常识推理和符号推理等任务上，CoT能将LLM的准确率提升数倍。增强可解释性：通过阅读LLM的“思考过程”，我们可以理解它是如何得出结论的，这对于调试和信任AI的回答至关重要。如果过程错了，我们能清晰地知道错在哪里。上下文控制法
在RAG（检索增强生成）场景下，这是一种专门用于约束LLM行为的Prompt技术。其核心是建立一套严格的规则，强制LLM的回答只能来源于你提供的“上下文”（即从知识库检索出的信息），并定义当上下文不足时的“降级策略”。
角色设定：首先，赋予AI一个“严谨”、“一丝不苟”的角色，如“你是一个精确的知识库助手”。核心指令：明确指出回答必须“严格基于”、“完全根据”提供的上下文。负面约束：使用强烈的否定词汇来建立红线。“禁止”、“绝不允许”、“不要猜测”。降级策略 (Fallback)：清晰地定义当上下文信息不足时的标准回答。例如：“如果无法回答，请直接说‘我不知道’”。这是防止AI在知识不足时强行回答的关键。溯源要求：强制要求AI在回答后附上信息来源（通常在元数据中）。Few-Shots
在向LLM提出正式任务之前，先在Prompt中给它提供几个（通常是1到5个）完整的输入/输出示例，注意不要太多，太多的上下文将会影响问答时间。
作用：LLM非常擅长模式匹配和模仿。示例能让它快速、准确地理解你期望的输出格式、风格、甚至是复杂的任务逻辑，这通常比冗长的文字描述更有效。对于一些难以用语言清晰描述的复杂任务（如代码转换、特定风格的文本生成），提供示例是最佳的沟通方式。示例可以消除指令中的任何潜在歧义。注意事项：选择具有代表性的、高质量的示例，如果可能，包含一些边界情况的例子。不要期望一次就能写出完美的Prompt。Prompt工程是一个不断试错、评估和优化的过程，以上的方法都是可以配合使用的，现在也有非常多其他的撰写提示词的方法，在调试提示词时，推荐使用字节的promptpilot这个平台，可以一边调试一边修改，很高效的产品。
总结知识库应用非常广泛，往往是企业融入AI的第一个项目，有了知识库作为基础，能够不断的在这个基础之上设计各种不同的agent，实现从chat到act的转变。希望这篇文章对大家在知识库项目上的理解有所助力。
来源：人人都是产品经理