rag篇

如何评估一个rag系统的好坏

首先是检索相关性（找到的内容是否包含答案）
其次是生成质量，这又可以细分为
- 语义准确性（回答的意思是否正确）
- 词汇匹配度（专业术语是否使用得当）

如果优化rag

在性能层面，可以通过以下方式来提升效率和能力边界。
- 索引分层（对高频数据启用缓存）
- 多模态扩展（支持图像/表格检索）
在架构层面，简单的线性流程正在被更复杂的设计模式所取代
- 通过分支模式并行处理多路检索
- 或通过循环模式进行自我修正

agent 项目中的幻觉是怎么处理的

有哪些幻觉以及如何解决

工具参数幻觉
- 现象：Agent 在决定调用外部 API（如查询数据库、发送邮件）时，会凭空捏造不存在的参数名，或者把字段类型写错（比如把字符串格式写成了布尔值格式），导致后端接口直接报 400 错误。
- 解决：我们在代码中（使用 Pydantic 或 Eino 的类型控制）为所有工具定义了严格的 JSON Schema。
- 兜底：
  - 大模型生成工具调用指令后，必须先经过拦截器校验。
  - 如果发现参数幻觉，直接在工程层拦截，不真正请求 API，
  - 而是把错误结构化地扔回给大模型：“你生成的参数 X 不合规，请参考规范重试”。
  - 通过这种自愈机制，将参数幻觉率降低了 90% 以上。
工具结果误读
- 现象：
  - 当外部工具执行失败并返回错误日志时（例如 SQL 语法错误），大模型不承认失败。它会在上下文中假装工具执行成功，并顺着错误的思路继续往下推演，给用户返回一个完全虚假编造的结论。
- 做法：
  - 为了防止 Agent 在工具报错时执迷不悟、产生自我欺骗的幻觉，
  - 我们在上下文管理器里引入了 Loop Guard（死锁守护）。
- 兜底：
  - 如果检测到模型连续两次出现相同的错误调用或在上下文里打转，
  - 系统会硬编码介入，强行清空中间冗余的报错日志，并以高优先级的 System Alert 写入最终强调：
  - “当前路径已连续失败 3 次，请立刻放弃并寻找替代方案”，强行打破模型的幻觉惯性。
上下文迷失与知识混淆（Context Distraction / Lost in the Middle）：
- 现象：在长对话或多轮工具调用后，上下文积压得很长。此时模型会产生‘选择性色盲’，忽略掉放在上下文中间的核心系统约束（比如‘必须输出 JSON’、‘只能基于给定文档回答’），开始调用它自己脑子里过期的、错误的预训练知识。
- 做法：
  - 我们采用前面提到的“冷热分离滚动压缩机制”。
  - 当 Token 逼近安全线时，调用廉价小模型把过去的琐碎废话洗干净，提炼成高密度的状态矩阵（JSON）。
- 兜底：
  - 同时，为了对抗长文本‘中间遗忘’的特性，
  - 我们在组装最终 Prompt 时采用首尾双向锚定——把最核心的防幻觉指令
  - （如‘只能基于给定文档，不知道请说不知道’）不仅在开头 System Prompt 里写一遍，
  - 还在 User 最新提问的后面强行追加一遍，确保模型在最后生成时注意力绝对聚焦。
机制上引入【Critic-Actor 反思博弈】与【Ragas 自动化评测】做法：
- 对于高资产、不容错的复杂业务（如财务报表生成），我们设计了双智能体协同。Actor 模块生成完内容后，交由专职的 Critic（判官模型）进行全方位的 Checklist 扫描（审视是否包含上下文里没有提及的伪造事实）。量化监控：在 CI/CD 流程中，我们沉淀了 200 多个线上发生过的真实幻觉 Case 作为固定评测集，通过 Ragas 工具量化评估忠实度（Faithfulness）指标，只有当测试集幻觉率低于 2% 时才允许代码上线。

agent的安全控制

工具调用拦截
- 工具调用和实际执行之前，需要增加审批层、如果是读操作直接放行、如果是写操作需要二次确认，如果设计到钱之类的操作，需要增加人工审核流程
prompt注入风险
- 增加正则规则匹配常见的注入方式、或者用专门的小模型做识别
输出风险
- 做脱敏的检测和处理

向量数据库的索引类型有哪些

HNFW
- 分层的图结构，查询时不是把 1000 万个向量全部算一遍，而是从图的高层快速找到目标区域，再逐层向下搜索
- 优缺点：检索快，但是构建索引会比较慢，同时占用内存较大
- 场景：数据量百万级以下
IVF
- 将向量聚类为多个区域，先检索最有可能的区域，然后在区域内进行搜索
- 优缺点：内存占用小，检索快，但准确率差一点
- 场景：数量级在千万级以上