一，如何优化 LLM 调用的延迟和成本？

优化大语言模型（LLM）调用的延迟和成本，核心在于减少不必要的计算、提升用户感知的响应速度以及提高并发处理效率。以下是三种关键的优化策略：

1. 缓存机制 —— 相同问题直接返回缓存

对于重复或高频的查询，直接返回历史结果，避免重复调用模型。这能显著降低 Token 消耗和响应时间。

代码示例（Spring Cache）：

// 1. 缓存 — 相同问题直接返回缓存
@Cacheable(value = "llm-responses", key = "#query")
public String ask(String query) { ... }

2. 流式输出 —— 降低首字延迟

采用流式传输，让模型“边生成边返回”。虽然总生成时间不变，但用户看到第一个字的时间（首字延迟）会从几秒降低到几百毫秒，极大提升体验。

代码示例（Spring AI Flux）：

// 2. 流式输出 — 降低首字延迟
Flux<ChatResponse> stream = chatClient.prompt("介绍 Java").stream().chatResponse();
// 边生成边返回，用户感知延迟从 3s → 0.5s

3. 异步并发 —— 多个独立问题并行请求

当需要处理多个互不依赖的请求时，使用异步编程模型并行发送请求，而不是串行等待，从而缩短整体任务的完成时间。

代码示例（CompletableFuture）：

// 3. 异步并发 — 多个独立问题并行请求
var futures = queries.stream()
    .map(q -> CompletableFuture.supplyAsync(() -> chatModel.call(q)))
    // ... collect and join

二，设计一个企业级 AI 对话平台，你会如何架构？

设计一个企业级 AI 对话平台，核心在于构建一个高内聚、低耦合、安全可控的分层架构。通常推荐采用五层架构体系，以确保系统的可扩展性、灵活性以及对企业内部业务的深度赋能：

1. 基础设施层（基础资源）

为整个平台提供底层的算力和存储支撑。

• 异构算力：支持 GPU/CPU 混合集群，满足模型训练与高并发推理的需求。
• 数据存储：部署对象存储（存放非结构化文档）、关系型数据库（存储元数据和用户信息）以及向量数据库（用于存储知识库的 Embedding 向量）。

2. 模型服务层（大脑与调度）

负责大模型的管理与调用，不绑定单一模型，确保高可用与成本优化。

• 统一适配：通过模型网关（Model Gateway）屏蔽不同厂商（如 OpenAI、DeepSeek、通义千问等）的 API 差异，支持模型热插拔。
• 智能路由：根据任务的复杂度、成本预算和延迟要求，动态分配模型（例如：简单任务走轻量级低成本模型，复杂逻辑走高性能模型）。

3. 知识数据层（企业专属记忆）

解决大模型在企业场景中的“幻觉”和知识时效性问题。

• RAG 增强：建立检索增强生成（RAG）管道，将企业内部文档（Word、PDF、Wiki、数据库等）进行清洗、分块（Chunking）和向量化。
• 混合检索：结合向量检索、关键词检索与知识图谱，精准召回企业私有数据，确保 AI 回答的准确性与可追溯性。

4. 核心能力层（编排与执行）

将模型能力转化为实际的业务解决方案。

• Agent 智能体：具备感知、规划、执行能力的智能代理。通过 Function Calling 或标准化协议（如 MCP），让 AI 能够调用企业内部 ERP、CRM、OA 等系统的 API 执行实际业务操作。
• 工作流编排：提供可视化编排引擎，将复杂的业务流程（如请假审批、订单查询）拆解为多步骤的自动化工作流，支持多智能体协作（Multi-Agent）。

5. 应用接入与安全运维层（交互与管控）

负责面向用户的交互输出以及企业级安全保障。

• 多渠道接入：支持将对话能力嵌入 Web、App、企业微信、钉钉、飞书等办公平台。
• 安全合规：建立全链路的安全护栏（Guardrails），对敏感数据进行脱敏处理，对输出内容进行实时合规审核；同时支持完善的权限管控与全量审计日志。
• 可观测性：提供完善的监控与运营面板，实时追踪 Token 消耗、请求成功率、用户反馈及对话质量，为后续持续优化提供数据支撑。

