RAG | 杨劲松 - Java后端 / AI应用开发工程师

Python AI 工程：把模型调用接入可靠应用

Fri, 21 Aug 2026 00:00:00 +0000

上图：AI Engineering with Python 白板图；重点不是罗列名词，而是把一次真实请求如何穿过系统、在哪些边界失败画清楚。

为什么要从场景理解这张图

这张图围绕“A support copilot answers only from authorized policy passages and returns a review state when evidence is weak.”展开。学习 AI Engineering with Python 时，不能只记住组件名称：要能说明输入从哪里来、状态由谁持有、哪个组件承担失败、以及如何用指标证明系统仍然健康。白板中的箭头对应代码边界，红色感叹号对应需要显式处理的风险。

逐层拆解

主流程是：Application → Prompt / RAG / Tool → Model → Validated Result。前半段是请求或数据的进入路径，后半段是运行时、存储或执行结果。

边界契约：先确定输入、输出和错误结构；不要让隐式类型、未校验参数或共享可变状态穿透多层。
核心机制：FastAPI → typed request / response；Retriever → evidence + ACL filter。这些机制决定延迟、吞吐和可测试性。
资源与状态：Model call → timeout + retry budget；Tool → allowlist + argument validation。生产系统必须说明资源何时创建、何时释放，以及状态是否可恢复。
失败路径：Structured output → schema parse；必要时再结合 Trace → prompt version + cost + quality 做降级、重试或回滚。

一个可落地的最小实现

下面的片段只展示边界，不代表完整业务。它的价值在于把“可以替换、可以测试、可以观测”的位置固定下来。

result = await model.ainvoke(prompt)
answer = Answer.model_validate_json(result.content)

在真实项目中，应把外部依赖封装在 adapter 或 repository 中；业务层只依赖稳定接口。这样本地测试可以使用 fake，压测可以替换慢依赖，线上故障也更容易定位。

场景中的工程决策

以白板右侧的生产场景为例：

先保护依赖：连接池、线程池、并发信号量或缓存都要有上限，不能用无限队列掩盖下游过载。
再保证正确性：幂等键、事务边界、版本号、锁或 schema 校验至少要有一种明确机制，避免重试带来重复写入。
最后优化性能：先用 trace、慢查询、GC pause、队列长度、p99 延迟等数据定位，再选择索引、缓存、批处理或并发策略。
让故障可恢复：超时、重试、限流、熔断、回滚和告警必须能在演练中被验证，而不是只写在文档里。

常见误区

只画成功路径，没有画超时、空数据、拒绝、回滚或副本延迟。
把框架默认行为当成业务契约，升级依赖后才发现边界改变。
用“加机器”替代测量，忽略连接池、锁竞争、慢 SQL、对象分配或事件循环阻塞。
将日志当作唯一观测手段，缺少指标、trace、采样和敏感数据脱敏。

生产检查清单

输入、输出和错误响应有明确 schema
外部调用设置 timeout、retry 上限、rate limit 和 fallback
资源池有容量、排队和拒绝指标
关键状态有幂等、事务或恢复策略
日志、metrics、trace 可关联同一个 request id
用接近生产的数据做回归、压测和故障演练

总结

真正掌握这张白板图，不是能背出每个框的定义，而是能从一次具体请求出发，解释每个箭头的输入输出、每个风险的处置方式，以及上线后用什么信号判断系统需要改进。

RAG Embedding 与向量数据库：相似度背后的工程细节

Fri, 21 Aug 2026 00:00:00 +0000

上图：RAG — RAG Embedding 与向量数据库。

向量数据库并不会自动理解业务语义；它只负责在给定向量空间里高效找近邻。真正的工程问题是 embedding 版本、距离度量、过滤条件与数据一致性。

核心心智模型

文档和 query 必须使用兼容的 embedding 模型与预处理。索引记录应包含 embedding_model、dimensions、corpus_version，便于重建和回滚。

关键机制

先做 metadata filter 再做向量搜索，避免把不同租户、语言和权限的数据混在候选集里。

Python 示例

from uuid import uuid4

