01 · A
问题
企业手册篇幅长、术语密集，信息分散在不同章节。只有系统找到了正确证据且用户能够检查时，流畅回答才真正有用。
全部项目08 / 09
从用户需求到原型与评估
企业产品手册 RAG 论文
一项 Design Science 论文研究，把技术手册问答转化为带来源的本地 RAG 原型，并分别设计检索与回答评估。
- 时间
- Diplom thesis
- 方向
- Enterprise RAG · Design Science · User Research
- 核心技术
- Python · Local Embeddings · Hybrid Retrieval · Reranking
三行摘要
- 问题
- 企业手册篇幅长、术语密集，信息分散在不同章节。只有系统找到了正确证据且用户能够检查时，流畅回答才真正有用。
- 我做了什么
- 把用户需求转化为系统要求，并完成架构设计。
- 结果 / 限制
- 由于论文使用保密的企业手册和研究材料，我不公开参与人数、内部文档或未发布的评估表。
01 · B
背景
我采用 Design Science 研究流程，覆盖用户需求、系统架构、本地检索生成原型、技术评估与用户反馈。
流程示意
回答、来源片段与评估应在同一视图中
我用这张流程示意图呈现带引用回答与排序来源片段并列的工作流，并将检索质量与回答质量分开考察。
为什么重要
一次漂亮演示不能证明企业知识系统有效。检索相关性、回答支持度与用户信任是不同问题，需要不同证据。
展开技术细节真正的难点 · 系统路径 · 关键取舍
真正的难点
- 01
用户语言与手册术语不总是一致。
- 02
向量相似度高不代表片段足以回答问题。
- 03
检索质量与回答质量需要分开评估。
- 04
领域 benchmark 需要专家定义问题与相关来源。
我的方案
系统路径
发现
把用户需求转化为检索、引用与本地部署要求
检索
组合本地 embedding、词法信号与 reranking
回答
基于选定片段生成，并保留来源追溯
评估
把技术检索/回答检查与访谈反馈分开
带来源的回答链路
检索与生成保持可分别检查
原型先收集并重排支持材料，再基于选定片段生成回答，同时保留来源身份。
01需求
用户问题
自然语言与手册术语可能不同
02召回层
混合检索
词法与本地 embedding 候选
03精排层
重排序
针对具体问题重新排列片段
04综合
LLM 回答
只基于选定上下文生成
05信任
引用
暴露支持章节供用户检查
关键取舍
从使用场景开始
Design Science 让原型围绕用户任务，而不是围绕某个偏好的模型。
评估两层失败
找错资料，与从正确资料中回答失败，应被分别观察。
由领域专家定义相关性
系统不能自己出题，再把这套题当作独立有效性证据。
04 · A
我的贡献
- 把用户需求转化为系统要求，并完成架构设计。
- 实现本地 embedding、混合检索、reranking 与 LLM 回答链路。
- 与领域专家构建技术问题，并结合技术检查与用户反馈开展评估。
04 · B
已实现结果
- 完成从需求、本地 RAG 原型到技术与用户评估的完整研究路径。
- 由于论文使用保密的企业手册和研究材料，我不公开参与人数、内部文档或未发布的评估表。
评估设计
找到正确片段与给出正确回答是两种不同陈述
分离两层评估才能定位失败，也避免一个总分掩盖系统究竟在哪一层出错。
01证据访问
检索评估
系统是否找到专家认定的相关材料？
02回答质量
回答评估
回答是否有支持、完整且适合问题？
03使用体验
用户反馈
工作流是否易理解且对任务有帮助？
为保护保密的论文材料，我不在此公开参与人数或详细指标。
经验与反思
01RAG 是一组围绕来源、失败类型与信任的系统决策，而不只是向量数据库。
02用户反馈可以解释体验，但不能替代技术检索证据。
我能公开的内容
企业手册、项目仓库与用户研究材料属于保密内容，因此不能公开。我可以介绍研究设计、本地 RAG 架构与评估方法；具体参与者和 benchmark 数字保持私密。
公开来源