企业官网建设流程全解析

1. 项目概述：当AI智能体遇上多PDF文档聊天

最近在开源社区里看到一个挺有意思的项目，叫“Multi-PDFs_ChatApp_AI-Agent”。光看名字，就能大概猜出它的核心功能：一个能让你和多个PDF文档进行对话的AI智能体应用。这玩意儿听起来是不是有点像给你的文档库配了个24小时在线的、博闻强识的私人助理？没错，它解决的正是我们在处理大量技术手册、研究报告、合同文件或学术论文时，最头疼的那个问题——信息检索。

想象一下这个场景：你手头有十几份关于某个前沿技术（比如RAG架构优化）的PDF白皮书、会议论文和产品文档。你想快速找到所有文档中关于“查询重写”的具体实现方案和各家优劣对比。传统做法是，你得挨个打开PDF，用Ctrl+F搜索关键词，然后在不同窗口间反复横跳，手动拼凑信息。这个过程不仅耗时，而且极易遗漏关键上下文。而这个项目，就是要把这个繁琐的过程，变成一个简单的对话：“嘿，帮我总结一下这几份文档里关于查询重写的所有方法，并对比一下它们的优缺点。” 然后，AI智能体就能给你一个结构清晰的答案，甚至能告诉你每个观点出自哪份文档的第几页。

这个项目的价值，远不止是一个“高级版PDF搜索工具”。它本质上是一个基于大语言模型（LLM）的智能信息提取与问答系统，其核心是将非结构化的PDF文本内容，通过嵌入（Embedding）技术转化为机器可理解、可检索的向量，再结合LLM强大的理解和生成能力，实现精准的、基于语义的问答。它非常适合开发者、研究人员、学生、法律或金融从业者等任何需要频繁与大量文档打交道的人。对于开发者而言，它更是一个绝佳的学习案例，完整展示了如何构建一个端到端的、生产可用的AI应用，涵盖了文档加载、文本分割、向量化存储、语义检索以及智能体对话等多个核心环节。

2. 核心架构与设计思路拆解

要理解这个项目，我们不能只停留在“它能做什么”，更要深入“它为什么这么设计”。一个健壮的多PDF聊天应用，其架构必须同时考虑效率、准确性、成本以及用户体验。下面，我们来拆解其典型的核心设计思路。

2.1 技术栈选型：为什么是它们？

一个现代的多文档QA应用，其技术栈通常呈现清晰的层次化结构。这个项目很可能采用了类似下面的组合，而每一个选择背后都有其深思熟虑的理由。

后端与AI核心层：

• LangChain / LlamaIndex：这几乎是当前构建LLM应用的事实标准框架。它们的作用是“胶水”，将文档加载、文本处理、向量存储、LLM调用等离散的模块串联成一个完整的工作流（Pipeline）。LangChain更偏向于灵活编排，提供了大量底层的Chain和Tool供开发者组合；而LlamaIndex则对检索增强生成（RAG）场景做了深度优化，内置了更智能的索引构建和查询引擎。选择它们，能避免重复造轮子，快速实现核心逻辑。
• 大语言模型（LLM）：这是系统的大脑。开源方案如Llama 3、Qwen系列，或通过API调用的GPT-4、Claude都是可选项。选择时需权衡：本地部署的模型（如通过Ollama）数据隐私性好、无调用成本，但对硬件要求高、性能可能稍弱；云端API性能强大、功能新颖，但会产生持续费用并有数据出境考量。对于PDF问答这种对上下文长度和理解深度要求较高的任务，一个拥有强大推理能力和长上下文窗口的模型是关键。
• 文本嵌入模型（Embedding Model）：这是系统的记忆索引方式。它将每一段文本转换为一个高维向量（一组数字）。语义相近的文本，其向量在空间中的距离也更近。开源模型如BAAI/bge-large-zh（中文优）、text-embedding-ada-002（OpenAI）等都是成熟选择。嵌入模型的质量直接决定了检索的准确性，因此需要选择在目标语言（中/英文）和领域上表现良好的模型。
• 向量数据库（Vector Database）：这是存储和快速检索海量向量记忆的地方。当用户提问时，系统会将问题也转化为向量，并在向量数据库中快速找到与之最相似的文本片段（即最近邻搜索）。ChromaDB因其轻量、易用且与LangChain集成度极高，成为原型开发和中小规模项目的首选。Pinecone或Weaviate则是生产级、可扩展的云服务选择。PGVector（PostgreSQL插件）适合那些希望将向量数据与传统关系数据统一管理的团队。

