1. 这不是“学AI”的速成班而是一套能立刻上手写测试脚本的工程化训练体系“人工智能测试开发”这八个字最近半年在招聘平台和内推群里出现频率直线上升但绝大多数人点开岗位JD后第一反应是懵的——它既不像传统功能测试那样有明确的用例执行路径也不像算法岗那样要求扎实的数学功底更不像运维岗那样围着服务器打转。它卡在一个特别真实的缝隙里业务方急着上线大模型应用开发团队刚跑通一个RAG流程产品经理甩过来一份“支持多轮对话知识库检索结果可验证”的需求而测试工程师打开Postman发现连请求体该填什么字段都得先读三遍文档。我带过7期测试团队转型AI项目最常听到的抱怨不是“不会”而是“不知道从哪下手”——工具链太散、概念太新、验证逻辑太模糊。这个训练营标题里藏着两个关键信号“六大模块”不是知识罗列而是按真实交付节奏切分的工程阶段“10大实战项目”不是Demo堆砌而是覆盖了从单点能力验证比如用LangChain读Excel测试用例生成Playwright脚本到端到端闭环比如搭建一个能自动回归验证RAG召回准确率的智能体。它解决的不是“要不要学AI”而是“明天晨会就要汇报测试方案今天下午怎么写出第一行可运行代码”。适合三类人干了3年功能测试想突破瓶颈的工程师、刚毕业但简历里只有Selenium基础的应届生、以及技术负责人——你不需要自己写代码但必须能判断测试方案是否覆盖了Embedding漂移、Prompt注入、上下文截断这些真实风险点。核心关键词就五个人工智能、测试开发、大模型、RAG、智能体它们不是并列关系而是层层嵌套的验证对象你要测的不是“AI”而是“跑在特定架构上的AI服务”它的输入输出、状态流转、错误边界全由RAG或智能体框架定义。所以这个训练营的起点从来不是Python语法而是读懂一份LangChain调试日志里那行Retriever returned 3 documents, top_k5意味着什么。2. 内容整体设计与思路拆解为什么必须用“模块项目”双轨制2.1 拆解“六大模块”的底层逻辑拒绝知识搬运聚焦验证动作市面上90%的AI测试课程把模块设计成“大模型原理→LangChain入门→RAG构建→智能体开发→评估方法→部署监控”看似完整实则致命。我去年帮某金融客户做AI测试能力建设时发现他们的测试工程师花两周学完Transformer结构回到工位面对一个已上线的信贷审批RAG系统依然不知道该测什么——因为模型结构和业务验证之间隔着三层抽象第一层是向量数据库的索引策略比如HNSW vs IVF第二层是检索器的重排序逻辑比如Cohere Rerank vs 自研BM25语义混合第三层才是业务规则比如“拒贷理由必须包含‘收入不足’或‘负债过高’”。所以这个训练营的六大模块本质是六类必须亲手操作的验证动作模块一AI服务接口契约验证不是教你怎么调API而是训练你用OpenAPI Schema反向生成测试用例——当开发给你一份Swagger文档你能立刻识别出哪些字段是必填、哪些是枚举值、哪些字段组合会产生冲突比如top_k0和return_metadatatrue同时出现。重点练的是Postman的Tests脚本和JSON Schema校验而不是背HTTP状态码。模块二RAG流水线断点诊断把RAG拆成“文档加载→文本分割→Embedding→向量存储→检索→重排序→LLM生成”七个环节每个环节配一个故障模拟环境。比如故意把ChromaDB的n_results参数设为1但业务要求返回3个最相关片段你得用Python脚本抓取检索日志对比retrieved_docs和expected_docs的相似度得分分布而不是只看最终回答对不对。模块三大模型输出稳定性压测重点不是QPS而是同一问题连续100次请求的输出一致性。我们用真实业务问题如“根据这份合同摘要列出3条甲方违约风险”跑LangChain的RetryPolicy记录每次生成的JSON结构是否符合Schema、关键字段如risk_items数组长度是否恒定。这里会暴露很多隐藏坑比如某些开源模型在温度值设为0时反而更不稳定或者当输入token接近上限时LLM会随机截断输出。模块四智能体状态机验证智能体不是“更聪明的聊天机器人”它是有明确定义的状态迁移图。训练营里用LangGraph搭一个客服工单处理Agent你必须手动绘制它的状态图awaiting_user_input → analyzing_issue → querying_kb → drafting_response → waiting_approval然后用JUnit写状态迁移测试——比如当用户输入“我要投诉”Agent必须进入analyzing_issue状态而不是直接跳到drafting_response。这比背诵Agent框架API重要十倍。模块五评估指标工程化落地拒绝“人工打分”。教你怎么把业务指标翻译成可计算的函数比如“回答准确性”不是主观评分而是定义为len(extract_entities(answer) ∩ extract_entities(ground_truth)) / len(extract_entities(ground_truth))其中实体抽取用spaCy而非LLM确保评估过程不引入新噪声。所有评估脚本都封装成CLI工具一键跑完生成HTML报告。模块六生产环境可观测性植入测试不是上线前的最后一步而是贯穿生命周期。模块里教你在LangChain链路里埋点比如给每个RunnablePassthrough加on_chain_start回调记录输入token数、耗时、下游服务响应码用Prometheus暴露rag_retrieval_latency_seconds_bucket指标当llm_output_length突增200%自动触发告警并保存上下文快照。这才是真正的“测试左移”。提示所有模块的练习数据都来自真实脱敏项目——某电商的售后知识库RAG、某政务热线的智能体工单系统、某银行的信贷报告生成服务。没有虚构的“Hello World”只有“昨天刚上线的接口今天要回归的用例”。2.2 “10大实战项目”的筛选标准每个项目必须解决一个具体交付阻塞点项目不是为了炫技而是为了破局。我们筛掉所有“用Streamlit搭个UI”的项目只保留那些测试工程师在真实项目中卡住超过2小时的场景项目1从Excel测试用例自动生成Playwright脚本输入销售部门提供的200行Excel用例含URL、操作步骤、预期结果输出可直接执行的.spec.ts文件且能动态注入测试数据如用例中的客户ID自动替换为当前环境可用ID关键难点Excel里“点击搜索按钮”这种自然语言描述如何映射到Playwright的page.getByRole(button, { name: 搜索 })选择器我们用小型微调模型LoRA on Qwen做指令微调不是为了生成完美代码而是生成90%可用的骨架剩下10%人工补selector。项目2RAG知识库变更影响范围分析当法务部更新了100份合同模板如何快速定位哪些问答对会受影响项目教你用Sentence-BERT计算新旧文档的语义距离矩阵结合业务规则如“涉及‘违约金条款’的问答必须重测”生成影响报告和回归测试集。项目3大模型幻觉检测沙盒构建一个对抗测试环境给LLM输入“请列出2023年诺贝尔物理学奖得主”故意在提示词里埋入错误信息如“根据《自然》杂志2023年10月报道…”观察模型是否复述错误。用Diffusers生成对抗样本图片测试多模态模型重点练的是如何设计“诱导性提示”。项目4智能体循环调用熔断机制验证某客服Agent在用户反复说“我不明白”时会不断调用知识库检索→LLM生成→重试导致API调用雪崩。项目要求你用Locust模拟并发监控agent_loop_count指标当单次会话循环超3次时强制触发降级策略返回预设FAQ列表。项目5本地化RAG性能基线测试在4GB显存的RTX4060上部署Llama3-8BChromaDB测量不同chunk_size128/256/512下的首字延迟、召回率、内存占用三者平衡点。不是跑一遍就完事而是用Py-Spy抓取CPU火焰图定位瓶颈在Embedding还是向量检索。项目6Prompt注入攻击面测绘针对一个医疗问诊Agent系统性测试12类Prompt注入变体角色扮演、XML注入、Base64编码绕过等记录每种攻击的成功率和泄露信息类型如系统提示词、知识库路径。产出物是可导入Burp Suite的测试用例集。项目7多租户RAG隔离性验证某SaaS平台为不同客户部署独立RAG实例但共享同一个向量数据库。项目要求你构造跨租户查询如用客户A的API Key访问客户B的知识片段验证Embedding命名空间隔离是否生效。项目8LLM输出格式强校验工具链开发一个CLI工具输入JSON Schema和LLM原始输出自动修复格式错误如将items: [a,b]补全为{items: [a,b]}并标记不可修复的语义错误如price: free违反type: number。这比写100个正则表达式更可靠。项目9智能体决策链路回溯当Agent给出错误建议时如何还原它“为什么选这条路”项目教你用LangGraph的StateSnapshot机制保存每步调用的输入输出、调用时间、所用工具生成可交互的决策树可视化用Mermaid语法生成非图表渲染。项目10AI服务混沌工程实验在K8s集群里对RAG服务注入网络延迟tc qdisc add dev eth0 root netem delay 1000ms、内存泄漏stress-ng --vm 1 --vm-bytes 2G观察智能体是否优雅降级如切换到缓存答案并用Jaeger追踪失败请求的完整链路。注意所有项目都提供“最小可行交付物MVDO”标准——不是“代码能跑”而是“交付物能直接插入CI/CD流水线”。比如项目1的输出必须是符合Playwright v1.42规范的TypeScript文件项目5的报告必须包含latency_p95: 1240ms这样的Prometheus兼容指标。3. 核心细节解析与实操要点从LangChain调试日志开始的第一课3.1 真正的起点读懂LangChain的DEBUG日志比写代码更重要很多测试工程师卡在第一步连环境都起不来。不是因为不会装Python而是看不懂启动日志里的关键信号。比如这段典型日志DEBUG:langchain_core.runnables:Invoking runnable with config{callbacks: [langchain.callbacks.tracers.langchain.LangChainTracer object at 0x7f8b1c0d2e50], run_name: Retriever} DEBUG:langchain_community.vectorstores.chroma:Searching with query: 如何申请退款 and k3 DEBUG:langchain_community.embeddings.huggingface:HuggingFaceEmbeddings: Using model BAAI/bge-small-zh-v1.5 INFO:langchain_community.vectorstores.chroma:Found 3 documents in ChromaDB DEBUG:langchain_core.runnables:Invoking runnable with config{callbacks: [...], run_name: LLM} DEBUG:langchain_community.llms.ollama:Ollama: Using model qwen2:7b INFO:langchain_community.llms.ollama:Ollama response took 2.34s, tokens: 156新手会盯着Ollama response took 2.34s觉得慢但老手第一眼扫的是k3和Found 3 documents——如果业务要求召回5个片段这里就存在配置错位。再往下看tokens: 156结合模型上下文窗口Qwen2-7B是32K能预判当用户输入长文档时是否触发截断。训练营第一课就是带学员逐行解析这类日志建立三个检查清单检索层检查k值是否匹配业务需求Found X documents是否等于k如果不等比如k5但只找到2个说明知识库覆盖率不足或Embedding质量差LLM层检查response took Xs是否在SLA内tokens是否接近模型上限如果tokens持续25K需预警上下文溢出风险链路层检查run_name是否按预期顺序出现比如Retriever后应该接LLM如果中间插了Router说明路由逻辑被触发需检查路由条件是否合理。实操中我们会故意制造日志异常比如把ChromaDB的k参数硬编码为1但业务用例要求返回3个答案让学员通过日志定位问题而不是靠猜。这比教100个API参数更有效。3.2 RAG测试的黄金三角召回率、相关性、时效性缺一不可RAG测试最容易陷入的误区是只测“最终答案对不对”。但真实项目中90%的问题出在中间环节。我们用“黄金三角”模型定义RAG健康度召回率Recall知识库中所有相关文档被检索器找出来的比例。计算公式TP / (TP FN)其中TP是正确召回的文档数FN是漏召的文档数。测试方法人工标注100个问题的“黄金文档集”用chroma.get(where{question_id: Q1})查出实际召回文档比对交集。相关性Relevance检索器返回的文档中真正相关的比例。计算公式TP / (TP FP)FP是误召的无关文档。测试方法对每个召回文档打分0-3分2分才算相关统计平均分。时效性Timeliness从用户提问到返回答案的端到端延迟。但关键不是P95而是长尾延迟——比如90%请求1s但10%卡在3s以上。用Prometheus的histogram_quantile(0.99, rate(chroma_query_duration_seconds_bucket[1h]))抓P99。这三个指标必须联动分析。比如某次测试召回率95%但相关性仅40%说明检索器过于激进召回了很多弱相关文档如果相关性90%但时效性暴跌可能是重排序模型如Cohere Rerank拖慢了流水线。训练营里会带学员用Python脚本批量计算这三个指标并生成雷达图——当某个角塌陷时立刻知道该优化哪个组件。实操心得别信开发说的“我们用了最先进的Embedding模型”。我见过用text-embedding-3-large的项目召回率还不如用bge-small-zh-v1.5原因在于前者对中文长尾词泛化差。测试时必须用业务真实query测试而不是通用benchmark。3.3 智能体测试的核心状态验证比输出验证更关键智能体测试最大的陷阱是把Agent当成“高级LLM”来测。比如一个工单处理Agent测试用例写成“输入‘我的订单没收到’期望输出‘已为您创建工单#12345’”。这完全错了。Agent的本质是状态机它的价值在于状态迁移的确定性。正确测试方式分三步状态定义明确每个状态的进入/退出条件。比如waiting_approval状态的进入条件是LLM_output.contains(请主管审核)且user_role manager状态观测在LangGraph中启用checkpointer每次状态变更时保存StateSnapshot包含next下一步状态、messages当前消息历史、tool_calls调用的工具状态断言用Pytest写断言不是断言输出字符串而是断言状态属性。例如def test_agent_moves_to_approval_state(): state run_agent(我的订单没收到) assert state[next] [waiting_approval] assert len(state[messages]) 3 # system user assistant assert state[tool_calls][0][name] create_ticket这样测试的好处是当开发把waiting_approval改成pending_review时测试会立刻失败而不是等上线后才发现流程断了。训练营里所有智能体项目都强制要求先画状态图再写测试最后才写实现代码——倒逼开发思维结构化。3.4 大模型评估的避坑指南为什么BLEU分数毫无意义很多团队用BLEU、ROUGE这些NLP传统指标评估LLM输出结果发现分数很高但业务效果很差。根本原因是这些指标只算表面token匹配不关心语义正确性。比如问题“苹果公司CEO是谁”标准答案是“蒂姆·库克”但LLM回答“蒂姆·库克他于2011年接替史蒂夫·乔布斯”BLEU分数可能高达0.9可如果业务场景是“提取CEO姓名用于表单填充”多余信息反而导致解析失败。训练营教四类业务导向的评估法结构化提取评估用正则或spaCy提取关键字段比对是否匹配。比如从回答中提取{ceo: Tim Cook}再和Ground Truth JSON比对事实核查评估调用外部API验证事实。比如回答“珠穆朗玛峰海拔8848.86米”用地理信息API查证逻辑一致性评估对多步推理题验证中间步骤是否自洽。比如“如果AB且BC那么AC吗”回答“是”但若追问“为什么”回答“因为A最大”这就是逻辑断裂业务规则评估把业务规则编译成可执行函数。比如保险条款问答规则是“所有回答必须包含免责条款引用”写个函数检查输出是否含依据《XX条款》第X条。所有评估脚本都封装成evaluate.py --taskceo_extraction --modelqwen2:7b输出标准化JSON报告直接对接Jenkins。不追求学术指标只关注业务指标能否达标。4. 实操过程与核心环节实现以“Excel用例生成Playwright脚本”为例4.1 项目目标与约束条件不是AI生成而是AI辅助的确定性工程这个项目常被误解为“用大模型写自动化脚本”实则核心是确定性工程。我们的目标不是让AI写出100%完美的Playwright代码而是构建一个管道Excel用例 → 结构化解析 → 选择器映射 → 脚本生成 → 人工校验 → CI集成。关键约束有三条选择器必须可维护不能生成page.locator(div:nth-child(3) button)这种脆弱选择器必须基于语义如page.getByRole(button, { name: 提交 })数据注入必须安全Excel里的测试数据如邮箱、手机号要自动脱敏生成脚本时替换为process.env.TEST_EMAIL这样的环境变量输出必须可执行生成的.spec.ts文件要通过TypeScript编译且能被Playwright Test Runner直接执行。这意味着AI只负责“理解自然语言意图”不负责“生成最终代码”。我们用Qwen2-1.5B做微调训练数据是1000对样本左边是Excel里的操作描述如“在搜索框输入‘iPhone15’点击搜索按钮”右边是对应的Playwright代码片段。微调目标不是100%准确而是90%生成语义正确的骨架剩下10%由规则引擎补全。4.2 核心实现步骤四步管道每步都有防错机制步骤1Excel解析与结构化建模不用Pandas直接读Excel而是用openpyxl逐行解析因为测试用例常含合并单元格、批注等非结构化信息。关键处理用例ID提取从第一列非空单元格读取TC-001这类ID作为脚本文件名操作步骤拆解用正则r([①②③]|[1-9]\.)\s*(.*)匹配编号步骤避免AI误判“点击搜索按钮快捷键CtrlS”为两个操作预期结果标准化将“页面显示‘未找到商品’”转为expect(page.getByText(未找到商品)).toBeVisible()这样的断言语句。实操技巧Excel里常有“截图附件”列我们不处理图片而是提取图片文件名如TC-001_step3.png生成脚本时自动添加await page.screenshot({ path: screenshots/TC-001_step3.png })方便后续比对。步骤2自然语言到选择器的映射引擎这是最易出错的环节。AI可能把“搜索按钮”映射到page.getByText(搜索)但实际页面是button aria-label搜索/button。我们构建三层映射语义层用spaCy对操作描述做依存分析提取动词click、宾语search button、修饰语primaryDOM层爬取目标页面HTML用CSS选择器生成器如SelectorGadget提取所有按钮的aria-label、>- name: Run generated tests run: npx playwright test --projectchromium --grep${{ github.event.inputs.test_id }} - name: Upload test report uses: dorny/test-reporterv1 if: always() with: name: Playwright Test Report path: playwright-report/index.html reporter: playright当测试失败时自动触发Issue创建附带失败截图、控制台日志、以及原始Excel用例链接。这样测试工程师看到Issue就知道是脚本问题还是应用BUG而不是在日志里大海捞针。4.3 参数选择与性能权衡为什么选Qwen2-1.5B而不是更大模型项目初期我们试过Llama3-8B生成质量略高92%骨架正确但推理速度太慢单次生成平均8秒无法满足“编辑Excel后10秒内生成脚本”的需求。最终选Qwen2-1.5B原因有三量化友好用AWQ量化到4-bit显存占用从3.2GB降到1.1GB可在消费级显卡运行中文适配好在中文测试用例数据集上微调后准确率比Llama3高3个百分点推理稳定Llama3在长上下文2000 token时偶发OOMQwen2-1.5B无此问题。参数调优实录max_new_tokens256足够生成Playwright代码再长容易引入冗余temperature0.1降低随机性保证相同输入总是生成相同输出top_p0.95保留一定多样性避免死板重复。踩过的坑曾用temperature0.7导致同一用例多次生成不同选择器如有时用getByText有时用getByRole破坏了脚本一致性。后来强制设为0.1并加规则校验问题解决。5. 常见问题与排查技巧实录来自7个真实项目的故障库5.1 RAG召回率骤降不是模型问题而是向量数据库的“幽灵索引”现象某政务知识库RAG上线后召回率从95%跌到60%但Embedding模型和文档都没变。排查过程第一步确认ChromaDB版本。发现从v0.4.20升级到v0.4.24新版本默认启用hnsw:spacecosine而旧版本用l2距离。两种距离算法对同一向量集的排序结果差异可达40%第二步检查索引重建日志。发现运维同学用chroma.reset()清库后没重新add_documents()而是直接persist()导致索引元数据损坏第三步验证向量一致性。用collection.get(ids[doc1])取出向量与原始Embedding比对发现数值有微小漂移浮点精度误差。解决方案回滚ChromaDB到v0.4.20重建索引时强制指定distance_functionl2加入CI检查每次部署前用10个固定query跑召回P95召回率低于90%则阻断发布。经验RAG问题80%出在基础设施层不是模型层。永远先查向量数据库日志再查LLM日志。5.2 智能体无限循环状态机缺失“超时退出”状态现象客服Agent在用户连续发送“”时不断调用知识库→LLM→重试直到API限流。根因分析状态图里只有awaiting_user_input → analyzing_issue → querying_kb → drafting_response缺少max_retry_exceeded状态LangGraph的interrupt机制没启用无法在循环次数超限时强制中断LLM的system prompt里写了“请始终尝试回答”没加“最多尝试3次”。修复方案在状态图中增加retry_count字段每次循环1当retry_count 3时自动跳转到fallback_to_human状态在LangGraph里配置configurable{max_concurrent: 1, max_retries: 3}。实操心得所有智能体必须有“熔断开关”。我们给每个Agent加max_retries参数测试时用Locust模拟1000并发“”请求验证熔断是否生效。5.3 大模型输出截断不是显存不足而是Tokenizer的“隐形截断”现象Qwen2-7B在处理长合同文本时输出总在第2000字左右突然中断且无报错。深度排查查llm.invoke()返回的response对象发现content字段末尾是...但usage里completion_tokens显示已用满32768检查TokenizerQwen2用Qwen2TokenizerFast其encode()方法默认truncationTrue但llm.invoke()没传max_tokens参数导致tokenizer按自身最大长度截断验证手动调tokenizer.encode(long_text, truncationTrue, max_length32000)果然截断。解决方案在LLM调用时显式设置max_tokens32000或改用truncationFalse由LLM自身处理截断但需确保LLM支持最佳实践所有LLM调用必须带max_tokens参数且值模型上下文窗口-预留空间如32768-1024。提示不同模型Tokenizer行为差异极大。Llama3用LlamaTokenizer截断逻辑不同必须针对每个模型单独验证。5.4 Playwright脚本执行失败不是选择器错误而是Shadow DOM穿透问题现象生成的page.getByRole(button, { name: 提交 })在本地Chrome能跑但在CI的Docker容器里失败。真相揭露CI用的是Playwright自带的Chromium版本v112本地Chrome是v118新版本对Shadow DOM的attachShadow()支持更好目标页面用Web Components提交按钮在Shadow Root里旧版Chromium无法穿透。解决路径升级CI的Playwright到v1.42支持Shadow DOM或改用page.locator(shadowsubmit-button button)这种Shadow DOM专用选择器最终方案在脚本生成时自动检测页面是否有Shadow DOM用page.evaluate(() document.querySelector(my-component).shadowRoot ! null)有则用专用选择器。教训自动化测试环境必须和生产环境一致。我们后来在CI里加了playwright version检查版本不匹配直接失败。5.5 评估指标失真人工标注的“认知偏差”污染数据集现象RAG评估报告显示相关性95%但业务方反馈答案质量差。调查发现评估用的“黄金文档集”由3个测试工程师人工标注他们习惯性给技术文档打高分但业务用户更关注操作步骤是否清晰某个问题“如何重置路由器密码”标注员认为“查看说明书第5页”相关但用户需要的是“按Reset键10秒”这样的具体动作。改进措施引入业务方参与标注用“用户视角打分表”1-5分1分完全无法指导操作对标注员做一致性校验随机抽20%用例让3人独立打分Kappa系数0.7则重新培训评估时加权操作类问题权重0.8概念类问题权重0.2。关键认知评估指标不是客观真理而是业务共识的量化。没有业务方参与的评估都是空中楼阁。6. 工具链与生态选型为什么坚持用LangChainPlaywrightChromaDB组合6.1 LangChain不是因为它“最火”而是因为它“最可控”很多人质疑“LangChain太重不如直接调API”但测试开发恰恰需要它的“重”。原因有三可观测性内置LangChainTracer能自动记录每个Runnable的输入输出、耗时、错误无需额外埋点调试友好invoke()方法支持debugTrue直接打印完整执行链路比自己写日志省力十倍生态统一所有组件Retriever、LLM、Tool都遵循Runnable协议测试代码可以复用——测RAG的invoke()方法和测智能体的invoke()方法调用方式完全一样。我们对比过LlamaIndex它在检索性能上略优但调试日志碎片化很难追踪“为什么这个文档没被召回”。而LangChain的LangChainTracer日志是线性的一眼就能看出断点在哪。6.2 Playwright超越Selenium的“确定性”保障选Playwright不为新潮为两点硬需求自动等待page.getByRole(button).click()会自动等待元素可见、可点击不用写waitForSelector大幅降低脚本脆弱性多浏览器一致性在Chromium、Firefox、WebKit上行为一致避免“Chrome能跑Firefox失败”的尴尬。实测数据同样100个用例Playwright脚本维护成本比Selenium低60%因为90%的等待逻辑由框架自动处理。6.3 ChromaDB轻量级向量数据库的“够用就好”哲学不选Milvus或Weaviate因为部署简单单进程启动pip install chromadb即可CI环境零配置Python原生不用REST API直接collection.add()调试时可collection.peek()查数据够用性能百万级文档下P95召回延迟100ms满足RAG实时性要求。当然它不适合亿级数据但训练营所有项目都在10万文档规模内ChromaDB是性价比最优解。最后分享一个小技巧