ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

基于RAG与LangChain构建智能文本分析系统:以《堂吉诃德》为例

2026/9/2 11:05:54 拓冰建站 浏览量
基于RAG与LangChain构建智能文本分析系统:以《堂吉诃德》为例 1. 这篇文章真正要解决的问题当“菲宝读《堂吉诃德》第三十三章”这个标题出现在技术社区时很多开发者可能会感到困惑这看起来像是一个文学分享和技术有什么关系这正是本文要解决的核心问题——如何将看似非技术的内容转化为一个可复现、可扩展、且极具技术价值的项目实践。我们真正要探讨的不是文学评论而是如何利用现代AI技术特别是大语言模型对经典文本进行深度、结构化的解析与交互式学习。想象一下你正在开发一个教育类应用、一个智能读书助手或者一个需要理解复杂长文本的Agent。你的核心挑战是如何让AI不只是“读完”一本书而是能像一位资深读者一样理解章节间的关联、角色的成长弧光、以及文本背后的深层隐喻更进一步如何将这种理解封装成一个可调用的服务或工具“菲宝读《堂吉诃德》”就是一个绝佳的切入点。《堂吉诃德》作为西方文学巨著结构庞大人物复杂讽刺与哲理并存。第三十三章“公爵夫人与侍女们的恶作剧以及值得铭记和传颂的其他事情”更是情节转折、人物性格集中展现的一章。通过拆解如何让“菲宝”可以是一个AI助手、一个智能体去“读”这一章我们将完整走通以下技术链路文本预处理与向量化如何处理长篇、非结构化的原始文本将其转化为机器可理解、可检索的格式。上下文理解与摘要生成如何让AI提炼章节核心事件、人物关系与情感变化而不仅仅是复述。深度问答与推理如何实现基于章节内容的问答让AI能回答“为什么公爵夫人要戏弄堂吉诃德”这类需要推理的问题。知识关联与扩展如何将本章内容与全书主线、历史背景、文学手法相关联构建网状知识。工程化与API封装如何将上述能力打包成一个服务供其他应用调用。本文的目标读者是希望将大语言模型应用于垂直领域如教育、数字人文、内容分析的中高级开发者、对RAG检索增强生成和智能体开发感兴趣的技术人员以及任何想超越简单Chat对话构建深度文本理解系统的工程师。你将获得一套从数据准备到服务部署的完整方法论和可运行的代码示例。2. 核心概念与技术选型在开始构建之前我们需要明确几个核心概念并做出合理的技术选型。这决定了项目的技术栈和最终效果的上限。1. RAG (检索增强生成)这是本项目的基石。传统的大语言模型LLM有上下文长度限制和“幻觉”问题。RAG通过将外部知识库这里是《堂吉诃德》文本向量化存储在回答问题时先检索最相关的文本片段再将片段与问题一起交给LLM生成答案。这极大地提升了答案的准确性和依据性。对于“读”一本书RAG是让AI“引经据典”的关键。2. 嵌入模型与向量数据库嵌入模型负责将文本转换为高维向量 embeddings。这个向量的几何关系能反映文本的语义相似度。例如“骑士”和“侠客”的向量距离应该很近。我们选择text-embedding-ada-002或开源的BGE-M3、multilingual-e5-large模型它们对文学文本有较好的语义捕捉能力。向量数据库用于高效存储和检索这些向量。ChromaDB轻量易用适合快速原型Qdrant或Weaviate性能更强适合生产环境。本项目将以ChromaDB为例。3. 大语言模型负责最终的推理、摘要和答案生成。我们将使用 OpenAI 的 GPT-4 或 GPT-3.5-Turbo 作为核心引擎因其在理解和生成复杂语言方面表现优异。同时也会介绍如何兼容开源模型如DeepSeek、Qwen的 API。4. 智能体框架为了模拟“菲宝”这个有“阅读”行为的智能体我们可以引入智能体框架如LangChain或LlamaIndex。它们提供了连接LLM、向量数据库、工具链的高层抽象能让我们用更简洁的代码组织“检索-分析-回答”的流程。本项目将使用LangChain进行演示。5. 文本分块策略这是容易被忽视但至关重要的一环。如何把一整章文本切分成块按句子按段落按固定字符数糟糕的分块会割裂语义导致检索失效。对于小说章节建议按“语义连贯性”分块例如以一个完整的事件或对话场景为单位。我们将使用LangChain的RecursiveCharacterTextSplitter并配置合适的分隔符和块大小。技术选型总结表组件推荐选项备选方案在本项目中的作用嵌入模型OpenAItext-embedding-3-smallBAAIBGE-M3将文本转化为语义向量向量数据库ChromaDB (本地)Qdrant (Docker)存储和快速检索文本向量大语言模型OpenAI GPT-4/3.5-Turbo通义千问、DeepSeek API执行摘要、问答、推理等核心任务开发框架LangChainLlamaIndex编排整个RAG流程简化代码编程语言Python 3.9-主要开发语言3. 环境准备与依赖安装我们将在一个干净的 Python 虚拟环境中进行。确保你的系统已安装 Python 3.9 或更高版本。步骤1创建并激活虚拟环境# 创建虚拟环境 python -m venv venv_filibao # 激活虚拟环境 # 在 Windows 上 venv_filibao\Scripts\activate # 在 macOS/Linux 上 source venv_filibao/bin/activate步骤2安装核心依赖创建一个requirements.txt文件内容如下langchain0.1.0 langchain-openai0.0.2 langchain-community0.0.10 chromadb0.4.22 tiktoken0.5.1 python-dotenv1.0.0 beautifulsoup44.12.2 # 可选用于从网页抓取文本 requests2.31.0 # 可选然后使用 pip 安装pip install -r requirements.txt步骤3配置 API 密钥本项目需要 OpenAI API 密钥。强烈建议通过环境变量管理避免密钥硬编码在代码中。在项目根目录创建.env文件。在.env文件中写入OPENAI_API_KEY你的_OpenAI_API_密钥安装python-dotenv以便在代码中加载这个文件。步骤4准备源文本我们需要《堂吉诃德》第三十三章的纯文本。你可以从古登堡计划等公版书网站获取。假设我们将文本保存为don_quixote_chapter_33.txt并放在项目根目录下。 文本开头大致如下示例第三十三章 公爵夫人与侍女们的恶作剧以及值得铭记和传颂的其他事情 堂吉诃德在公爵府邸受到了极其隆重而又充满讽刺的款待。公爵和公爵夫人表面上将他奉为上宾实则将他当作取乐的小丑。这一章详细描述了公爵夫人和她的侍女们如何设计一系列精巧而又残忍的恶作剧来捉弄深信不疑的堂吉诃德和桑丘·潘沙...注意请确保你使用的文本编码是 UTF-8。4. 文本预处理与向量知识库构建这是给“菲宝”准备“大脑”的关键一步。我们将把原始文本进行清洗、分块然后转化为向量存入数据库。步骤1加载与清洗文本# 文件路径src/ingest.py import os from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma from dotenv import load_dotenv # 加载环境变量 load_dotenv() def create_knowledge_base(text_path: str, persist_directory: str ./chroma_db): 从文本文件创建向量知识库 :param text_path: 文本文件路径 :param persist_directory: 向量数据库持久化目录 # 1. 加载文档 print(f正在加载文档: {text_path}) loader TextLoader(text_path, encodingutf-8) documents loader.load() print(f文档加载成功共 {len(documents)} 个文档对象。) # 2. 分割文本 # 对于小说章节按段落分割比按固定字符数更合理 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个块的最大字符数 chunk_overlap50, # 块之间的重叠字符数保持上下文连贯 separators[\n\n, \n, 。, , , , , , ] # 中文分隔符优先 ) print(正在分割文本...) splits text_splitter.split_documents(documents) print(f文本分割完成共得到 {len(splits)} 个文本块。) # 打印前两个块看看效果 for i, split in enumerate(splits[:2]): print(f\n--- 块 {i} (长度{len(split.page_content)}) ---) print(split.page_content[:200] ...) # 3. 初始化嵌入模型 embeddings OpenAIEmbeddings( modeltext-embedding-3-small, openai_api_keyos.getenv(OPENAI_API_KEY) ) # 4. 创建向量存储并持久化 print(f\n正在生成向量并存入数据库路径: {persist_directory}...) vectordb Chroma.from_documents( documentssplits, embeddingembeddings, persist_directorypersist_directory ) # 显式持久化Chroma 有时不会自动保存 vectordb.persist() print(向量知识库构建完成) return vectordb if __name__ __main__: # 运行构建流程 kb create_knowledge_base(don_quixote_chapter_33.txt)关键点解释RecursiveCharacterTextSplitter会尝试按分隔符列表优先顺序进行分割直到块大小符合要求。我们调整了分隔符顺序以适配中文标点。chunk_overlap设置重叠可以防止一个完整的句子或关键信息被割裂到两个块中。Chroma.from_documents方法完成了向量化的核心工作为每个文本块调用嵌入模型并将结果向量存储到本地chroma_db目录。步骤2运行脚本构建知识库在终端执行python src/ingest.py如果一切顺利你将看到控制台输出分割的文本块信息并在项目根目录下生成一个chroma_db文件夹里面就是“菲宝”关于这一章的记忆了。5. 实现“菲宝”的核心问答能力现在我们将创建一个问答链。这是“菲宝”能够回答问题的核心。# 文件路径src/qa_chain.py import os from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings from langchain.prompts import PromptTemplate from dotenv import load_dotenv load_dotenv() class QuixoteReader: 堂吉诃德章节阅读器菲宝的核心 def __init__(self, persist_directory: str ./chroma_db): # 1. 加载已构建的向量数据库 embeddings OpenAIEmbeddings( modeltext-embedding-3-small, openai_api_keyos.getenv(OPENAI_API_KEY) ) self.vectordb Chroma( persist_directorypersist_directory, embedding_functionembeddings ) # 2. 将向量数据库转换为检索器设置相似度最高的前3个结果 self.retriever self.vectordb.as_retriever(search_kwargs{k: 3}) # 3. 定义提示词模板引导LLM基于检索到的内容回答 self.qa_prompt PromptTemplate( input_variables[context, question], template你是一个专业的文学分析助手“菲宝”专门研究《堂吉诃德》。请严格根据以下提供的文本片段来回答问题。如果提供的文本不足以回答问题请直接说“根据原文无法确定答案”不要编造信息。 相关文本 {context} 问题{question} 基于上述文本的答案 ) # 4. 初始化大语言模型 self.llm ChatOpenAI( modelgpt-3.5-turbo, temperature0.1, # 低温度使输出更确定更贴近原文 openai_api_keyos.getenv(OPENAI_API_KEY) ) # 5. 创建检索问答链 self.qa_chain RetrievalQA.from_chain_type( llmself.llm, chain_typestuff, # 将所有检索到的文档“塞”进上下文 retrieverself.retriever, chain_type_kwargs{prompt: self.qa_prompt}, return_source_documentsTrue # 返回来源文档便于追溯 ) def ask(self, question: str): 向菲宝提问 print(f\n 菲宝思考中... 问题: 「{question}」) result self.qa_chain.invoke({query: question}) answer result[result] sources result[source_documents] print(f 菲宝的回答\n{answer}\n) print( 回答依据的原文片段) for i, doc in enumerate(sources): print(f 片段 {i1}: {doc.page_content[:150]}...) # 预览片段前150字符 return answer, sources if __name__ __main__: # 初始化阅读器 reader QuixoteReader() # 进行测试问答 test_questions [ 公爵夫人为什么要戏弄堂吉诃德, 桑丘·潘沙在这一章里有什么表现, 这一章里提到了哪些恶作剧 ] for q in test_questions: reader.ask(q) print(- * 50)关键点解释RetrievalQA是 LangChain 提供的标准链它封装了“检索-组合-提问-生成答案”的流程。chain_typestuff是最简单直接的方式将所有检索到的文档内容合并后送入LLM。对于单章内容这通常够用。如果处理整本书可能需要用map_reduce或refine等更复杂的方式。提示词工程我们设计的提示词强制要求模型基于提供的上下文({context})回答并明确告知不要胡编乱造。这是控制LLM“幻觉”保证答案忠实于原文的关键。return_source_documentsTrue让我们能追溯答案的来源这对于验证答案可信度和调试至关重要。6. 运行结果与效果验证运行python src/qa_chain.py你将看到类似以下的输出 菲宝思考中... 问题: 「公爵夫人为什么要戏弄堂吉诃德」 菲宝的回答 根据提供的文本公爵夫人戏弄堂吉诃德主要是为了打发时间从堂吉诃德荒诞的骑士言行和桑丘·潘沙滑稽的对话中取乐。公爵夫妇将堂吉诃德主仆二人视为提供消遣的“奇观”通过精心设计的恶作剧来验证堂吉诃德是否真的如传说中那样疯狂和执着同时也为了满足他们及其府邸上下人员的好奇心和娱乐需求。 回答依据的原文片段 片段 1: ...公爵和公爵夫人表面上将他奉为上宾实则将他当作取乐的小丑。这一章详细描述了公爵夫人和她的侍女们如何设计一系列精巧而又残忍的恶作剧来捉弄深信不疑的堂吉诃德和桑丘·潘沙... 片段 2: ...公爵夫人对侍女们说“我们得找点乐子这位骑士和他的侍从可比任何喜剧都有趣。”她们策划着如何让堂吉诃德相信一些完全虚构的骑士冒险... 片段 3: ...其根本动机源于贵族阶级的无聊与傲慢他们将底层人物的真诚与理想视为可供消遣的玩物... -------------------------------------------------- 菲宝思考中... 问题: 「桑丘·潘沙在这一章里有什么表现」 菲宝的回答 在这一章中桑丘·潘沙的表现凸显了他的务实、贪婪与天真。他一方面对公爵府上的奢华款待感到欣喜若狂喋喋不休地讲述他对自己未来“海岛总督”职位的憧憬和治理规划表现出对权力和财富的渴望。另一方面他同样落入了公爵夫人设计的恶作剧圈套例如被哄骗去完成一些荒唐的任务但他比起堂吉诃德多了一份底层农民的狡黠和怀疑偶尔会嘀咕这些贵族老爷夫人是否在拿他们开心但最终又往往被美食和承诺所征服。他的言行与堂吉诃德的理想主义形成了鲜明对比。 回答依据的原文片段 片段 1: ...桑丘·潘沙则对宴席上的美食赞不绝口他悄悄对堂吉诃德说“大人这日子可比咱们风餐露宿强多了要是能一直这样当不当总督我都乐意。”... 片段 2: ...当公爵夫人询问他如何治理海岛时桑丘立刻滔滔不绝地讲起他的“施政纲领”包括税收、民生、司法等其内容充满民间智慧却又滑稽可笑... 片段 3: ...侍女们骗桑丘说后花园的喷泉是“魔泉”喝了能增长智慧桑丘将信将疑但还是喝了一大口嘟囔道“要是能让我更聪明点好管好我的海岛喝一桶也行。”...效果验证答案相关性菲宝的回答紧密围绕问题并从提供的原文片段中提取了关键信息。答案综合性它不是简单地复制一个句子而是综合了多个片段的信息进行了概括和总结如桑丘的“务实、贪婪与天真”。依据可追溯每个答案下面都列出了来源片段你可以快速核对答案是否“有据可查”。这是RAG系统可信度的核心体现。拒绝幻觉你可以尝试问一个本章节绝对没有涉及的问题例如“堂吉诃德在这一章里杀了多少巨人”。一个良好的提示词和RAG系统应该回答“根据原文无法确定答案”或类似表述而不是编造一个数字。7. 扩展功能章节摘要与角色分析一个只会问答的“菲宝”还不够。我们可以扩展它的能力让它主动提供章节摘要和角色分析。# 文件路径src/advanced_analysis.py from langchain.chains import LLMChain from langchain.prompts import ChatPromptTemplate, HumanMessagePromptTemplate from langchain_core.messages import SystemMessage from src.qa_chain import QuixoteReader # 导入之前定义的阅读器 class AdvancedQuixoteAnalyzer(QuixoteReader): 扩展的阅读分析器 def __init__(self, persist_directory: str ./chroma_db): super().__init__(persist_directory) # 专门用于摘要和分析的LLM链可以使用更强的模型 self.analysis_llm ChatOpenAI( modelgpt-4, # 使用GPT-4进行更复杂的分析 temperature0.2, openai_api_keyos.getenv(OPENAI_API_KEY) ) def generate_summary(self): 生成章节摘要 # 首先检索本章最具代表性的几个片段例如检索一个空或宽泛的问题 representative_docs self.retriever.get_relevant_documents(本章主要内容) combined_context \n\n.join([doc.page_content for doc in representative_docs[:5]]) # 取前5个 prompt ChatPromptTemplate.from_messages([ SystemMessage(content你是一位文学教授请为以下小说章节撰写一段简洁、准确、生动的摘要突出核心情节和人物关系。), HumanMessagePromptTemplate.from_template(章节内容片段\n{context}\n\n请撰写摘要) ]) chain LLMChain(llmself.analysis_llm, promptprompt) summary chain.run(contextcombined_context) return summary def analyze_character(self, character_name: str): 分析特定角色在本章中的表现 # 检索与角色相关的所有片段 character_docs self.retriever.get_relevant_documents(character_name) if not character_docs: return f在第三十三章中未找到关于角色{character_name}的显著描述。 combined_context \n\n.join([doc.page_content for doc in character_docs]) prompt ChatPromptTemplate.from_messages([ SystemMessage(content你是一位文学评论家。请根据提供的文本分析指定角色在特定章节中的行为、动机、性格特点及其与其他角色的关系。), HumanMessagePromptTemplate.from_template(角色{character}\n相关文本\n{context}\n\n角色分析) ]) chain LLMChain(llmself.analysis_llm, promptprompt) analysis chain.run(charactercharacter_name, contextcombined_context) return analysis def compare_characters(self, char1: str, char2: str): 比较两个角色在本章中的异同 # 为两个角色分别检索上下文 docs_char1 self.retriever.get_relevant_documents(char1) docs_char2 self.retriever.get_relevant_documents(char2) context_char1 \n.join([doc.page_content for doc in docs_char1[:3]]) context_char2 \n.join([doc.page_content for doc in docs_char2[:3]]) prompt ChatPromptTemplate.from_messages([ SystemMessage(content你是一位敏锐的文学分析者。请对比以下两个角色在给定章节中的表现聚焦于他们的动机、行为和对情节的作用。), HumanMessagePromptTemplate.from_template( 章节堂吉诃德第三十三章\n 角色A「{char1}」的相关描述\n{ctx1}\n\n 角色B「{char2}」的相关描述\n{ctx2}\n\n 请对比分析角色A与角色B ) ]) chain LLMChain(llmself.analysis_llm, promptprompt) comparison chain.run(char1char1, char2char2, ctx1context_char1, ctx2context_char2) return comparison if __name__ __main__: analyzer AdvancedQuixoteAnalyzer() print(*60) print( 章节摘要生成中...) summary analyzer.generate_summary() print(f摘要\n{summary}\n) print(*60) print( 角色分析堂吉诃德) analysis_dq analyzer.analyze_character(堂吉诃德) print(f{analysis_dq}\n) print(*60) print(⚖️ 角色对比堂吉诃德 vs 桑丘·潘沙) comparison analyzer.compare_characters(堂吉诃德, 桑丘) print(comparison)运行此脚本你将得到一段连贯的章节摘要而非简单的事实罗列。对堂吉诃德在本章中的深度分析涵盖其行为、处境和讽刺意味。堂吉诃德与桑丘的对比分析突出主仆二人在面对捉弄时的不同反应从而揭示作品的核心矛盾之一理想主义与实用主义。8. 常见问题与排查思路在构建和运行“菲宝”的过程中你可能会遇到以下问题问题现象可能原因排查方式解决方案运行ingest.py时报错OpenAIError1. API密钥未设置或错误。2. 网络问题导致无法连接OpenAI。1. 检查.env文件中的OPENAI_API_KEY。2. 在Python中运行import os; print(os.getenv(‘OPENAI_API_KEY’))验证。3. 尝试ping api.openai.com。1. 确保密钥正确且有效。2. 检查网络代理设置如需。3. 确认OpenAI账户有额度。向量数据库构建成功但问答时检索不到相关内容1. 文本分块策略不合理块太大或太小。2. 检索器返回的结果数量k设置过小。3. 嵌入模型对中文语义捕捉不佳。1. 打印检索到的源文档 (source_documents)看内容是否与问题相关。2. 调整ingest.py中的chunk_size和chunk_overlap。3. 在qa_chain.py中增大search_kwargs{“k”: 5}。1. 对于小说尝试chunk_size300-800,overlap50-100。2. 将k增加到 5 或 7。3. 考虑更换为针对中文优化的嵌入模型如BGE-M3。答案看起来是编造的与原文不符1. 提示词 (PromptTemplate) 约束力不够。2. LLM的temperature参数过高。3. 检索到的上下文本身不相关或不足。1. 检查提示词中是否包含“严格根据以下文本”等强约束语句。2. 将temperature调低至 0.1 或 0。3. 查看source_documents确认检索质量。1. 强化提示词明确要求“不知道就说不知道”。2. 降低temperature。3. 优化检索环节见上一条。处理长文本时LLM返回超出上下文长度错误chain_type“stuff”将所有检索到的文档拼接到一起可能超出模型令牌限制。计算检索到的所有文档内容的总字符数或令牌数。1. 减少检索数量k。2. 使用chain_type“map_reduce”或“refine”它们能处理更长的文档。3. 对检索到的文档进行二次摘要压缩后再送入LLM。运行速度很慢1. 每次问答都重新计算嵌入如果配置错误。2. 使用了大型开源嵌入模型本地推理。3. 网络延迟高。1. 确认向量数据库已持久化且问答时是从磁盘加载。2. 检查是否在循环中重复初始化嵌入模型。1. 确保Chroma(persist_directory…)只加载一次。2. 对于原型使用OpenAI的嵌入API通常比本地运行大模型更快。3. 考虑异步调用或缓存常见问题的答案。9. 最佳实践与工程化建议要将“菲宝”从一个脚本升级为一个可靠的服务或产品组件需要考虑以下几点1. 数据预处理规范化文本清洗建立标准的清洗流程去除无关的页眉页脚、注释、特殊字符。分块策略调优针对不同体裁小说、论文、新闻设计不同的分块策略。可以尝试语义分割模型而不是简单的递归字符分割。元数据附加在分块时为每个块附加元数据如章节号、页码、角色等。这可以实现更精准的过滤检索例如“只检索与‘桑丘’相关的第三十三章内容”。2. 检索策略优化混合搜索结合语义搜索向量检索和关键词搜索如BM25。LangChain的EnsembleRetriever可以轻松实现能同时保证召回率和精确率。重排序初步检索出较多结果如10个后使用一个更小的、专注于相关性的模型对结果进行重排序将最相关的3个送入LLM提升答案质量。元数据过滤利用附加的元数据在检索时进行过滤确保上下文来源的准确性。3. 提示词工程与模型管理提示词模板化将不同任务摘要、问答、分析的提示词存储在配置文件或数据库中便于管理和A/B测试。模型降级与回退在生产环境中可以设置策略优先使用GPT-4进行复杂分析若失败或超时则自动降级到GPT-3.5-Turbo进行问答。同时可以集成开源模型作为备选。流式输出对于Web应用使用LLM的流式响应接口给用户更即时的反馈。4. 系统架构与部署服务化使用 FastAPI 或 Flask 将核心功能封装成RESTful API。# 示例FastAPI 端点 from fastapi import FastAPI, HTTPException app FastAPI() analyzer AdvancedQuixoteAnalyzer() # 注意全局变量启动时加载 app.post(“/api/ask”) async def ask_question(question: str): try: answer, sources analyzer.ask(question) return {“answer”: answer, “sources”: [doc.page_content for doc in sources]} except Exception as e: raise HTTPException(status_code500, detailstr(e))向量数据库独立部署对于大规模应用将ChromaDB或Qdrant部署为独立服务与应用解耦。缓存对常见问题如“本章摘要”的答案进行缓存减少对LLM和向量数据库的调用提升响应速度并降低成本。5. 监控与评估日志记录详细记录用户的每一个问题、检索到的片段、生成的答案以及耗时。这是后续优化和排查问题的依据。评估指标设计评估方法。对于问答可以采用“人工评估答案相关性”或“基于标准答案的自动评分”。对于摘要可以使用ROUGE等指标。持续评估是迭代系统的基础。通过以上步骤你已经不仅仅是让“菲宝”读了一章《堂吉诃德》而是构建了一个可扩展、可评估的垂直领域文本深度理解系统原型。这套方法论可以无缝迁移到分析技术文档、法律条文、学术论文、会议纪要等任何需要深度理解和交互式问答的场景中。