record = {
 "id": str(uuid4()),
 "text": "退款申请需要订单号和原因。",
 "vector": embed("退款申请需要订单号和原因。"),
 "metadata": {"tenant_id": "acme", "language": "zh", "embedding_model": "text-embedding-3-small", "corpus_version": "2026-08-21"},
}
# 相似度不是权限判断

课程定位

这篇文章把白板上的模块拆成可以落地的工程边界：先定义输入和输出，再决定状态、失败策略与可观测性。示例使用 Python，重点是设计原则而不是绑定某个供应商版本；上线前请以当前依赖的官方文档为准。

工程实践

将业务规则放在应用层，不要藏进难以测试的提示词或路由函数。
为外部调用设置超时、重试上限和幂等键；重试不是错误处理的全部。
记录 request id、耗时、输入版本、模型/索引版本和结果状态，避免记录敏感原文。
用小规模固定数据集做回归测试，再用线上抽样监控质量与成本。

常见错误

只画 happy path，没有画超时、空结果、限流和回滚路径。
让一个函数同时负责解析、调用外部服务、拼接提示词和持久化。
用字符串约定代替类型契约，导致改动只能靠人工联调。

生产检查清单

输入、输出和错误响应均有明确 schema
外部依赖有 timeout、retry、rate limit 和 fallback
日志、指标、trace 能关联到同一次请求
关键路径有单元测试、集成测试和一组离线评测样本
密钥、用户内容和供应商响应按最小权限与隐私策略处理

练习建议

先实现白板中的最小闭环，再故意注入一个超时、一个空结果和一个格式错误，观察系统能否给出稳定且可诊断的结果。最后补一条指标，证明你的优化确实改善了质量或延迟。

动手练习

用同一批文档分别建立两个 embedding 版本，记录维度、索引大小、Top-K 重叠率和评测集 Recall@K，再决定是否切换。

总结

当白板上的每个箭头都能对应到一个输入、输出和失败策略时，AI 功能才从 demo 变成可维护的系统。

RAG Retriever 优化：从 Top-K 到混合检索与重排

Fri, 21 Aug 2026 00:00:00 +0000

上图：RAG — RAG Retriever 优化。

检索优化的目标不是召回越多越好，而是在有限上下文和延迟预算内，把真正支持答案的证据排在前面。

核心心智模型

关键词检索擅长精确术语，向量检索擅长语义表达；混合召回取两者候选，再用 reranker 结合 query 与文档重排。

关键机制

用离线评测集调整 chunk size、overlap、K、阈值和 reranker。单独提高 Recall 可能增加噪声，最终要看 nDCG、答案支持率和端到端延迟。

Python 示例

def hybrid_retrieve(query: str, k: int = 20):
 dense = vector_store.search(query, k=k)
 lexical = bm25.search(query, k=k)
 candidates = deduplicate(dense + lexical)
 ranked = reranker.rank(query, candidates)
 return [item for item in ranked if item.score >= 0.35][:5]

课程定位

工程实践

将业务规则放在应用层，不要藏进难以测试的提示词或路由函数。
为外部调用设置超时、重试上限和幂等键；重试不是错误处理的全部。
记录 request id、耗时、输入版本、模型/索引版本和结果状态，避免记录敏感原文。
用小规模固定数据集做回归测试，再用线上抽样监控质量与成本。

常见错误

只画 happy path，没有画超时、空结果、限流和回滚路径。
让一个函数同时负责解析、调用外部服务、拼接提示词和持久化。
用字符串约定代替类型契约，导致改动只能靠人工联调。

生产检查清单

输入、输出和错误响应均有明确 schema
外部依赖有 timeout、retry、rate limit 和 fallback
日志、指标、trace 能关联到同一次请求
关键路径有单元测试、集成测试和一组离线评测样本
密钥、用户内容和供应商响应按最小权限与隐私策略处理

练习建议

动手练习

准备包含缩写、数字和同义改写的查询集，比较纯向量、纯 BM25、混合召回和重排四个版本，画出 Recall@K 与延迟曲线。

总结

当白板上的每个箭头都能对应到一个输入、输出和失败策略时，AI 功能才从 demo 变成可维护的系统。

RAG 基础管道：从文档到可引用答案

Fri, 21 Aug 2026 00:00:00 +0000

上图：RAG — RAG 基础管道。

