看完本篇文章你可以了解：

1.如何从0-1构建知识库？

2.如何提升知识库召回率、准确率？常见问题如何定位解决？

3.如何做数据处理？

4.构建知识库后还可以在这个基础上做什么？

1. 项目构建流程

2. 方案评估

1. 业务痛点分析：

• 信息检索效率低：企业知识散落在多处（在线文档、本地文件、纸质资料），员工或客户查找信息耗时耗力。
• 重复性咨询成本高：客服、HR、IT支持等部门需要花费大量精力回答重复性问题。
• 知识传承困难：核心员工离职易造成知识断层，新员工上手周期长。
• 合规与准确性风险：在金融、法律、医疗等领域，确保输出信息的准确性和合规性至关重要。通用大模型的“幻觉”问题在此类场景下是不可接受的。
• 内部数据隐私：企业核心数据（如财务、战略、研发资料）大模型主流应用rag的介绍从架构到技术细节高度敏感，不能依赖知识库数据处理公开的在线大模型服务。

2. 指标拆解

1. 指标拆解法一：公式法

• 节省成本 = (AI处理的会话数) * (人工处理单次会话的平均时长) * (客服时薪)
• 为了提升“节省成本”，你可以：
  • 提升 AI处理的会话数：这又可以拆解为 总会话数 * AI应答率。
  • 降低 人工处理单次会话的平均时长：如果AI作为助手赋能人工，可以通过提供高质量信息来达到此目的。

2. 指标拆解法二：因素拆对比了6家国产智能体 ai agent 我找到了企业落地ai的方向解法

• 为了让用户自助解决问题，必须满足：
  • 用户愿意用
    1. 系统入口是否明显？ -> 触达率
  • AI能听懂用户的问题
    1. AI是否能正确理解用户意图？ -> 意图识别准确率
    2. 用户是否需要反复换说法？ -> 平均会话轮次
  • 知识库里有相关知识
    1. 用户提问后，系统是否能找到知识？ -> 知识召回率
    2. 有多少问题系统完全找不到答案？ -> 零结果率
  • AI给出的答案是优质的
    1. 答案是否准确无误，没有幻觉？ -> 答案准确性
    2. 答案是否解决了用户的问题？企业知识产权管理标准化工作方案 -> 答案采纳率
    3. 系统响应速度快不快？ -> 平均响应时长

3. 系统设计

1. 需求细化与确认

• 细化需求：现在需要深入现场，和真正使用系统的一线用户以及管理知识源的专家进行交流。细化并确认中的需求，尤其是智能问答的应用场景、对话腾讯云rag技术应用与实践pdf流程、知识库的具体内容和结构，设计出项目架构。
• 开展调研：列出调研明细，双方分别需要如何配合，原则就是根据你的目标列出你要做什么，你需要对方（客户）什么人员、怎么配合你、提供什么资料，调研方法通常是以下这些：
  • 用户访谈：
    • 对llm大模型学习圣经从0到1精通rag架构基于llm rag构建生产级企业知识库象：挑选典型用户，包括新手、专家、高频使用者和偶尔使提示词工程和rag用者。
    • 问题清单 (半结构化)：准备问题提纲，观察客户现有工作流程中的问题，根据问题挖掘痛点，发现隐性知识和求助路径，探索期望功能和交互方式。
  • 现场观察：
    • 内容：如果条件允许，直接坐在用户旁边，观察他们如何工作。这能发现很多用户在访谈中因习以为常而忽略的细节。
  • 问卷调查：
    • 优势：当用户群体庞大时，可以通过问卷快速收集量化数据。
    • 内容：可以调查最常查询的知识类型、对当前信息查找方式的满意度评分、最希望优先解决的问题等。
• 收集资料：客户腾讯云rag技术应用与实践pdf各种数据都需要提供，且需要明确资料收集的方式。
  • 企业内部数据：如历史纸质资料、各个系统的历史资料、扫描件、各种在线文档……
  • 外网公开数据：各种公开资料，通常使用爬虫的方式收集，不过如果是信创项目，爬虫可能存在风险，这也是需要提前与客户沟通的内容。
  • 付费外采数据：内部资料不足或者不够优质，如各种公司的资料、行业报告等，就需要付费了。