前端与交互层：

• Streamlit / Gradio：对于快速构建AI应用原型，这两个框架是神器。它们允许你用纯Python代码创建出包含聊天界面、文件上传组件、按钮等元素的Web应用，无需编写HTML/CSS/JavaScript。Streamlit的响应式设计更接近传统Web应用，Gradio则更专注于机器学习演示的快速搭建。这个项目采用它们，可以极大降低前端开发门槛，让开发者专注于核心AI逻辑。

数据处理流水线：这是项目的灵魂，其设计遵循一个清晰的管道：

1. 加载（Load）：使用PyPDF2、pdfplumber或Unstructured库读取PDF文件，提取原始文本和元数据（如页码）。
2. 分割（Split）：将长文本切割成语义相对完整的小块（Chunk）。这是关键一步！分割过大，检索会包含无关信息；分割过小，会丢失上下文。通常采用“递归字符分割”结合“滑动窗口”策略，并尽量在句末或段落末分割，保证语义完整性。
3. 嵌入（Embed）：使用嵌入模型将每个文本块转化为向量。
4. 存储（Store）：将向量及其对应的原始文本、元数据（来源文件、页码）一并存入向量数据库。
5. 检索与生成（Retrieve & Generate）：用户提问 -> 将问题嵌入为向量 -> 在向量库中检索出最相关的K个文本块 -> 将这些文本块作为“上下文”与问题一起提交给LLM -> LLM生成最终答案。

注意：分割策略是影响效果的最大变量之一。对于技术文档，按章节或子标题分割可能比固定字符数分割更有效。项目中可能需要针对PDF结构进行定制化处理。

2.2 智能体（Agent）思维的融入

项目标题中的“AI-Agent”是点睛之笔，意味着它不止于简单的“检索-回答”。一个真正的智能体具备工具使用（Tool Use）和自主规划（Planning）能力。在这个项目中，智能体思维可能体现在：

• 多轮对话与记忆：能理解上下文中的指代（如“上面提到的那个方法”），维持连贯的对话历史。
• 复杂查询分解：当用户提出一个复杂问题时（如“比较A文档的方案1和B文档的方案2”），智能体可以将其分解为多个子查询：先检索A文档中关于方案1的描述，再检索B文档中关于方案2的描述，最后进行综合对比。
• 自我验证与引用：在生成答案时，强制要求引用来源（如“根据[文档A第5页]...”），提高答案的可信度和可追溯性。这可以通过在给LLM的提示词（Prompt）中严格设定输出格式来实现。
• 工具扩展潜力：智能体框架允许未来轻松扩展其他工具，例如连接网络搜索验证信息、调用计算器进行数据核算等，使其能力边界远超单个文档库。

3. 核心模块深度解析与实操要点

理解了宏观架构，我们深入到几个核心模块，看看在具体实现中会遇到哪些“坑”，以及如何避开它们。

3.1 文档处理：从PDF到向量，步步惊心

文档处理是流水线的第一步，也是地基。地基不稳，后续的检索和生成质量无从谈起。

1. 文本提取的陷阱：不是所有PDF生而平等。扫描版PDF（图片格式）需要使用OCR（光学字符识别）工具，如Tesseract，但识别准确率受图片质量影响极大。即使是文本版PDF，也可能因为复杂的排版（多栏、图表、页眉页脚、公式）导致提取文本顺序错乱。pdfplumber库在保持文本空间位置信息方面表现较好，有助于理解排版；而Unstructured库则提供了更高级的、基于AI的文档元素识别和分割功能，能更好地处理复杂文档。

实操建议：

• 对于重要项目，务必对不同类型的样本PDF进行提取测试，检查文本的完整性和顺序。
• 在提取后，添加一个文本清洗步骤，移除过多的换行符、空格和不可见字符。