三，用 Spring AI 实现一个简单的客服问答机器人，要求基于产品文档回答、不知道时说“请转人工”、支持对话历史记忆，如何实现？

使用 Spring AI 实现该客服问答机器人，核心思路是利用 RAG（检索增强生成）机制检索产品文档，并通过配置 Advisors 实现检索增强与对话记忆，同时在 Prompt 中设定好“未知兜底”规则。

核心实现步骤与代码

1. 依赖注入与 ChatClient 构建
在 Controller 层，通过 Spring 的依赖注入获取 ChatClient.Builder 和 VectorStore（向量数据库，用于存储和检索产品文档）。利用 Builder 模式构建 ChatClient，并配置默认的建议器（Advisors）。

2. 配置核心功能

• 基于产品文档回答（RAG）：通过 QuestionAnswerAdvisor 关联向量数据库，实现语义检索增强。
• 对话历史记忆：添加 MessageChatMemoryAdvisor，使模型能够根据上下文进行连贯回复。
• 未知问题兜底：在 Prompt 的 System Prompt 中明确指令，当检索到的文档信息不足以回答问题时，强制回复“请转人工”。

完整代码示例

@RestController
public class CustomerServiceBot {

    private final ChatClient chatClient;

    // 通过构造函数注入 ChatClient.Builder 和存储了产品文档的 VectorStore
    public CustomerServiceBot(ChatClient.Builder builder, VectorStore vectorStore) {
        
        // 1. 在 Prompt 中设定“请转人工”的兜底规则（实际开发中常写在 prompt template 中）
        String systemPrompt = "你是一个客服助手。你必须仅基于给定的产品文档内容回答用户问题。" +
                              "如果文档中没有相关信息，或者你不知道答案，请绝对不要编造，直接回复：'请转人工'。";

        this.chatClient = builder
                .defaultSystem(systemPrompt) // 注入系统指令
                .defaultAdvisors(
                        // 实现 RAG：从向量数据库中检索文档上下文
                        new QuestionAnswerAdvisor(vectorStore),
                        // 实现对话历史记忆（如使用内存存储）
                        new MessageChatMemoryAdvisor(new InMemoryChatMemory())
                )
                .build();
    }

    @PostMapping("/ask")
    public Map<String, String> chat(@RequestBody String question) {
        // 调用 ChatClient 处理用户问题
        String response = chatClient.prompt()
                                    .user(question)
                                    .call()
                                    .content();
        
        Map<String, String> result = new HashMap<>();
        result.put("reply", response);
        return result;
    }
}

四，如何处理大文档（超过模型上下文窗口）的 RAG？

处理大文档的核心思路是化整为零，分治处理。业界最常用且有效的方法是采用 Map-Reduce 策略。该策略将大文档的处理流程拆分为“Map（映射）”和“Reduce（归纳）”两个阶段，完美规避了大语言模型的上下文窗口限制。

具体实现步骤如下：

1. 切分（Split）

首先，使用文本分割器（如 Spring AI 提供的 splitter）将庞大的文档按一定规则切割成多个较小文本块（Chunk）。同时，可以利用 Apache Tika 等工具高效读取文件内容。

// 1. 切分
List<Document> chunks = splitter.split(new TikaDocumentReader(doc.get()));

2. Map（映射）—— 并行总结每个分块

利用并行流（如 Java 的 parallelStream）对每一个文本块独立进行总结。此时每个文本块的内容都在模型的上下文窗口范围内，可以高效并发处理。

// 2. Map —— 并行总结每个 chunk
List<String> summaries = chunks.parallelStream()
    .map(chunk -> chatClient.prompt()
        .user("总结以下内容: " + chunk.getText())
        .call().content())
    .toList();

3. Reduce（归纳）—— 合并所有总结