• 数据整理：与客户的业务专家共同设计知识结构，定好全部数据的储存框架、策略，否则后续的维护和查重工作也非常头大。
• 对接方式：不同的数运用vllm s结合你的后端技术对相关数据做一些分析与处理构建业务场景知识库据对接方式是不一样的，比如客户有数据中台，那我们直接对接数据中台，客户纸质文件是需要落地转为电子文件的。

2. 需求验证

• 数据范围界定：明确知识来源，如内部Wiki、PDF/Word文档库、数据库、付费外采的行业报告等。
• POC产品选择：市面上可以选择的知识库、智能体搭建产品有 fastgpt、n8n、coze、dify、AppBuilder等等，后续会专门出一篇关于产品评测选择的文章。
• 技术路径：
  • • 是否需要知识库 (RArag技术实际应用G)：对于需要依据特定、私有、高时效性知识进行回答的场景，RAG是必选项，它可以有效解决LLM的知识局限和幻觉问题。
    • 是否需要微调 (Fine-tuning)：当需要模型模仿特定风格（如客服语气）或掌握特定领域的复杂指令时，可以考虑微调。但微调成本高，对数据质量要求苛刻，需谨慎评估。
  • 判断是否需要微调：微调的成本是非常高的，判断方式主要基于以下几点
    • 数据模块
      • 数据偏移：微调提供的数据和模型原始数据差异过大，模型在新任务上表现反而不会好
      • 数据质量差：微调需标注准确、覆盖全面，噪声数据会大大影响模型性能
    • 训练模块
      • 过拟合：训练方式不当或者数据量不够，泛化能力下降，过度专注单一任务
      • 数据遗忘：训练可能导致原预训练数据被遗忘，所以一定要选择合适匹配的模型进行训练
    • 成本模块
      • 人力/ai agent搭建时间成本：微调需足够高质量数据（如数千条标注数据），项目预算是否可以覆盖
• 验证目的：先收集测试数据，通过测试数据就可以知道，这个过程能够更深层的梳理出本次项目可能存rag和提示词工程在的风险
• 技术预研：要判断客户目前积累的数据和我们沉淀的算法，是否可以达到业务需求，任何项目都是尽可能采取更小成本的方式落地，初期产品大多会以最简单的方式，比如Prompt工程初步做验证，整体评估下来如果数据不满足，产品需要协助算法在客户内部获rag全栈技术从基础到精通打造高精准ai应用取数据
• 评估算力资源：需要评估项目所需的GPU型号和显存，取决于模型的参数量以及采用的操作方式，如下表是常见的部署方式和所需资源，通常由产品经理、算法工程师和研发工程共同完成

3. 需求详细定义

• 功能需求: 比如AI Agent的对话能力、意图识别、多轮对话、上下文理解、知识推荐、任务执行（如开单、查询）
• 集成需求：与客户内部系统，如CRM、ERP、单点登录系rag技术实际应用统、用户权限信息等
• 知识库需求: 知识的来源、具体格式、采集、清洗、结构化、标签化、版本控制、权限管理、更新机制、检索效率、召回率、准确率等
• 非功能需求: 性能（并发数、响应时间）、可用性（易用性、UI/UX）、安全性（数据加密、访问控制、合规性）、可扩展性、可维护性
• AI模型需求: 模型适配（除了已经适配的模型，客户可能采了别人的模型需要做适配）、领域微调需求（通常不做微调）、模型评估指标、持续学习能力（badcase优化、抓取实时2024 年企业 ai 大模型应用落地白皮书数据、数据集持续优化）
• 产出: 详细需求规格说明书、用例、需求调研报告，这部分的内容是非常宝贵的，在深入客户现场调研清楚需求后，后续可以抽象需求形成产品的标准化功能，推广至更多客户

4. 系统架构与功能设计