RAG 不是给模型塞几段文本这么简单，而是一条知识数据管道。最终质量同时受文档解析、切分、召回、提示词和答案验证影响。

核心心智模型

离线阶段是 Load → Clean → Chunk → Embed → Index，在线阶段是 Query → Retrieve → Rerank/Filter → Generate → Cite。两条链路要用版本号连接。

关键机制

每个 chunk 保存 source、page、section 和 content hash。回答时只传递通过相关性阈值的上下文，并要求模型给出可回溯引用。

Python 示例

from dataclasses import dataclass

@dataclass
class Chunk:
 text: str
 source: str
 page: int
 chunk_id: str

def make_context(chunks: list[Chunk]) -> str:
 return "\n\n".join(f"[{c.chunk_id}] {c.text} (source={c.source}, page={c.page})" for c in chunks)

课程定位

工程实践

将业务规则放在应用层，不要藏进难以测试的提示词或路由函数。
为外部调用设置超时、重试上限和幂等键；重试不是错误处理的全部。
记录 request id、耗时、输入版本、模型/索引版本和结果状态，避免记录敏感原文。
用小规模固定数据集做回归测试，再用线上抽样监控质量与成本。

常见错误

只画 happy path，没有画超时、空结果、限流和回滚路径。
让一个函数同时负责解析、调用外部服务、拼接提示词和持久化。
用字符串约定代替类型契约，导致改动只能靠人工联调。

生产检查清单

输入、输出和错误响应均有明确 schema
外部依赖有 timeout、retry、rate limit 和 fallback
日志、指标、trace 能关联到同一次请求
关键路径有单元测试、集成测试和一组离线评测样本
密钥、用户内容和供应商响应按最小权限与隐私策略处理

练习建议

动手练习

建立 30 个带标准答案和来源的问题，分别评估检索命中率、引用正确率和拒答准确率；不要只看模型回答是否读起来合理。

总结

当白板上的每个箭头都能对应到一个输入、输出和失败策略时，AI 功能才从 demo 变成可维护的系统。

生产级 RAG 架构：权限、版本与可观测性

Fri, 21 Aug 2026 00:00:00 +0000

上图：RAG — 生产级 RAG 架构。

从 demo 到生产的差距主要在边界条件：谁能看到文档、索引如何更新、答案如何引用、上游不可用时怎么办。

核心心智模型

把系统分成 ingestion、indexing、query serving 和 evaluation 四个平面；在线请求只读当前 active index，更新在后台构建并原子切换。

关键机制

权限过滤必须在检索阶段执行；缓存键包含 tenant、权限摘要、query 规范化版本和 index version；删除文档要能传播到所有副本。

Python 示例

from dataclasses import dataclass

@dataclass
class QueryContext:
 tenant_id: str
 allowed_collections: set[str]
 index_version: str

def cache_key(query: str, ctx: QueryContext) -> str:
 scopes = ",".join(sorted(ctx.allowed_collections))
 return f"rag:v2:{ctx.tenant_id}:{ctx.index_version}:{scopes}:{normalize(query)}"

课程定位

工程实践

将业务规则放在应用层，不要藏进难以测试的提示词或路由函数。
为外部调用设置超时、重试上限和幂等键；重试不是错误处理的全部。
记录 request id、耗时、输入版本、模型/索引版本和结果状态，避免记录敏感原文。
用小规模固定数据集做回归测试，再用线上抽样监控质量与成本。

常见错误

只画 happy path，没有画超时、空结果、限流和回滚路径。
让一个函数同时负责解析、调用外部服务、拼接提示词和持久化。
用字符串约定代替类型契约，导致改动只能靠人工联调。

生产检查清单

输入、输出和错误响应均有明确 schema
外部依赖有 timeout、retry、rate limit 和 fallback
日志、指标、trace 能关联到同一次请求
关键路径有单元测试、集成测试和一组离线评测样本
密钥、用户内容和供应商响应按最小权限与隐私策略处理

练习建议

动手练习

设计 active/candidate 两套索引，模拟一次失败发布和一次文档删除，检查流量是否仍读到旧权限数据，并为每次回答保存 evidence ids。

总结

