Langchain-Chatchat可疑交易识别知识问答系统

Langchain-Chatchat 可疑交易识别知识问答系统

在金融合规一线，一个常见的场景是：反洗钱专员接到运营团队的咨询——“某客户近一周内每天向不同账户转账9,800元，累计已达十几笔，是否构成可疑交易？”
按照传统流程，专员需要翻阅《金融机构大额和可疑交易报告管理办法》、内部风控手册、历史案例库，甚至请教资深同事，才能给出判断。整个过程耗时长、依赖经验，且容易因理解偏差导致标准不一。

如今，借助Langchain-Chatchat搭建的本地化知识问答系统，同样的问题只需输入一句自然语言：“客户频繁小额分散转账是否属于可疑行为？”，系统即可在数秒内返回结构化答案，并附上依据来源。这不仅是效率的跃升，更是企业知识资产从“沉睡文档”走向“智能服务”的关键一步。

这套系统的背后，融合了当前最前沿的 AI 工程实践：以LangChain为应用骨架，本地部署的大语言模型（LLM）作为推理引擎，结合向量数据库实现语义级检索，最终构建出一个既安全又智能的企业专属 AI 助手。它不依赖云端 API，所有数据处理均在内网完成，完美契合金融行业对隐私与合规的严苛要求。

要真正理解这一系统的价值，我们需要深入拆解它的三大核心技术模块——它们不是孤立的技术堆砌，而是环环相扣、协同运作的整体。

首先看LangChain。很多人把它简单理解为“调用大模型的工具包”，但实际上，它的核心能力在于“流程编排”。想象一下，一个完整的问答流程涉及文档加载、文本切分、向量化、检索、提示词构造、模型生成、结果后处理等多个步骤。如果每个环节都手动编码串联，不仅开发成本高，维护也极为困难。

而 LangChain 提供了一套高度模块化的组件体系：

• DocumentLoaders支持从 PDF、Word、网页等多种格式读取内容；
• TextSplitters能智能地将长文档切分为适合嵌入的小块，比如按段落或句子边界分割，避免把一句话硬生生拆开；
• Embedding Models接口统一，可自由切换 HuggingFace 上的不同 Sentence Transformer 模型；
• Vector Stores抽象层让 FAISS、Chroma、Milvus 等数据库可以无缝替换；
• 最关键的是Chains，如RetrievalQA链，能自动将“检索 + 生成”两个阶段连接起来，开发者只需配置参数即可运行。

这种设计哲学极大降低了 AI 应用的门槛。以下是一个典型的实现示例：

from langchain.chains import RetrievalQA from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from langchain.llms import CTranslate2 # 初始化嵌入模型 embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2") # 加载本地向量库 vectorstore = FAISS.load_local("faiss_index", embeddings) # 初始化本地LLM（如量化后的ChatGLM） llm = CTranslate2(model_path="chatglm2-6b-q4", device="cuda") # 构建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 执行问答 query = "哪些交易行为可能构成可疑交易？" result = qa_chain({"query": query}) print(result["result"])

这段代码看似简洁，实则完成了复杂的多阶段处理。其中chain_type="stuff"表示将所有检索到的上下文拼接后一次性送入 LLM；若文档较长，也可选择"map_reduce"或"refine"模式进行分段处理，避免超出模型上下文长度限制。

但光有流程还不够，回答的质量最终取决于大语言模型本身的表现力与可控性。我们常听到 LLM “会编造信息”、“答非所问”，这些问题在专业领域尤为致命。例如，在反洗钱场景中，模型若凭空捏造一条“监管规定”，可能导致误报甚至法律风险。

因此，不能把 LLM 当作“全能百科全书”来用，而应将其定位为“基于证据的生成器”。这就引出了检索增强生成（RAG）的核心思想：模型的所有输出必须严格依据检索到的上下文，而不是依赖其训练数据中的记忆。

如何实现这一点？关键在于提示词工程（Prompt Engineering）。通过精心设计的 prompt，我们可以明确告诉模型角色、任务、输出格式以及行为边界。例如：

from langchain.prompts import PromptTemplate prompt_template = """你是一个金融合规专家，请根据以下上下文回答问题。 如果无法从中得到答案，请说“我不知道”，不要编造答案。 上下文: {context} 问题: {question} 请用中文简洁作答: """ PROMPT = PromptTemplate(template=prompt_template, input_variables=["context", "question"]) qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(), chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True )

这个 prompt 至少设定了四个约束：
1. 角色设定：你是“金融合规专家”，引导模型使用专业语气；
2. 输入来源：答案必须来自{context}；
3. 容错机制：无法回答时应回复“我不知道”；
4. 输出规范：要求“简洁作答”。