• 架构设计: 知识库系统架构、集成接口设计。
• AI模型设计: 领域词典、意图分类本地知识库数据预处理、实体抽取、对话管理策略、知识表示（如有知识简述你对ai行业的理解和想法 包括使用的ai工具、了解的ai新技术、可能应用的场景等图谱）。
• 知识库设计: 知识分类体系、元数据标准、知识图谱Schema设ai agent搭建工具计（如果有）。
• UI/UX设计: Agent交互界面、知识库管理后台界面。
• 产出: 系统架构设计文档、数据库设计文档、接口设计文档、UI/UX设计稿。

5. 数据埋点规划

• 需要采集的数据：
  • 后端日志：每次请求的用户ID、问题、时间戳、召回的知识源、生成的答案、响应时长等对比了6家国产智能体 ai agent 我找到了企业落地ai的方向。
  • 前端埋点：用户点击了哪个入口、会话开始/结束时间、是否点击“赞/踩”、是否复制了答案、是否在得到答案后很快关闭了窗口。
  • 用户主动反馈：在每个答案后提供明确的反馈按钮（如 /，或“已解决”/“未解决”）。
  • 离线评估数据：建立人工评测流程，定期抽样问题进行“准确性”、“相关性”等维度的打分。

4. 知识库构建

1. 知识库构建流程

2. 知识库构建架构

3. 数据收集:

• 对于在线系统 ：编写脚本，利用API定期拉取更新的文档。不过同时需要注意处理权限问题。
• 对于文件服务器：编写脚本（如Python的os和shutil库），定期扫描指定文件夹，同步新增或修改的文件。
• 对于数据库：编写SQL查询，从业务数据库中导出结构化的知识（如FAQ对）。
• 手动上传：为无法自动采集的零散文件（如邮ai知识库构建流程件附件、本地Word），提供一个统一的知rag的提示词工程识管理后台上传入口（前面推荐的平台都会有这个入口）。
• 注意事项：
  • 忽视数据源的动企业知识产权管理方案态性：未建立自动化同步机制，导致知识库信息严重滞后于源头。
  • 低估非文本内容的处理难度：对于扫描件、图片、复杂表格，若没有合适的OCR或版面分析方案，会造成大量关键信息丢失。

4. 规划知识库结构

• 按业务领域：如“产品知识库”、“HR政策知rag简述你对ai行业的理解和想法 包括使用的ai工具、了解的ai新技术、可能应用的场景等全栈技术从基础到精通打造高精准ai应用识库”、“销售话术知识库”。
• 按数据敏感度：如“公开信息知识库”简述你对ai行业的理解和想法 包括使用的ai工具、了解的ai新技术、可能应用的场景等、“内部核心知识库”。
• 按部门：如“市场部资料库”、“研发部文档库请简述你对ai行业的理解和想法 包括使用的ai工具、了解的ai新技术、可能应用的场景等”。

5. 格式转换及初步清洗:

• 清理格式：在上传前，手动打coze知识库的数据预处理功能不支持以下哪项操作开Word/PDai agent搭建教程F文档，删除不必要的页眉页脚、封面、目录。修正文档中的错别字和格式错误。
• 优化结构：对于长文档，尽量使用清晰的标题层级（如Word的标题1, 标题2）。这能帮助平台的自动分段功能更好地理解文档结准确率 accuracy 、召回率构。
• 转换格式：如果平台对某些格式（如扫描版PDF）支持不佳，需要在平台之外先用OCR工具将其转换为纯文本或格式化的Word文档。
• 图文处理：有些复杂文档不光格式复杂，甚至还有图文同时存在的情况，图知识库数据处理片的处理跟文字相比会麻烦点，可能涉及的方法有以下三种：
  • 策略一：OCR提取图中文字
    • 适用场景：软件截图、包含文字的流程图、扫描的文档。
    • 工具：
      • 开源：PaddleOCR（对中文场景优化好）、Tesseract。
    • 执行：对提取出的每张图片，调用OCR服务，获取图片中的所有文字。
  • 策略二：图像描述生成
    • 适用场景：产品照片、场景图、无文字的示意图。
    • 工具：使用多模态大模型API
    • 执行：将图片输入到这些模型中，让模型生成一段描述性文字。例如，对于一张产品接口图，它可能会生成：“这是一张电简述你对ai行业的理解和想法 包rag和提示词工程括使用的ai工具、了解的ai新技术、可能应用的场景等子设备的背部面板图，包含一个HDMI接口、两个USB-A接口和一个电源接口。”
  • 策略三：上下文关联描述 (实际工作中最有效)
    • 逻辑：一张图片的意思往往取决于它周围的文本，尤其是复杂的图片，大模型根本无法描述清楚里面的内容（如逻辑图表、生产线、设备图等）
    • 执行：
      • • 利用之前记录的图片坐标(bbox)。
        • 在同一页的文本中，找到紧邻图片上方和下方的文本段落（通常是图题或对图片的解释）。
        • 将这些上下rag技术的应用场景文文本与OCR或Image Captioning生成的结果组合起来，形成对该图片最全面、最准确的描述。
        • 示例组合描述：

      • [上下文-上文]: “请按企业规模化落地ai:时代已来 前路仍艰照下图所示连接数据线。” [图片-Caption]: “一张展示设备接口的图片，包含HDMI和USB接口。” [图片-OCR]: “1. HDMI Out; 2. USB 3.0” [上下文-下文]: “图5-1: 设备接口示意图。确保所有连接牢固。” 最终生成的图片描述文本: “关于’如何连接数据线’的说明。图片内容为’设备接口示意图’，展示了HDMI和USB接口。具体接口为1. HDMI Out和2. USB 3.0。操作时需确保连接牢固。”

6. 数据去重

• 哈希检测：通过计算文本的哈希值（如MD5, SHA256），将文本映射为唯一的、定长的指纹，从而实现快速、精准的内容比对。
• 注意事项/关键陷阱：
  • 去重粒度选择不当：在文档级别去重可能过于粗糙，忽略了文档内部的部分重复。而在过细的文本块上做精确去重，意义又不大。通常在“段落”或“逻辑章节”级别执行效果较好。
  • 仅依赖精确去重：认为此步完成后就万事大吉，忽略了大量“同义不同文”的语义重复，这是更重要也更难处理的问题。

7. 精确切分

• 固定长度切分：最基础，但容易割裂语义。通常配合重叠（Overlap）来缓解（也就是每一个片段的开头和结尾跟上下切片有重叠）。
• 递归/分隔符切分：更智能，优先寻找自然的语义边界（如段落、句子）进行切分，是目前的主流方法。
• 语义切分：基于Embedding向量的相似度来判断语义连贯性，效果更佳但计算成本更高。
• 元数据附加：为每个chunk打上丰富的“标签”信息（来源、标题、日期、类别）。
• 注意事项：
  • “One-Size-Fits-All”的切分策略：对不同类型（如代码、财报、对话记录）的文档使用相同的切分参数，效果一般都不行。
  • Chunk尺寸的极端化：切分太小，导致上下文信息不足，LLM难以理解dify搭建agent；切分太大，导致包含过多无关噪声，降低了检索的信噪比。
  • 索引方式：通常是平台默认的向量索引，但FastGPT等平台还支持全文索引，可以开启以增强关键词匹配能力。

8. 文本补全/内容增强

• 假设性问题生成：利用LLM为知识“答案”反向生成多个可能的“问题”，极大地扩展了召回的入口。
• 内容摘要与关键词提取：利用LLM生成精炼的摘要作为原文的补充或元数据，增强语义表示。
• 注意事项：
  • LLM生成内容的质量失控：未对LLM的生成进行有效约束（通过Prompt Engineering），可能导ai agent搭建教程致生成的rag技术实际应用问题与原文偏离，引入噪声。
  • 成本与收益失衡：对知识库中的所有内容都进行LLM增强，成本极高。应考虑优先对高价值、查询频企业知识产权管理标准化工作方案率高的知识进行增强。

9. 索引入库