最后，将前面所有文本块生成的局部总结拼接起来，再次提交给大模型，要求它将这些零散的总结整合成一份完整、连贯的最终结果。

// 3. Reduce —— 合并所有总结
return chatClient.prompt()
    .user("将以下多个总结合并为一个完整总结: \n" + String.join("\n---\n", summaries))
    .call().content();

五，什么是 RAG？解决了什么问题？

**RAG（检索增强生成，Retrieval-Augmented Generation）**是一种将“信息检索”与“大模型生成”相结合的架构。其核心定义是在大模型生成回答之前，先从外部知识库中检索出相关的信息，作为上下文（Context）补充给大模型，从而提升回答的质量。

RAG 主要解决了大模型在落地过程中遇到的三大核心痛点：

1. 知识滞后（时效性问题）

• 痛点：大模型的训练数据有截止日期（知识冻结），无法回答模型训练之后发生的新闻、政策或业务变化。
• 解决：RAG 可以实时检索最新的外部信息，让模型掌握最新的知识。

2. 幻觉问题（一本正经胡说八道）

• 痛点：大模型在不知道答案时，经常会凭借概率“编造”看似合理的虚假内容，导致答案不可信。
• 解决：强制要求模型“仅基于检索到的上下文”进行回答，没有相关信息就不回答或明确告知，极大降低了幻觉率。

3. 私有数据缺失与安全问题

• 痛点：通用大模型没有企业的内部数据（如产品手册、客户订单、内部制度），直接进行全量预训练或微调成本极高且存在数据泄露风险。
• 解决：RAG 允许企业挂载自有的私有知识库，无需重新训练模型即可让模型掌握企业内部专属知识，成本低且数据安全可控。

核心价值总结：
RAG 极大地提高了问答的准确性和可溯源性（可以指出答案来源于哪篇文档），同时无需重新训练模型，更新成本低，是目前企业落地大模型最主流的架构。

六，RAG 的标准流程是怎样的？

RAG（检索增强生成）的标准工作流可以分为两个核心阶段：索引阶段（数据的预处理与入库）和查询阶段（用户提问与回答生成）。这两个阶段共同构成了一个完整的闭环，标准步骤如下：

1. 索引阶段（数据准备）

这一阶段负责将非结构化的文档转化为大模型可以理解并进行语义搜索的向量数据。

• 文档清洗：去除文档中的特殊符号、乱码或无效信息。
• 文本切分（Chunking）：由于大模型有上下文窗口限制，需要将长文档按段落或字符数切割成较小的文本块（Chunk）。
• 向量化（Embedding）：利用 Embedding 模型将切分好的文本块转化为数学意义上的“向量”（即高维空间中的坐标点）。
• 存入向量数据库：将这些向量及其对应的原始文本存入专门的向量数据库中，以便后续进行高效的语义检索。

2. 查询阶段（问答生成）

当用户发起提问时，系统会实时调用处理好的知识库来生成答案。

• 用户问题向量化：将用户输入的自然语言问题，使用与索引阶段相同的 Embedding 模型转化为向量。
• 相似度检索：拿用户问题的向量去向量数据库中进行匹配，找出与问题在语义上最相似的 Top K 个文本块。
• 重排序（Rerank，进阶优化）：为了进一步提升准确率，可以使用 Rerank 模型对检索到的 Top K 个结果进行二次精细排序，确保最相关的文本排在最前面。
• 拼接 Prompt：将用户的问题与检索（和重排序）到的相关文本块作为“上下文（Context）”，按照预设的模板组装成一条完整的 Prompt（提示词）。
• LLM 生成答案：将组装好的 Prompt 提交给大语言模型（LLM），模型基于 Prompt 中的上下文约束，生成最终回答。

七，RAG vs SFT（微调）的区别？

RAG 和 SFT 是大模型落地企业级应用时两种最核心的技术路线，它们在处理“知识”的方式上有着本质的区别，通常可以概括为**“外挂知识库”与“内化知识”**的差异。

1. SFT（监督微调，Supervised Fine-Tuning）

