简介检索增强生成RAG是一种将外部知识库与大语言模型LLM相结合的技术范式其核心原理是通过向量化检索从结构化知识库中动态获取相关信息再交由LLM基于这些上下文生成精准答案。这一架构在技术上解决了传统微调方案成本高、知识更新慢和幻觉问题特别适用于对准确性、可溯源性和数据安全有严苛要求的垂直领域。在工程实践中RAG通过向量数据库与嵌入模型如BGE-large-zh实现高效语义检索结合本地化部署的轻量化模型如Qwen2-7B能够构建出安全可控的领域智能问答系统。在审计等专业场景中该系统可快速响应准则查询、程序解读等需求将审计师从繁琐的信息检索中解放出来聚焦于更高价值的职业判断。1. 项目缘起当审计师遇上大语言模型作为一名在审计行业摸爬滚打了十来年的老兵我太清楚审计工作的痛点了。每年到了年审季面对堆积如山的合同、凭证、报表和底稿团队里的新老同事最常问的问题就是“这个科目的审计程序是什么来着”“这个行业的特殊风险点有哪些”“这个会计处理合规吗”这些问题有的在审计准则里有但翻起来费时有的靠个人经验但经验难以快速复制和传承。更头疼的是面对客户海量的非结构化文档——比如一份复杂的股权转让协议或者一份新业务的合同——如何快速提取关键审计线索一直是个老大难。直到去年大语言模型LLM的风刮到了我们这行。看着网上各种基于LLM的智能客服、代码助手我就在想能不能给审计也做一个“智能助手”一个能回答专业问题、能解读复杂文档、能7x24小时在线的“老专家”这个想法就是我们这个“基于大语言模型的智能审计问答系统”的起点。它不是要取代审计师而是想成为审计师手边一个超级高效的“外挂大脑”把我们从重复、繁琐的信息检索和初步判断中解放出来让我们能更聚焦于需要职业判断的核心环节。这个项目我把它做成了一个完整的Python实现从模型选型、知识库构建、到后端API和前端交互全部走通。今天我就把这个高分项目的源码和设计思路毫无保留地分享出来。无论你是想了解LLM如何落地垂直领域还是想亲手搭建一个属于自己的知识问答系统相信这篇长文都能给你带来实实在在的参考。2. 核心架构设计为什么是RAG而不仅仅是微调在决定技术路线时我们面临两个主流选择一是对通用大语言模型进行领域微调二是采用检索增强生成RAG架构。经过深入对比和实际测试我们果断选择了RAG作为核心架构。这里面的“为什么”是项目成败的关键。2.1 微调路线的局限性微调听起来很美好拿大量的审计准则、案例报告、政策法规去训练一个模型让它“变成”审计专家。但实际操作中问题很多成本高昂训练一个百亿参数级别的模型需要大量的GPU算力和时间对于大多数事务所或团队来说这是一笔巨大的投入。知识更新滞后会计准则、税法政策几乎年年有变。每次更新都需要重新收集数据、重新训练或增量训练流程繁琐响应慢。“幻觉”问题依旧即便经过微调LLM固有的“幻觉”即编造看似合理但错误的信息问题依然存在。在严谨的审计工作中这是不可接受的风险。知识容量瓶颈模型本身的知识容量受限于训练数据难以容纳所有细节和最新的客户特定资料。2.2 RAG架构的优势与我们的选择RAG的核心思想是“按需取用”。它不试图把海量知识全部塞进模型参数里而是将知识存储在外部向量数据库中。当用户提问时系统先去知识库中检索最相关的文档片段然后将这些片段和问题一起交给LLM让它基于这些给定的、准确的上下文来生成答案。这完美契合了审计场景的需求答案可溯源生成的每一个答案都能追溯到知识库中的原文出处。审计师可以快速核对极大增强了可信度。知识更新便捷更新知识库只需要向向量数据库插入新的文档向量即可几乎是实时的。成本可控我们可以选用优秀的开源模型进行推理无需承担天价的训练成本。降低幻觉由于答案严格限制在提供的上下文内编造信息的概率大大降低。因此我们的系统架构确定为文档处理 - 向量知识库 - 检索 - LLM生成 - 前端展示。这个选择让项目从“炫技”变成了“实用”。3. 技术栈选型详解每一个组件背后的取舍确定了RAG架构接下来就是具体的技术选型。每一款工具和框架的选择都经过了本地测试和对比核心原则是轻量、高效、可控、开源。3.1 大语言模型Qwen2-7B的胜出模型是整个系统的“大脑”。我们测试了多个开源模型包括LLaMA 2、ChatGLM3、Baichuan等最终选择了Qwen2-7B。理由一出色的中文能力与合规性通义千问团队在中文语料上训练充分Qwen2-7B在中文理解、推理和生成任务上表现非常均衡且完全开源商用友好避免了合规风险。理由二适中的规模7B参数在精度和推理速度之间取得了很好的平衡。在消费级显卡如RTX 4060 Ti 16G上可以流畅进行INT4量化推理响应速度能满足交互式问答的需求。理由三优秀的工具调用与长文本支持Qwen2系列对Function Calling有良好支持为未来扩展如自动执行分析程序留下了空间。其上下文长度也足以处理我们检索回来的多段文本。我们没有选择直接调用OpenAI等云端API核心是为了数据安全。审计文档涉及大量客户商业机密必须本地部署杜绝数据出境风险。3.2 模型推理与量化Llama.cpp的魔力如何高效地在本地运行Qwen2-7B我们选择了Llama.cpp这个C编写的推理引擎。极致性能通过GGUF量化格式和纯C实现它能在CPU上实现可用的推理速度在GPU上则更快。相比原生的PyTorch推理内存占用更少速度提升明显。量化方案选择我们采用了q4_k_m这个量化等级。它相比原始的FP16模型体积缩小至约1/4精度损失在可接受范围内是性价比最高的选择。量化命令如下# 使用llama.cpp提供的量化工具将下载的原始模型转换为GGUF格式并量化 ./quantize ./models/qwen2-7b-f16.gguf ./models/qwen2-7b-q4_k_m.gguf q4_k_m内存与显存占用量化后的模型文件约4GB。推理时如果使用GPU显存占用约5-6GB纯CPU推理内存占用约6-8GB。这使得在普通的开发机或工作站上部署成为可能。3.3 向量数据库与嵌入模型ChromaDB BGE的黄金组合检索是RAG的“心脏”。这部分需要两个核心把文本变成向量的嵌入模型和存储、检索这些向量的数据库。嵌入模型BGE-large-zh-v1.5北京智源研究院开源的BGE系列模型是中文文本嵌入的“国家队”选手。BGE-large-zh-v1.5在中文语义相似度任务上表现出色能精准捕捉审计专业文本的细微差别。我们使用sentence-transformers库来调用它。from sentence_transformers import SentenceTransformer embed_model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 将一段文本转换为768维的向量 vector embed_model.encode(审计重要性水平如何确定)向量数据库ChromaDB选择ChromaDB是因为它足够简单。它可以直接在内存或本地文件系统中运行无需复杂的服务部署如Milvus。其API设计非常Pythonic几行代码就能完成建库、插入和检索非常适合快速原型和中小规模知识库万级文档片段以内。3.4 后端与前端FastAPI 简约HTML为了提供HTTP API服务和一个简单的演示界面我们选择了以下组合后端FastAPI一个现代、高性能的Python Web框架。它自动生成交互式API文档Swagger UI对于调试和前后端联调非常方便。其异步特性也能更好地处理可能并发的请求。前端纯HTML/JS为了极致简化前端就是一个简单的HTML页面使用JavaScript调用后端的API。没有引入复杂的框架使得整个项目重点突出也易于理解修改。整个技术栈的协作流程如下图所示概念描述用户在前端提问 - FastAPI后端接收问题 - 使用BGE模型将问题转换为向量 - 在ChromaDB中检索相似文本 - 将检索结果和问题拼接成Prompt - 发送给由Llama.cpp服务的Qwen2模型 - 将生成的答案返回给前端。4. 知识库构建实战从杂乱文档到结构化向量一个RAG系统的好坏八成取决于知识库的质量。审计知识库的构建远不止是“把PDF扔进去”那么简单。4.1 文档收集与预处理我们收集了多类文档构建了初始知识库结构化知识企业会计准则、审计准则及应用指南、税法条文等PDF和Word文档。半结构化/非结构化知识历年审计报告、内部审计手册、经典审计案例、违规处罚公告等。客户特定资料这是一个可扩展的模块可以为每个项目导入客户的章程、重要合同、既往年度的审计底稿等。预处理的第一步是格式转换和文本提取。我们使用pdfplumber和python-docx库因为它们能较好地保持文本的原始结构如段落、标题。import pdfplumber def extract_text_from_pdf(pdf_path): text with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 提取页面文本并尽量保留布局信息 page_text page.extract_text(layoutTrue) if page_text: text page_text \n return text注意layoutTrue参数在某些格式复杂的PDF上可能效果不佳此时可以尝试pymupdf库作为备选。预处理阶段一定要人工抽样检查提取结果防止乱码或错位。4.2 文本分割的艺术与技巧这是构建知识库最核心、也最易出错的环节。不能简单按固定字符数切割否则会割裂完整的语义单元。我们的策略递归式分割我们采用了langchain的RecursiveCharacterTextSplitter并精心配置了分隔符优先级。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( separators[\n\n, \n, 。, , , , ], # 中文分隔符优先 chunk_size500, # 目标块大小 chunk_overlap80, # 块间重叠字符数 length_functionlen, ) chunks text_splitter.split_text(long_text)关键参数解读chunk_size500这是根据我们使用的BGE-large-zh模型和Qwen2-7B模型的上下文窗口权衡决定的。500字左右的片段既能包含一个相对完整的概念如一个审计程序的定义又不会过长导致检索精度下降和模型处理负担增加。chunk_overlap80重叠是为了避免一个完整的句子或概念被硬生生切到两个块里导致检索时上下文缺失。80个字符的重叠能有效缓解这个问题。针对审计文档的优化对于准则类文档我们额外增加了按“章”、“节”标题的分割逻辑确保每个知识块的主题更加聚焦。4.3 向量化与入库将分割好的文本块转化为向量并存入ChromaDB。import chromadb from sentence_transformers import SentenceTransformer # 初始化嵌入模型和客户端 embedder SentenceTransformer(BAAI/bge-large-zh-v1.5) chroma_client chromadb.PersistentClient(path./audit_knowledge_db) # 持久化到本地 # 创建集合类似数据库的表 collection chroma_client.create_collection(nameaudit_rules) # 假设chunks是文本块列表metadatas是包含来源、页码等信息的元数据列表 embeddings embedder.encode(chunks).tolist() # 批量编码效率更高 # 为每个块生成唯一ID ids [fchunk_{i} for i in range(len(chunks))] # 批量添加到集合 collection.add( embeddingsembeddings, documentschunks, metadatasmetadatas, # 例如 [{source: CAS_30.pdf, page: 15}, ...] idsids )实操心得metadatas字段至关重要一定要记录每个文本块的来源文件名和位置页码或章节。这是实现“答案溯源”功能的基石。入库前建议对chunks列表进行清洗去除过短如少于20字或全是无意义字符的块。5. 核心功能实现从提问到答案的完整链路知识库准备好后就进入了系统的核心逻辑处理用户查询。这个过程我们将其封装成了一个清晰的工作流。5.1 查询处理与向量检索后端API接收到用户问题query后首先进行预处理如去除多余空格然后将其转换为向量并在知识库中进行相似度检索。from fastapi import FastAPI, Query from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str top_k: int 3 # 默认返回最相关的3个片段 app.post(/ask) async def ask_question(req: QueryRequest): query req.question # 1. 查询向量化 query_vector embedder.encode([query]).tolist()[0] # 注意encode接收列表 # 2. 向量检索 results collection.query( query_embeddings[query_vector], n_resultsreq.top_k, include[documents, metadatas, distances] # 返回文档、元数据和距离 ) # results结构{ids: [...], distances: [[...]], documents: [[...]], metadatas: [[...]]} retrieved_docs results[documents][0] # 取出最外层的列表 retrieved_metas results[metadatas][0]这里有个关键点top_k检索数量的设置。不是越多越好。经过测试对于大多数事实性问答top_k3或5已经足够。过多的无关上下文会干扰LLM可能导致答案质量下降或“幻觉”增加。对于复杂、综合性的问题可以适当调大但一般不超过10。5.2 Prompt工程给模型清晰的指令检索到的文档片段需要和用户问题一起构造成一个清晰的Prompt送给Qwen2模型。Prompt的设计直接决定了答案的质量和格式。def build_prompt(query, retrieved_docs, retrieved_metas): context for i, (doc, meta) in enumerate(zip(retrieved_docs, retrieved_metas)): source meta.get(source, 未知来源) page meta.get(page, 未知页码) context f[参考片段{i1}来源{source}页码{page}]\n{doc}\n\n prompt f你是一个专业的审计助手请严格根据以下提供的参考上下文来回答问题。如果上下文中的信息不足以回答问题请直接说“根据现有资料无法回答该问题”不要编造信息。 参考上下文 {context} 用户问题{query} 请用专业、清晰的中文回答。在回答的最后请列出你所依据的参考片段编号及来源。 专业回答 return prompt这个Prompt有几个设计要点角色设定明确告诉模型“你是一个专业的审计助手”引导其使用专业口吻。指令明确“严格根据以下提供的参考上下文”这是限制幻觉的核心指令。上下文格式化为每个检索片段添加了清晰的编号和来源标记便于模型引用和后续展示。安全兜底明确要求模型在信息不足时承认无法回答这是确保严谨性的关键。输出格式要求列出依据这既是对模型的约束也方便用户溯源。5.3 与本地LLM交互集成Llama.cpp我们通过llama-cpp-python这个Python绑定库来调用本地部署的Llama.cpp服务。from llama_cpp import Llama # 加载量化后的模型 llm Llama( model_path./models/qwen2-7b-q4_k_m.gguf, n_ctx4096, # 上下文长度需足够容纳Prompt和生成内容 n_threads8, # CPU线程数根据机器调整 n_gpu_layers35 # 在GPU上运行的层数-1表示全部根据显存调整 ) def generate_answer(prompt): # 设置生成参数 output llm( prompt, max_tokens1024, # 生成的最大token数 stop[/s, 用户问题], # 停止词防止模型乱跑 temperature0.1, # 温度值设低让答案更确定、更少随机性 echoFalse # 不返回输入的prompt ) answer output[choices][0][text].strip() return answer关键参数解析n_gpu_layers这个参数决定了有多少层模型加载到GPU上。层数越多GPU加速效果越明显但显存占用也越大。需要通过实验找到你显卡上的最优值。对于7B模型通常33-40层是常见范围。temperature在审计问答这种需要严谨、事实准确的场景下必须设置为一个很低的值如0.1或0.2。高温如0.8会导致答案创造性过强不确定性高不适合。max_tokens根据问题复杂度和我们提供的上下文长度设定。1024对于大多数审计问答已足够。5.4 结果整合与API返回最后我们将LLM生成的答案和检索到的参考来源信息整合返回给前端。app.post(/ask) async def ask_question(req: QueryRequest): # ... (之前的检索和Prompt构建代码) prompt build_prompt(query, retrieved_docs, retrieved_metas) answer_text generate_answer(prompt) # 构造返回结果 response { question: query, answer: answer_text, references: [] # 存放参考来源信息 } # 可以尝试从答案文本中解析出引用的片段编号或者简单地将所有检索到的来源都返回 # 这里我们选择将所有检索片段的元数据返回由前端决定如何展示 for meta in retrieved_metas: response[references].append({ source: meta.get(source, N/A), page: meta.get(page, N/A), # 甚至可以返回一部分原文预览 excerpt: meta.get(excerpt, ) }) return response这样一个完整的问答流程就结束了。前端拿到这个结构化的响应可以清晰地展示答案并在旁边或底部列出“依据来源”点击甚至可以跳转到原文位置极大提升了可信度和实用性。6. 系统部署与优化让项目真正跑起来代码写完了如何把它变成一个随时可用的服务这里分享我们的部署方案和性能调优经验。6.1 本地开发环境一键启动为了方便开发和演示我们编写了一个docker-compose.yml文件将整个系统容器化。虽然模型推理部分对GPU有依赖但我们可以将模型文件挂载进容器并通过参数将宿主机的GPU设备透传给容器。version: 3.8 services: rag-api: build: ./backend ports: - 8000:8000 volumes: - ./models:/app/models # 挂载模型目录 - ./knowledge_db:/app/knowledge_db # 挂载向量数据库 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] # 申请GPU资源需要NVIDIA Container Toolkit environment: - MODEL_PATH/app/models/qwen2-7b-q4_k_m.gguf - EMBED_MODEL_NAMEBAAI/bge-large-zh-v1.5 command: uvicorn main:app --host 0.0.0.0 --port 8000 --reload部署踩坑记最常遇到的问题就是GPU透传失败。确保宿主机已安装正确版本的NVIDIA驱动和nvidia-container-toolkit。在Linux下运行docker run --gpus all ...测试是否成功。在Windows下需要配置Docker Desktop的WSL2后端并安装相关驱动过程更为繁琐。6.2 性能优化点嵌入模型缓存BGE模型加载一次后可以常驻内存避免每次请求都重复加载。在FastAPI中可以使用lifespan事件或直接在全局初始化。LLM模型预热第一次调用Llama.cpp加载模型会比较慢。可以在服务启动后先发送一个简单的预热请求让模型完成加载。检索优化当知识库文档量很大时10万条ChromaDB的内存检索可能成为瓶颈。此时可以考虑升级到支持持久化、索引更专业的向量数据库如Qdrant或Weaviate。在检索前先使用传统的关键词检索如Elasticsearch或元数据过滤进行粗筛减少需要做向量相似度计算的候选集大小。这就是“混合检索”策略。异步处理对于耗时的LLM生成步骤可以考虑使用FastAPI的BackgroundTasks或者像Celery这样的任务队列将生成任务异步化避免HTTP请求阻塞提升接口响应速度。6.3 前端简单界面前端我们保持极简一个HTML文件足矣使用fetchAPI与后端交互。!DOCTYPE html html headtitle智能审计问答助手/title/head body h2审计智能问答/h2 input typetext idquestionInput placeholder请输入您的审计问题... stylewidth: 400px; button onclickaskQuestion()提问/button div idanswerArea stylemargin-top: 20px; white-space: pre-wrap;/div div idreferenceArea stylemargin-top: 20px; font-size: 0.9em; color: #666;/div script async function askQuestion() { const question document.getElementById(questionInput).value; const resp await fetch(http://localhost:8000/ask, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({question: question, top_k: 3}) }); const data await resp.json(); document.getElementById(answerArea).innerText data.answer; // 渲染参考来源 let refHtml h4参考依据/h4ul; data.references.forEach(ref { refHtml li${ref.source} (P${ref.page})/li; }); refHtml /ul; document.getElementById(referenceArea).innerHTML refHtml; } /script /body /html7. 效果评估与迭代我们离“智能”还有多远系统跑起来后我们进行了大量的内部测试。效果有好有坏这也是所有AI项目必须面对的过程。7.1 成功案例准则查询对于明确的准则条文查询如“收入确认的五步法是什么”系统能精准定位到《企业会计准则第14号——收入》的相关段落并给出清晰解释准确率很高。程序性问答对于“货币资金的审计程序有哪些”这类程序性问题系统能综合多个审计准则指南中的片段给出比较完整的步骤列表。概念解释对专业术语如“控制测试”、“实质性程序”的区别能结合上下文给出不错的对比说明。7.2 暴露的问题与改进方向复杂、综合性问题处理不佳例如“针对一家跨境电商企业收入审计的重点和风险点有哪些”。这类问题需要综合行业知识、商业模式、会计准则和审计经验。系统检索出的片段可能是零散的LLM难以进行高层次的归纳和推理答案往往流于表面或拼凑感强。改进思路构建更细粒度的知识图谱。不仅存储文本片段还将实体如“收入”、“跨境电商”、“风险”和关系抽取出来。检索时先进行图谱查询找到相关实体网络再补充文本细节为LLM提供更有结构性的背景信息。对数字、日期等精确信息敏感度不足虽然RAG提供了出处但LLM在整合多个片段中的数字信息时有时会出错。例如将不同法规中的不同税率张冠李戴。改进思路在Prompt中加强指令要求模型“直接引用上下文中的数字不要计算或更改”。或者在后处理阶段加入一个校验模块专门核对答案中出现的数字、日期是否与原文严格一致。检索精度依赖分割质量如果文本分割不当导致一个关键概念被拆散那么无论检索还是生成效果都会大打折扣。改进思路采用更智能的分割方法如基于语义的句子嵌入分割或者利用文档本身的层级结构PDF书签、标题样式进行分割。定期人工审核知识库中的“边界”案例持续优化分割策略。无法进行复杂计算和推理审计中涉及大量的财务比率分析、趋势分析、重新计算等。目前的纯文本问答系统无法完成。扩展方向引入“工具调用”能力。让LLM学会在需要时调用我们预先写好的Python函数如计算流动比率、执行Benford定律分析。这将是系统从“问答机”向“智能助手”演进的关键一步。这个项目目前还是一个强有力的“辅助检索和初步解释工具”。它把审计师从记忆和查找的体力活中解放了出来但距离真正的“职业判断”还有很长的路要走。技术的迭代很快但核心永远是如何更好地理解业务、服务于人。希望这个开源项目能成为一个起点吸引更多同行和开发者一起让技术真正为审计这个古老而重要的行业赋能。本文还有配套的精品资源点击获取
简介检索增强生成RAG是一种将外部知识库与大语言模型LLM相结合的技术范式其核心原理是通过向量化检索从结构化知识库中动态获取相关信息再交由LLM基于这些上下文生成精准答案。这一架构在技术上解决了传统微调方案成本高、知识更新慢和幻觉问题特别适用于对准确性、可溯源性和数据安全有严苛要求的垂直领域。在工程实践中RAG通过向量数据库与嵌入模型如BGE-large-zh实现高效语义检索结合本地化部署的轻量化模型如Qwen2-7B能够构建出安全可控的领域智能问答系统。在审计等专业场景中该系统可快速响应准则查询、程序解读等需求将审计师从繁琐的信息检索中解放出来聚焦于更高价值的职业判断。1. 项目缘起当审计师遇上大语言模型作为一名在审计行业摸爬滚打了十来年的老兵我太清楚审计工作的痛点了。每年到了年审季面对堆积如山的合同、凭证、报表和底稿团队里的新老同事最常问的问题就是“这个科目的审计程序是什么来着”“这个行业的特殊风险点有哪些”“这个会计处理合规吗”这些问题有的在审计准则里有但翻起来费时有的靠个人经验但经验难以快速复制和传承。更头疼的是面对客户海量的非结构化文档——比如一份复杂的股权转让协议或者一份新业务的合同——如何快速提取关键审计线索一直是个老大难。直到去年大语言模型LLM的风刮到了我们这行。看着网上各种基于LLM的智能客服、代码助手我就在想能不能给审计也做一个“智能助手”一个能回答专业问题、能解读复杂文档、能7x24小时在线的“老专家”这个想法就是我们这个“基于大语言模型的智能审计问答系统”的起点。它不是要取代审计师而是想成为审计师手边一个超级高效的“外挂大脑”把我们从重复、繁琐的信息检索和初步判断中解放出来让我们能更聚焦于需要职业判断的核心环节。这个项目我把它做成了一个完整的Python实现从模型选型、知识库构建、到后端API和前端交互全部走通。今天我就把这个高分项目的源码和设计思路毫无保留地分享出来。无论你是想了解LLM如何落地垂直领域还是想亲手搭建一个属于自己的知识问答系统相信这篇长文都能给你带来实实在在的参考。2. 核心架构设计为什么是RAG而不仅仅是微调在决定技术路线时我们面临两个主流选择一是对通用大语言模型进行领域微调二是采用检索增强生成RAG架构。经过深入对比和实际测试我们果断选择了RAG作为核心架构。这里面的“为什么”是项目成败的关键。2.1 微调路线的局限性微调听起来很美好拿大量的审计准则、案例报告、政策法规去训练一个模型让它“变成”审计专家。但实际操作中问题很多成本高昂训练一个百亿参数级别的模型需要大量的GPU算力和时间对于大多数事务所或团队来说这是一笔巨大的投入。知识更新滞后会计准则、税法政策几乎年年有变。每次更新都需要重新收集数据、重新训练或增量训练流程繁琐响应慢。“幻觉”问题依旧即便经过微调LLM固有的“幻觉”即编造看似合理但错误的信息问题依然存在。在严谨的审计工作中这是不可接受的风险。知识容量瓶颈模型本身的知识容量受限于训练数据难以容纳所有细节和最新的客户特定资料。2.2 RAG架构的优势与我们的选择RAG的核心思想是“按需取用”。它不试图把海量知识全部塞进模型参数里而是将知识存储在外部向量数据库中。当用户提问时系统先去知识库中检索最相关的文档片段然后将这些片段和问题一起交给LLM让它基于这些给定的、准确的上下文来生成答案。这完美契合了审计场景的需求答案可溯源生成的每一个答案都能追溯到知识库中的原文出处。审计师可以快速核对极大增强了可信度。知识更新便捷更新知识库只需要向向量数据库插入新的文档向量即可几乎是实时的。成本可控我们可以选用优秀的开源模型进行推理无需承担天价的训练成本。降低幻觉由于答案严格限制在提供的上下文内编造信息的概率大大降低。因此我们的系统架构确定为文档处理 - 向量知识库 - 检索 - LLM生成 - 前端展示。这个选择让项目从“炫技”变成了“实用”。3. 技术栈选型详解每一个组件背后的取舍确定了RAG架构接下来就是具体的技术选型。每一款工具和框架的选择都经过了本地测试和对比核心原则是轻量、高效、可控、开源。3.1 大语言模型Qwen2-7B的胜出模型是整个系统的“大脑”。我们测试了多个开源模型包括LLaMA 2、ChatGLM3、Baichuan等最终选择了Qwen2-7B。理由一出色的中文能力与合规性通义千问团队在中文语料上训练充分Qwen2-7B在中文理解、推理和生成任务上表现非常均衡且完全开源商用友好避免了合规风险。理由二适中的规模7B参数在精度和推理速度之间取得了很好的平衡。在消费级显卡如RTX 4060 Ti 16G上可以流畅进行INT4量化推理响应速度能满足交互式问答的需求。理由三优秀的工具调用与长文本支持Qwen2系列对Function Calling有良好支持为未来扩展如自动执行分析程序留下了空间。其上下文长度也足以处理我们检索回来的多段文本。我们没有选择直接调用OpenAI等云端API核心是为了数据安全。审计文档涉及大量客户商业机密必须本地部署杜绝数据出境风险。3.2 模型推理与量化Llama.cpp的魔力如何高效地在本地运行Qwen2-7B我们选择了Llama.cpp这个C编写的推理引擎。极致性能通过GGUF量化格式和纯C实现它能在CPU上实现可用的推理速度在GPU上则更快。相比原生的PyTorch推理内存占用更少速度提升明显。量化方案选择我们采用了q4_k_m这个量化等级。它相比原始的FP16模型体积缩小至约1/4精度损失在可接受范围内是性价比最高的选择。量化命令如下# 使用llama.cpp提供的量化工具将下载的原始模型转换为GGUF格式并量化 ./quantize ./models/qwen2-7b-f16.gguf ./models/qwen2-7b-q4_k_m.gguf q4_k_m内存与显存占用量化后的模型文件约4GB。推理时如果使用GPU显存占用约5-6GB纯CPU推理内存占用约6-8GB。这使得在普通的开发机或工作站上部署成为可能。3.3 向量数据库与嵌入模型ChromaDB BGE的黄金组合检索是RAG的“心脏”。这部分需要两个核心把文本变成向量的嵌入模型和存储、检索这些向量的数据库。嵌入模型BGE-large-zh-v1.5北京智源研究院开源的BGE系列模型是中文文本嵌入的“国家队”选手。BGE-large-zh-v1.5在中文语义相似度任务上表现出色能精准捕捉审计专业文本的细微差别。我们使用sentence-transformers库来调用它。from sentence_transformers import SentenceTransformer embed_model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 将一段文本转换为768维的向量 vector embed_model.encode(审计重要性水平如何确定)向量数据库ChromaDB选择ChromaDB是因为它足够简单。它可以直接在内存或本地文件系统中运行无需复杂的服务部署如Milvus。其API设计非常Pythonic几行代码就能完成建库、插入和检索非常适合快速原型和中小规模知识库万级文档片段以内。3.4 后端与前端FastAPI 简约HTML为了提供HTTP API服务和一个简单的演示界面我们选择了以下组合后端FastAPI一个现代、高性能的Python Web框架。它自动生成交互式API文档Swagger UI对于调试和前后端联调非常方便。其异步特性也能更好地处理可能并发的请求。前端纯HTML/JS为了极致简化前端就是一个简单的HTML页面使用JavaScript调用后端的API。没有引入复杂的框架使得整个项目重点突出也易于理解修改。整个技术栈的协作流程如下图所示概念描述用户在前端提问 - FastAPI后端接收问题 - 使用BGE模型将问题转换为向量 - 在ChromaDB中检索相似文本 - 将检索结果和问题拼接成Prompt - 发送给由Llama.cpp服务的Qwen2模型 - 将生成的答案返回给前端。4. 知识库构建实战从杂乱文档到结构化向量一个RAG系统的好坏八成取决于知识库的质量。审计知识库的构建远不止是“把PDF扔进去”那么简单。4.1 文档收集与预处理我们收集了多类文档构建了初始知识库结构化知识企业会计准则、审计准则及应用指南、税法条文等PDF和Word文档。半结构化/非结构化知识历年审计报告、内部审计手册、经典审计案例、违规处罚公告等。客户特定资料这是一个可扩展的模块可以为每个项目导入客户的章程、重要合同、既往年度的审计底稿等。预处理的第一步是格式转换和文本提取。我们使用pdfplumber和python-docx库因为它们能较好地保持文本的原始结构如段落、标题。import pdfplumber def extract_text_from_pdf(pdf_path): text with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 提取页面文本并尽量保留布局信息 page_text page.extract_text(layoutTrue) if page_text: text page_text \n return text注意layoutTrue参数在某些格式复杂的PDF上可能效果不佳此时可以尝试pymupdf库作为备选。预处理阶段一定要人工抽样检查提取结果防止乱码或错位。4.2 文本分割的艺术与技巧这是构建知识库最核心、也最易出错的环节。不能简单按固定字符数切割否则会割裂完整的语义单元。我们的策略递归式分割我们采用了langchain的RecursiveCharacterTextSplitter并精心配置了分隔符优先级。from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( separators[\n\n, \n, 。, , , , ], # 中文分隔符优先 chunk_size500, # 目标块大小 chunk_overlap80, # 块间重叠字符数 length_functionlen, ) chunks text_splitter.split_text(long_text)关键参数解读chunk_size500这是根据我们使用的BGE-large-zh模型和Qwen2-7B模型的上下文窗口权衡决定的。500字左右的片段既能包含一个相对完整的概念如一个审计程序的定义又不会过长导致检索精度下降和模型处理负担增加。chunk_overlap80重叠是为了避免一个完整的句子或概念被硬生生切到两个块里导致检索时上下文缺失。80个字符的重叠能有效缓解这个问题。针对审计文档的优化对于准则类文档我们额外增加了按“章”、“节”标题的分割逻辑确保每个知识块的主题更加聚焦。4.3 向量化与入库将分割好的文本块转化为向量并存入ChromaDB。import chromadb from sentence_transformers import SentenceTransformer # 初始化嵌入模型和客户端 embedder SentenceTransformer(BAAI/bge-large-zh-v1.5) chroma_client chromadb.PersistentClient(path./audit_knowledge_db) # 持久化到本地 # 创建集合类似数据库的表 collection chroma_client.create_collection(nameaudit_rules) # 假设chunks是文本块列表metadatas是包含来源、页码等信息的元数据列表 embeddings embedder.encode(chunks).tolist() # 批量编码效率更高 # 为每个块生成唯一ID ids [fchunk_{i} for i in range(len(chunks))] # 批量添加到集合 collection.add( embeddingsembeddings, documentschunks, metadatasmetadatas, # 例如 [{source: CAS_30.pdf, page: 15}, ...] idsids )实操心得metadatas字段至关重要一定要记录每个文本块的来源文件名和位置页码或章节。这是实现“答案溯源”功能的基石。入库前建议对chunks列表进行清洗去除过短如少于20字或全是无意义字符的块。5. 核心功能实现从提问到答案的完整链路知识库准备好后就进入了系统的核心逻辑处理用户查询。这个过程我们将其封装成了一个清晰的工作流。5.1 查询处理与向量检索后端API接收到用户问题query后首先进行预处理如去除多余空格然后将其转换为向量并在知识库中进行相似度检索。from fastapi import FastAPI, Query from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str top_k: int 3 # 默认返回最相关的3个片段 app.post(/ask) async def ask_question(req: QueryRequest): query req.question # 1. 查询向量化 query_vector embedder.encode([query]).tolist()[0] # 注意encode接收列表 # 2. 向量检索 results collection.query( query_embeddings[query_vector], n_resultsreq.top_k, include[documents, metadatas, distances] # 返回文档、元数据和距离 ) # results结构{ids: [...], distances: [[...]], documents: [[...]], metadatas: [[...]]} retrieved_docs results[documents][0] # 取出最外层的列表 retrieved_metas results[metadatas][0]这里有个关键点top_k检索数量的设置。不是越多越好。经过测试对于大多数事实性问答top_k3或5已经足够。过多的无关上下文会干扰LLM可能导致答案质量下降或“幻觉”增加。对于复杂、综合性的问题可以适当调大但一般不超过10。5.2 Prompt工程给模型清晰的指令检索到的文档片段需要和用户问题一起构造成一个清晰的Prompt送给Qwen2模型。Prompt的设计直接决定了答案的质量和格式。def build_prompt(query, retrieved_docs, retrieved_metas): context for i, (doc, meta) in enumerate(zip(retrieved_docs, retrieved_metas)): source meta.get(source, 未知来源) page meta.get(page, 未知页码) context f[参考片段{i1}来源{source}页码{page}]\n{doc}\n\n prompt f你是一个专业的审计助手请严格根据以下提供的参考上下文来回答问题。如果上下文中的信息不足以回答问题请直接说“根据现有资料无法回答该问题”不要编造信息。 参考上下文 {context} 用户问题{query} 请用专业、清晰的中文回答。在回答的最后请列出你所依据的参考片段编号及来源。 专业回答 return prompt这个Prompt有几个设计要点角色设定明确告诉模型“你是一个专业的审计助手”引导其使用专业口吻。指令明确“严格根据以下提供的参考上下文”这是限制幻觉的核心指令。上下文格式化为每个检索片段添加了清晰的编号和来源标记便于模型引用和后续展示。安全兜底明确要求模型在信息不足时承认无法回答这是确保严谨性的关键。输出格式要求列出依据这既是对模型的约束也方便用户溯源。5.3 与本地LLM交互集成Llama.cpp我们通过llama-cpp-python这个Python绑定库来调用本地部署的Llama.cpp服务。from llama_cpp import Llama # 加载量化后的模型 llm Llama( model_path./models/qwen2-7b-q4_k_m.gguf, n_ctx4096, # 上下文长度需足够容纳Prompt和生成内容 n_threads8, # CPU线程数根据机器调整 n_gpu_layers35 # 在GPU上运行的层数-1表示全部根据显存调整 ) def generate_answer(prompt): # 设置生成参数 output llm( prompt, max_tokens1024, # 生成的最大token数 stop[/s, 用户问题], # 停止词防止模型乱跑 temperature0.1, # 温度值设低让答案更确定、更少随机性 echoFalse # 不返回输入的prompt ) answer output[choices][0][text].strip() return answer关键参数解析n_gpu_layers这个参数决定了有多少层模型加载到GPU上。层数越多GPU加速效果越明显但显存占用也越大。需要通过实验找到你显卡上的最优值。对于7B模型通常33-40层是常见范围。temperature在审计问答这种需要严谨、事实准确的场景下必须设置为一个很低的值如0.1或0.2。高温如0.8会导致答案创造性过强不确定性高不适合。max_tokens根据问题复杂度和我们提供的上下文长度设定。1024对于大多数审计问答已足够。5.4 结果整合与API返回最后我们将LLM生成的答案和检索到的参考来源信息整合返回给前端。app.post(/ask) async def ask_question(req: QueryRequest): # ... (之前的检索和Prompt构建代码) prompt build_prompt(query, retrieved_docs, retrieved_metas) answer_text generate_answer(prompt) # 构造返回结果 response { question: query, answer: answer_text, references: [] # 存放参考来源信息 } # 可以尝试从答案文本中解析出引用的片段编号或者简单地将所有检索到的来源都返回 # 这里我们选择将所有检索片段的元数据返回由前端决定如何展示 for meta in retrieved_metas: response[references].append({ source: meta.get(source, N/A), page: meta.get(page, N/A), # 甚至可以返回一部分原文预览 excerpt: meta.get(excerpt, ) }) return response这样一个完整的问答流程就结束了。前端拿到这个结构化的响应可以清晰地展示答案并在旁边或底部列出“依据来源”点击甚至可以跳转到原文位置极大提升了可信度和实用性。6. 系统部署与优化让项目真正跑起来代码写完了如何把它变成一个随时可用的服务这里分享我们的部署方案和性能调优经验。6.1 本地开发环境一键启动为了方便开发和演示我们编写了一个docker-compose.yml文件将整个系统容器化。虽然模型推理部分对GPU有依赖但我们可以将模型文件挂载进容器并通过参数将宿主机的GPU设备透传给容器。version: 3.8 services: rag-api: build: ./backend ports: - 8000:8000 volumes: - ./models:/app/models # 挂载模型目录 - ./knowledge_db:/app/knowledge_db # 挂载向量数据库 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] # 申请GPU资源需要NVIDIA Container Toolkit environment: - MODEL_PATH/app/models/qwen2-7b-q4_k_m.gguf - EMBED_MODEL_NAMEBAAI/bge-large-zh-v1.5 command: uvicorn main:app --host 0.0.0.0 --port 8000 --reload部署踩坑记最常遇到的问题就是GPU透传失败。确保宿主机已安装正确版本的NVIDIA驱动和nvidia-container-toolkit。在Linux下运行docker run --gpus all ...测试是否成功。在Windows下需要配置Docker Desktop的WSL2后端并安装相关驱动过程更为繁琐。6.2 性能优化点嵌入模型缓存BGE模型加载一次后可以常驻内存避免每次请求都重复加载。在FastAPI中可以使用lifespan事件或直接在全局初始化。LLM模型预热第一次调用Llama.cpp加载模型会比较慢。可以在服务启动后先发送一个简单的预热请求让模型完成加载。检索优化当知识库文档量很大时10万条ChromaDB的内存检索可能成为瓶颈。此时可以考虑升级到支持持久化、索引更专业的向量数据库如Qdrant或Weaviate。在检索前先使用传统的关键词检索如Elasticsearch或元数据过滤进行粗筛减少需要做向量相似度计算的候选集大小。这就是“混合检索”策略。异步处理对于耗时的LLM生成步骤可以考虑使用FastAPI的BackgroundTasks或者像Celery这样的任务队列将生成任务异步化避免HTTP请求阻塞提升接口响应速度。6.3 前端简单界面前端我们保持极简一个HTML文件足矣使用fetchAPI与后端交互。!DOCTYPE html html headtitle智能审计问答助手/title/head body h2审计智能问答/h2 input typetext idquestionInput placeholder请输入您的审计问题... stylewidth: 400px; button onclickaskQuestion()提问/button div idanswerArea stylemargin-top: 20px; white-space: pre-wrap;/div div idreferenceArea stylemargin-top: 20px; font-size: 0.9em; color: #666;/div script async function askQuestion() { const question document.getElementById(questionInput).value; const resp await fetch(http://localhost:8000/ask, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({question: question, top_k: 3}) }); const data await resp.json(); document.getElementById(answerArea).innerText data.answer; // 渲染参考来源 let refHtml h4参考依据/h4ul; data.references.forEach(ref { refHtml li${ref.source} (P${ref.page})/li; }); refHtml /ul; document.getElementById(referenceArea).innerHTML refHtml; } /script /body /html7. 效果评估与迭代我们离“智能”还有多远系统跑起来后我们进行了大量的内部测试。效果有好有坏这也是所有AI项目必须面对的过程。7.1 成功案例准则查询对于明确的准则条文查询如“收入确认的五步法是什么”系统能精准定位到《企业会计准则第14号——收入》的相关段落并给出清晰解释准确率很高。程序性问答对于“货币资金的审计程序有哪些”这类程序性问题系统能综合多个审计准则指南中的片段给出比较完整的步骤列表。概念解释对专业术语如“控制测试”、“实质性程序”的区别能结合上下文给出不错的对比说明。7.2 暴露的问题与改进方向复杂、综合性问题处理不佳例如“针对一家跨境电商企业收入审计的重点和风险点有哪些”。这类问题需要综合行业知识、商业模式、会计准则和审计经验。系统检索出的片段可能是零散的LLM难以进行高层次的归纳和推理答案往往流于表面或拼凑感强。改进思路构建更细粒度的知识图谱。不仅存储文本片段还将实体如“收入”、“跨境电商”、“风险”和关系抽取出来。检索时先进行图谱查询找到相关实体网络再补充文本细节为LLM提供更有结构性的背景信息。对数字、日期等精确信息敏感度不足虽然RAG提供了出处但LLM在整合多个片段中的数字信息时有时会出错。例如将不同法规中的不同税率张冠李戴。改进思路在Prompt中加强指令要求模型“直接引用上下文中的数字不要计算或更改”。或者在后处理阶段加入一个校验模块专门核对答案中出现的数字、日期是否与原文严格一致。检索精度依赖分割质量如果文本分割不当导致一个关键概念被拆散那么无论检索还是生成效果都会大打折扣。改进思路采用更智能的分割方法如基于语义的句子嵌入分割或者利用文档本身的层级结构PDF书签、标题样式进行分割。定期人工审核知识库中的“边界”案例持续优化分割策略。无法进行复杂计算和推理审计中涉及大量的财务比率分析、趋势分析、重新计算等。目前的纯文本问答系统无法完成。扩展方向引入“工具调用”能力。让LLM学会在需要时调用我们预先写好的Python函数如计算流动比率、执行Benford定律分析。这将是系统从“问答机”向“智能助手”演进的关键一步。这个项目目前还是一个强有力的“辅助检索和初步解释工具”。它把审计师从记忆和查找的体力活中解放了出来但距离真正的“职业判断”还有很长的路要走。技术的迭代很快但核心永远是如何更好地理解业务、服务于人。希望这个开源项目能成为一个起点吸引更多同行和开发者一起让技术真正为审计这个古老而重要的行业赋能。本文还有配套的精品资源点击获取
方法)
