佑瞻的博客

通过 Milvus 构建 RAG 管道，我们实现了从 “数据存储” 到 “智能生成” 的全流程优化。从基础的向量检索到高级的性能调优，每个环节都需要根据业务需求精细设计。随着 RAG 应用的普及，如何在检索效率与生成质量间找到平衡，将成为持续优化的核心课题。如果你在搭建过程中遇到问题，欢迎在评论区交流！

在 LlamaIndex 中，所有工具都需遵循BaseTool抽象，包含元数据（名称、描述、参数）和执行逻辑。假设我们有三个工具：python# 示例工具（代码省略具体实现）search_weather # 天气查询工具send_email # 邮件发送工具query_customer # 客户信息查询工具这些工具会在初始化 Agent 时被注册，形成可调用的 “工具字典”。我们今天实现的，本质上是大模型推理能力与工具执行能力的 “粘合剂”。

新手入门：直接用，快速验证想法逻辑严谨场景：选ReActAgent，确保每一步推理可追溯复杂流程控制：用底层 API 组合，实现定制化调度工具集优化：加入工具检索或上下文检索，提升复杂场景下的准确性作为开发者，我们只需根据项目阶段和需求复杂度，选择合适的「工具组合」。如果觉得内容对你有帮助，欢迎关注我的 CSDN 账号，后续会持续分享 LlamaIndex 性能优化、多模态工具集成等进阶技巧，让我们一起把 Agent 开发从「能用」打磨到「好用」！

简单来说，Data Agent 是能自主理解任务、规划步骤、调用工具并完成目标的 AI 程序。RAG：侧重数据检索与生成，缺乏主动规划能力Data Agent：具备三重核心能力①任务规划：通过大模型推理出完成任务的具体步骤（如 ReAct 范式的 “推理 - 行动” 循环）②工具调用：适配各类外部工具（API、函数、查询引擎等）③记忆系统：结合长期记忆（向量库）与短期记忆（对话历史）

自己实现融合检索虽然灵活，但需要处理异步任务、结果映射等细节。LlamaIndex 的帮我们封装了这些逻辑：pythonquery = "北京市有多少人口，是怎么分布的"vector_retriever = create_vector_index_retriever('北京市')kw_retriever = create_kw_index_retriever('北京市')# 一行代码创建融合检索器，支持多种重排序算法num_queries=1, # 可自定义扩展的子查询数量。

从单一文档到多文档，从简单问答到复杂知识处理，Agentic RAG 架构带来的是一种 “分层智能” 的设计思路：让底层 Agent 专注垂直领域，顶层 Agent 负责全局调度，再通过检索机制破解 “选择困难”。这种模式不仅适用于学术文档分析，在企业知识库管理、多模态数据处理等场景也有广阔应用空间。如果你正在构建需要处理大量文档的智能应用，不妨试试这种架构 —— 让 Agent 成为你的 “知识管家”，把繁琐的文档处理交给系统，专注挖掘知识背后的价值。

首先加载多份原始文档（如北京、上海的城市资料），并为每份文档设置唯一的index_id作为标识：pythondoc.metadata['index_id'] = os.path.splitext(doc.metadata['file_name'])[0] # 提取文件名作为唯一标识这一步是后续关联摘要与原始文档的基础，就像给每本书贴上独一无二的标签。使用 LlamaIndex 的生成文档级摘要，这里采用模式保留文档层次结构（适合长文档）：python。

在企业级 RAG 应用中，面对海量知识文档时，我们不能依赖简单的「分割 + 检索」模式，而是要通过「元数据过滤 + 向量检索」构建分层检索体系。这种策略就像给知识块搭建了一个「语义导航系统」，让检索过程既能理解用户问题的领域指向，又能捕捉具体内容的语义细节。如果你正在开发复杂的知识密集型应用，不妨尝试这套分层检索方案。用大模型给知识块打标分类，用向量库实现高效过滤检索。

在某些场景下，原始知识包含大量细节，而用户的问题相对概括单一。这时，我们可以采用从知识摘要扩充到知识内容的策略。通过从知识摘要扩充到知识内容和从小知识块扩充到大知识块这两种策略，我们可以在不同场景下更高效地处理和利用知识块，提升 RAG 应用的性能。希望这篇文章能对你有所帮助，