• 核心机制：把知识“灌”进模型的权重里。通过在特定领域的数据集上继续训练模型，让模型深度记忆并内化这些知识。
• 主要作用：非常适合改变模型的说话风格、语气（例如让它扮演一个特定的客服角色），或者让模型掌握某个固定领域的深度推理逻辑。
• 局限性：更新成本极高。一旦企业业务数据发生变更，就需要重新收集数据进行微调，无法做到实时更新。

2. RAG（检索增强生成，Retrieval-Augmented Generation）

• 核心机制：让模型“查资料”。知识存储在模型外部的向量数据库中，模型只是在回答问题时实时检索并参考这些资料。
• 主要作用：极其灵活、更新快、可溯源。非常适合企业文档、最新政策等知识频繁变动的场景，且能明确告诉用户答案出自哪篇文档。
• 局限性：模型本身的推理和生成风格不会改变，且检索的准确度高度依赖于文档的切分策略。

结论

在实际的企业级应用中，通常的选型策略是：优先使用 RAG（成本低、落地快、数据实时）；如果 RAG 无法满足特定的风格或深度推理需求，再考虑 SFT 微调；最理想的方案往往是两者结合，通过 SFT 让模型“学会”如何更好地使用 RAG 检索来的外部资料。

八，文档切分（Chunking）有哪些方式？

文档切分（Chunking）是 RAG 流程中最基础也最关键的一步，切分的好坏直接决定了后续向量检索的效果。常见的切分方式主要分为三大类：

1. 基础规则切分

这类方式实现简单，工程成本最低，适用于对语义连贯性要求不高的普通文本。

• 固定大小切分：按固定的字符数或 Token 数进行切割。为了解决“切断句子”的问题，通常会设置一定的重叠（Overlap），例如每 500 Token 切一个块，前后各重叠 50 Token。
• 按句子/标点切分：以句号、问号等自然分隔符为边界，确保每个块都包含完整的句子。
• 递归字符切分：LangChain 等框架的常见做法。按照“段落 -> 句子 -> 词/字符”的优先级依次尝试切分，尽可能保留语义单元。

2. 结构化与格式切分

这类方式利用文档本身的格式特征，能够很好地保留上下文结构，适用于格式规范的文档。

• 按文档结构切分：根据 Markdown 的标题层级（# ## ###）、HTML 的段落标签（）、PDF 的章节目录等，将每个独立的小节内容切为一个块。
• 特定格式智能切分：针对代码文档按函数、类或 AST 语法树切分；针对法律/规范文档按条款编号切分；针对简历进行布局分析后切分。
• 页面级切分（Page-level Chunking）：NVIDIA 的实验表明，在大多数数据集中，以自然页面边界进行切分，往往能提供比部分级切分更连贯的数据块，实现最高的平均检索准确率。

3. 语义与主题切分

这是较为高级且成本较高的切分方式，追求极致的语义完整性。

• 语义切割（Semantic Chunking）：不依赖标点或固定长度，而是通过 Embedding 模型计算相邻句子的向量相似度。当相邻句子的相似度突然下降（语义断层）时，就在此处进行切分，确保每个文本块内部语义高度一致。

九，幻觉（Hallucination）怎么处理？

大模型（LLM）的幻觉（即一本正经地编造错误信息）是其落地应用最大的挑战之一。目前业界普遍采用**“提示约束 + 引用溯源 + 阈值拦截 + 事实核查”**等多维度的系统防御策略来最大程度地压制幻觉。以下是四种核心且行之有效的处理手段：

1. Prompt 约束：明确指令与拒绝机制

在系统提示词（System Prompt）中明确告知模型的边界。例如，强制要求：“如果检索到的上下文中没有答案，请明确回答‘我不知道’，严禁自行编造或调用模型内部参数知识补全答案。”这种“显式不确定性”提示能有效降低模型在未知领域的胡编乱造。

2. 引用溯源：强制标注来源

