高级精算师的GenAI高效工作流，告别无效检索

导入功能可以将一个包含 PDF 文件的文件夹转换成一个可以按上下文（语义搜索）而非仅仅按关键词搜索的文件夹。目标是：我不再需要在 400 页文档中输入“Ctrl+F 'Cape Cod'”，而是可以问“Cape Cod 方法的关键假设和常见陷阱是什么？”，然后就能找到包含页码引用的相关段落。

我首先使用少量PDF文件，确认其中的文本可以提取。纯文本PDF文件可以直接搜索。扫描版PDF或纯图像文档通常需要进行光学字符识别（OCR）扫描，将图像转换为可搜索的文本；在某些情况下，多模态模型可以直接提取文本。

接下来是分块，即将长文档拆分成较短的部分以方便处理。在我使用的简单设置中，每一页都被视为一个块。这样可以简化引用，并作为一个良好的起点。如果后续检索从密集的页面中提取了太多无关内容，可以将较长的页面拆分成更小的块，或者允许轻微重叠。无论采用哪种方式，页码和文件名都会与每个块一起存储，因此引用是自动生成的。

然后，为每个文本块创建嵌入向量并将其存储在索引中。嵌入向量是文本的数值表示，它支持语义搜索，因为含义相似的两段文本会被映射到彼此“接近”的数值表示。这意味着即使问题使用的措辞与原文不同，它也能匹配到正确的段落。

在步骤1结束时，我得到了一个库，它可以回答以下问题：“我的文档中哪些段落与我刚才提出的问题较为相关？”

这是“提问”阶段。当一个问题出现时，系统会从索引中检索出较为匹配的模块，然后将这些段落连同问题一起发送给大型语言模型（LLM），以生成初步的回复。

关键的设计选择是克制。在我的设置中，操作提示故意写得很枯燥。它会说：

• “仅使用提供的段落回答问题。”

• “使用一致的页码格式引用支持文本。”

• “如果段落中不包含答案，请明确指出。”

这些限制措施可以降低出现幻觉的风险。

关于模型选择的实用建议：这里涉及两个独立的决策，即嵌入和草稿撰写，两者可以灵活组合。嵌入通常在本地运行，而草稿撰写步骤可以使用本地模型，也可以使用由第三方（例如 OpenAI 或 Google Gemini）托管并通过 API 访问的模型。托管模型通常是获得高质量写作效果的至快途径，并且请求在传输过程中通常会进行加密。但是，检索到的段落和问题仍然会传输到外部设备，因此务必遵循公司的数据处理指南。由于每个问题只需发送少量段落，因此成本通常不高。虽然定价会随着模型输入和输出的大小而变化，但良好的检索习惯有助于控制成本。本地模型的质量可能略有不足或需要更多设置，但它们将所有内容都保存在您自己的计算机上，这可以简化数据处理。无论采用哪种方式，工作流程都保持不变：先进行检索，然后根据检索到的内容进行草稿撰写。

如果该工具仅供您自己使用，那么步骤2可以通过脚本、笔记本或命令行运行，并且非常实用。如果需要共享，一个简单的界面会有所帮助。界面无需花哨。在我们的学习材料示例中，一个实用的UI仅仅是：

1）一个输入问题的文本框，以及

2）一个显示答案和引用的结果区域。

对于小型团队来说，界面可以很简单，例如轻量级的 Python Web 应用程序（例如 Streamlit 或 Gradio）、笔记本 UI（Jupyter）或可以导入 Teams 或 Slack 的 FastAPI 端点。

在实践中，这个工作流通过快速找到正确的段落并跨多个文档，为我节省了时间。与通用GenAI相比，这是一个显著的改进，因为输出始终与我的材料相关联，并带有我可以立即使用的页码引用。主要风险是检索效果不佳，即使有引用，模型偶尔也可能超出所支持的段落范围，当检索到的文本可见时，这种情况较容易被发现。

我使用的指导原则很简单：“看不到来源？不要相信答案。” 以这种方式使用RAG，它就成为了精算师的一个实用切入点：更快的研究、更好的综合能力，以及我们已经秉持的相同问责制。