• 向量数据库选型：根据数据规模、并发需求、运维能力和成本，选择合适的向量数据库（如Milvus, Qdrant, Pinecone等）。
• 索引构建：在数据库中选择并配置合适的索引算法（如HNSW, IVF-PQ），在检索速度和准确率之间取得平衡。
• 批量写入：采用批量方式将数据写入数据库，以获得最佳的写入性能。
• 注意事项/关键陷阱：
  • 索引配置与应用场景不匹配：例如，对需要100%精确召回的场景使用了牺牲精度的近似索引。
  • 元数据索引缺失：未对附加的元数据字段（如日期、类别）创建索引，导致基于这些条件的过滤查询速度极慢，无法在生产环境中使用。
  • 忽视可扩展性：初期选择了无法水ai行业:人力资源中的ai业务案例平扩展的轻量级方案，当数据量和用户量增长时，系统性能迅速成为瓶颈。

10. 知识库项目常见问题

• 在企业环境中，不同部门、不同级别的员工能看到的知识是不同的。数据安全和权限隔离是B端产品的红线。 比如普通员工看到了公司财务机密；销售A组看到了销售ai agent搭建平台B组的客户资料。产品设计之初就要深度集成企业的权限体系（如LDAP/AD域）。在知识入库时就要打上权限标签，在检索和生成时进行严格的权限过滤，确保用户只能看到其权限范围内的信息。

5. 评测

1. 检索召回率

1. 构建测试集

• 操作：与业务专家合作，手动创建ai落地:让人工智能为你所用 pdf一份高质量的测试集rag 提示词工程（建议至少100-200个问题）。最关键的是，对ai落地:让人工智能为你所用 pdf于每个问题，需要人工标注出它在知识库中对应的正确答案源（一个或多个文档/知识片段ID）。
• 示例：
  • 问题：”公司的差旅报销标准是什么？”
  • 标注的正确知识源ID：[‘doc_hr_policy_v3.pdf_chunk_15’, ‘doc_hr_policy_v3.pdf_chunk_16’]

2. 离线批量评测

• 操作：编写一个评测脚本，遍历测试集中的所有问题。对于每个问题，只执行**检索（Retrieve）**步骤，而不进行生成（Generate）。记录下系统实际召回的知识片段ID列表。
• 计算召回率：
  • • 召回率 (Recall) = (召回的正确知识源数量) / (标注的全部正确知识源数量)
    • 对整个测试集的所有问题计算平均召回率。
  示例：对于上述问题，如果系统只召回了[‘doc_hr_policy_v3.pdf_chunk_15’]，那么召回率就是 1 / 2 = 50%。

3. 失败案例分析

• 操作：找出所有召回率低（<100%）的问题，进行人工分析，归类失败原因。这是优化的关键输入。
  • 召回内容不相关：是切分问题导致关键信息丢失？还是Embedding模型理解不了问题？
  • 部分召回：为什么另一个相关的片段没有被召回？是它们在向量空间中距离太远了吗？
  • 召回内容相关但是排序不对

4. 优化方案

1. 优化知识切分

• 问题表现：一个完整的答案被切分到两个不相邻的chunks里，导致只能召回其中一个。
• 优化方案：
  • 调整Chunk Srag检索生成技术应用ize和Overlap：增加chunk_overlap，让上下文信息在相邻chunks之间有更多重叠。适当增大chunk_size，但要注意不要引入太多噪声。
  • 调整切分方法：从固定长度切分切换到语义切分或按标题结构切分，确保语义单元的完整性。

2. Query重写