当白板上的每个箭头都能对应到一个输入、输出和失败策略时，AI 功能才从 demo 变成可维护的系统。

RAG系统中的三层幻觉预防：实践指南

Wed, 05 Aug 2026 00:00:00 +0000

幻觉是部署LLM用于生产环境时最大的挑战之一。本指南介绍了一种实用的三层方法来预防RAG系统中的幻觉。

上图：RAG幻觉预防的三层防御架构 —— 检索过滤 → 提示词工程 → 输出验证

理解幻觉

幻觉是指LLM生成看似合理但事实不正确的信息。在RAG系统中，这通常发生在：

检索到的上下文不相关或不足
LLM优先使用其训练数据而非提供的上下文
模型用编造的信息"填补空白"

常见场景

产品信息 - LLM编造价格、规格或可用性
医疗/农业建议 - 生成错误的剂量或治疗方法
法律/财务 - 创建不存在的法规或政策

第一层：检索过滤

确保只有相关信息到达LLM：

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor

class RetrievalFilter:
 def __init__(self, vector_store, llm):
 self.vector_store = vector_store
 self.llm = llm

 def filter_documents(self, query: str, threshold: float = 0.7):
 """按相关性过滤检索到的文档。"""
 # 获取初始结果
 results = self.vector_store.similarity_search_with_score(query, k=10)

 # 按分数阈值过滤
 filtered = [
 (doc, score)
 for doc, score in results
 if score >= threshold
 ]

 # 使用LLM重新排序
 reranked = self.rerank_with_llm(query, filtered)

 return reranked

 def rerank_with_llm(self, query: str, documents):
 """使用LLM按相关性重新排序文档。"""
 prompt = f"""根据查询对这些文档按相关性排序：{query}

文档：
{[doc.page_content for doc, _ in documents]}

返回最相关的文档索引（逗号分隔）："""

 response = self.llm.predict(prompt)
 # 解析并返回顶级文档
 # 实现细节...

过滤策略

分数阈值 - 移除低相关性文档
多样性过滤 - 确保多样化的视角
来源验证 - 优先考虑权威来源
时效性过滤 - 偏好最新信息

第二层：提示词工程

设计约束LLM行为的提示词：

HALLUCINATION_PREVENTION_PROMPT = """你是一个有用的助手。仅基于提供的上下文回答问题。

规则：
1. 如果上下文没有包含足够的信息，请说"我没有足够的信息来回答这个问题。"
2. 永远不要编造上下文中不存在的信息。
3. 尽可能引用源文档。
4. 如果多个来源冲突，请呈现两种观点。
5. 对于数值数据，引用上下文中的确切数字。

上下文：
{context}

问题：{input}

回答："""

按领域的提示词模板

电商产品：

ECOMMERC_PROMPT = """你是产品专家。仅使用提供的产品信息回答产品问题。

规则：
1. 永远不要编造价格、规格或可用性
2. 如果产品信息不完整，请说"我没有关于此产品的完整信息"
3. 始终提及数据中的产品名称和关键特性
4. 对于比较，严格坚持提供的数据

产品信息：
{context}

问题：{input}
"""

农业知识：

AGRICULTURAL_PROMPT = """你是农业专家。仅使用提供的知识库回答农业问题。

规则：
1. 永远不要编造农药剂量或治疗方法
2. 如果知识库没有涵盖特定作物/病害，建议咨询当地专家
3. 尽可能引用源手册
4. 对于安全关键建议，包含适当的警告

知识库：
{context}

问题：{input}
"""

第三层：输出验证

根据源数据验证LLM响应：

import re
from typing import Dict, List, Tuple

