项目背景：从枯燥规则书中发现的趣味细节

本次分享由In The Pocket的数字产品工作室工程师Nina和Eleonora主讲，旨在复盘他们为一家比利时大型金融科技公司构建检索增强生成（RAG）系统的技术决策。该系统基于约270个PDF文件、6,000页的规则手册构建，其中包含大量表格。在整理这些通常被视为枯燥的金融文档时，团队发现了一个有趣的细节：支付设备列表中不仅包含手机和卡片，还列出了袖扣、手提包甚至冰箱。这一发现成为演讲的引子，展示了在严谨金融规则中存在的创意瞬间。

"There are the expected things, like phones or cards, but there are also more creative ones: cufflinks, a handbag, clothes, and even a refrigerator."

系统的主要挑战在于引用的准确性。在金融语境下，答案必须正确且每个回答都需包含指向具体规则和页码的链接。此外还需解决知识边界问题，确保通用大模型不会混入外部支付系统的费用或运作方式等未定义知识。系统最终呈现为一个聊天机器人，用户提问后，若答案涉及表格会直接展示原表，并在下方列出来源章节以便查阅。

离线索引：PDF碎片化与结构化元数据构建

Nina详细介绍了系统的左侧部分——离线索引流程。该过程将PDF文件转换为片段并存储于向量数据库中。第一步是文本提取与碎片化。系统从每页提取文本，按段落分组并合并至约2000字符的片段（snippet），同时确保不将表格跨碎片切断。通过正则表达式识别如“Section 3”或“4.2.1”的标题，为每个片段生成章节路径（Section Path）。这种非重叠的分块方式使得将碎片按序排列即可还原原始章节，便于后续检索完整上下文。

第二步是元数据增强。每个片段被赋予丰富的元数据，包括指南标题、页码（用于生成用户可点击的链接）、章节路径以及碎片索引。特别地，团队使用LLM为每本手册生成摘要目录作为描述字段，使代理能识别片段来源。其余元数据涵盖业务逻辑字段，如规则书类型、适用规则及是否包含表格。目前索引已生成约4,000个片段，为后续检索奠定基础。

表格处理：从格式丢失到CSV转换的精度提升

索引过程中的第三阶段是关键的数据清洗环节——表格处理。由于规则书中大量知识蕴含在表格里，初始的简单文本提取导致格式混乱。例如，一个示例中“国内（domestic）”字段跨越多行，“跨境（cross-border）”和“退款（refunds）”也占据不同行数。若未正确解析，代理可能读取错误的行列数据，尤其在涉及佣金（commissions）等关键信息时会导致严重错误。

为解决此问题，团队将表格转换为CSV格式。这一过程本质上是对字段进行重复填充（duplication），确保每行数据都包含完整的列信息。当代理接收这些数据时，能够准确读取所需的正确行列组合。这一改进显著提升了回答的准确性。随后Eleonora将接管讲解在线服务部分的维护与检索逻辑，完成从数据准备到用户交互的全链路技术解析。

"So we convert the tables to CSV format, essentially duplicating those fields... And this really improved the accuracy of the answers significantly."

highlights: ["There are the expected things, like phones or cards, but there are also more creative ones: cufflinks, a handbag, clothes, and even a refrigerator.", "So we convert the tables to CSV format, essentially duplicating those fields... And this really improved the accuracy of the answers significantly."]

混合检索策略与递归工具链

在从4000个片段中精准定位10个关键信息的过程中，单一检索方式存在明显局限。密集嵌入（Dense Embeddings）擅长理解语义内容，但对规则代码、消息名称等精确标识符视为噪声；而BM25算法虽能精准匹配确切Token，却无法处理同义改写。为此，团队采用混合检索方案：结合密集向量前50名与BM25前50名的结果，利用互反等级融合（Reciprocal Rank Fusion, RRF）方法合并为前30名，再经内容重排序后选出Top 10传递给Agent。RRF的优势在于无需校准两种方法的评分差异。

"With BM25 we have a mirror image. Exact tokens will work, but paraphrasing won't."

在仅针对63个问题的独立搜索评估中，该混合方法将成功率从密集嵌入的92%提升至97%，且未遗漏任何有效问题。然而，固定数量的片段不足以覆盖所有复杂查询。为此，Agent配备了四种由窄到宽的工具：首先是目录搜索；若信息不足，则通过路径提取整个分区（Partition）以获取完整上下文；对于小目录可直接加载全文，大目录则返回章节列表以防过载。此外还设有“纪律指令”工具，在第六次调用前强制Agent自省是否陷入重复搜索循环。

延迟优化与流式界面重构

