大模型RAG“翻车“?原来是分块没做好!小白程序员必看的分块秘籍,让你的AI应用准确率飙升300%

大模型应用开发实战地图:RAG与AI Agent工程落地指南 大语言模型(LLM)应用开发的核心挑战,早已从模型能力转向真实业务场景中的工程化落地。RAG(检索增强生成)与AI Agent并非孤立技术,而是解决数据异构、语义对齐、动态决策等接口层问题的关键范式。其技术价值在于将非结构化文档、多源系统与业务规则转化为可检索、可编排、可审计的知识执行流。典型应用场景涵盖智能客服、企业知识库、代码助手及合规审查等垂直领域。本文基于87个高星开源项目深度实践,聚焦RAG知识库构建的7大生死关与AI Agent任务分解的state machine设计,提供从文档切块、向量索引、 阅读详情

如果你正在构建基于大语言模型(LLMs)的 AI 应用,那么用你的特定数据来“锚定”生成的文本响应,是获得准确答案的关键。检索增强生成(RAG) 将大语言模型与外部知识源(如向量数据库)连接起来。这使得模型在生成回复之前能够找到相关的事实依据。检索过程的质量是影响应用程序性能的最大因素之一。许多开发者专注于挑选合适的向量数据库或嵌入模型(Embedding Model),但最重要的一步往往是你如何准备数据本身。

这就是分块(Chunking) 发挥作用的地方。

接下来,我们将回顾一些基本的分块策略,从基础到高级技术,分析它们的权衡取舍,并提供为你的 RAG 应用选择正确方法的建议。

什么是分块?

简单来说,分块是将大型文档分解为更小、更易于管理的片段(称为“块”或 chunks)的过程。这是准备数据以供大语言模型使用时的关键第一步。

主要原因是 LLM 具有有限的上下文窗口(context window),这意味着它们一次只能处理一定量的文本。如果上下文窗口中的文本过多,重要的细节就会丢失,从而导致答案不完整或不准确。

分块通过创建更小、更聚焦的内容片段来解决这个问题,使 LLM 能够利用这些片段回答用户的查询,而不会迷失在无关的信息中。

每个块的大小、内容和语义边界都会影响检索性能,因此决定使用哪种技术会对 RAG 系统的下游性能产生巨大的影响。

为什么分块对 RAG 如此重要?

分块可以说是 RAG 性能中最重要的因素。你如何拆分文档会直接影响系统找到相关信息并给出准确答案的能力。当一个 RAG 系统表现不佳时,问题往往不在于检索器,而在于块。如果是在准备得很糟糕的数据上进行搜索,即使是完美的检索系统也会失败。

这就产生了一个根本性的挑战:你的分块既要便于向量搜索找到,又要给 LLM 提供足够的上下文来生成有用的答案。

1. 优化检索准确性

第一步是确保你的系统能够在向量数据库中找到正确的信息。向量搜索通过比较用户查询与分块的嵌入向量来实现这一点。

分块过大的问题在于:它们通常混合了多种观点,子主题可能会丢失或变得模糊。这就好比试图通过平均所有章节的内容来描述一本书。这会产生一个嘈杂的、“平均化”的嵌入向量,无法清晰地代表任何单一主题,从而使向量检索步骤难以找到所有相关的上下文。

分块小而聚焦则能捕捉到一个清晰的观点。这会产生一个精确的嵌入向量,能够编码内容的细微差别。这使得系统更容易找到正确的信息。

2. 为生成保留上下文

当系统找到最佳的分块后,它们会被传递给 LLM。这就是上下文质量决定输出响应质量的地方。

这有一个简单的测试方法:如果一个分块单独阅读时对你来说有意义,那么它对 LLM 来说也会有意义。

分块过小无法通过这个测试。想象一下从一篇研究论文的中间读一个单独的句子——如果没有更多的上下文,即使是人类也很难理解发生了什么。

分块过大则会产生另一个问题。由于注意力稀释(attention dilution)和“迷失在中间(lost in the middle)”效应,LLM 的性能会随着上下文输入的变长而下降。也就是说,模型很难访问埋藏在长上下文中间的信息,尽管它能较好地处理开头和结尾的信息。随着上下文长度的增加,模型的注意力在所有输入上变得过于分散,使其在寻找相关信息时变得不那么准确,导致推理错误增多,并增加了产生幻觉(hallucinating)的可能性。

分块的最佳平衡点 (The Sweet Spot)

你希望在保留作者的**“思路(train of thought)”的同时,创建足够小的分块以进行精确检索,但又足够完整以给 LLM 提供全部上下文。这是上下文工程(context engineering)**的一部分:以一种 LLM 能够理解并据此生成准确响应的方式准备输入。

当你找准了这个平衡点,几件事会得到改善:

  • 提高检索质量: 通过创建聚焦的、语义完整的分块,你使检索系统能够精确定位查询最相关的上下文。
  • 管理 LLM 的上下文窗口: 有效的分块确保只有相关数据被传递给 LLM,有助于避免过长的上下文长度混淆模型。
  • 减少幻觉: 通过向模型提供小的、高度相关的分块,你将模型的回答锚定在事实数据中,最大限度地降低了它编造信息的风险。
  • 提高效率并降低成本: 处理较小的分块速度更快,计算效率更高,这能带来更快的响应时间和更低的 LLM 使用成本。

预分块 (Pre-Chunking) vs 后分块 (Post-Chunking)