• 问题表现：用户的提问方式与知识原文的措辞差异太大，导致语义匹配失败。
• 优化方案：
  • 同义词扩展：
    1. 1. 方法：识别出Query中的关键词，并用同义词词典将其扩展。

    1. “笔记本电脑没声音怎么办？” -> “笔记本电脑/手提电脑/膝上电脑 没声音/静音/无声现有数据库及应用领域、数据库研究 怎么办/如何解决？”

  • 子问题分解：
    1. 1. 方法：对于复杂问题，让LLM将其分解为多个更简单的子问题，然后对每个子问题分别进行检索。

    • 示例：“对比一下产品A和B在性能和价格上的差异？” ->
      • 子问题1：“产品A的性能和价格是多少？”
      • 子问题2：“产品B的性能和价格是多少？”

  • 历史对话融合：
    1. 1. 方法：在多轮对话中，用户的后续问题往往省略了上下文。需要将当前问题与历史对话内容结合，生成一个完整的、无歧义的新问题。

    • 示例：
      • 用户1: “介绍一下iPhone 15 Pro。”
      • AI: (回答…)
      • 用户2: “那它的摄像头怎么样？” -> 重写后 -> “iPhone 15 Pro的摄像头怎么样？”

  • LLM生成式重写：
    1. 方法：这是一种ai落地:让人工智能为你所用 pdf非常巧妙的技术。让LLM根据用户的原始问题，先生成一个它想象中的“完美答案”（一个假设性文档）。然后，不用这个生成的答案，而是将这个假设性文档进行向量化，用它的向量去知识库里搜索最相似的真实文档。
    2. 原理：LLM生成的假设性文档，在语义上通常比简短的用户问题更丰富、更接近知识库中详细的文档片段，因此它的向量能更精准地“定位”到真正的答案。
    3. 缺点：成本高、时间长

3. 更换或微调Embedding模型

• 优化方案：
  • 更换更强的模型：查阅MTEB排行榜，选择一个在你的语言和领域上表现更好的预训练模型。
  • 微调 (Fine-tuning)2024 年企业 ai 大模型应用落地白皮书：如果预算和数据充足，可以基于你自己的数据（特别是badcase）对Embedding模型进行微调，让它更懂行业术语。

4. 采用混合检索（多路召回）

• 问ai agent搭建题表现：纯向量检索不擅长匹配特定的关键词、ID号、产品型号等，可以采用多路召回的方式，增加召回内容，召回后再确定最终顺序生成内容。
• 优化方案：
  • 向量检索 ：强大的语义理解能力，能处理同义词、近义词和不同措辞。
  • 稀疏向量/关键词检索 精准匹配关键词，对于包含专业术语、产品型号、人名的查询非常有效。
  • 图谱检索：如果你知识库数据处理的知识库构建了知识图谱，可以直接查询实体及其关系。
  • 结构化数据查询 ：直接查询数据库中的表格数据。

2. 答案相关性

1. 归一化折损累计增益

• 相关性： 检索出的文档与问题的相关程度（可以由人工标注，如：非常相关=3，相关=2，不相关=1）。dify知识库数据处理
• 位置： 越靠前的结果权重越高。
• 注意事项： 需要人工标注相关性等级，成本较高，但效果最准。

2. 对比分析 (A/BTest)

1. 将经过Re-ranker排序后的上下文，和未经排序的上下文，分别喂给同一个LLM生成答案。然后由人工判断，哪一组生成的答案质量更高。这是一种非常直观的端到端评测方法，能直接体现Re-ranker带来的价值。

3. 问答准确率

1. 端到端（End-to-End）评测

• 操作：同样使用“黄金测试集”，但这次运行完整的“检索+生成”流程，获取最终的AI回答。
• 人工评估 (Human Evaluation)：这是目前最可靠的准确性评估方式。邀请评估员（最好是业务专家）对每个回答，从以下几个维度进行打分（例如1-5分制）：
  • 忠实度 (Faithfulness)：答案是否完全基于提供的上下文？有没有捏造信息（幻觉）？
  • 答案准确性 (Answer Correctness)：答案本身的事实是否正确？
  • 完整性 (Completeness)：答案是否全面地回答了用户的问题？
  • 简洁性 (Conciseness)：答案是否简洁明了，没有多余的废话？

2. 自动化评估

• 操作：对于大规模测试，可以借助自动化评估框架，如 RAGAS。RAGAS可以计算出一些量化指标，作为人工评估的补充。
• RAGAS核心指标：
  • Faithfulness：通过LLM判断答案是否忠于上下文。
  • Answer Relevancy：答案与问题的rag全栈技术从基础到精通打造高精准ai应用相关性。
  • Context Precision：检索到的上下文的相关性。
  • Answer Correctness：答案与ai知识库构建标准答案（ground truth）的语义相似度。