这些细节看似微小，却极大提升了系统的可靠性。实践中我们发现，即使使用较小的模型（如 ChatGLM-6B），只要 prompt 设计得当，其表现远优于未加约束的更大模型。

当然，再聪明的模型也需要“好素材”。这就是向量数据库与语义检索机制的作用所在。传统的关键词搜索，比如用“可疑交易”去匹配文档，往往漏检大量相关但表述不同的内容。例如，“资金快进快出”、“无合理经济目的的资金转移”等表达，虽然语义相近，但在字面匹配下可能被忽略。

而语义检索通过将文本转化为向量，在高维空间中计算相似度，实现了真正的“按意思找内容”。其工作流程如下：

1. 使用RecursiveCharacterTextSplitter将原始文档切分为 500 字左右的片段，保留段落完整性；
2. 利用嵌入模型（如 all-MiniLM-L6-v2）将每段文本编码为 384 维向量；
3. 将所有向量存入 FAISS 数据库并建立索引；
4. 用户提问时，问题同样被编码为向量，在库中查找余弦相似度最高的 Top-K 文档片段作为上下文。

代码实现如下：

from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.document_loaders import DirectoryLoader # 加载文档 loader = DirectoryLoader('docs/', glob="*.pdf") documents = loader.load() # 分割文本 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_documents(documents) # 生成向量并保存到FAISS vectorstore = FAISS.from_documents(texts, embeddings) vectorstore.save_local("faiss_index")

这里有几个工程上的关键点值得注意：
-chunk_size 设置需权衡：太小会丢失上下文，太大则可能超出 LLM 的输入窗口（如 2K/4K tokens）。一般建议控制在 300~800 字之间；
-overlap 参数不可忽视：设置 50~100 字的重叠区域，有助于保持句子和段落在切分时不被断裂；
-扫描版 PDF 需 OCR 预处理：直接用 PyPDF2 读取图像型 PDF 会失败，需先通过 Tesseract 或 PaddleOCR 提取文字；
-表格内容单独处理：普通文本分割会破坏表格结构，建议用专用工具（如 Camelot、Tabula）提取后以 Markdown 格式保存。

整个系统的运行架构可以概括为三个层次：

+------------------+ +--------------------+ | 用户提问界面 |<--->| Langchain-Chatchat | +------------------+ +--------------------+ | +--------------------v--------------------+ | 核心处理流程 | | 1. 问题向量化 → 2. 向量检索 → 3. LLM生成 | +-----------------------------------------+ | +-------------------------------+ | 本地资源依赖 | | - 私有文档库（PDF/Word/TXT） | | - 嵌入模型（all-MiniLM-L6-v2） | | - 向量数据库（FAISS） | | - 本地LLM（ChatGLM-6B-GGUF） | +-------------------------------+

所有组件均可部署在企业内网服务器或边缘设备上，无需联网，彻底杜绝数据外泄风险。

在实际落地过程中，除了技术选型，还需考虑一系列现实因素：

• 性能优化方面：对于资源有限的环境，推荐使用 GGUF 量化的 LLaMA 模型（如 Llama-3-8B-Instruct-Q4_K_M），可在消费级 GPU（如 RTX 3090）甚至高端 CPU 上流畅运行；
• 缓存机制：对高频问题（如“什么是大额交易？”）可缓存检索结果，减少重复计算开销；
• 知识更新策略：监管政策常有变动，建议建立定期同步机制，自动重新生成向量索引；
• 审计与追踪：记录每一次查询的问题、时间、用户身份及返回结果，便于后续合规审查；
• 前端体验设计：展示答案时同时列出引用的原文段落和出处文件名，增强结果可信度；支持多轮对话，维持上下文连贯性。

更进一步，该系统并非静态终点，而是可持续进化的知识中枢。随着新案例、新规不断加入，知识库越丰富，系统判断就越精准。未来还可扩展为智能工单辅助、自动报告生成、员工培训模拟等复合功能。

Langchain-Chatchat 的真正意义，不在于它用了多么先进的模型，而在于它提供了一条低门槛、高安全性、可快速迭代的企业智能化路径。它证明了：即使没有庞大的标注数据集，无需昂贵的模型训练，仅靠现有文档和开源工具，也能构建出真正有价值的 AI 应用。

这种“轻量化 + 本地化”的范式，正在成为金融、医疗、政务等敏感行业的主流选择。而对于技术团队而言，掌握这套方法论，意味着拥有了将静态知识转化为动态智能服务的核心能力。