AI 知识助手（RAG）参考架构

应用参考。这是一份说明性架构与范围检查清单，并非经过验证的客户项目或经过测量的部署。技术、集成范围和交付内容将根据实际需求说明确定。

场景与约束

某企业希望基于自身的产品文档、政策或支持历史实现 AI 问答。真正决定架构的要求包括：答案必须引用来源；系统必须在不知道时明确表示不知道，而不是编造答案；每次对话的成本必须可控；并且在任何提示词或模型变更前后，质量都必须可衡量。

层级	技术	负责内容
数据摄取	Python 工作进程	文档解析、分块、嵌入和元数据提取。以流水线方式运行，因此重新建立索引是例行操作，而不是重建系统。
向量存储	PostgreSQL + pgvector	将分块嵌入与关系型元数据存储在一起。在这一规模下，使用一个数据库而非独立的向量服务，可简化权限和备份管理。
检索	Go 服务	混合搜索：向量相似度加关键词匹配，然后重新排序。关键词召回能够捕获嵌入通常会遗漏的精确部件编号和代码。
回答	调用模型 API 的 Go 服务	将检索到的上下文组装到提示词中，强制执行引用，流式返回，并设置每次请求的 token 预算。
防护措施	应用层	范围检查、检索置信度较低时拒答、个人身份信息过滤，以及升级到人工队列。
管理后台	Vue 管理后台	文档管理、重新建立索引的触发器、对话审核、评估集和成本仪表板。

下面的表承载着其他所有部分所依赖的规则。这里设计错误，会把一个可运行的演示变成无法扩展的系统。

实体	关键字段、关系与规则
document / version	包含版本历史和生效日期的源文档，因此可以将答案追溯到生成该答案的文档修订版本。
chunk	包含嵌入向量、标题路径、token 数量以及指向文档和位置的指针的文本片段。位置决定了引用能够链接到正确位置，而不是整个文件。
access_scope	哪些角色或租户可以检索某个分块。过滤必须在检索查询内部完成，绝不能在生成之后才过滤，否则受限内容可能在检查运行前泄露到答案中。
conversation / message	记录每条消息的对话轮次历史、检索到的分块 id、所用模型、token 数量和延迟，从而可以按对话归因成本和质量。
feedback	记录每个答案的点赞、纠正和升级标记，并将其纳入评估集，而不是让它们消失在日志文件中。
eval_case	包含问题、预期来源和验收说明。每次提示词或模型变更都运行该评估，以便在发布前发现回归，而不是等客户发现。

端点	用途与并发说明
POST /api/v1/ingest	将文档加入解析、分块和嵌入队列；以 (document, version) 为单位保持幂等，因此重新提交会替换原内容，而不会产生重复项。
POST /api/v1/chat	以流式方式返回答案。对检索应用访问范围，限制上下文 token 数量，强制执行引用，并在检索置信度低于配置阈值时返回拒答。
POST /api/v1/chat/{id}/escalate	将包含完整上下文的对话交给人工队列，这是让受控系统保持诚实、而不是强迫其回答所有问题的安全阀。
POST /api/v1/eval/run	使用当前配置运行评估集，并按案例报告通过率和引用准确率。
GET /api/v1/usage	按租户和周期统计 token 与成本，这是设置速率限制和预算提醒的基础。

采用混合检索，而不是仅使用向量检索。仅使用向量检索可能会遗漏部件编号、错误代码或文章引用等精确标识符。应在实际评估问题上比较不同的检索方式。关键词匹配可以弥补这一缺口，重新排序则负责合并两者结果。
强制执行引用，而不是提出引用要求。礼貌地要求模型引用来源并不可靠。答案会根据检索到的分块 id 进行验证；如果没有引用任何来源，就拒绝该答案。这是一个值得信赖的系统与一个听起来似乎合理的系统之间的区别。
根据检索置信度设置拒答阈值。自信但错误的答案，其代价高于没有答案。当置信度低于阈值时，系统会表示不知道，并提供升级处理选项。
使用 pgvector，而不是专用向量数据库。对于单个企业常见的文档规模，一个 PostgreSQL 实例即可同时处理向量和元数据，使运维、权限和备份集中到一个系统中。只有在规模大得多时，专用存储才值得承担其复杂性。
从第一周开始建立评估集。没有评估集，每次提示词变更都只能靠猜测，回归问题也会由用户发现。它是 AI 项目中成本最低的质量控制手段，却也是最常被跳过的部分。
通过我们的后端访问模型。API 密钥不会到达客户端，速率限制、预算上限和模型切换也保留为服务端配置，而不是要求通过应用发布来变更。

以下数据是用于容量规划的假设性示例，不是经过测量的客户结果、经过验证的容量建议或 SLA。在定义工作负载、设备、数据、硬件和第三方依赖后，再设定项目特定的验收目标；在承诺生产目标前，应通过试点和负载测试进行验证。

目标	数值与假设
首 token 延迟	先定义一个假设性的首 token 预算，然后使用选定的供应商、检索流水线和评估集进行基准测试。供应商延迟不受应用控制；流式传输可以展示进度，但不能承诺响应时间。
检索	对于约数十万块左右的较低规模语料库，在使用适当 pgvector 索引的情况下，混合搜索加重新排序耗时低于 200 ms。
每次对话成本	通过上下文 token 上限和按租户设置的预算及提醒进行控制；实际数值取决于模型选择和对话长度，并在试点期间进行测量。
答案质量	以评估集上的通过率和引用准确率进行跟踪。基线应在试点期间建立，而不是提前承诺。

上述模块是起点，而不是固定套餐。我们通常会将首个版本限定为一个核心工作流加一个管理工作流，待实际使用显示出负载和边界情况的真实分布后再进行扩展。提交范围明确的需求说明，我们会根据这一架构进行匹配，并告知您目前还不需要哪些部分。