3. 优化方法

1. 优化Prompt (最直接有效)

• 问题表现：AI回答过于自由，添加了知识库之外的信息，或者没有遵循指定的格式。
• 优化方案：
  • 加强上下文控制：在Prompt中用更强硬的措辞（如“禁止”、“绝不允许”）来约束LLM，强制它只使用提供的上下文。
  • 明确降级策略：清晰地告诉LLM，当知识不足时应该如何回应（例如，回复“我不知道”）。
  • 使用如何搭建ai agentFew-Shot示例：提供一两个高质量的“问题-上下文-完美回答”的示例，让LLM模仿。

2. 调整检索参数 (Top-K & Score Threshold)

• 问题表现：召回了太多不相关的chunks，干扰了LLM的判断rag的提示词工程，导致答案出现偏差。
• 优化方案：
  • 调整Top-K：减小K值（例如从5减到3），只将最相关的几个知识片段提供给LLM，减少噪声。
  • 设置相似度阈值：过滤掉那些虽然在Top-K内，但本身相关性得分就不高的chunks。

3. 更换或优化LLM

• 问题表现：即使上下文很清晰，LLM仍然无法正确理解或进行总结，出现事实性错误。
• 优化方案：
  • 更换更强的LLM：不同的LLM在遵循指令和逻辑推理能力上有巨大差异。通常，更强大的模型（如GPT-4, Claude 3 Opus）能更好地理解和总结上下文，从而提高准确性。
  • 微调 (Fine-tuning)：对于需要遵循特定、复杂格式或逻辑的场景，可以考虑对生成模型进行微调。但这是最后的手段，成本较高。

6. 进阶建设

1. 落地还缺失了什么？

2. 场景扩展

• 智能客服 / 企业内问答机器人：客户/员工的大量重复性问题，耗费人力，响应不及时；
• 领域专家助理：销售、法务、研发等专业人员，需要快速从海量资料中找到精准信息来支持工作ai方案库-传递最新ai应用落地解决方案；
• 报agent智能体搭建告/文案自动生成：撰写周报、专业性报告、会议纪要、营销文案等格式化文档，费时费力；
• 竞品情报智能分析：市场信息庞杂，人工分析竞品动态和用户反馈效率低、不全面；
• 合同/标书风险审查：人工审查上百页的合同或标书，容易遗漏关键风险点；
• 复杂工单/故障归因分析：复杂ai行业:人力资源中的ai业务案例的系统故障，需要资深工程师查阅大量日志和文档才能定位根因；

1. 意图识别

方法一：基于关键词与规则

• 如何操作：
  • 预先定义一套关键词或正则表达式规则。
  • 将每个规则与一个特定的意图（或工具）绑定。
  • 当用户输入时，用这些规则去匹配。匹配成功，则触发对应的意图。

方法二：传统NLU分类模型

• 优点：
  • 具备一定的泛化能力：能理解训练数据中未出现过的相似说法。
  • 相对成熟：有很多开rag全栈技术从基础到精通打造高精准ai应用源工具（如Rasa NLU, spaCy）可以使用。
• 缺点：
  • 需要大量的标注数据：这是最大的瓶颈，数据准备工作非常耗时。
  • “冷启动”困难：对于新的意图，必须重新收集数据和训练模型，迭代速度慢。
  • 无法处理未知意图：dify搭建agent只能在预定义的意图类别中进行选择。

方法三：基于LLM的零/少样本分类

2. 工具实现与封装

• 如果你的项目工具集相对稳定，对安全性和稳定性要求极高，优先选择Function Calling。
• 如果你的项目需要频繁地增删工具，或者你想在自己的小模型上快速实现工具调用能力，或者你的目标是部署在端侧设备上，MCP是一个非常值得考虑的、更轻量灵活的方案。

1. Function call