import re def clean_text(text): # 合并因PDF换行导致的断句 text = re.sub(r'(\w+)-\n(\w+)', r'\1\2', text) # 将多个连续换行符替换为一个句号或空格，视情况而定 text = re.sub(r'\n+', ' ', text) # 移除多个连续空格 text = re.sub(r'\s+', ' ', text) return text.strip()

2. 文本分割的艺术：分割是RAG应用的“阿喀琉斯之踵”。固定长度分割（如每500字符一段）最简单，但很容易把一个完整的概念或句子从中间切断。

更优的策略是递归分割：

• 首先尝试按“\n\n”双换行符（段落）分割。
• 如果段落太长（如超过800字符），再尝试按句子分割器（如nltk的sent_tokenize）或标点（。！？. ! ?）进行二次分割。
• 同时，可以采用重叠（Overlap）策略。比如，每段500字符，但相邻两段之间有100字符的重叠。这能保证即使分割点不太理想，关键信息也不会被完全割裂，在检索时仍有较大概率被找到。

实操心得：

• 分块大小需要实验：对于通用文本，500-1000字符是一个常见范围。对于技术性很强、概念密集的文本，块可以小一些（如300-500字符），以确保检索精度。对于叙述性、上下文连贯的文本，块可以大一些。
• 重叠不是越大越好：通常重叠设置为块大小的10%-20%。过大的重叠会增加存储和检索的计算量，并可能在最终答案中导致信息重复。
• 保留元数据：在分割时，必须为每个文本块记录其来源（文件名）和位置（起始页码、结束页码）。这是实现答案引用的基础。

3.2 向量检索：寻找最相关的记忆

检索环节的目标是：给定一个问题，从成千上万的文本块中，快速找到最相关的那几个。

1. 相似度计算与索引：向量数据库使用近似最近邻（ANN）算法来加速搜索。ChromaDB默认使用余弦相似度。关键在于创建索引。对于生产环境，当向量数量巨大时（数十万以上），需要选择合适的索引类型（如HNSW、IVF），在召回率、速度和内存消耗之间取得平衡。

2. 检索策略的进阶：

• 简单相似性检索：直接计算问题向量与所有文本块向量的相似度，取Top-K。这是基础。
• 最大边际相关性（MMR）：这是为了优化检索结果的多样性。在选取Top-K结果时，MMR不仅考虑与问题的相似度，还考虑已选结果之间的相似度。这样可以避免返回多个高度重复的文本块，让答案的参考来源更全面。
• 元数据过滤：这是多PDF场景的利器！用户可能问：“在今年的市场报告中，关于云计算的部分说了什么？” 这里，“今年”和“市场报告”就是元数据过滤器。我们可以在检索时，先通过元数据（如文件类型、年份）筛选出一个子集，再进行向量搜索，能极大提升准确性和效率。
• 重排序（Re-ranking）：向量检索是“粗排”，可能因为语义细微差别或嵌入模型局限而漏掉关键信息。可以引入一个更精细但更耗时的“重排序”模型（如BAAI/bge-reranker-large），对向量检索返回的Top-N（N>K）个结果进行重新打分，选出最终的Top-K。这能显著提升精度，但会增加延迟。

实操配置示例（使用LangChain和Chroma）：

from langchain_community.vectorstores import Chroma from langchain_huggingface import HuggingFaceEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 初始化嵌入模型 embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5") # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", ".", "!", "?"] ) docs = text_splitter.create_documents([your_text], metadatas=[{"source": "file1.pdf"}]) # 3. 创建向量库并持久化 vectorstore = Chroma.from_documents( documents=docs, embedding=embeddings, persist_directory="./chroma_db" # 指定持久化目录 ) vectorstore.persist() # 保存到磁盘 # 4. 检索（带简单相似度） retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) relevant_docs = retriever.invoke("你的问题是什么？")

4. 智能问答与智能体实现详解

当系统拿到了最相关的文本片段（上下文）后，如何让LLM生成一个高质量、基于上下文的答案，就是提示工程和智能体逻辑的舞台了。

4.1 提示工程：如何与LLM有效沟通

给LLM的提示词（Prompt）是质量控制的核心。一个糟糕的Prompt会导致LLM忽略上下文、胡编乱造或格式混乱。

一个强大的RAG提示词模板通常包含以下部分：