要求模型在生成每一句关键结论时，必须在末尾强制标注引用来源（如：[来源：文档X 第3章 第2节]）。这不仅能让用户验证答案的真实性，也能倒逼模型在生成过程中严格依赖提供的上下文，减少幻觉的产生。

3. 阈值拦截：置信度兜底

在 RAG 流程中引入拦截机制。如果检索（或重排序 Rerank）后得到的相关文档分数低于预设阈值，或者模型生成的置信度过低，系统应直接触发拦截，转为“未检索到相关信息，请重新提问或转人工客服”，从而避免强行生成错误答案。

4. 事实核查：生成后二次校验

在模型输出答案后，利用额外的校验机制进行把关。常见做法是使用一个轻量级模型、专门的 NLI（自然语言推理）模型，甚至是大模型自身（LLM-as-a-Judge），对生成的答案和原始检索到的上下文进行二次比对，检查答案是否在原文中得到了真实支撑，未通过的将被丢弃或要求模型重新生成。

十，延迟（Latency）怎么优化？

RAG 系统的用户体验很大程度上取决于响应速度。延迟优化通常需要打一套“组合拳”，从数据检索、模型生成到整体系统架构三个层面同时入手：

1. 检索层优化：让查找数据更快

• HNSW 索引优化：HNSW（Hierarchical Navigable Small World）是向量数据库中最常用的近似最近邻搜索算法，能极大提升在大规模数据中的检索效率。
• 量化（Quantization）：对向量数据进行精度压缩（如从 FP32 降到 FP8 或 INT8），在略微牺牲准确率的前提下，大幅降低内存占用并提升检索速度。
• 缓存热点 Query 的检索结果：建立缓存层，对于重复或相似的高频提问（如“你们公司有哪些产品线？”），直接返回上一次已经检索到的结果，跳过向量计算过程。

2. 生成层优化：让模型出字更快

• 使用 vLLM 等推理框架：vLLM 专为大模型推理设计，通过高效的 KV Cache 管理和调度，能显著提升 LLM 的吞吐量和生成速度。
• KV Cache 复用：在长对话或多次追问的场景下，复用之前计算过的 KV 缓存，避免对相同的前缀 Prompt 进行重复计算。
• 流式输出（Streaming）：采用 SSE（Server-Sent Events）等流式传输协议，让大模型逐字吐出结果，让用户“看到”内容在实时跳动，大幅降低主观等待的焦虑感。
• Prompt 压缩：去除检索结果中的冗余废话、无效换行符和特殊标记，减少输入到大模型的总 Token 数量，从而缩短推理耗时。

3. 架构层优化：按需分配算力

• 模型路由（Model Routing）：引入一个前置的调度模块，对问题进行复杂度分析。
  • 简单问题（如问候、查简单事实）：走小模型（如 7B 甚至更小）甚至规则匹配，实现毫秒级响应。
  • 复杂问题（如多步骤推理、代码生成）：才走完整的 RAG 流程，并交由 30B/70B 以上的大模型来处理。

十一，知识库更新策略

在 RAG 系统投入生产环境后，如何保证知识库的实时性和一致性，同时又不影响现有服务的稳定性，是至关重要的。以下是两种主流且工程化的更新策略：

1. 增量更新 (Incremental Update)

• 核心机制：当业务数据发生变更（新增、修改或删除）时，只对发生变化的文档进行 Embedding 处理并更新到向量数据库中。
• 主要优势：极大地降低了工程成本。相比于每次有更新都对全量数据进行重新切分、向量化和入库（全量重建），增量更新能节省大量的算力和时间，非常适合文档频繁变动且数据量庞大的场景。

2. 双写/蓝绿部署 (Blue/Green Deployment)

• 核心机制：在更新知识库时，系统会先保留正在使用的“旧索引”（蓝环境），然后在后台并行构建包含最新数据的“新索引”（绿环境）。待新索引完全构建并测试无误后，通过路由切换将用户流量无缝指向新索引，最后再下线旧索引。
• 主要优势：零停机且保证数据一致性。这种机制确保了用户在更新期间依然能享受到稳定的检索服务，不会出现服务中断或检索到新旧数据混杂的混乱情况。