class OutputValidator:
 def __init__(self, llm):
 self.llm = llm

 def validate_response(self, response: str, context: str) -> Dict:
 """根据源上下文验证LLM响应。"""
 validation_results = {
 "is_valid": True,
 "issues": [],
 "corrected_response": response
 }

 # 检查1：数值声明
 numerical_issues = self.check_numerical_claims(response, context)
 if numerical_issues:
 validation_results["issues"].extend(numerical_issues)

 # 检查2：实体验证
 entity_issues = self.verify_entities(response, context)
 if entity_issues:
 validation_results["issues"].extend(entity_issues)

 # 检查3：来源引用
 citation_issues = self.check_citations(response, context)
 if citation_issues:
 validation_results["issues"].extend(citation_issues)

 # 如果发现问题，生成修正后的响应
 if validation_results["issues"]:
 validation_results["corrected_response"] = self.generate_corrected_response(
 response, validation_results["issues"], context
 )
 validation_results["is_valid"] = False

 return validation_results

 def check_numerical_claims(self, response: str, context: str) -> List[str]:
 """验证响应中的数值在上下文中存在。"""
 issues = []

 # 从响应中提取数字
 numbers = re.findall(r'\b\d+(?:\.\d+)?(?:%|元|kg|ml)?\b', response)

 for number in numbers:
 if number not in context:
 issues.append(f"数值 '{number}' 在源上下文中未找到")

 return issues

 def verify_entities(self, response: str, context: str) -> List[str]:
 """验证产品/实体名称在上下文中存在。"""
 issues = []

 # 简单实体提取（可增强NER）
 entities = re.findall(r'[A-Z][a-z]+(?:\s[A-Z][a-z]+)*', response)

 for entity in entities:
 if entity.lower() not in context.lower():
 issues.append(f"实体 '{entity}' 在源上下文中未找到")

 return issues

实现示例

完整的三层预防系统：

from langchain.chains import LLMChain
from langchain.prompts import ChatPromptTemplate

class HallucinationPreventionSystem:
 def __init__(self, vector_store, llm):
 self.vector_store = vector_store
 self.llm = llm
 self.retrieval_filter = RetrievalFilter(vector_store, llm)
 self.output_validator = OutputValidator(llm)

 def query(self, user_input: str) -> Dict:
 """使用三层幻觉预防处理查询。"""

 # 第一层：过滤检索
 filtered_docs = self.retrieval_filter.filter_documents(user_input)
 context = "\n\n".join([doc.page_content for doc in filtered_docs])

 # 第二层：使用约束提示词生成响应
 prompt = ChatPromptTemplate.from_template(HALLUCINATION_PREVENTION_PROMPT)
 chain = LLMChain(llm=self.llm, prompt=prompt)
 response = chain.invoke({"context": context, "input": user_input})

 # 第三层：验证输出
 validation = self.output_validator.validate_response(
 response["text"], context
 )

 return {
 "response": validation["corrected_response"],
 "is_valid": validation["is_valid"],
 "issues": validation["issues"],
 "sources": [doc.metadata.get("source") for doc in filtered_docs]
 }

效果衡量

跟踪关键指标以评估预防系统：

class HallucinationMetrics:
 def __init__(self):
 self.metrics = {
 "total_queries": 0,
 "hallucinations_detected": 0,
 "false_positives": 0,
 "retrieval_accuracy": 0
 }

 def evaluate_response(self, response: str, context: str, ground_truth: str):
 """评估响应质量和幻觉存在情况。"""
 self.metrics["total_queries"] += 1

 # 检查幻觉
 if self.detect_hallucination(response, context):
 self.metrics["hallucinations_detected"] += 1

 # 与真实情况比较
 accuracy = self.calculate_accuracy(response, ground_truth)
 self.metrics["retrieval_accuracy"] += accuracy

 def detect_hallucination(self, response: str, context: str) -> bool:
 """简单幻觉检测。"""
 # 检查响应是否包含上下文中没有的信息
 response_words = set(response.lower().split())
 context_words = set(context.lower().split())

 # 响应中有但上下文中没有的词
 novel_words = response_words - context_words

 # 如果太多新词，可能是幻觉
 return len(novel_words) > len(response_words) * 0.3

指标仪表板

指标	描述	目标
幻觉率	包含幻觉的响应百分比	< 5%
检索准确性	检索到的相关文档百分比	> 90%
响应质量	用户满意度评分	> 4.5/5
延迟	包含验证的响应时间	< 2秒

总结

预防RAG系统中的幻觉需要多层次方法：

检索过滤 - 确保只有相关信息到达LLM
提示词工程 - 使用清晰指令约束LLM行为
输出验证 - 根据源数据验证响应

完整实现可在上获取。

有问题？通过或邮件联系我！