你是一个专业的文档分析助手。请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题，请直接说“根据提供的资料，我无法回答这个问题”，不要编造信息。 上下文信息： {context} 问题：{question} 请用中文，以清晰、有条理的方式回答。在回答中，对于关键事实或结论，请注明其出处，格式为【文档名，第X页】。

关键点解析：

• 角色设定：让LLM进入特定角色，有助于稳定输出风格。
• 指令清晰：“严格根据...”、“如果不足以...不要编造” 这些指令是减少幻觉（Hallucination）的关键。
• 结构化上下文：将检索到的多个文本块用明确的分隔符（如---）连接，并最好在每个块前加上其元数据，便于LLM区分来源。
• 输出格式要求：明确要求引用来源，这是可追溯性的保障。

实操心得：

• 上下文长度（Token数）是硬约束：必须确保{context}和{question}的总长度不超过LLM的上下文窗口限制，并预留出足够空间给生成的答案。需要实时计算Token数（可用tiktoken库）。
• 系统提示词（System Prompt）与用户提示词分离：在OpenAI等API中，可以将固定的角色指令放在system消息中，将每次变化的上下文和问题放在user消息中，这样更清晰，也节省Token。
• 迭代优化：Prompt需要根据实际问答效果反复调试。可以准备一批测试问题，评估答案的准确性和引用规范性，不断调整Prompt的措辞。

4.2 从简单QA到智能体：赋予系统思考能力

基础版本是“一次检索，一次回答”。而智能体版本则更复杂、更强大。

1. 实现多轮对话记忆：最简单的方式是将之前的对话历史（Q&A对）也作为上下文的一部分，附加到当前问题中。但要注意，这会使Prompt迅速膨胀。更优的方案是使用LangChain的ConversationBufferMemory或ConversationSummaryMemory。后者会自动将较长的历史对话总结成一段摘要，既能保留关键信息，又节省了Token。

2. 实现复杂查询分解：这是智能体的核心能力之一。例如，用户问：“对比文档A中的方案X和文档B中的方案Y。”

• 规划（Plan）：智能体首先应规划步骤：1) 检索文档A中关于方案X的描述；2) 检索文档B中关于方案Y的描述；3) 综合两者进行对比分析。
• 执行（Act）：智能体可以调用“检索工具”分别执行步骤1和2。
• 反思（Reflect）：检查检索结果是否充分，是否需要进一步检索。
• 回答（Answer）：最后，将收集到的信息综合，生成对比答案。

在LangChain中，这可以通过AgentExecutor配合Tool和特定的Agent类型（如ReAct代理）来实现。你需要为“检索文档”这个动作定义一个Tool函数。

3. 自我验证与引用：除了在Prompt中要求，还可以在输出解析（Output Parser）阶段做强制检查。例如，定义一个ResponseSchema，要求答案必须包含一个citations字段，该字段是一个列表，每个元素包含引用的文本和来源。如果LLM的回复不符合这个格式，则要求其重试。

一个简单的智能体流程代码示意：

from langchain.agents import AgentExecutor, create_react_agent from langchain.tools import Tool from langchain.prompts import PromptTemplate from langchain_community.llms import Ollama # 假设使用本地Ollama # 1. 定义检索工具 def retrieve_docs(query: str) -> str: """根据问题检索相关文档片段。""" docs = retriever.invoke(query) return "\n\n".join([f"来源：{doc.metadata['source']}, 页码：{doc.metadata.get('page', 'N/A')}\n内容：{doc.page_content}" for doc in docs]) retrieve_tool = Tool( name="DocumentRetriever", func=retrieve_docs, description="当需要从上传的PDF文档中查找信息时，使用此工具。输入是一个清晰的问题。" ) # 2. 定义智能体提示词 agent_prompt = PromptTemplate.from_template( """你是一个文档分析智能体。你可以使用工具来获取信息。请逐步思考。 你有以下工具： {tools} 使用以下格式： 问题：用户的问题 思考：你需要思考做什么，是否需要使用工具 行动：要使用的工具，应该是[{tool_names}]中的一个 行动输入：工具的输入 观察：工具返回的结果 ... (这个思考/行动/观察循环可以重复多次) 最终答案：基于所有观察，给出最终答案。务必注明信息来源。 开始！ 历史对话：{chat_history} 问题：{input} {agent_scratchpad}""" ) # 3. 创建智能体和执行器 llm = Ollama(model="llama3") tools = [retrieve_tool] agent = create_react_agent(llm, tools, agent_prompt) agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True, handle_parsing_errors=True) # 4. 执行 result = agent_executor.invoke({"input": "对比方案X和方案Y的优缺点。", "chat_history": ""}) print(result["output"])