十二，为什么需要识别表格？

表格作为非结构化文档中最核心、最复杂的结构化数据之一，对其进行精准识别是 OCR（光学字符识别）和文档智能领域的重大挑战。其识别的必要性及难点主要体现在以下几个方面：

1. 格式与样式的极度多样性

表格并没有绝对统一的标准。它在尺寸、类型和样式上表现出极大的差异性：

• 视觉样式：背景填充、网格线有无、线条粗细各异。
• 结构复杂性：普遍存在多行合并、多列合并、多级表头、跨页表格等复杂情况。
• 内容异构性：单元格内可能混合文本、数字、公式甚至嵌套的小表格，增加了排版解析的难度。

2. 跨越电子与手写扫描场景

文档识别面临的对象极其广泛，不仅包括排版规整的现代电子文档，更包含了大量的历史手写扫描文档。这两者在视觉特征上存在显著差异，导致识别引擎难以用同一套逻辑完美适配。

3. 物理与成像环境的干扰

在实际扫描或拍照识别过程中，物理条件的限制会带来巨大挑战：

• 样式设计：不同年代、不同行业的排版逻辑千奇百怪。
• 光照条件：扫描件或照片常伴随阴影、反光、明暗不均，导致线条断裂或文字模糊。
• 纹理特征：纸张的褶皱、污渍、水印等背景噪声，极易被误识别为表格线条或文字。

综上所述，由于表格在结构和成像上的高度复杂性，精准地还原其行列结构与数据关联，一直是文档识别领域必须攻克的技术难题。

十三，介绍一下表格识别任务？

表格识别是将图片或文档中复杂的非结构化表格，转化为计算机可直接编辑和计算的结构化数据（如 Excel、JSON）的过程。这个过程通常包含以下两个关键步骤：

1. 表格定位 (Table Localization)

这是识别的第一步，核心任务是识别并划定表格的整体边界。
由于真实文档的排版往往非常复杂（包含大量文本、图片、嵌套表格等），系统首先需要利用目标检测算法（如 YOLO、Faster RCNN 或 Mask RCNN 等）在版面中准确地找到表格区域，并将其完整地框选出来。为了应对复杂背景，有时甚至会借助生成对抗网络（GAN）来辅助精确勾勒出表格的外轮廓。

2. 表格元素解析与结构重建 (Table Element Parsing and Structure Reconstruction)

找到表格后，需要对其内部进行深度解析，这一步又可细分为两个子任务：

• 表格单元格划分 (Cell Detection)：主要任务是精准识别并区分表格内部的各个单元格。这不仅要处理由连续线条完全包围的标准单元格，还要应对仅有部分边框，甚至是完全没有可见线条分隔的“隐形表格”。
• 表格结构理解 (Table Structure Understanding)：在划分出单元格的基础上，系统需要进一步分析单元格内的数据内容及其内在逻辑关系，明确行与列的分布规律以及单元格之间的层级关联（如多级表头、合并单元格等），最终实现对表格原始结构的高度准确还原。

十四，基于 LLM+向量库的文档对话 核心技术是什么？

这个问题的答案就藏在图片里，它其实就是在解释 RAG（检索增强生成） 的基本原理。整个流程主要由以下两个核心步骤构成：

1. 知识向量化与存储（Embedding 入库）
   将庞大的知识库文档经过 embedding 模型转化为向量，并存储到向量数据库（Vector Database）中，建立起语义索引。

2. 语义检索与提示工程（Prompt 组装）
   当用户发起提问时，系统将用户的问题同样经过 embedding 处理。接着，利用向量相关性算法（如余弦算法）在数据库中计算出最匹配的几个知识库片段。最后，将这些检索到的知识片段作为“上下文（Context）”，与用户的原始问题一起组装成一个新的 prompt，提交给大模型（LLM）进行回答。

十五，有哪些表格识别方法？

利用规则指导和图像处理技术，可以通过以下六个步骤来识别表格结构：