既然我们已经涵盖了分块的基本困境,我们可以探讨在 RAG 管道中何时执行分块步骤。这个决定导致了两种主要策略:标准的预分块和一种更先进的替代方案,后分块。

  • 预分块是最常见的方法。它异步处理文档,在嵌入和存储到向量数据库之前将它们分解成更小的部分。这种方法需要预先决定分块的大小和边界,但由于所有分块都是预先计算和建立索引的,因此能够在查询时实现快速检索。

  • 后分块采取了不同的方法,它首先嵌入整个文档,然后仅在实际检索到文档后,才在查询时进行分块。分块结果可以被缓存,因此随着频繁访问的文档积累起缓存的块,系统会随着时间的推移变得更快。这种方法避免了对可能永远不会被查询的文档进行分块,同时允许根据具体查询采用更动态、上下文感知的分块策略。然而,它在首次访问时会引入延迟,并需要额外的基础设施决策。

分块策略

最好的分块策略取决于你正在处理的文档类型以及你的 RAG 应用的需求。以下方法主要针对基于文本的文档。对于其他格式(如 PDF),需要额外的步骤将其转换为干净的文本。

关于处理 PDF在对 PDF 进行分块之前,你需要干净、结构化的文本。PDF 是一种视觉格式,因此提取文本可能很棘手。分栏、表格、页眉或扫描页面会使文本提取变得不可靠。对于扫描文档,需要光学字符识别 (OCR) 来获取文本。专家建议: 最可靠的方法是首先将 PDF 转换为结构化格式,如 Markdown。这个预处理步骤确保你在应用以下任何分块策略之前,拥有干净、逻辑有序的文本。

简单分块技术

固定大小分块 (Fixed-Size Chunking / Token Chunking)

固定大小分块是最简单、最直接的方法。它将文本分割成预定大小的块,通常以 Token(模型处理文本的单位)或字符来衡量。这种方法易于实现,但不尊重文本的语义结构。因此,它可能会在句子甚至单词的中间切断,导致尴尬的断裂。

一个常见的解决方案是**分块重叠 (Chunk Overlap)**,即一个分块末尾的一些 Token 会在下一个分块的开头重复出现。这保留了原本可能在分块边界处丢失的上下文。

关键考虑因素:

  • 分块大小 (Chunk Size): 一个常见的起点是与嵌入模型的上下文窗口对齐的大小。较小的分块可能更适合捕捉细粒度的细节,而较大的分块可能更适合理解更广泛的主题。
  • 分块重叠 (Chunk Overlap): 典型的重叠比例是分块大小的 10% 到 20%。

适用场景: 快速原型设计以及获取 RAG 系统性能的基准线。这是最简单的起点,特别是当你处理结构不一致的文档或尚不确定正在处理什么内容时。只要确保使用适当的重叠(10-20%),这样你就不会因信息被分割到不同块中而丢失重要上下文。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

代码示例:

from typing import Listimport re# Split the text into units (words, in this case)def word_splitter(source_text: str) -> List[str]:    source_text = re.sub("\s+", " ", source_text)  # Replace multiple whitespces    return re.split("\s", source_text)  # Split by single whitespacedef get_chunks_fixed_size_with_overlap(text: str, chunk_size: int, overlap_fraction: float = 0.2) -> List[str]:    text_words = word_splitter(text)    overlap_int = int(chunk_size * overlap_fraction)    chunks = []    for i in range(0, len(text_words), chunk_size):        chunk_words = text_words[max(i - overlap_int, 0): i + chunk_size]        chunk = " ".join(chunk_words)        chunks.append(chunk)    return chunks
递归分块 (Recursive Chunking)

递归分块是一种更细致的方法。它使用优先级的常用分隔符列表来分割文本,例如双换行符(用于段落)或单换行符(用于句子)。它首先尝试用优先级最高的分隔符(段落)来分割文本。如果产生的任何分块仍然太大,算法会对该特定分块递归地应用下一个分隔符(句子)。

这种方法适应文档的结构,尽可能保持结构相关的单元在一起。它避免了固定大小分块的突然切断,并确保分块保留其原始格式的结构。

推荐用于: 非结构化文本文档,如文章、博客文章和研究论文。这通常是一个可靠的默认选择,因为它尊重文本的自然组织,而不是随机分割。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

代码示例:

from typing import Listdef recursive_chunking(text: str, max_chunk_size: int = 1000) -> List[str]    # Base case:if text is small enough, returnas single chunk    if len(text) <= max_chunk_size:        return [text.strip()] if text.strip() else []        # Try separators in priority order    separators = ["\n\n", "\n", ". ", " "]        for separator in separators:        if separator in text:            parts = text.split(separator)            chunks = []            current_chunk = ""                        for part in parts:                # Check if adding this part would exceed the limit                test_chunk = current_chunk + separator + part if current_chunk else part                                if len(test_chunk) <= max_chunk_size:                    current_chunk = test_chunk                else:                    # Save current chunk and start new one                    if current_chunk:                        chunks.append(current_chunk.strip())                    current_chunk = part                        # Add the final chunk            if current_chunk:                chunks.append(current_chunk.strip())                        # Recursively process any chunks that are still too large            final_chunks = []            for chunk in chunks:                if len(chunk) > max_chunk_size:                    final_chunks.extend(recursive_chunking(chunk, max_chunk_size))                else:                    final_chunks.append(chunk)                        return [chunk for chunk in final_chunks if chunk]        # Fallback: split by character limit if no separators work    return [text[i:i + max_chunk_size] for i in range(0, len(text), max_chunk_size)]
基于文档的分块 (Document-Based Chunking)