上述复杂的多步检索带来了显著的性能成本，每次响应的中位延迟为38秒。这并非简单的聊天回复，而是一项小型研究任务。为了缓解等待焦虑，系统依赖流式传输（Streaming）将38秒转化为流畅的工作体验。在界面设计上，初期尝试让Agent生成Pydantic模型组件（如来源卡片、可折叠列表），以实现比纯文本更丰富的AI生成界面。

"The problem is that you can't stream a partial Pydantic object. It becomes valid JSON only after the last token arrives."

然而，Pydantic对象仅在最后一个Token到达时才成为有效JSON，导致用户面临38秒的空白屏幕后内容瞬间全部出现。为解决此体验断点，团队将响应拆分为两部分：Agent逐Token流式传输Markdown文本并实时渲染样式；而来源卡片等交互组件则作为独立元素，在完整答案呈现后添加。这种设计避免了用户点击未读内容的冲动，提供了更友好的交互式卡片体验。

评估体系与使用洞察

产品的有效性通过真实来源的测试问题、两轮用户实测以及严格的AI行为准则（如不提供建议、保持中立）来验证。评估流程包括约86个端到端测试（通过Promptfoo运行），涵盖LLM对Agent的完整评估、来源引用检查及搜索阶段单独评估。团队从中总结出两条关键经验：首先，LLM评分存在背景噪声，测试结果需多次运行以确认真实性（例如5次中有12次结果变化未重复）；其次，评估系统本身可能存在缺陷（如误判真实规则文本为幻觉日期并扣分）。

"We learned two lessons from our experience that we want to share: first, LLM scores have background noise... and secondly, sometimes the problem lies in the assessment system itself."

目前，该规则助手于6月上线，初期仅面向客户内部用户开放，计划年底前扩展至外部参与者。系统通过Azure Table Storage记录日志，包括问题、工具调用、响应、反馈及最近20条对话历史。这些基础数据足以支撑当前阶段的产品迭代，未来将随产品增长调整监控维度。

项目初期使用量与用户行为分析

该项目在启动阶段共收到了约 900个问题，这些问题分布在超过 100次对话中。尽管初始参与度看似不错，但实际活跃用户仅有约 34人。在反馈机制方面，团队虽然收集了“点赞”和“点踩”数据，但数据显示大多数用户在第一个月后就停止了使用该功能。为了更深入地理解用户行为，团队还追踪了源文档点击次数和答案复制次数等指标。然而，这些量化数据仅停留在表面统计层面。

"We have received about 900 questions so far. They are distributed across over 100 conversations, and about 34 people actually use them."

AI辅助分析与红队测试的演变

团队利用AI进行数据分析，通过大语言模型（LLM）解读用户交互模式。在上线的第一个月，观察到了明显的“红队测试”（red teaming）现象：用户试图黑客攻击助手、使其偏离主题或提出奇怪的问题。然而，到了第三个月，情况发生了显著变化：超过90%的提问变得真实且切中要害。此外，用户开始将AI用于现实世界的工作场景，例如插入客户邮件请求回复建议，或粘贴协议中的真实消息和表格来验证自己起草的答案。由于直接的点赞反馈较少，团队转而通过分析后续问题的语境来判断交互质量。

基于语境的互动评估方法

为了弥补显性反馈的不足，团队开发了一套隐式情感分析逻辑。如果用户说“谢谢”或转向新话题，系统将其计为正面交互；而如果用户重复询问相同内容，则大概率被判定为负面交互。分析结果显示，大多数对话最终都是成功的。这一发现强调了从单一查询转向智能体搜索（agent search）的重要性，因为这种转变显著提升了评估分数。同时，从用户体验角度来看，数据的流式传输（streaming）是使工具变得便捷和实用的关键因素。

文档处理与早期测试的核心结论

在总结项目经验时，团队强调了保持文档结构完整性的重要性。对于LLM而言，章节划分不仅有助于获取答案，也是智能体捕获知识的关键；而表格则需要单独的处理方法。在用户体验设计上，团队坚持只在界面需要时才添加结构化组件。最后，项目成功的关键在于早期让真实用户参与测试，并利用这些访谈创建评估提示词（evaluation prompts），从而帮助团队判断所谓的改进是否真正有效。

"We also saw that tables require a separate approach and special handling. ... And finally, we think it's important that we tested with real users early on..."

结论

该项目验证了混合检索与结构化表格处理在金融规则问答中的有效性，将搜索成功率从92%提升至97%，且未遗漏有效问题。尽管38秒的中位延迟较高，但通过流式传输和分步渲染优化了用户体验。早期红队测试现象消退后，超90%的提问转为真实工作场景应用。

然而，系统存在明显短板：活跃用户仅34人，多数用户在首月后停止使用；LLM评估存在噪声且可能误判。项目成功的关键在于保持文档结构完整性、单独处理表格以及早期引入真实用户测试，而非单纯依赖量化反馈。