• 精准、可企业知识产权管理方案控、安全： 因为函数和参数都是你预先严格定义的，模型只能在你的“白名单”里做选择，不会胡乱调用。
• 复杂参数支持： 能处理复杂的、结构化的参数，如嵌套的JSON对象。
• 主流支持： OpenAI、Google Gemai的本质一种获取知识、使用知识达到目标的通用能力ini等主流coze知识库的数据预处理功能不支持以下哪项操作模型API都原生支持，使用方便。
• 不够灵活： 每次新增或修改工具，都需要重新定义Schema并修改代码，不够灵活。
• 依赖模型能力： 强依赖大模型自身的工具调用意图识别能力。

2. MCP

• 极其灵活： 增删改查工具，只需要修改“说明文档”文本即可，无需修改代码和复杂的Schema。
• 轻量高效： 对于小模型（如端侧模型）非常友好，因为其实现方式更简单，开销更小。
• 符合直觉： 用自然语言描述工具，更符合人的思维习惯。
• 安全性、可控性稍弱： 因为是弱结构化的，理论上模型输出的格式可能会有偏差（虽然MCP通过校准技术很大程度上解决了这个问题）。
• 复杂参数处理能力： 对于深层嵌套的复杂参数，可能不如JSON Schema那样明确和稳定。
• 生态和标准化： 目前主要是MiniCPM系列模型在主推，生态和标准化程度不如Function Calling。

3. 提示词撰写

1. 提示词的基本框架-RTF

• R – Role (角色)：为LLM设定一个具体、专业的身份。这个身份就像给演员一个剧本，让他能立刻进入状态，知道该用什么样的知识、语气ai行业:人力资源中的ai业务案例和视角来回应。
• T – Task (任务)：清晰、无歧义地描述LLM需要完成的具体工作。这是Prompt的核心和骨架。
• F – Format (格式)：明确规定LLM输出结果的结构、样式和组织方式。

2. 思维链法（CoT）

• 提升准确性：在算术、常识推理和符号推理等任务上，CoT能将LLM的准确率提升数倍。
• 增强可解释性：通过阅读LLM的“思考过程”，我们可以理解它是如何得出结论的，这对于调试和信任AI的回答至关重要。如果过程错了，我们能清晰地知道错在哪里。

3. 上下文控制法

• 作用
  • 抑制幻觉 (Hallucination)：这是RAG系统的头号天敌。通过严格的上下文控制，可以最大程度地防止LLM捏造事实。
  • 保证事实一致性：确保AI的回答与你的私有知识库内容保持一致，这在企业、法律、医疗等严肃场景下是绝对必要的。
  • 建立信任：当用户知道AI的每一个回答都有据可查时，他们会更愿意信任和使用这个系统。
• 如何操作 – 构建一个“规则围栏”:
  • 角色设定：首先，赋予AI一个“严谨”、“一丝不苟”的角色，如“你是一个精确的知识库助手”。
  • 核心指令：明确指出回答必须“严格基于”、“完全根据”提供的上下文。
  • 负面约束：使以下哪个不属于人工智能的核心层 模式识别 ai算法 硬件系统 数据用强烈的否定词汇来建立红线。“禁止”、“绝不允许”、“不要猜测”。
  • 降级策略 (Fallback)：清晰地定义当上下文信息不足时的标准回答。例如：“如果无法回答，请直接说‘我不知道’”。这是防止AI在知识不足时强行回答提示词工程和rag的区别的关键。
  • 溯源要求：强制要求AI在回答后附上信息来源（通常在元数据中）。

4. Few-Shots

• 作用：
  • 精准模仿：LLM非常擅长模式匹配和模仿。示例能让它快速、准确地理解你期望的输出格式、风格、甚至是复杂的任务逻辑，这通常比冗长的文字描述更有效。
  • 解决复杂任务：对于一些难以用语言清晰描述的复杂任务（如代码转换、ai知识库构建流程特定风格的文本生成），提供示例是最佳的沟通方式。
  • 降低模糊性：示例可以消除指令中的任企业知识产权管理标准化工作方案何潜在歧义。
• 注意事项：
  • 精心设计：选择具有代表性的、高质量的示例，如果可能，包含一些边界情况的例子。

总结