RAG 系统的优化没有 “银弹”，知识块大小的选择和阶段分离策略，本质上是在精确性、上下文、性能之间寻找动态平衡。用数据说话：通过评估框架量化不同策略的效果，避免主观判断（就像代码中用做初步筛选）。分阶段设计：检索阶段追求 “精准快”（如仅嵌入问题），生成阶段追求 “全而准”（如组装上下文或提取元数据答案）。持续迭代：企业数据环境和业务需求在变，知识块策略也要跟着变，通过自动化评估工具定期验证效果，确保系统始终处于最优状态。

在实际业务中，我们常常需要一些 "个性化标准"。比如要求 "答案必须包含具体数据"、"避免使用模糊表述" 等。这时候就派上用场了：python"答案应完全覆盖问题要点","避免使用模糊或歧义性词汇","优先使用具体数据或案例支撑观点"评估以下查询和响应是否符合指南：查询: {query}响应: {response}指南: {guideline}如果符合，输出"符合"，否则输出"不符合"。"""

当我们借助 LangChain、LlamaIndex 等框架快速搭建起 RAG 应用时，往往会沉浸在大模型带来的智能交互体验中。但别忘记，在将 RAG 应用推向生产环境之前，有一个至关重要的环节必须认真对待 —— 那就是测试与评估。这不仅是传统软件研发的必备流程，在 RAG 场景下更有着特殊的重要性。

当需要复杂逻辑时，我们可以继承，实现三个核心接口：python@propertyreturn {'response'} # 定义需要的输入参数名@propertyreturn {'output'} # 定义生成的输出参数名# 自定义逻辑：将响应解析为结构化对象cpu: strreturn {'output': output.dict()} # 必须包含_output_keys定义的键。

通过 Chroma 向量库与 LlamaIndex 的协同，我们实现了从多模态数据摄入到智能检索的完整闭环。标准化流程：图片嵌入、文档解析、索引构建均有成熟工具支持模态融合：将非结构化的图片转换为可检索的文本描述，打破模态壁垒工程友好：代码结构清晰，关键节点预留扩展接口（如模型替换、存储升级）建议开发者从简单场景入手，先尝试单模态图片检索，再逐步整合 PDF 解析功能。遇到问题时可通过 Chroma 的方法调试向量生成，或利用 LlamaIndex 的函数检查文本节点内容。

通过 DashScope 与 LlamaIndex 的协同，我们实现了从图片加载、模型交互到结果解析的完整流程。标准化设计：消息格式、图片处理流程完全遵循行业规范低代码成本：高层 API 封装复杂逻辑，代码量减少 60% 以上强扩展性：预留 OCR、多模型切换等扩展接口建议开发者在实践中重点关注消息角色的正确使用和图片预处理效果，这两个环节直接影响模型解析的准确性。如果需要处理含文本的复杂图片，可结合 LlamaIndex 的 OCR 扩展接口进一步优化输入数据。

通过上述架构与技术，我们解决了多模态文档处理中的三大核心问题：解析复杂性（工具选型）、索引低效性（差异化处理）、生成准确性（递归检索）。工具链适配：根据文档类型选择解析工具 —— 扫描件优先 Open-Parse（OCR 支持），结构化报告优先 LlamaParse（自动摘要），复杂文档优先 Unstructured（深度解析）分阶段测试：先验证单模态处理流程（如纯文本 / 纯表格文档），再逐步集成多模态场景元数据管理：重视表格结构、图片摘要等元数据的生成质量，这直接影响检索精度性能优化。

如何让不同技术栈的组件协同工作，以及如何高效处理结构化数据。用实现多引擎的智能调度用解决大模型上下文溢出问题通过支持复杂问题的多源信息融合这些技术并非孤立存在，实际项目中我们可以组合使用：比如先用语义路由选择 SQL 查询引擎，再通过智能检索定位目标表，最后生成 SQL 并返回结果。关键是根据具体场景选择合适的组件，让系统像路由器一样自动匹配最优处理路径。如果你在开发中遇到多引擎协同或结构化数据查询的难题，欢迎在评论区交流。觉得内容有帮助的话，，后续我们会分享更多企业级应用的优化技巧～

节点后处理器是一种能对检索出的节点进行转换、过滤或重排序等操作的组件。它通常在查询引擎内使用，工作顺序是在检索器之后、响应生成器之前。若内置的节点后处理器无法满足需求，我们还能自定义。自定义的节点后处理器要从组件派生，并通过接口实现具体逻辑。示例代码如下：pythonimport repattern = r"过滤正则表达式"在这个自定义处理器中，我们使用正则表达式过滤掉包含特定模式的节点。

检索前的查询转换，本质上是在构建用户问题与知识库之间的 “翻译层”。通过简单改写、假设性生成、多步分解、工具约束等不同策略，我们可以让系统更智能地理解用户意图，从而实现更精准的知识召回。这些技术并非孤立存在，实际项目中我们可以组合使用：比如先用 HyDE 生成假设性嵌入提升召回，再通过多步分解实现答案的逻辑整合。关键是根据具体场景选择合适的转换策略，让查询转换成为 RAG 系统的智能起点。如果你在实际开发中遇到查询转换的难题，欢迎在评论区交流。

python。

合并节点适应上下文窗口多节点时并行生成子答案递归合并直至生成唯一结论这种树形结构让它在处理长文本总结时表现优异，比如文献综述或报告归纳。LlamaIndex 的响应生成器就像一个智能的上下文编排器，通过不同策略将检索结果转化为优质答案。掌握这些模式的核心差异和参数配置，能让我们在构建智能系统时更精准地控制输出效果。如果你在实践中遇到具体问题，欢迎在评论区交流 ——，后续我们会带来更多 LlamaIndex 核心组件的深度解析！关注我，获取更多 AI 开发干货，一起解锁智能系统构建的底层逻辑～

先对输入的 node 在 document 级别生成摘要 node，并做嵌入与索引，检索时先查询相关的摘要 node，再溯源到对应的基础 node 返回。llm：使用大模型判断摘要内容与输入问题的相关性，获得最相关的摘要 node，然后输出对应的基础 node。对应的检索器类型为，参数有（使用大模型判断摘要相关性的 prompt 模版）、（选择相关的摘要 node 数量，注意不是返回的 node 数量）。embedding。

当我们处理法律条文、研究报告等长文档时，直接检索成百上千的基础节点效率太低。这时候 ** 文档摘要索引（DocumentSummaryIndex）** 就派上用场了 —— 它会先让大模型生成文档的摘要节点，就像给知识加了个 “目录页”，我们先在摘要层检索，再定位到具体内容。从向量存储的 “语义指纹” 到知识图谱的 “关系网络”，每种索引都有其独特的应用场景。LlamaIndex 通过统一的接口设计，让我们能轻松组合这些技术，无论是处理纯文本、结构化数据还是复杂关系，都能找到最优解。

python# 定义自定义处理器my_splitter = SentenceWindowNodeParser(window_size=2) # 按每2句话分割my_extractor = TitleExtractor() # 提取标题元数据# 通过transformations管道应用处理docs,这里的就像数据处理流水线，会依次执行文本分割和元数据提取，确保进入索引的 node 符合我们的格式要求。

开发者可根据需求扩展转换器，例如实现文本清洗、格式转换等功能，只需遵循__call__方法的输入输出规范即可无缝接入管道。数据摄取管道是 LLamaIndex 框架中实现高效知识处理的核心模块，通过标准化的转换器接口与灵活的配置机制，让开发者能够快速构建可扩展的数据处理流程。无论是小规模原型开发还是大规模知识库建设，合理利用管道的并行处理与缓存机制，都能显著提升开发效率。如果本文对您理解 LLamaIndex 数据处理流程有帮助，欢迎，后续将分享更多关于向量存储、检索优化的实战经验。关注作者。

在自然语言处理和知识检索领域，数据的处理和组织方式对系统的性能和效果起着至关重要的作用。当我们使用 LlamaIndex 框架时，将不同来源的文档加载并提取成document对象后，还需要对其进一步解析与分割，形成更小粒度的数据块，即node对象。那么，为什么不直接使用document对象作为索引与检索的单位呢？尽管较大的数据块能携带更完备的内容与语义信息，但会降低检索时召回数据块的精确性。这就好比在关系型数据库中把所有数据都存储在一条记录里，会影响后续响应生成的质量。因此，对document。

有时候，我们可能需要处理一些特殊格式的文档，比如.psql文档，其中存储了 PostgreSQL 数据库的执行语句。这时，我们可以自定义一个阅读器来读取并执行这些 SQL 语句。python在这个自定义阅读器中，PSQLReader类继承自BaseReader类。__init__方法用于初始化对象，load_data方法用于读取文件内容并执行其中的 SQL 语句，将执行结果作为文本生成 Document 对象。*args用于接收位置参数，**kwargs用于接收关键字参数。表示参数的类型可以是字典或者。

在 LlamaIndex 中，Document 类型的对象可以看作是一个通用的不同来源的数据容器。它能够容纳来自文档、数据库或者企业级应用系统中的数据。通过 Document 对象，我们可以方便地将各种数据源整合到一起，为后续的处理和分析提供统一的接口。Node 类型的对象可以想象成对应的 Document 对象分割后的一个块。在 LlamaIndex 中，Node 类型来自basenode基类，有 4 种 Node 类型，分别是 text、image、document 和 index 索引 Node。

通过本文的介绍，我们了解了如何在 LlamaIndex 中集成 LangChain 支持的大模型，以及如何使用和定制个性化的 Prompt 模板。合理使用 Prompt 模板可以让大模型更好地理解我们的需求，提高回答的准确性和质量。在实际应用中，我们可以根据具体的任务和场景，灵活运用这些技巧，打造出更强大的大模型应用。希望本文对你有所帮助，如果你有任何问题或建议，欢迎在评论区留言讨论。

实现一个大模型组件，通常需要实现几个关键接口，以支持获取元数据、文本预测与对话、流式与非流式输出以及同步与异步操作。这些接口的实现可以让我们的自定义组件与 LlamaIndex 框架中的其他模块无缝集成。通过本文的介绍，我们学习了如何使用 LlamaIndex 框架实现一个自定义的大模型组件，并掌握了一些 Python 编程技巧。自定义大模型组件可以让我们更好地集成不同的大模型，提高开发效率和灵活性。在未来的工作中，我们可以进一步扩展这个组件，支持更多的功能，如异步操作、对话管理等。

三大核心功能，帮助开发者实现 RAG 系统的可观测性。本文将以 LlamaIndex 为框架，结合 Langfuse 平台，深入解析企业级 RAG 系统的监控实现与优化策略。Langfuse 作为 LLM 应用的全链路监控平台，通过。

组件优势适用场景Ollama本地部署、模型丰富中小型企业 / 个人开发者Chroma轻量级、支持 HTTP 接口快速原型开发LangChain标准化组件、生态完善复杂 RAG 系统开发。

本文通过 LlamaIndex 与 ChromaDB 的深度集成，完整呈现了 RAG 应用的开发流程。细粒度文本分割技术提升检索精度HNSW 索引优化向量查询性能Ollama 模型的本地部署与成本控制生产级系统的架构设计与监控体系随着向量数据库与大模型技术的不断演进，未来可探索多模态数据融合、实时数据更新、智能体协同等高级功能。建议关注 LlamaIndex 的LlamaParse文档解析工具和蚂蚁集团的 VSAG 向量索引库，这些新技术将进一步提升 RAG 应用的可靠性与效率。

集合类似于关系型数据库中的表。get_collection这个代码是用来获取集合的，这里写入之前嵌入时的集合名，也可以用get_or_create_collection方法获取集合（如果存在），否则创建集合。4.这里使用一个交互式的查询程序，借助向量库查询到向量后将其作为上下文添加到大模型的prompt中，这是rag大模型应用的经典查询方法。3.引入ollama并且获取配置的开源大模型和嵌入模型。1.创建chroma客户端并且获取要查询的集合。2.获取集合中的前10条数据。

本文通过完整的代码示例和行业案例，详细讲解了如何利用 Chroma 和 Ollama 构建本地知识库系统。关注我，获取更多 AI 工程化实践经验！

pythonraise ValueError('一个句子至少要有2个Chunk！')raise ValueError("overlap 参数必须大于等于0，且小于sentence_per_chunk")函数表示要分割的源文本，类型为字符串；表示每个知识块包含的句子数量；overlap表示知识块之间的重叠部分。函数使用进行类型提示，表明该函数的返回值是一个字符串列表。代码对和overlap进行了参数检查，如果参数不符合要求，会抛出ValueError异常。

通过上述代码和解释，你已经学会了如何使用 Python 加载和读取纯文本文件。这个函数不仅可以帮助你处理本地文件，还可以作为基础代码，扩展到更复杂的文档处理场景中。

访问大模型有两种方式，一种即通过商业API的形式访问大模型，另一种是开源大模型，可以下载到本地部署后使用，不管是开发LLM应用还是调试都非常的方便。大模型的选择非常的多，在LLM应用开发中，可能会涉及到多个外部模型的调用，包括大模型和嵌入模型等，这里推荐本地模型运行与推理的管理工具Ollama。4）运行ollama list命令查看当前ollama下载的模型，运行ollama run 命令选择模型进行服务重启。2）根据硬件配置与需要选择模型后，拷贝模型的命令，在本地终端中执行，见下图红框。