我做AI搜索搭建时，常被问到一个问题：这东西和传统搜索差别在哪。我的理解很直接，传统搜索帮人找链接，生成式检索帮人拿答案。这一章我想把地图摊开，讲清核心概念、系统架构、需求拆解和选型思路，让后面动手搭建时少走弯路。
1.1 AI搜索搭建的核心概念、价值与适用场景
我理解AI搜索搭建，核心是把“找链接”变成“给答案”。传统搜索里，用户输入关键词，系统靠倒排索引、BM25、点击日志做排序，返回十条蓝色链接。生成式检索里，用户可以用自然语言提问，系统先理解意图，再去知识库里召回片段，交给LLM组织成答案，顺手给出引用。这个变化听起来轻，落地很重。
站在我的产品视角，AI搜索搭建的价值在长尾问题和多轮追问。客服知识库、企业内部文档、电商导购、开发者文档、法律与医疗资料，都有大量表述不统一的问题。关键词搜不到，语义检索能靠近；传统搜索给链接，生成式检索给可读答案。我的运营朋友更在意另一个点：用户愿不愿意继续问。
适用场景要看数据形态和答案要求。文档多、更新频繁、权限复杂、答案需要引用来源，这些场景适合AI搜索搭建。精确ID查询、强事务列表、极低延迟的简单筛选，传统搜索或数据库查询更稳。我的经验是，把AI搜索搭建放在“知识密集、表达多样、人工查找成本高”的地方，收益更明显。
1.2 AI搜索系统的基本架构与关键模块
我画AI搜索搭建架构图时，会把它拆成离线链路和在线链路。离线侧做数据接入、解析、清洗、切分、向量化、索引构建与更新。在线侧做query理解、召回、重排、LLM生成、引用拼装、缓存和反馈回流。两条链路像水管和净水器，任何一段堵住，答案都会变味。
从后端工程视角，关键模块包括文档解析器、切分器、嵌入模型、向量数据库、关键词索引、混合检索器、重排模型、LLM服务、权限过滤器、审计日志和监控面板。向量数据库负责语义召回，关键词索引负责精确匹配，重排模型负责把更相关的片段推到前面。权限过滤器很容易被忽略，企业搜索里它经常决定项目能不能上线。
从业务和运营视角，AI搜索搭建还需要反馈按钮、bad case回收、答案引用、会话管理和评估集。用户点“有用”或“没用”，运营同学把坏例子整理出来，工程同学调切分、召回或提示词。缺少这套闭环，系统只能算演示。我的体会是，架构图上的模块越清楚，后面排障越省力。
1.3 AI搜索搭建的常见需求拆解与技术选型思路
我接到AI搜索搭建需求，会先问一串很具体的问题。用户是谁，问什么类型的问题，数据在哪些系统，规模多大，更新频率多高，延迟预算多少，单次成本能接受多少，要不要私有化，要不要引用来源，要不要多轮对话，权限怎么控。这些问题不问清，后面选型会飘。
技术选型像搭积木，不是挑一个最火的模型就结束。RAG框架、向量数据库、嵌入模型、重排模型、LLM、编排层、缓存、监控，各自解决一段问题。小团队可以从托管LLM加pgvector起步，快速验证。中大型团队面对海量文档和高并发，常会看Milvus、Qdrant、Weaviate这类向量库，再配混合检索和重排。开源方案很多，组合方式可以在后续教程里展开。
我会把评估指标放在选型前面。召回率、MRR、答案正确率、引用准确率、P95延迟、单次成本、人工介入率，这些数字比“感觉聪明”可靠。我的踩坑经验是，AI搜索搭建先做小闭环，用真实问题跑评估，再决定换模型、换库、还是改切分。选型围绕场景和指标走，项目更容易从Demo走到生产。
我在第一章画了架构图，接下来得把图变成能跑的命令行和配置文件。这一章我按真实项目节奏来写，从需求对焦到环境准备，从数据洗切到向量入库，从召回重排到大模型出答案，再把开源方案的选型和部署讲透。我尽量把踩过的坑写进去，少写漂亮话。
2.1 AI搜索搭建教程一：需求分析、架构设计与环境准备
我带的项目里，需求分析经常被压缩成一句话，比如“做一个公司知识库搜索”。这种表述没法开工。我会拉着业务方开一次两小时的对焦会，把问题拆成可量化的条目。用户群体是全员还是某个部门，日均查询量是两百还是两万，文档是PDF为主还是Confluence加飞书，更新是日更还是月更，延迟是两秒能忍还是一秒都嫌慢。这些数字定下来，架构才有边界。
架构设计阶段我喜欢白板。离线链路画一条，在线链路画一条，中间标出数据契约。文档解析后输出什么结构，切分后的chunk带哪些元数据，向量库存哪些字段，权限标签怎么透传。我吃过一次亏，元数据里没留tenant_id，上线前强行加字段，重建了整个索引。那次之后我会把元数据schema提前评审，业务、工程、安全三方签字。
环境准备是低成本但高频翻车的环节。我会先列一张清单：GPU机器或API key、向量数据库实例、对象存储、消息队列、监控组件、密钥管理。本地开发用Docker Compose把Milvus、Redis、Postgres拉起来，模型走托管API，省显卡。测试环境要不要独立集群，取决于数据敏感程度。我习惯把环境变量集中放在一份.env.example里，谁拉代码都能一键起demo，这能省掉很多“在我机器上能跑”的扯皮。
2.2 AI搜索搭建教程二：数据接入、清洗、切分与向量化
数据接入这一步，我称它为“脏活里的脏活”。企业文档散在NAS、Notion、Confluence、飞书、SharePoint、内部wiki，格式从PDF、Word、PPT到Markdown和HTML都有。我通常先做一个连接器矩阵，每个源写一个adapter，输出统一的Document对象，字段包含doc_id、source、title、url、update_time、acl、raw_content。先求通，再求全。
清洗我会重点处理四类噪声。页眉页脚和页码，扫描PDF的OCR错字，表格跨页断裂，还有目录和参考文献这类低信息密度段落。切分器我一般按标题层级优先，再按token长度兜底。chunk大小我从512 token起步，重叠留80到120 token。遇到代码块和表格，我会单独抽出来做特殊处理，不让它被切碎。我的经验是，切分策略对召回率的影响，比换嵌入模型更大。
向量化阶段要盯三件事。嵌入模型的语言覆盖和领域适配，批处理的大小和并发，以及失败重试和幂等。我做过一个中文法律文档项目，通用嵌入模型在法条检索上表现一般，换成领域微调版本后MRR涨了一截。入库时我会给每个chunk写入content_hash，更新时先算hash再决定是跳过还是覆盖。全量重建索引很贵，增量更新才是常态。
2.3 AI搜索搭建教程三：向量检索、重排与LLM答案生成
在线链路的入口是query理解。我会先做query改写，把口语化问题补全成检索友好的形式，抽取时间、实体、意图标签。多轮对话里，还要把历史轮次压缩成上下文。这一步做得好，后面的召回压力小很多。我遇到过用户问“它多少钱”，没有上下文，任何检索器都救不了。
召回我一般做混合检索。向量召回负责语义相近的片段，BM25或稀疏向量负责关键词精确匹配，两路结果用RRF或加权融合。召回数量从top 20到top 50起步，给重排留空间。重排模型我用过bge-reranker和Cohere Rerank，效果比单纯比余弦相似度稳。重排后再取top 3到top 8个片段，送进LLM。片段太多会稀释注意力，太少会漏信息。
LLM答案生成这一环，提示词是可控性最高的地方。我会在system prompt里写清三件事：只依据给定片段回答，不确定就说不确定，每个结论后面挂引用编号。输出格式要求结构化，方便前端渲染引用卡片。流式输出要开，用户等两秒不难受，等八秒就走人。我还会加一层答案校验，检查引用编号是否落在召回片段范围内，避免模型编造来源。
2.4 开源AI搜索搭建方案选型：RAG框架、向量数据库与模型组合
RAG框架我按团队规模和定制需求来分。小团队想快速验证，LlamaIndex和LangChain的社区版本够用，文档多、示例全。要上线到生产，我会看Haystack、RAGFlow、Dify这类偏工程的框架，它们对数据接入、评估、部署的支持更完整。框架本身不是护城河，能读懂它的抽象、在必要时替换组件，才是。
向量数据库这块，我按数据量和运维成本来选。数据在百万级以内，pgvector最省事，业务库和向量库合一，事务也简单。千万级到亿级，我会考虑Milvus、Qdrant、Weaviate，分区、副本、混合检索能力更成熟。选库时我会重点看四件事：过滤性能、混合检索支持、增量更新机制、备份恢复方案。过滤性能经常被低估，带权限过滤的检索和纯向量检索，延迟差别可能到三五倍。
模型组合是另一道选择题。嵌入模型我倾向中文用bge系列或m3e，英文用text-embedding-3或E5。重排用bge-reranker-v2或bce-reranker。生成模型看场景，对成本和数据出境敏感就用Qwen、DeepSeek、GLM这类可私有化的模型，追求效果可以用GPT-4o或Claude。我会准备两三套组合跑对比，用同一份评估集打分，不靠感觉换模型。
2.5 开源AI搜索搭建方案部署：本地、云端与混合架构实践
本地部署适合数据不能出内网的场景。我做过一次全本地化项目，模型跑在两张A100上，向量库用Milvus集群，前端走内网nginx。难点不在部署本身，在资源调度和版本管理。模型文件、镜像、向量库版本都要打标签，用Helm或Docker Compose管理。我习惯把整套编排脚本放Git，配一份部署文档，换个人也能起全套。
云端部署启动快，弹性好。我一般用K8s跑无状态服务，向量库用托管版或自建StatefulSet，对象存储和消息队列走云服务。成本控制靠自动扩缩和请求合并。LLM调用做并发限制和缓存，相同query命中缓存直接返回，能省不少token。云端要注意的是网络出口和数据合规，涉及敏感数据时要配VPC和私网访问。
混合架构是我目前见得最多的形态。数据和向量库放在本地或私有云，LLM调用走公有云API，中间加一层脱敏和审计网关。这样做的好处是敏感原文不出内网，模型能力又能用上。网关要做的事包括字段脱敏、请求日志、配额控制、失败降级。降级策略我会配一条规则，API不可用时切到本地小模型，答案质量降一点，服务不能断。
2.6 效果评估、监控与迭代优化：让搜索答案更准确可靠
评估集是项目的锚。我会在项目初期就攒一百到三百条真实问题，配标准答案和标准引用片段。评估维度分四层：检索层看Recall@k和MRR，重排层看NDCG，生成层看答案正确率和引用准确率，产品层看点击率、追问率和人工介入率。每次改动跑一遍，用数字决定留不留。
监控看板我常放六类指标：QPS、P95延迟、召回命中数、重排耗时、LLM首token时间、单次成本。还要监控空召回率和低置信答案比例，这两个指标异常往往意味着数据管道出问题。告警阈值我设得保守一些，宁可多报几次，也别让用户在页面上看见“抱歉，我没有找到相关信息”反复出现。
迭代优化我按“先数据、再检索、后模型”的顺序做。空召回多就先查切分和数据覆盖，检索不准就调混合权重和重排，答案表达差再动提示词和生成模型。每次只改一个变量，改完跑评估集。我见过团队同时换模型又换切分，效果变差了分不清是谁的锅。迭代节奏保持每周一小轮、每月一大轮，配合bad case回收机制，系统会慢慢变成一个越用越准的东西。
前两章把系统从图纸跑成了能回答问题的服务。上线只是起点，后面要处理的是日复一日的故障、账单、审计和需求变更。我把我踩过的坑和觉得管用的做法写在这一章，分三块：排查、治理、演进。
3.1 常见问题、性能瓶颈与排查思路
我见过的问题清单很长：空召回、答非所问、权限泄露、延迟毛刺、并发上不去、成本突然翻倍。每个问题看起来是单点，拉出调用链往往牵出一串环节。我的排查习惯是分层看：数据层查文档和chunk，检索层查召回和重排，生成层查提示词和模型，服务层查网络和并发。给每个query打上trace id，每段耗时和输出都记下来，定位效率会高很多。
空召回最让人头疼。用户搜不到，本能反应是模型不行，实际原因经常在数据管道。我会拿一条bad case，手动跑离线流程：文档解析了吗，切分后chunk还在吗，向量算出来了吗，用同样的query去向量库搜，看有没有结果。有一次发现ACL标签写错了，把整个部门的文档都过滤掉。还有一次是扫描件OCR质量太差，嵌入向量根本代表不了原文。
性能瓶颈分两类。计算瓶颈在嵌入和重排，资源瓶颈在向量库和LLM并发。排查时我看P95延迟，不看均值，均值会掩盖毛刺。重排模型batch size设太大，单次延迟从200毫秒涨到1.2秒，调小后稳定。LLM首token慢，可能是排队或网络，加连接池和并发限制能缓解。向量库过滤性能被低估，带权限过滤的检索比纯向量检索慢三五倍，过滤字段必须建索引。
3.2 成本、安全、合规与数据治理要点
成本要算总账。嵌入、向量库、GPU、LLM token、存储、带宽，每一项都可能变成大头。我做过一个项目，LLM费用占七成，后来加语义缓存和结果缓存，相同问题直接返回，省了三分之一。冷热数据分层也管用，半年前的文档检索频率低，放到便宜存储和低配索引上，账单会好看很多。
安全是我最不敢省的地方。权限过滤必须在检索阶段做，不能只在前端藏按钮。每个chunk带ACL标签，query带用户身份，向量库过滤条件里拼权限。脱敏放在网关，身份证、手机号、金额这些字段进LLM前替换掉。审计日志要记全：谁问了什么，命中了哪些文档，答案引用了哪段。出了事能追溯，平时也能做合规检查。
合规和数据治理是慢功夫。数据出境、个人信息保护、行业监管，每个项目都要过法务。删除权要能落地，用户要求删文档，得从原始存储、向量库、缓存、备份、日志里清掉。元数据管理是基础，doc_id、版本、来源、责任人、保留期限，这些字段不齐，后面治理就是空话。我习惯在数据接入时就强制填元数据，不填不让入库。
3.3 从Demo到生产：最佳实践与持续演进路线
Demo到生产隔着一堆工程活。Demo只要跑通一条query，生产要考虑并发、失败、回滚、灰度、监控、告警、值班。我上线前会做三件事：压测到峰值的两倍，准备降级开关，写好回滚脚本。没有回滚能力的上线，我不批。降级路径也要提前定，LLM API挂了切本地小模型，答案质量降一点，服务不能断。
最佳实践我总结成几句口头禅。评估集先行，每次改动跑一遍。一次只改一个变量，改完看数字。bad case每周回收，做成回归测试。文档和代码一起提交，谁改的谁知道。灰度发布先放内部用户，再放小流量，观察一天再全量。这些做法不新鲜，能坚持下来的团队不多。
持续演进路线按时间铺。短期做多模态，图片和表格进检索，扫描件和图表不再丢信息。中期做Agent，让搜索能调工具、查数据库、走审批流，从回答问题走到完成任务。长期做个性化，结合用户角色和历史行为调整召回和排序。主动学习也有价值，把低置信问题挑出来人工标注，反哺微调和评估集。系统是长出来的，不是一次搭好的。我每季度会回头看一遍架构图，总有几个框需要换掉。