基于文档的分块利用文档的内在结构。它不是依赖通用的分隔符,而是根据文档特定格式的元素来解析文档。例如:

  • Markdown: 按标题(#, ##)分割以捕获章节或子章节。
  • HTML: 按标签(<p>, <div>)分割以保留逻辑内容块。
  • PDF: 预处理后(如 OCR 或转换为 Markdown),按页眉、段落、表格或其他结构元素分割。
  • 程序代码: 按函数或类(例如 Python 中的 def)分割以保持代码的逻辑单元。

使用这种方法,分块保持与文档逻辑组织的对齐,这种组织通常也与语义含义相关联。LangChain 和 LlamaIndex 都为各种文档类型(包括 Markdown、代码和 JSON)提供了专门的分割器。

适用场景: 高度结构化的文档,其格式可以轻松定义逻辑分隔。非常适合 Markdown、HTML、源代码或任何具有清晰结构标记的文档。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

代码示例:

from typing import Listimport redef markdown_document_chunking(text: str) -> List[str]:    # Split by markdown headers (# ## ### etc.)    header_pattern = r'^#{1,6}\s+.+$'    lines = text.split('\n')        chunks = []    current_chunk = []        for line in lines:        # Check if this line is a header        if re.match(header_pattern, line, re.MULTILINE):            # Save previous chunk if it has content            if current_chunk:                chunk_text = '\n'.join(current_chunk).strip()                if chunk_text:                    chunks.append(chunk_text)                        # Start new chunk with this header            current_chunk = [line]        else:            # Add line to current chunk            current_chunk.append(line)        # Add final chunk    if current_chunk:        chunk_text = '\n'.join(current_chunk).strip()        if chunk_text:            chunks.append(chunk_text)        return chunks

高级分块技术

语义分块 (Semantic Chunking / Context-Aware Chunking)

语义分块从传统的基于规则的分割转变为基于意义的分割。这种更高级的技术不是依赖字符数或文档结构,而是根据语义相似性来划分文本。该过程包括:

  1. 句子分割: 将文本分解为单独的句子。
  2. 嵌入生成: 将每个句子转换为向量嵌入。
  3. 相似度分析: 比较嵌入向量以检测语义断点(主题发生变化的地方)。
  4. 分块形成: 在这些断点之间创建新的分块。

结果是一组高度连贯的语义块,每个块包含一个独立的想法或主题。这种方法非常适合密集的非结构化文本,在这些文本中你希望保留论点或叙述的逻辑流。

推荐用于: 密集的非结构化文本,以保留一个想法的完整语义上下文。这种方法非常适合学术论文、法律文件或长篇故事。这些文本并不总是使用清晰的分隔符(如段落)来显示主题变化。当你处理复杂的内容,且语义边界与文档结构不完全一致时,这种方法非常棒。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

基于 LLM 的分块 (LLM-Based Chunking)

基于 LLM 的分块使用大语言模型 (LLM) 来决定如何分割文本。LLM 不是依赖固定规则或基于向量的相似度分数,而是处理文档并生成语义连贯的分块,通常还会添加额外的上下文、摘要或其他信息。这可以通过以下方式完成:

  • 识别命题 (Identifying propositions): 将文本分解为清晰、逻辑的陈述。
  • 部分摘要 (Summarizing sections): 归纳成更小的、保留原意的分块。
  • 突出关键点 (Highlighting key points): 确保捕获最相关的信息。

结果是一组比传统方法更准确地保留语义意义的分块。这使得基于 LLM 的分块成为检索增强生成 (RAG) 最强大的策略之一。

适用场景: 检索质量至关重要且预算不是主要顾虑的高价值、复杂文档。非常适合法律合同、研究论文、合规文件或企业知识库。这种方法可以生成概括或突出关键思想的分块,但也伴随着权衡。与其他分块技术相比,它是计算成本最高且速度最慢的方法。

代理式分块 (Agentic Chunking)

代理式分块将基于 LLM 的分块概念更进一步。AI 代理不是应用单一方法,而是动态决定如何分割你的文档。它会查看整个文档,包括其结构、密度和内容。然后,它决定使用最佳的分块策略或策略组合。例如,代理可能会看到一个文档是 Markdown 文件,然后按标题分割文件。它也可能发现一个更密集的文档需要命题式的方法。它甚至可以用元数据标签丰富分块,以实现更高级的检索。

这些“LLM 驱动的方法”可以创建非常清晰且内容丰富的分块。然而,它们需要大量的计算能力,成本更高。通常每个文档需要多次调用强大的模型。

适用场景: 高风险的 RAG 系统,你需要尽可能最好的分块,且成本不是决定性因素。当你需要针对每个文档的独特特征量身定制自定义分块策略时,这是完美的选择。

后期分块 (Late Chunking)

后期分块是一种略有不同的技术,旨在解决其他分块策略中的一个常见问题:上下文丢失。

在其他分块技术中,当你先分割文档然后创建嵌入时,每个分块都会变得孤立。这可能导致分块内的上下文模棱两可或丢失,而这些上下文是在文档前面的部分解释或引用的。

后期分块反其道而行之。你不是先分割,而是首先将整个文档输入到一个长上下文嵌入模型中。这创建了详细的、Token 级别的嵌入,能够理解全貌。只有在那之后,你才将文档分割成块。

当你为每个分块创建嵌入时,你使用的是已经包含完整上下文的 Token 嵌入。你只需平均该分块的相关 Token 嵌入。这意味着每个分块都保留了关于整个文档的上下文。

适用场景: 在检索质量依赖于理解分块与整个文档之间关系的 RAG 系统中使用。这对技术文档、研究论文 or 法律文本非常有用。这些文档的章节经常引用其他地方提到的想法、方法或定义。这有助于捕捉常规分块方法会错过的文档不同部分之间的联系。

分层分块 (Hierarchical Chunking)

分层分块对于非常大和复杂的文档来说可能是一个游戏规则改变者。这个想法非常直接:你在不同的细节层级上创建多层分块。

  • 在顶层,你创建大的分块,总结广泛的章节或主题,如标题和摘要。
  • 在下一层,你将这些章节分割成逐渐变小的分块,以捕捉更精细的细节,如论点、例子或定义。

这让你的 RAG 系统可以从高层概览开始,然后在用户需要更多细节时深入到具体内容。LlamaIndex 的 HierarchicalNodeParser 使这种方法的实现变得容易。

适用场景: 非常大和复杂的文档,如教科书、法律合同或广泛的技术手册。当你需要回答高层总结性问题和高度具体、细节性查询时,此策略非常理想。它为你提供了广阔上下文和细粒度访问之间的良好中间地带,虽然比基本分割方法更复杂,但没有完全的代理式分块那么复杂。

自适应分块 (Adaptive Chunking)

自适应分块技术根据文档的内容动态调整关键参数(如分块大小和重叠)。

这种方法不是对整个文档应用单一、固定的规则,而是将文本视为变化的景观。它可能会使用机器学习模型来分析不同部分的语义密度和结构。例如,它可以自动为复杂、信息丰富的段落创建更小、更细粒度的分块以捕捉细节,同时为更一般的介绍性部分使用更大的分块。

目标是创建大小和边界针对其包含的具体内容量身定制的分块,从而实现更精确和上下文感知的检索。这与代理式分块不同,后者由代理决定使用哪种分块策略,而不仅仅是调整一种策略的参数。

适用场景: 具有变化和不一致内部结构的文档。想象一份长报告,其中包含密集的技术段落和稀疏的叙述部分。自适应策略在这里表现出色,因为它避免了“一刀切”的问题。它可以在同一文档中为复杂部分创建细小的颗粒状分块以捕捉每个细节,并为较简单的文本创建较大的分块以保留上下文。

如何选择最佳分块策略?

没有单一的“最佳”分块方法;最优策略始终取决于你的具体用例。但在深入研究不同技术之前,要问的最重要的问题是:

“我的数据真的需要分块吗?”

分块旨在分解长的、非结构化的文档。如果你的数据源已经包含小的、完整的信息片段,如常见问题解答(FAQ)、产品描述或社交媒体帖子,通常不需要对它们进行分块。分块甚至可能引起问题。目标是创建有意义的语义单元,如果你的数据已经是这种格式,你就已经准备好进入嵌入阶段了。

一旦你确认文档足够长,可以从分块中受益,你可以使用以下问题来指导你选择策略:

  1. 我的文档性质是什么? 它们是高度结构化的(如代码或 JSON),还是非结构化的叙述性文本?
  2. 我的 RAG 系统需要什么级别的细节? 它需要检索具体的、细粒度的事实,还是总结更广泛的概念?
  3. 我使用的是哪种嵌入模型? 输出向量的大小是多少(维度越多,存储更细粒度信息的能力越强)?
  4. 用户查询会有多复杂? 它们是需要小的、目标明确的分块的简单问题,还是需要更多上下文的复杂问题?
分块策略工作原理复杂度最佳适用场景示例
固定大小 (Fixed-Size)按 Token 或字符计数分割。低小型或简单文档,或当速度最重要时。会议记录、短博文、邮件、简单 FAQ
递归 (Recursive)重复分割文本直到符合所需大小,通常保留一些结构。中需要保持一定结构但速度仍然重要的文档。研究文章、产品指南、简短报告
基于文档 (Document-Based)将每个文档视为一个分块,或仅在文档边界分割。低短小、独立的文档集合。新闻文章、客户支持工单、短合同
语义 (Semantic)在自然意义边界(主题、想法)处分割文本。中-高技术、学术或叙述性文档。科学论文、教科书、小说、白皮书
基于 LLM (LLM-Based)使用语言模型根据上下文、意义或任务需求决定边界。高意义感知分块能改善下游任务(如摘要或问答)的复杂文本。长报告、法律意见书、医疗记录
代理式 (Agentic)让 AI 代理根据意义和结构决定如何分割。非常高需要自定义策略的复杂、微妙文档。监管文件、多章节合同、公司政策
后期 (Late)先嵌入整个文档,然后从中推导分块嵌入。高分块需要感知完整文档上下文的用例。案例研究、综合手册、长篇分析报告
分层 (Hierarchical)将文本分解为多个层级(章节 → 段落 → 句子)。保持结构完整。中大型、结构化文档,如手册、报告或合同。员工手册、政府法规、软件文档
自适应 (Adaptive)使用 ML 或启发式方法动态调整分块大小和重叠。高结构和长度各异的混合数据集。来自多源的数据:博客、PDF、邮件、技术文档
代码 (Code)按逻辑代码块(函数、类、模块)分割,同时保留语法。中源代码、脚本或编程文档。Python 模块、JavaScript 项目、API 文档

分块工具和库

在为 RAG 应用程序设置数据摄取管道时,你经常面临分块的经典权衡:你可以依赖专用库以获得速度和易用性,或者自己构建逻辑以获得完全控制。

使用库

幸运的是,你不必从头开始。LLM 社区经常使用两个强大的开源库:LangChain 和 LlamaIndex,每一个都有不同的分块方法:

  • LangChain: 一个用于构建 LLM 应用程序的广泛框架。其灵活的 TextSplitters使其易于将分块集成为更大系统(如多步 AI 代理)的一部分。
  • 最适合: 模块化工作流,其中分块只是拼图的一块。
  • LlamaIndex: 专为 RAG 管道设计。其复杂的 NodeParsers 生成针对摄取和检索进行优化的“节点(Nodes)”。
  • 最适合: 高性能、以数据为中心的检索系统。
  • chonkie: 一个轻量级、专用的分块库,专注于分割文本。它提供各种分块策略,如 SemanticChunker,并且易于与其他 RAG 库集成。
  • 最适合: 那些你想要简单、专注的解决方案,而不需要大型框架开销的项目。
手动实现

使用库的替代方案是自己实现分块逻辑。像固定大小或递归分块这样的策略在 Python 中很容易编写代码,这让你对数据处理方式拥有完全的权威,并避免在项目中添加外部依赖。

  • 最适合: 那些希望避免添加大型库、需要实现高度自定义分块策略或需要数据管道完全透明的项目。

如何在生产环境中优化 RAG 的分块大小

在生产环境中优化分块大小需要大量的测试和审查。以下是你可以采取的一些步骤:

  1. 从通用的基准策略开始,例如固定大小分块。一个好的起点是 512 个 Token 的分块大小和 50-100 个 Token 的重叠。这为你提供了一个稳固的基准,易于复现并与其他分块策略进行比较。
  2. 尝试不同的分块方法,通过调整分块大小和重叠等参数,找到最适合你数据的方法。
  3. 测试检索效果,通过运行典型的查询并检查命中率 (hit rate)、精确率 (precision) 和召回率 (recall) 等指标,看看哪种策略效果最好。
  4. 引入人工审查,检查检索到的分块和 LLM 生成的回复——他们的反馈会捕捉到指标可能遗漏的问题。
  5. 持续监控生产环境中 RAG 系统的性能,并准备好根据需要迭代你的分块策略。

如何学习大模型 AI ?

由于新岗位的生产效率,要优于被取代岗位的生产效率,所以实际上整个社会的生产效率是提升的。

但是具体到个人,只能说是:

“最先掌握AI的人,将会比较晚掌握AI的人有竞争优势”。

这句话,放在计算机、互联网、移动互联网的开局时期,都是一样的道理。

我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述

第一阶段(10天):初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识,对大模型 AI 的理解超过 95% 的人,可以在相关讨论时发表高级、不跟风、又接地气的见解,别人只会和 AI 聊天,而你能调教 AI,并能用代码将大模型和业务衔接。

  • 大模型 AI 能干什么?
  • 大模型是怎样获得「智能」的?
  • 用好 AI 的核心心法
  • 大模型应用业务架构
  • 大模型应用技术架构
  • 代码示例:向 GPT-3.5 灌入新知识
  • 提示工程的意义和核心思想
  • Prompt 典型构成
  • 指令调优方法论
  • 思维链和思维树
  • Prompt 攻击和防范
  • …

第二阶段(30天):高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习,学会构造私有知识库,扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架,抓住最新的技术进展,适合 Python 和 JavaScript 程序员。

  • 为什么要做 RAG
  • 搭建一个简单的 ChatPDF
  • 检索的基础概念
  • 什么是向量表示(Embeddings)
  • 向量数据库与向量检索
  • 基于向量检索的 RAG
  • 搭建 RAG 系统的扩展知识
  • 混合检索与 RAG-Fusion 简介
  • 向量模型本地部署
  • …

第三阶段(30天):模型训练

恭喜你,如果学到这里,你基本可以找到一份大模型 AI相关的工作,自己也能训练 GPT 了!通过微调,训练自己的垂直大模型,能独立训练开源多模态大模型,掌握更多技术方案。

到此为止,大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗?

  • 为什么要做 RAG
  • 什么是模型
  • 什么是模型训练
  • 求解器 & 损失函数简介
  • 小实验2:手写一个简单的神经网络并训练它
  • 什么是训练/预训练/微调/轻量化微调
  • Transformer结构简介
  • 轻量化微调
  • 实验数据集的构建
  • …

第四阶段(20天):商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知,可以在云端和本地等多种环境下部署大模型,找到适合自己的项目/创业方向,做一名被 AI 武装的产品经理。

  • 硬件选型
  • 带你了解全球大模型
  • 使用国产大模型服务
  • 搭建 OpenAI 代理
  • 热身:基于阿里云 PAI 部署 Stable Diffusion
  • 在本地计算机运行大模型
  • 大模型的私有化部署
  • 基于 vLLM 部署大模型
  • 案例:如何优雅地在阿里云私有部署开源大模型
  • 部署一套开源 LLM 项目
  • 内容安全
  • 互联网信息服务算法备案
  • …

学习是一个过程,只要学习就会有挑战。天道酬勤,你越努力,就会成为越优秀的自己。

如果你能在15天内完成所有的任务,那你堪称天才。然而,如果你能完成 60-70% 的内容,你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】

在这里插入图片描述

大模型AI应用开发企业级项目实战:从提示词工程到NLP应用落地 企业级大模型应用开发并非简单调用API,而是涉及提示词工程、对话管理、知识库检索与NLP任务处理的系统工程。提示词设计遵循上下文优于指令、示例优于描述、结构优于自然段的原则,并需配合评估集进行版本化管理。对话产品需构建会话管理、意图识别与RAG知识库增强的完整链路,以保障业务效果。大模型NLP应用通过统一流水线实现意图识别、实体抽取等任务,需规范化输出并控制推理参数。私有化部署、成本控制与效果监控是落地关键。本文结合实战项目,梳理从技术原理到工程实践的完整方法论,为AI对话产品与自然语言处理应用提供可复用的 阅读详情

相关推荐

AI产品经理大模型选型实战:五层漏斗决策法

大模型选型不是比参数、看榜单,而是面向真实业务交付的技术决策过程。其本质是平衡技术可行性、商业合理性与组织落地性三重约束,在合规准入、能力基线、工程成本、演进路径和商务服务五个维度上动态权衡。尤其对AI产品经理而言,需穿透宣传话术,聚焦中文长文本理解、首token延迟、RAG召回精度等可测指标,并依托真实业务数据验证模型在智能客服、合同审核、工业助手等典型场景下的鲁棒性与稳定性。本文基于23个模型筛选与6个落地项目经验,提供可复用的评估框架与避坑指南。

dicha7140的博客 473

RAG 知识库的文档要求

摘要:构建高效RAG知识库的关键在于文档质量与结构优化。优先选择Markdown、DOCX等格式,慎用PDF;确保内容准确、相关、术语统一;采用清晰标题层级组织文档,合理控制文本分块长度(建议300字左右)。预处理时需转换格式、清理杂质、添加元数据。优化技巧包括:巧用标题层级、灵活调整分块策略、设计内容重叠、规范表格处理。特别注意避免扫描件PDF,遵守文件大小限制,并确保敏感数据安全。定期迭代验证文档效果,持续优化知识库质量。(149字)

qq_35354529的博客 1448

大模型上下文长度实战指南:ICL、RAG与长上下文的协同决策

上下文长度是大语言模型落地的核心工程变量,它并非单纯的技术参数,而是影响In-context learning效果、RAG架构设计与任务精度的关键杠杆。其原理根植于注意力机制衰减规律、位置编码偏差及KV缓存特性;技术价值体现在平衡知识密度与推理空间,避免示例冗余导致的模仿陷阱与格式崩坏;典型应用场景包括客服意图识别、合同审查、多文档摘要等需模式匹配或结构化输出的任务。实践中需警惕‘更多即更好’误区,结合few-shot示例精炼、锚点信号设计与混合架构(如RAG+长上下文)实现效能跃迁。

weixin_34268579的博客 356

实战:利用 AI 自动拆分复杂网页,生成更适合‘碎片化检索’的语义切片(Chunks)

各位同仁,下午好!今天,我们齐聚一堂,探讨一个在信息爆炸时代日益凸显的挑战——如何高效地从浩瀚的网页信息中提取、组织和检索我们真正所需的内容。传统上,我们习惯于将整个网页视为一个不可分割的整体进行索引,但这在面对日益复杂的现代网页时,效率往往不尽如人意。例如,一篇长篇技术博客,可能涵盖多个子主题,用户若只想了解其中某个特定技术点,完整的网页检索结果往往会淹没在大量无关信息中。。

weixin_41455464的博客 264

AI编排:企业级大模型落地的神经中枢设计

AI编排(AI Orchestration)是面向生产环境的大模型工程化核心范式,其本质是构建可治理、可审计、高可用的智能调度中枢,解决数据可达性、决策可信度与业务闭环三大断层。它融合API集成、规则引擎与LLM推理能力,在金融、保险、零售等强合规行业中,支撑自然语言驱动真实业务动作——如CRM内一键生成合规挽留邮件、销售风险实时研判等。区别于单点AI工具链,AI编排强调分层解耦:MuleSoft负责确定性任务(认证、脱敏、熔断),LangChain专注不确定性推理(RAG、Prompt编排、多模型协同)。

weixin_34209851的博客 380

大模型落地避坑指南:RAG、微调与Prompt工程的生产实践

大语言模型(LLM)应用的核心挑战不在理论理解,而在真实业务场景中的确定性交付。RAG并非简单检索+生成,其效果取决于语义过滤、结构校验与可信度熔断等工程化设计;微调常被高估,80%术语问题可通过动态词典注入或后处理映射高效解决;Prompt需从‘艺术调试’转向模块化、可版本化、可AB测试的工程配置。技术价值在于将模糊需求转化为可审计、可监控、可降级的确定性链路。典型应用场景包括客服摘要、智能工单分派、设备故障诊断等强规则、高可用要求的垂直领域。本文聚焦12个已上线项目的共性断点,直击RAG失效、微调漂移、

weixin_33698043的博客 383

你的RAG还在“原地打转”?别再瞎调模型了!真正该测的是这三件事,让检索命中率飙升!

当面试官问:“RAG 的检索模块怎么优化?” 很多测试工程师的第一反应是: “那不是算法同学的活儿吗?” 其实不然。 RAG(Retrieval-Augmented Generation)的检索模块,决定了系统回答的准确性、性能稳定性,以及整个优化链路能否被**量化与验证**。 而这,恰恰是测试开发最擅长发力的地方。

m0_59163425的博客 610

RAG工程实践手册:从实验室到生产环境的落地指南

RAG(检索增强生成)作为当前企业知识库与大模型应用的核心架构,其本质是将信息检索的确定性与大语言模型的生成能力协同融合。理解RAG需回归基础:它不是黑箱模型调用,而是由数据预处理、向量检索、重排序、可控生成构成的端到端数据流系统。技术价值在于突破LLM固有知识边界与幻觉缺陷,实现基于可信源的精准响应;典型应用场景涵盖金融合规问答、医疗文档解读、工业标准检索等强准确率、低容错业务。然而,90%的失败源于数据管道设计失当——PDF解析失真、语义分块断裂、Embedding未适配领域,而非模型本身。本文聚焦可复

weixin_30352191的博客 416

救命!RAG技术已全面爆发,5个等级教你从入门到生产级,小白也能逆袭!

RAG技术已成为AI开发必备技能,86%企业正在使用。本文详解5级RAG进阶路径,从Level 1的Naive RAG(68%准确率)到Level 5的Production RAG(95%准确率),涵盖技术要点、成本分析和最佳实践。RAG比微调便宜100倍,可构建企业知识护城河。文章提供3个月学习路径和商业应用方向,帮助开发者快速掌握这一关键技术,提升竞争力。

m0_59235945的博客 719

RAG技术原理与实战:解决大模型幻觉与知识滞后问题

检索增强生成(RAG)是一种融合信息检索与大语言模型的混合架构,其核心原理是通过向量检索从外部知识源实时获取高相关性片段,再驱动模型进行引文式生成,从而突破纯生成式AI固有的幻觉(Hallucination)和知识滞后(Knowledge Staleness)两大瓶颈。该技术显著提升回答的可验证性、时效性与业务可信度,广泛应用于企业知识库问答、合规文档解读、客服智能辅助等强依据、高准确率要求的场景。本文深入剖析RAG四大关键模块——知识库构建、语义检索、重排序与约束生成,并结合中文垂直领域实践,提供可落地的

diandingyin9417的博客 360

大模型落地案例集:RAG、结构化抽取与多轮对话的工程化实践

大模型应用落地常面临从Demo到生产的工程化挑战,涉及提示词管理、输出约束、成本控制与评测闭环。以RAG知识问答为例,文档切分粒度与向量模型选型直接影响检索召回,结合重排可提升准确率。结构化抽取通过Schema约束、JSON mode与后处理校验保障格式稳定。多轮对话需管理状态与历史摘要,内容生成则依赖评测标准。这些模式共同构成可复用的落地框架,帮助团队跨越最后一公里。

weixin_29056701的博客 201

你的RAG还在“大海捞针”?LightRAG:图+向量双涡轮引擎,24G显存让百万文档检索进入“光速时代”!

今天给你安利 **LightRAG**——**23.7k Star** 的“轻量图式 RAG”框架,**1 分钟把百万文档拆成知识图谱**,**问答快 10 倍、显存省一半、无需 Neo4j**!真正的“**闪电知识库**”⚡

xx_nm98的博客 995

帆软js--获取控件和单元格

参数面板: 获取面板控件 ,name为控件名称:_g().parameterEl.getWidgetByName("name") 取值:_g().parameterEl.getWidgetByName("tt3").getValue()2323 赋值:_g().parameterEl.getWidgetByName("tt2").setValue("987") 调用对应的事件比...

江湖行骗老中医 7200

大模型 API 检索权重调参翻车记:离线评估涨 20% 的配置,上线后效果暴跌一半

作者详细记录了在接入大模型API优化混合检索系统时,因离线评估与线上真实场景差异导致的严重事故。原本离线测试提升20%的配置上线后引发延迟暴涨和答案混乱。文章深入分析了DeepSeek、Claude等大模型API在长文本处理、成本控制等方面的陷阱,最终给出包含动态权重调整、熔断机制和对抗性测试的7条实战经验。

weixin_47315004的博客 17

汇川PLC用户程序结构详解:如何像搭积木一样配置多任务?附EtherCAT最佳实践

本文深入解析汇川PLC用户程序结构,阐述如何像搭积木一样,通过POU、FB、FC等模块化组件高效配置多任务。文章重点结合EtherCAT通讯场景,分享了任务周期、优先级设置的最佳实践与关键避坑指南,帮助工程师构建稳定、高效的运动控制系统。

weixin_29184075的博客 541

BIDS数据存储格式介绍与dcm2bids安装与使用

BIDS格式&dcm2bids安装与使用

machinelearning_er的博客 7319

RAG进阶指南:从预检索优化到后检索精炼的全链路调优

本文深入探讨了RAG(检索增强生成)从基础到进阶的全链路调优方法,涵盖预检索、检索和后检索三大阶段。通过动态分块、混合检索、查询扩展等实战技巧,显著提升问答系统的准确率和召回率。特别适合需要优化AI生成内容质量的技术团队参考。

weixin_30576827的博客 517

为什么你的 RAG 项目总在 POC 阶段就死了?从零到一完整部署指南

本文深入解析LangChain框架在AI智能体时代的应用,提供从理论到实践的全面指南。主要内容包括: 框架概述:介绍LangChain作为AI应用开发生态系统的定位,及其核心设计理念。 核心架构:详细拆解RAG/IAG项目的三大组件: 知识库构建(文档加载、文本分割、向量化嵌入) 检索生成(查询处理、提示工程、LLM交互) 智能体增强(任务规划、工具调用、记忆管理) 部署流程:分阶段指导环境准备、向量知识库构建和服务搭建,包含Python代码示例(文档处理、Chroma向量库、FastAPI服务)。 关键决

热爱技术与前沿创新,深耕科技领域,在科创中精进自我;探索技术乐趣,分享技术干货与成长心得,以技术为伴,热爱生活,在科创与生活中双向成长。 1160

基于高光谱的物质反演与分类 — 技术文章(原理详解 + 深度代码实现)

高光谱遥感 / 近场光谱采集产生逐像素上百波段的光谱曲线,是物质识别与定量反演(abundance / composition estimation)和语义分类(landcover / material class)的一把利器。本文第一部分对常用模型(线性混合模型、非线性辐射传输、稀疏反演、降维与特征选择、分类器/神经网络)进行数学推导与理论分析;第二部分给出两套完整实现:A. 基于 LMM 的约束最小二乘 / 稀疏反演流水线(含端到端评估);

VectorShift的博客 221

基于STM32、HAL库的W25Q01JVZEIQ TR FLASH存储器驱动应用程序设计

1Gb (128MB),分为512个可擦除块(block),每个块256KB。:块擦除约30-50ms,芯片擦除约30s。:标准SPI (支持1/2/4线模式)// 初始化CS引脚为高电平。// 擦除扇区(4KB)// 初始化Flash。/* 状态寄存器位 *//* 指令定义 *//* 超时定义 *//* 函数声明 */

corlin6688的博客 268

AI产品经理必看!模型评测避坑指南,附实用模板和清单,助你转行成功!

很多人以为AI产品经理跟传统产品类似,写好PRD交给研发就完事(所以一直有人找我要AI产品的PRD模板),结果上线直接翻车,被算法同学追着问“”“今天就把我踩过无数坑总结的模型评测干货,全部分享给大家,直接可以使用。先跟大家说清楚核心传统产品和AI产品的区别,避免走弯路**传统产品经理:**靠PRD定功能,研发照着做、联调、测试,最后上线,全程都是确定的流程,按部就班来就行。**AI产品经理:**我们的PRD,本质就是“评测集”!

2401_85343303的博客 563

173、LLC谐振变换器的PCB设计实战(布线)

LLC谐振变换器PCB设计实战要点 LLC谐振变换器的PCB设计核心在于控制寄生参数,避免高频振铃和EMI问题。功率回路需确保电流路径最短且紧耦合,谐振电容焊盘需加宽以减少发热。驱动走线应独立于功率回路,避免干扰,并合理控制宽度和长度。变压器绕组结构影响共模噪声,建议原边在外层并加屏蔽铜箔。地平面设计需根据功率等级选择整块或分割,大功率下功率地与信号地应单点连接。谐振电流采样推荐四端开尔文电阻以减少电感干扰。散热需优化铜皮和过孔布局,功率器件优先放置顶层。布局应先确定谐振腔,再排布控制电路。经验上需实测寄生

Jack010169的博客 46

RAG不是喂资料,而是给大模型配专业助理

RAG(检索增强生成)是一种将信息检索与大语言模型生成解耦的混合架构,其核心原理是通过语义向量检索在生成前精准定位相关知识片段,从而抑制幻觉、提升事实准确性。该技术不依赖模型微调,却能显著增强私有文档问答、合规审查、设备维修等专业场景的回答可信度与可溯源性。相比端到端微调,RAG具备部署轻量、知识更新快、数据不出域等工程优势,已成为企业落地AI应用的首选范式。本文聚焦RAG系统中嵌入模型选型、智能切片、向量检索与提示约束四大关键技术环节。

cuml0912的博客 328

YOLOv8+BiFPN双向特征金字塔:多尺度目标检测精度提升28%的实战教程

双向特征金字塔网络(BiFPN)是一种强化多尺度特征融合支持“自顶向下+自底向上”的双向特征流动,同时保留不同尺度的细节信息;引入加权融合机制,自动学习不同特征的重要性权重;裁剪冗余节点,在轻量化的同时提升融合效率。

m0_64661770的博客 493

廖雪峰Python教程[完整版]

廖雪峰的python教程整理的,已经排好版了,而且还是完整的,适合小白

企业级大模型推理成本优化实战:从80%降本到生产落地

大模型推理成本高、部署复杂、SLA难保障,已成为企业AI规模化落地的核心瓶颈。本文围绕‘推理成本优化’这一高频搜索技术命题,深入解析如何通过模型量化(INT4+结构化稀疏)、轻量服务引擎(绕过vLLM)、硬件感知编译与Triton C++后端协同,实现端到端推理成本下降80%。区别于通用开源模型,该方案聚焦企业真实场景——合同解析、客服话术生成、工单分类等确定性任务,强调可审计、可预算、可集成的生产就绪能力。内容覆盖显存控制、批处理黄金值计算、RAG防幻觉设计、LoRA秩物理意义及三大关键监控指标,直击财务

366

efm32 入门.pdf

本PDF共计22页,介绍的是操作驱动API,下载与否自己斟酌。

上一篇: RLVR强化学习训练成本暴降98%!12种PEFT方法大PK,结果让人意外...
下一篇: 【硬核干货】BEiT-v3多模态大模型全解析:一个模型架构通吃图像+文本,AI开发者的“大一统“神器!
Python_金钱豹
博客等级 码龄5年 1万+粉丝 2840原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值