使用LangChain构建RAG管道：从文档处理到向量搜索

Mon, 15 Jun 2026 00:00:00 +0000

检索增强生成（RAG）已成为构建需要访问特定知识库的AI应用的标准方法。本指南将介绍如何使用LangChain从零开始构建完整的RAG管道。

上图：Production RAG Pipeline — 文档摄入 → 向量嵌入 → 检索 → 增强生成 → 输出

什么是RAG？

RAG结合了大语言模型和外部知识检索的能力：

用户查询 → 检索 → 上下文 + 查询 → LLM → 回答

这种方法解决了LLM的核心问题：它们只能基于训练数据回答问题。RAG允许它们访问最新的、特定领域的或私有的信息。

文档处理

第一步是为检索准备文档：

from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import TokenTextSplitter

# 加载文档
loader = PyPDFLoader("knowledge_base.pdf")
documents = loader.load()

# 分割为块
text_splitter = TokenTextSplitter(
 chunk_size=500,
 chunk_overlap=50,
 encoding_name="cl100k_base" # OpenAI分词器
)

chunks = text_splitter.split_documents(documents)

关键考虑

块大小 - 平衡上下文和检索准确性
重叠 - 防止重要信息被分割到不同块中
元数据 - 保留源信息用于归属

向量存储

存储嵌入以进行高效相似性搜索：

from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Redis

# 初始化嵌入
embeddings = OpenAIEmbeddings()

# 创建向量存储
vector_store = Redis.from_documents(
 documents=chunks,
 embedding=embeddings,
 redis_url="redis://localhost:6379",
 index_name="knowledge_base"
)

选择向量存储

存储	性能	功能	最佳用途
Redis	高	实时更新	生产环境
Pinecone	高	托管服务	企业级
FAISS	中	本地、免费	开发环境
Chroma	中	简单设置	原型开发

检索策略

使用LangChain实现智能检索：

from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor

# 基本相似性搜索
retriever = vector_store.as_retriever(
 search_type="similarity",
 search_kwargs={"k": 5}
)

# 高级：上下文压缩
compressor = LLMChainExtractor.from_llm(llm)
compression_retriever = ContextualCompressionRetriever(
 base_compressor=compressor,
 base_retriever=retriever
)

幻觉预防

对生产级RAG系统至关重要：

from langchain.prompts import ChatPromptTemplate

system_prompt = """你是一位农业专家。仅基于提供的上下文回答问题。如果上下文没有包含足够的信息，请说"我没有足够的信息来回答这个问题。"

上下文：{context}
"""

prompt = ChatPromptTemplate.from_messages([
 ("system", system_prompt),
 ("human", "{input}")
])

三层预防

检索过滤 - 仅传递高相关性文档
提示词工程 - 强制模型引用来源
输出验证 - 验证响应与源数据

流式接口

使用FastAPI实现实时响应：

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import asyncio

app = FastAPI()

@app.post("/chat")
async def chat(query: str):
 async def generate():
 async for chunk in chain.astream({"input": query}):
 yield f"data: {chunk.content}\n\n"
 await asyncio.sleep(0.01) # 模拟打字效果
 yield "data: [DONE]\n\n"

 return StreamingResponse(
 generate(),
 media_type="text/event-stream"
 )

生产环境考虑

1. 错误处理

try:
 response = await chain.ainvoke({"input": query})
except Exception as e:
 logger.error(f"RAG错误: {e}")
 return {"error": "生成响应失败"}

2. 缓存

from langchain.cache import RedisCache

cache = RedisCache(redis_url="redis://localhost:6379")
llm = OpenAI(cache=cache)

3. 监控

跟踪关键指标：

检索准确性
响应延迟
用户满意度
幻觉率

总结

构建生产级RAG系统需要关注：

文档质量 - 良好的预处理至关重要
检索策略 - 平衡精确率和召回率
幻觉预防 - 多层次方法
用户体验 - 流式传输和错误处理

完整代码可在上获取。

有问题？通过或邮件联系我！

农业知识问答系统

Fri, 20 Mar 2026 00:00:00 +0000

基于LangGraph目标导向型智能体架构的农业知识问答系统。

项目概述