1. 特征增强：应用腐蚀与膨胀算法来细化和增强目标区域的边界特征。
2. 区域标记：通过分析像素连通性，确定并标记图像中的各个显著区域。
3. 线性结构描绘：实施线段检测和直线拟合技术，精确描绘出图像内的线性结构元素（即表格线）。
4. 网络构建：计算这些线性结构之间的交点，以此构建可能的边框或连接关系网络。
5. 边界合并与优化：合并初步检测到的边界框（猜测框），运用智能合并策略减少冗余并提高精度。
6. 结果筛选：根据尺寸筛选优化，剔除不符合预期大小条件的候选区域，从而获得更为准确的目标识别结果。

十六，使用 RAG 的好处？

RAG（检索增强生成）方法让开发者无需为每个特定任务重新训练大模型，只需外挂知识库即可。这不仅能大幅降低训练成本，还能为模型提供额外的信息输入，从而提高其回答的准确性，尤其适合知识密集型的任务。

其核心优势主要体现在以下八个方面：

1. 可扩展性 (Scalability)：减少了模型本身的大小和训练成本，并允许轻松、低成本地扩展知识库。
2. 准确性 (Accuracy)：模型回答时可以引用具体的信息来源，用户可以核查答案的出处，从而增强了对输出结果的信任。
3. 可控性 (Controllability)：允许随时更新或定制知识库中的知识，而无需重新训练模型。
4. 可解释性 (Interpretability)：模型检索到的项目可以作为其预测和生成内容的来源参考，使得回答更加透明。
5. 多功能性 (Versatility)：可以针对多种任务进行微调和定制，包括 QA（问答）、文本摘要、对话系统等。
6. 及时性：利用检索技术能实时识别并纳入最新的信息，在保持回答的时效性和准确性方面，比只依赖历史训练数据的传统语言模型有明显优势。
7. 定制性：通过索引特定领域的文本语料库，能够为不同专业领域提供精准的知识支持。
8. 安全性：可以通过数据库设置角色和安全控制，实现对数据使用的精细化管理。相比之下，经过微调的模型在管理数据访问权限方面往往不够明确。

十七，为什么需要 Graph RAG？

我们需要 Graph RAG，主要是为了解决传统 RAG（基于向量检索）在处理复杂逻辑、跨文档关联以及全局性总结时的固有缺陷。简单来说，传统 RAG 擅长“找相似的文本片段”，而 Graph RAG 擅长“像人类专家一样理解知识间的深层关系网”。

其必要性主要体现在以下几个方面：

1. 突破传统 RAG 的语义检索局限

• 传统 RAG 的痛点：传统 RAG 依赖 Embedding 模型对非结构化文本进行向量相似度匹配。这种方法在处理专业领域或特定语境时，容易因为字面语义相似而产生误判。
• Graph RAG 的解决之道：图片中提到的“保温大棚”与“保温杯”的例子非常典型——尽管两者在通用语义下相关性极高，但在大多数实际场景中，它们属于完全不同的领域。如果仅靠向量检索，极易引入错误的上下文，导致大模型产生“幻觉”。Graph RAG 通过引入**知识图谱（实体与关系的结构化表达）**作为一路召回，利用领域知识显式地划定边界，从而精准规避这类“语义陷阱”，减少不准确性的干扰。

2. 赋予模型“多跳推理”与“全局洞察”能力

• 连接孤立的知识点：传统 RAG 将文档切成碎片化的文本块，导致跨文档的关联信息被割裂。Graph RAG 将非结构化文本转化为“实体-关系”三元组，构建出严密的知识网络。当回答问题需要跨越多个文档或进行多步逻辑推导时，它可以像人类一样顺藤摸瓜进行多跳推理。
• 宏观总结能力：面对“总结这个数据集的核心趋势”这类宏观问题，传统 RAG 只能机械地拼凑局部文本块。而 Graph RAG 通过对图谱进行社区聚类和分层摘要，能让模型从全局视角理解数据结构，给出高度概括且全面的答案。

