知识服务 POC
项目一：AI 导购 / 知识服务 POC
业务场景选茶推荐、产品问答与售后分流
核心问题SKU 与产品资料分散，人工客服需要反复查找；客户需要的是有依据的推荐，而不只是 FAQ。
方案一句话将商品资料整理为可检索、可解释、可追溯的知识服务，并以规则约束推荐范围。
我的工作需求场景拆解、知识边界设计、交互 Demo 与 POC 验证。
Presales Solution Workflow
从需求到落地的售前方案能力
从客户需求澄清，到技术方案设计、POC 验证和价值评估，展示我如何将 AI 能力转化为可落地的业务方案。
01
核心 POC / 项目实践
两个独立 POC，分别验证知识服务与多步骤 Agent 在真实业务场景里的可用性。
体验项目一：AI 导购
多步骤 Agent POC
项目二：招投标 Agent
业务场景招标文件解析、企业资料检索、资格与风险审查
核心问题长文件中资格、评分与风险信息分散，售前需要先判断能不能投、缺什么、风险在哪里。
方案一句话将解析、检索、资格匹配、风险分析与 Evidence 组织成可复核工作流。
我的工作需求与验收口径定义、工作流设计、工具路径与 POC 测试。
02
售前方案方法论
不是上来就列技术栈，而是先讲清楚：业务需求怎么一步步变成了技术方案。
售前方案方法论
01
需求澄清
确认客户真正想解决的问题和边界。
02
场景拆解
将大问题拆成具体任务与流程。
03
能力映射
判断何时使用 RAG、Agent、OCR 或 Web Search。
04
方案设计
形成系统架构、数据流与产品交互。
05
POC
先验证关键链路是否可行。
06
验证
通过测试用例与失败场景检查结果。
07
优化
针对检索、流程与降级路径持续调整。
08
交付 / 复盘
沉淀材料、边界与下一步判断。
技术选型决策树
从问题特征开始，而不是先选模型
客户问题是否依赖私有知识？
否 → 通用 LLM / Web Search
是 → 知识是否频繁变化？
是 → RAG
否 → 是否需要改变固定行为模式？
是 → Fine-tuning
多步骤任务 → Agent
扫描文件 → OCR
实时外部数据 → Web Search
04
技术选型与方案架构
选什么，更要说清为什么这样选；数据流和证据链共同保证方案可以解释、复核和迭代。
RAG vs 微调
产品知识与招标信息会更新，当前项目优先以 RAG 获取可更新、可追溯的知识，而不通过微调固化事实。
| 维度 | RAG | 微调 |
|---|---|---|
| 知识更新 | 更新资料后可重建索引 | 需重新训练 |
| 数据量要求 | 适合当前资料规模 | 通常需要更稳定的训练数据 |
| 成本 | 以检索与调用成本为主 | 需要训练与迭代成本 |
| 适用 | 动态私有知识 | 固定行为或风格模式 |
关键词 vs 向量 vs Hybrid RAG
招投标文件既有硬性专业关键词，也有自然语言条款；当前项目用 Hybrid RAG 兼顾精确命中与语义召回。
| 维度 | 关键词 | 向量 | Hybrid RAG |
|---|---|---|---|
| 精确关键词 | 强 | 一般 | 强 |
| 语义召回 | 有限 | 强 | 强 |
| 中文长文档 | 依赖词面 | 依赖语义相近 | 同时覆盖 |
| 稳定性 | 规则清晰 | 需关注相似但无关 | 以融合结果降低单一路径偏差 |
纯生成 vs RAG + Evidence
售前与招投标场景不能只给答案，还需要说明答案依据；因此关键结论尽可能绑定检索来源与执行轨迹。
| 维度 | 纯大模型生成 | RAG + Evidence |
|---|---|---|
| 回答依据 | 难以向用户解释 | 可回看来源 |
| 可追溯性 | 有限 | 保留 Evidence / Trace |
| 幻觉风险 | 需要额外控制 | 以检索资料约束回答 |
| 客户沟通 | 更像结论 | 可展示判断过程 |
System Architecture
项目一：AI 导购 · 系统架构
不是普通聊天框，而是基于真实产品知识库的可解释知识服务 POC。
01 用户交互层
用户提问 / 产品咨询 / 场景需求对话式 Web Demo商品推荐 + 产品问答 + 来源引用
02 AI 核心能力层
意图识别Query 重写RAG 检索商品信息匹配推荐边界判断DeepSeek / LLM 生成可解释回答
03 知识检索层
产品手册SKU 信息产品卖点价格 / 规格 / 包装FAQ / 业务资料
文本切分Embedding向量检索 + 关键词检索相关知识片段召回
04 输出与保障层
答案来源引用无答案兜底资料冲突处理越权请求限制日志 / 检索结果可追溯
System Architecture
项目二：招投标 Agent · 系统架构
文档解析、Hybrid RAG、Agent Tool Calling、Evidence 与外部检索共同构成可复核的判断系统。
01 输入层
招标文件 · PDF / Word / 扫描件企业资料 · 资质 / 案例 / 产品能力用户问题 · 能不能投 / 有哪些风险 / 还缺什么
02 文档处理层
文件解析OCR · 扫描件 / 图片型 PDF文本清洗Chunking结构化信息抽取 / 招标要求识别
03 知识与检索层
企业知识库
资质、案例、产品能力、历史材料
Hybrid RAG
关键词检索 + 向量检索 + RRF 融合
web_search / Tavily
外部公开信息补充与核验
04 Agent 核心层
Tender Analysis Agent
任务拆解工具选择多步分析证据收集结果校验风险判断缺失项识别评分项分析
Agent 根据当前任务自主选择 knowledge_search、web_search、OCR、企业知识库与招标文件，而不是固定流程调用。
05 输出层
可投性结论风险项缺失资料资质匹配评分分析行动建议证据引用 / 页码
Execution Flow
招投标 Agent · 单次任务执行流程
系统结构说明“由什么组成”；这条流程说明 Agent 接到一次任务后如何一步步完成判断。
STEP 01 上传资料
招标文件企业资料
STEP 02 文档预处理
文件类型识别文本解析必要时 OCR文本切分 / 结构化
STEP 03–04 Agent 理解与任务拆解
识别“我们公司能不能参与这次投标？”等用户问题，并拆解为资质要求检查、企业能力与案例匹配、评分项、风险项及缺失资料识别。
STEP 05 工具调用
当前信息是否足够？
信息不足
knowledge_search → Hybrid RAG 检索企业资料
仍然不足
web_search / Tavily → 外部公开信息核验
PDF 无法解析
OCR → 提取扫描件文本
STEP 06 Evidence 汇总
招标文件原文企业资料原文外部信息来源页码 / 引用
STEP 07–09 综合判断、输出与 Trace
LLM + Rules + Evidence 输出可投 / 谨慎投 / 不建议投，以及风险原因、缺失资料、资质差距、评分机会和下一步行动。
投标分析总览风险清单评分分析补充资料建议Agent Trace：工具、检索与结论依据
03
从业务问题到 POC
展示我如何从客户问题拆解到可验证方案。
| 业务场景 | 客户问题 | 我的判断 | POC 验证重点 |
|---|---|---|---|
| 项目一：AI 导购 |
| 不是缺一个聊天框，而是缺一个可检索、可解释、可追溯的知识服务。 | RAG 检索推荐边界来源引用多轮问答 |
| 项目二：招投标 Agent |
| 不是简单 PDF 摘要，而是一个多步骤判断与证据组织流程。 | OCRHybrid RAG企业资料检索资格判断EvidenceAgent Trace |
05
竞品与替代方案分析
把替代路径说清楚，才能说明方案价值。
以下比较用于解释不同解法的适用范围，不将人工客服、FAQ 或通用模型简单称为“竞品”。
AI 导购：从客服工具到知识服务
| 维度 | 人工客服 | 传统 FAQ / 关键词机器人 | 通用大模型 | RAG AI 导购 |
|---|---|---|---|---|
| 私有知识 | 靠人工查找 | 依赖预设问答 | 默认不具备 | 以项目资料检索 |
| 推荐能力 | 依赖人员经验 | 规则有限 | 可能无依据 | 结合需求与商品资料 |
| 知识更新 | 培训与同步 | 人工维护词条 | 需补充上下文 | 更新资料与索引 |
| 来源可追溯 | 人工说明 | 较有限 | 较有限 | 展示命中资料 |
招投标：不只是“把 PDF 丢给模型总结”
| 维度 | 人工阅读 | PDF 摘要工具 | 通用大模型上传文件 | 招投标 Agent |
|---|---|---|---|---|
| 资格项识别 | 人工核对 | 不保证结构化 | 依赖提示 | 拆分并匹配 Evidence |
| 评分规则 | 人工整理 | 可能遗漏 | 依赖提示 | 提取后进入分析 |
| 企业资料匹配 | 人工查库 | 通常不支持 | 需手动提供 | 内部资料检索 |
| 多步骤与 Trace | 人工过程 | 通常无 | 不透明 | 工具调用路径可查看 |
06
方案价值量化 / ROI
先说明价值如何产生，再讨论具体 ROI。
业务价值推演，不代表真实商业部署结果。
AI 导购
现状：人工查找产品资料并手工回答。方案：知识库检索 + AI 导购。
减少重复查询缩短资料查找路径统一回答口径支持首轮问答降低新人培训成本
招投标 Agent
现状：人工逐页浏览招标文件。方案：Agent 首轮筛查 + 人工复核。
更快定位资格条件提取评分标准发现资料缺失降低遗漏风险减少重复整理
ROI / 效率评估框架
人工时间 × 人员数量 × 任务频次
减少的人工处理时间
降低的遗漏风险
知识复用价值
实际 ROI 需结合客户实际业务量、人员成本和调用成本测算；当前页面不展示未经验证的效率或成本百分比。
07
POC 验证与价值交付
展示这些能力如何构成一个可以验证的 POC，以及结果该怎样被正确解读。
AI 导购 POC 链路
用户需求
规则 / 检索
商品匹配
带来源回答
边界提示
以项目资料、价格 Evidence、推荐规则和可选实时 RAG 组织回答；资料不足时明确回退。
招投标 Agent POC 链路
文件输入
解析 / OCR
检索 / 工具
分析
Evidence / Trace
人工复核
将解析、Hybrid RAG、企业资料、Web Search 与工具调用路径组织为可复核的首轮分析。
实测结果
57 / 57 PASS
招投标 Agent evidence regression，覆盖解析、Evidence、工具路径、降级与项目隔离等回归用例。
npm run test:tender
验证边界
已验证
生产构建招投标回归测试Evidence / TraceOCR / Web 降级
待进一步验证
大规模并发真实生产数据长期知识维护成本客户现场验收
未将个人作品集 POC 描述为正式生产部署；上述范围外需要结合真实业务环境继续验证。
08
关键决策与项目复盘
不只展示最终结果，也展示方案中真实做过的判断、失败边界与迭代方向。
为什么采用 Hybrid RAG？
关键词检索擅长精准命中，向量检索擅长语义召回；招投标文档同时存在专业关键词与自然语言条款，因此使用融合检索。
为什么区分演示与真实企业资料？
Demo 环境不需要上传敏感资料；真实资料入口模拟客户部署流程，并保持资料与演示数据隔离。
为什么增加 Evidence？
招投标属于高可信要求场景，用户不仅需要结论，也需要知道结论来自哪里。
为什么增加 Agent Trace？
让用户理解工具调用路径，同时方便调试多步骤任务与解释复杂执行过程。
09
失败案例与复盘
把问题、根因、方案与收获讲清楚。
CASE 01
项目切换后残留上一份文件的上下文
根因会话、分析结果与当前项目文件需要一起切换，单独保留会造成上下文混淆。
解决方案新建或替换项目时重新初始化当前会话、分析结果与文件状态；历史内容保存在对应项目中。
最终结果当前项目记录按项目 ID 隔离，回归测试覆盖文件、分析、对话、Evidence 与 Trace 的恢复。
我的判断 / 收获多轮 Agent 产品中，状态管理与业务上下文隔离和模型能力同样重要。
CASE 02
首次分析与后续问答混在同一入口
根因上传文件后的首轮任务和完成分析后的追问，属于不同用户任务。
解决方案保留独立的“开始分析”入口；分析完成后再开启基于当前结果的连续问答。
最终结果首次分析不依赖额外问题，后续问题复用当前项目的分析结果与 Trace。
我的判断 / 收获Agent 交互要按用户任务路径设计，而不仅是按技术调用链排列。
CASE 03
联网检索或 OCR 不能保证始终可用
根因外部 Provider、密钥和文件类型都会影响工具调用。
解决方案保留 Tool fallback、错误状态和来源标注；未配置时不伪造 OCR 文本或联网结论。
最终结果回归测试覆盖 OCR 与 Web Search 的未配置、失败和降级路径。
我的判断 / 收获Agent 的可用性还取决于工具失败时如何清晰退化。
CASE 04
单一检索路径并不总能命中业务相关资料
根因词面精确匹配与语义相似召回各有盲区。
解决方案组合 keyword retrieval、vector retrieval 与 RRF fusion，形成 Hybrid RAG。
最终结果检索路径与降级信息会进入 Evidence / Trace，而不是只输出一个无来源结论。
我的判断 / 收获检索质量需要与业务判断标准一起设计，而非只看语义相似度。