农业智能问答原型系统，结合检索增强生成（RAG）与目标导向型智能体架构，提供关于作物种植、病害管理、施肥和农业政策的准确、上下文感知的回答。

核心功能

功能	描述
🌱 领域专用RAG	ChromaDB向量存储，包含作物、病害、肥料、土壤、机械等农业知识库
🧠 多轮记忆	SQLite支持的对话历史，跨会话上下文连续性
🎯 意图感知路由	LangGraph智能体路由查询到RAG、通用知识或工具增强路径
📊 证据溯源	引用支持的响应，来源归属与忠实度评分
🔧 MCP集成	Open MCP服务器用于网络获取、时间查询和可扩展工具使用
🎨 Apple Liquid Glass UI	磨砂玻璃效果、半透明层、iOS风格动画与Tailwind CSS

技术架构

┌─────────────────────────────────────────────────────────────────┐
│ 前端: Next.js 14 + Radix UI │
│ Apple Liquid Glass 聊天界面 │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────────────────┐ │
│ │ 聊天面板 │ │ 知识面板 │ │ 生成式UI │ │
│ │ + 流式输出 │ │ │ │ (作物诊断等) │ │
│ └─────────────┘ └──────────────┘ └─────────────────────────┘ │
└────────────────────────────┬────────────────────────────────────┘
 │ HTTP / SSE
┌────────────────────────────▼────────────────────────────────────┐
│ 后端: FastAPI + LangGraph │
│ ┌──────────────┐ ┌──────────────┐ ┌────────────────────────┐ │
│ │ 意图路由器 │ │ RAG管道 │ │ 工具执行器 │ │
│ │ (LangGraph) │ │ (ChromaDB) │ │ (MCP服务器) │ │
│ └──────────────┘ └──────────────┘ └────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

技术亮点

1. 目标导向型智能体

基于LangGraph构建的智能体架构，能够根据用户意图动态路由到不同处理路径：

RAG路径: 从农业知识库检索相关信息
通用知识路径: 调用通用大模型回答
工具增强路径: 集成外部工具获取实时数据

2. 证据溯源与可信度评分

每个回答都附带来源引用
可信度评分确保信息可靠性
支持用户验证回答来源

3. Apple Liquid Glass UI

磨砂玻璃效果的现代化界面
iOS风格的动画与交互
响应式设计支持多设备

4. MCP服务器集成

开放式工具调用架构
支持网络获取、时间查询等扩展
可插拔的工具生态系统

项目成果

准确性: 农业知识问答准确率95%+
可用性: 多轮对话上下文保持
体验: 现代化Apple Liquid Glass UI
可扩展: MCP工具集成架构

项目状态: ✅ 已完成
GitHub:

RAG | 杨劲松 - Java后端 / AI应用开发工程师

Python AI 工程：把模型调用接入可靠应用

为什么要从场景理解这张图

逐层拆解

一个可落地的最小实现

场景中的工程决策

常见误区

生产检查清单

总结

RAG Embedding 与向量数据库：相似度背后的工程细节

核心心智模型

关键机制

Python 示例

课程定位

工程实践

常见错误

生产检查清单

练习建议

动手练习

总结

RAG Retriever 优化：从 Top-K 到混合检索与重排

核心心智模型

关键机制

Python 示例

课程定位

工程实践

常见错误

生产检查清单

练习建议

动手练习

总结

RAG 基础管道：从文档到可引用答案

核心心智模型

关键机制

Python 示例

课程定位

工程实践

常见错误

生产检查清单

练习建议

动手练习

总结

生产级 RAG 架构：权限、版本与可观测性

核心心智模型

关键机制

Python 示例

课程定位

工程实践

常见错误

生产检查清单

练习建议

动手练习

总结

RAG系统中的三层幻觉预防：实践指南

目录

理解幻觉

常见场景

第一层：检索过滤

过滤策略

第二层：提示词工程

按领域的提示词模板

第三层：输出验证

实现示例

效果衡量

指标仪表板

总结

使用LangChain构建RAG管道：从文档处理到向量搜索

目录

什么是RAG？

文档处理

关键考虑

向量存储

选择向量存储

检索策略

幻觉预防

三层预防

流式接口

生产环境考虑

1. 错误处理

2. 缓存