3. 显著提升答案的可解释性与溯源透明度

• 传统 RAG 的回答往往是一个黑盒，很难追溯其推理逻辑。Graph RAG 能够提供三级追溯机制（回答结果 -> 关联子图 -> 社区摘要 -> 原始文本）。这意味着系统可以明确告诉用户：“我是基于图谱中哪些实体关系、经过了怎样的逻辑推导，最终从哪篇文档中提取了该信息”，这在高可信度要求的严肃场景（如医疗、法律、金融风控）中至关重要。

十八，什么是 Graph RAG？它的核心思路是什么？

Graph RAG（Retrieval-Augmented Generation）是一种结合了知识图谱与大语言模型的检索增强生成技术。它不再仅仅依赖非结构化文本的向量相似度，而是通过构建图模型来表达知识，将实体和关系之间的联系用图的形式展示，从而利用大语言模型（LLM）进行更精准的检索增强。

其核心运作思路可以概括为以下两点：

1. 图谱即“超级词汇表”：
   Graph RAG 将庞大的知识图谱等价于一个超大规模的“词汇表”。在这个体系中，实体（如人名、地名、概念）和关系（如“属于”、“导致”、“位于”）就对应于传统的“单词”。通过这种方式，Graph RAG 在检索时能够以“实体”和“关系”作为最小单元进行联合建模，而非仅仅是文本片段。

2. 基于子图的上下文构建流程：
   具体的处理流程如下：

   • 提取：首先对用户输入的 Query（查询语句）进行解析，提取出其中的关键实体。
   • 构图：利用提取出的实体，在知识图谱中检索并构建出一个相关的子图（Subgraph）。这个子图包含了实体及其周边的复杂关系网络。
   • 生成：将这个结构化的子图信息转化为自然语言或特定的提示词格式，作为丰富的上下文（Context），最后送入大模型完成最终的回答生成。

十九，什么是大模型？你用过哪些大模型供应商

1. 什么是大模型？
大模型（LLM，Large Language Model）是一种拥有海量参数的深度学习模型，其参数规模通常达到数十亿甚至数千亿。这种庞大的参数量使其具备了强大的自然语言处理能力，能够深入理解人类语言并进行流畅、高质量的文本生成。

2. 常见的应用经历与供应商
在实践和应用中，接触过多种类型的大模型供应商，主要可以分为两大类：

• 云端在线 API：通过调用厂商的接口直接使用，例如 DeepSeek（如 deepseek-chat/V3）、阿里通义千问（如 qwen3-max/qwen3.7-max）以及智谱 AI（如 GLM-4-Flash）等。
• 本地部署模型：通过 Ollama 等工具在本地运行开源模型，例如 qwen3:4b 和 deepseek-r1:8b。

3. 模型调用的核心三件套
无论是云端 API 调用还是本地部署的接口交互，接入和使用一个大模型通常都离不开以下三个核心要素：

• API Key：用于身份验证的密钥。
• 模型名 (Model Name)：指定要调用的具体模型版本。
• 调用地址 (Base URL)：模型服务所在的服务端点地址。

二十，什么是 Token？Token 和字符的换算关系是怎样的？

1. 什么是 Token？
Token 是大语言模型处理文本时的最小单位，同时也是模型服务计费的基本计量单位。简单来说，模型并不是按“字”或“词”来阅读文本的，而是将文本拆解成一个个 Token 来进行理解和生成。此外，模型的上下文窗口大小（即一次能处理多少内容）也是通过 Token 数量来限制的。

2. Token 与字符的换算关系
由于中文和英文的编码方式不同，它们与 Token 的换算比例也有所差异。根据经验数据：

• 中文字符：1 个中文字符 ≈ 0.6 token
• 英文字符：1 个英文字符 ≈ 0.3 token

这意味着在同等长度下，中文消耗的 Token 数量通常多于英文。在实际使用中，建议以模型服务商提供的具体计费标准为准，因为不同的分词器（Tokenizer）算法会导致换算比例略有波动。