5. 前端应用搭建与部署考量

一个完整的项目离不开用户界面。Streamlit让这一切变得异常简单。

5.1 用Streamlit快速构建交互界面

Streamlit的核心思想是“脚本即应用”。一个基本的应用可能包含以下部分：

import streamlit as st from your_backend_logic import process_pdfs, ask_question # 假设的后端函数 st.set_page_config(page_title="多PDF智能对话助手", layout="wide") st.title("📚 多PDF文档智能对话助手") # 侧边栏：文件上传和配置 with st.sidebar: st.header("上传文档") uploaded_files = st.file_uploader("选择PDF文件", type="pdf", accept_multiple_files=True) chunk_size = st.slider("文本分割大小", 200, 1000, 500) k_value = st.slider("检索结果数量 (K)", 1, 10, 4) if st.button("处理文档并构建知识库") and uploaded_files: with st.spinner("正在处理文档，请稍候..."): # 调用后端处理函数 vectorstore = process_pdfs(uploaded_files, chunk_size) st.session_state['vectorstore'] = vectorstore # 存入会话状态 st.success(f"已成功处理 {len(uploaded_files)} 个文档！") # 主区域：聊天界面 st.header("开始对话") if 'vectorstore' not in st.session_state: st.info("请先在左侧上传并处理PDF文档。") else: # 初始化聊天历史 if "messages" not in st.session_state: st.session_state.messages = [] # 显示历史消息 for message in st.session_state.messages: with st.chat_message(message["role"]): st.markdown(message["content"]) # 接收用户输入 if prompt := st.chat_input("请输入关于文档的问题..."): # 添加用户消息到历史并显示 st.session_state.messages.append({"role": "user", "content": prompt}) with st.chat_message("user"): st.markdown(prompt) # 生成助手回复 with st.chat_message("assistant"): with st.spinner("思考中..."): # 调用后端问答函数 response, source_docs = ask_question(st.session_state['vectorstore'], prompt, k_value) st.markdown(response) # 可以折叠显示引用的来源 with st.expander("查看引用来源"): for doc in source_docs: st.caption(f"**来源：{doc.metadata['source']}** (页码：{doc.metadata.get('page', 'N/A')})") st.text(doc.page_content[:200] + "...") # 添加助手回复到历史 st.session_state.messages.append({"role": "assistant", "content": response})

这个简单的脚本就创建了一个功能完整的应用：侧边栏上传文件、调整参数，主区域进行多轮对话，并展示答案来源。

5.2 部署与性能优化

当原型开发完毕，考虑部署时，以下几点至关重要：

1. 向量库的持久化与共享：开发时，向量库可能存储在本地./chroma_db。部署时，需要考虑：

• 持久化存储卷：在Docker或云服务器中，需要将存储目录挂载到持久化卷上，否则容器重启数据会丢失。
• 共享存储：如果部署了多个应用实例（用于负载均衡），需要一个共享的向量数据库服务（如独立的Chroma服务、Pinecone或PGVector），让所有实例都能访问同一份数据。

2. 成本与延迟优化：

• 缓存：对常见问题或相似的查询结果进行缓存，可以显著降低LLM API调用成本和响应时间。
• 异步处理：文档处理（读取、分割、嵌入）是耗时操作，应使用异步任务（如Celery）在后台执行，避免阻塞Web请求。用户上传文件后，立即返回“正在处理”的提示，处理完成后再通知用户。
• LLM调用优化：选择合适的模型，在效果和成本/速度间平衡。考虑使用流式响应（Streaming）来提升用户体验，让答案逐字显示，而不是等待全部生成完毕。

3. 安全与隐私：

• 文件安全：对上传的PDF文件进行病毒扫描。设置文件大小和类型限制。
• 数据隔离：如果是多租户应用（不同用户上传不同文档），必须严格隔离他们的向量存储空间，确保用户A无法检索到用户B的文档。这可以通过在向量存储的元数据中添加user_id字段，并在检索时强制过滤来实现。
• API密钥管理：所有AI服务的API密钥必须通过环境变量或密钥管理服务获取，绝不能硬编码在代码中。

4. 容器化部署：使用Docker容器化应用是标准做法。Dockerfile需要包含所有Python依赖，并设置好工作目录和启动命令。

FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8501 CMD ["streamlit", "run", "app.py", "--server.port=8501", "--server.address=0.0.0.0"]

然后，可以使用Docker Compose或Kubernetes来编排应用、向量数据库（如果自托管）等组件。

6. 常见问题、排查技巧与扩展方向

在实际开发和运行中，你一定会遇到各种问题。下面是一些典型问题及其解决思路。

6.1 效果不佳：为什么AI答非所问或胡编乱造？

这是RAG系统最常见的问题，根源通常不在LLM，而在检索或Prompt环节。

一个实用的调试流程：

1. 隔离检索阶段：编写一个测试脚本，输入问题，直接打印出向量数据库返回的Top-K文本块及其相似度分数。直观判断检索质量。
2. 隔离生成阶段：手动构造一个“完美”的上下文（包含正确答案的文本块），连同问题发送给LLM，看它能否生成正确答案。如果能，问题在检索；如果不能，问题在Prompt或LLM本身。
3. 检查Token数：确保上下文+问题+系统指令的总长度未超过模型限制，否则模型会从尾部开始丢弃内容。

6.2 性能瓶颈：为什么应用响应慢？

• 文档处理慢：这是CPU密集型任务。解决方案：异步处理、使用更高效的解析库（如pdfplumber）、对于大规模文档预处理可以考虑分布式任务队列。
• 嵌入生成慢：嵌入模型推理是瓶颈。解决方案：使用GPU加速（如果本地部署）、选择更小的嵌入模型（权衡精度）、或直接使用API服务（如OpenAI的Embedding API，速度通常很快）。
• 向量检索慢：当向量数量超过10万时，简单线性扫描会变慢。解决方案：为向量数据库创建合适的ANN索引（如HNSW），或迁移到性能更强的专业向量数据库。
• LLM生成慢：这是主要延迟来源。解决方案：选择更快的模型（如较小的模型）、启用API的流式响应以提升感知速度、对答案进行缓存。

6.3 项目扩展方向

这个项目是一个优秀的起点，你可以在此基础上添加更多炫酷的功能：

• 混合检索（Hybrid Search）：结合关键词搜索（如BM25）和向量搜索，综合利用两者的优势。关键词搜索对精确术语匹配好，向量搜索对语义匹配好。可以将两者的搜索结果分数进行加权融合。
• 对话历史摘要：实现ConversationSummaryMemory，将长对话压缩成摘要，既能维持上下文，又节省Token。
• 多模态支持：使用多模态模型（如GPT-4V），不仅处理PDF中的文字，还能解读其中的图表、流程图，并回答相关问题。
• 智能体工具扩展：让智能体不仅能查文档，还能调用计算器、执行网络搜索（验证或获取最新信息）、甚至连接数据库查询结构化数据。
• 更友好的前端：在Streamlit中集成文档预览、高亮显示答案来源在原文中的位置、支持对话导出和分享等。

构建一个“Multi-PDFs_ChatApp_AI-Agent”就像搭建一个精密的数字大脑图书馆。从文档的摄入、消化（向量化）、索引，到理解问题、查找资料、组织语言回答，每一步都需要精心设计。这个项目完美地串联起了当前AI应用开发的核心技术栈，通过动手实现它，你不仅能获得一个强大的生产力工具，更能深入理解RAG和智能体背后的设计哲学与工程细节。在实际操作中，最大的体会是：没有一劳永逸的完美参数，分割大小、重叠比例、检索数量K、Prompt的措辞，都需要在你的具体文档和问题域上进行反复的测试和调优。从一个能跑通的简单版本开始，逐步迭代优化每一个模块，记录下每次改动对效果的影响，这个过程本身，就是积累AI工程经验的最佳途径。