家居装修这个行业信息差一直大得离谱。你自己上网搜“卫生间干湿分离怎么做”能翻出几百篇互相打架的文章有的说尺寸要90公分有的说60就够看完更不知道听谁的。而身边真懂装修的人又少就算认识一两个搞设计的朋友你也不好意思天天追着问。这就是我做“家居装修 AI 智能咨询助手”这个项目的出发点把散落各处的装修知识、常见案例、材料参数、验收标准全部收进一个知识库再让大模型基于这些资料直接回答用户问题把“大海捞针”变成“一问即答”。这篇文章就聊聊这个 AI 助手从想法到落地我踩过的坑、试过的方案以及你完全可以照着复现的实操过程。这个项目听起来高大上但本质上就是三件事建一个高质量的装修知识库、接一个大模型接口、写一套能把用户问题接住并精准回答的对话逻辑。适合谁看想给自家装修做个智能答疑工具的业主、做装修行业 SaaS 的开发者、刚入门 RAG检索增强生成想练手的同学都能从里面拿到一点能直接用的东西。1. 项目整体设计与思路拆解1.1 装修咨询的真实痛点到底痛在哪先换个角度想问题。装修咨询这个场景有一个非常反直觉的特征答案就在那里但你很难找到那个“正确的答案”。比如用户问“墙面开裂了怎么处理”其实网上有大量关于裂缝分类温度裂缝、沉降裂缝、腻子层裂缝和处理方法的资料但用户不知道自己的情况属于哪一种所以搜出来的内容对不上号问来问去还是不知道怎么办。另外装修问题的答案往往不是单一的。同样是“铺地板还是铺瓷砖”南方回南天严重的城市和北方干燥地区建议完全不同一楼潮湿的户型和高层采光好的户型结论也相反。这就导致传统的“百度式”搜索很难给出个性化答案用户必须自己消化一堆条件然后自己做判断。很多装修 App 里的问答社区也解决不了这个问题——回复慢质量参差不齐还夹杂着各种建材商家的软广。所以我判断这个场景的核心需求不是“提供信息”而是“提供经过筛选、匹配用户具体情境的建议”。大模型擅长这个但裸用大模型不行——它没有装修领域的深度知识容易把通用经验当成标准答案甚至一本正经地胡说。这就是这个项目最根本的设计逻辑用知识库约束大模型的回答边界用检索保证答案忠于行业经验。1.2 为什么选“大模型 知识库”而不是其他方案我在做之前其实对比过几条技术路线简单说一下取舍过程。第一种方案是纯人工咨询也就是做个表单用户提交问题后人工回复。这个方案效果可控但人力成本太高也没法 7×24 小时响应用户等半小时才收到回复体验基本就崩了。第二种方案是关键词搜索 推荐知识库文章类似给网站加个站内搜索。这个能做但用户得自己从文章里提炼答案本质上还是把筛选压力丢回给了用户没有解决“一问一答”的核心诉求。第三种方案是裸用大模型比如直接用通用对话接口。这个方案省事但实测下来问题很大模型会把“装修建议”和“行业规范”混为一谈回答风格过于“通用”比如你问“厨房台面高度多少合适”它先给你讲人体工程学原理就是不告诉你一个具体的参考值。而且你追问“我家身高 165 的做饭人适合多少”它又会泛泛而谈给不出基于装修行业经验数据的答案。第四种方案才是我最终采用的RAG检索增强生成架构。简单说就是先把装修知识库里的内容切成小块、做向量化用户提问时先从知识库里检索最相关的几段内容把它们和大模型接口一起打包发给大模型让大模型“看着资料回答问题”。这样既保留了大模型理解自然语言、多轮对话的能力又让回答有据可依不会跑出知识范围。你把这个架构想象成一个新来的咨询顾问他桌上放着一大摞公司内部资料和案例库你问他问题的时候他先快速翻资料再结合资料给你答复——检索是翻资料生成是开口说话。1.3 系统整体架构画在脑子里的一张图这个项目的架构不复杂分四个模块知识库构建模块负责收集装修领域的资料做清洗、分段、向量化存到向量数据库里。这是整个项目的地基。对话意图理解模块负责解析用户问题识别装修相关的实体比如“卫生间”“瓷砖”“防水”、判断问题类型是问材料、问工艺、问价格还是问验收必要时抽取出用户提到的房屋条件楼层、面积、地区。检索模块根据解析后的查询条件从向量数据库里召回最相关的知识片段。生成模块把检索到的片段、用户对话历史、系统提示词拼装成带上下文的请求发给大模型接口返回最终答案。整个链路看起来普通但每个环节都有不少细节坑。下面我就把从零搭建过程中的关键技术细节和踩坑经验拆开讲。2. 核心细节解析与实操要点2.1 知识库不是随便堆文档切片策略决定回答质量这是整个项目里最容易被低估的一步。我一开始想得很简单从网上扒了几百篇装修文章整个丢给向量化接口结果一测试就翻车——问“卫生间防水做多高合适”模型答非所问。问题出在切片方式上。很多现成工具默认按固定长度切文本比如每 500 个字切一块。装修文章里经常出现这种情况前面一大段在讲卫生间防水的施工步骤后面突然开始讲厨房防水的区别。如果固定长度切一块切片里可能混着两个完全不相关的主题检索的时候匹配度就被稀释了。我的调整方案是按标题层级 段落语义来切。具体做法是把装修资料统一转成 Markdown 格式根据标题##、###把文章切成多个语义完整的区块每个区块再按 300~500 字切小相邻切片之间保留 50 字左右的重叠。这样做的好处是检索时命中的切片内容主题高度聚焦大模型拿到的上下文干净回答自然就准了。注意切片重叠这个细节很容易被忽略但实际影响很大。如果没有重叠一个知识点刚好被切断在上一片结尾和下一片开头之间时检索只能命中其中一半回答就会缺信息。另外知识库必须做去重和矛盾处理。不同来源的资料对同一个问题可能有不同建议比如墙面腻子到底刮几遍有的说两遍有的说三遍。这种矛盾如果同时进知识库大模型就会左右摇摆。我的处理方式是以国家施工规范、知名装修公司内部工艺标准为优先其他来源打上“经验参考”的标签在提示词里要求模型优先采信规范类资料如果资料之间存在差异明确告诉用户这种差异存在并说明原因。2.2 提示词设计把大模型“约束”成装修行家很多第一次做 AI 应用的人以为提示词就是写几句“你是一位装修专家”效果好不好全看模型心情。其实提示词在这类 RAG 应用里承担着三个作用框定角色、规定回答结构、设定知识边界。我最终版的提示词大概是这样的结构你是一位拥有 15 年家装设计和施工管理经验的资深专家。请根据提供的参考资料回答用户问题严格遵循以下要求 1. 如果参考资料中包含明确答案优先引用资料中的数据和建议并在回答中标注信息来源类型施工规范/行业经验/产品说明。 2. 如果参考资料中没有相关内容直接回复“这个问题我这边资料库还没覆盖到建议咨询线下设计师或施工方”禁止编造。 3. 回答要做到先给结论再解释原因最后给出可执行的建议步骤。 4. 如果用户问题涉及房屋具体情况楼层、面积、地区、家庭人口等先确认这些信息是否齐全不齐全时主动追问。 5. 涉及价格、工期时给参考区间而不是绝对数字。 6. 禁止使用模糊词汇如“可能”“大概”这类词最多出现一次每个建议都应落到具体参数或动作上。这里面最有价值的是第 2 条和第 6 条。第 2 条解决大模型“爱编”的老毛病实测下来加了这条之后回答的“幻觉率”明显下降。第 6 条则是用规则强制模型输出可执行的答案而不是正确的废话。比如问“砌墙要注意什么”如果没有这条约束模型会给你一段“要用砖、要抹灰”的废话加了之后模型会直接告诉你“红砖要提前一天浇水湿润新老墙交界处每隔 50 公分要植筋顶部要用斜砌砖”。提示词还有一些动态拼接的部分。我会把用户对话历史、检索引擎召回的原文片段、用户画像信息如果有一并写进请求里。整体的请求结构是系统提示词固定不变的部分 知识库检索到的参考内容每个片段前面标注来源 最近两轮对话历史 当前用户问题这个拼接顺序不是随意定的。把参考内容放在对话历史之前是为了让模型在生成回答时注意力能集中到资料上把用户问题放最后是很多大模型 API 的习惯——越靠近末尾的内容模型往往会越重视。2.3 多轮对话状态管理让助手记住你说过什么装修咨询天然是多轮对话场景。用户第一句可能只问“厨房怎么设计”你回答了之后他才会补充“我家厨房只有 4 平米而且光线不好”。如果助手不记得第一轮聊了什么第二轮回答就成了空中楼阁。做多轮对话市面上有现成的框架但我说说我是怎么自己控制的。我维护了一个会话记忆队列最多保留 6 条最近的对话记录。每轮生成请求时把队列内容拼进提示词。超过 6 条时按时间顺序丢弃最老的记录。有个容易被忽略的细节要存的是“原文”不是“模型提炼过的摘要”。我之前试过用大模型把每轮对话先总结成摘要再存这样做虽然省 token但会丢失很多关键实体。比如用户说“我家的墙是轻质砖能不能挂电视”如果你把摘要总结成“用户询问挂电视条件”那“轻质砖”这个关键信息就丢了。直接存原文虽然每次请求多花一点点 token但信息保全度高得多。注意多轮记忆不是越多越好。对话超过 6 轮之后模型经常会“迷失在上下文中”反而把早几轮的过时信息当成当前条件。6 条是最适合我这套系统的长度你可以根据自己的场景调整但别超过 10 条。2.4 意图识别与实体抽取让检索更精准用户的问题五花八门有些问题根本没法直接拿去检索。比如用户问“开放式厨房能不能装燃气热水器”这个问题里检索关键词如果是“开放式厨房”和“燃气热水器”召回的结果往往不够精准因为最核心的知识点可能是“厨房通风条件对燃气设备排烟的要求”。所以我在检索之前加了一个轻量的查询改写层先把用户问题交给大模型让它提取关键实体和查询条件。大概是用这样一个小提示词你是一个查询解析器。请从用户问题中提取以下信息 1. 空间位置厨房/卫生间/卧室/客厅/阳台/玄关/全屋 2. 涉及的装修项目水电/防水/瓦工/木工/油漆/收纳/建材/家电 3. 关键限制条件层高/面积/楼层/地区/家庭成员/预算档位 4. 提取用于检索的核心关键词重写为一段简洁的描述 只输出 JSON 格式不要多余解释。输出大概是{ space: 厨房, project: 燃气设备安装, constraints: {通风: 开放式厨房}, query: 开放式厨房 燃气热水器 排烟 通风 安装条件 }这个改写过后的 query 拿去做向量检索命中率明显比原句更高。为什么因为大模型把“开放式厨房能不能装”这个模糊问法拆解成了“排烟”“通风”“安装条件”这几个在知识库文章里真正出现过的关键词和概念。这一步是整个系统里性价比最高的一笔投入。3. 实操过程与核心环节实现3.1 技术选型这是一套花钱少、上手快的组合说下我用到的具体工具都是个人开发友好的选择知识库来源国家建筑装饰装修工程质量验收规范公开摘要、《住宅设计规范》公开资料、几家装修公司公开的工艺标准文档、知乎/贴吧等平台的高赞问答清洗后使用。向量化模型用的是开源的中文向量模型本地跑不花 API 费用。如果你的机器配置一般可以用现成的向量化接口费用很低。向量数据库用开源向量数据库支持本地部署。短期数据量在几万条以内完全够用。大模型接口用的是国内某大厂的通用对话接口为了控制成本选择中档型号问题不大。后端框架Python 的 FastAPI轻量、文档自动生成、异步性能好适合快速搭建。前端界面第一版只做了简单的 Web 聊天界面原生 HTML JavaScript没有引入任何前端框架避免过度工程化。整套系统的成本如果不算人力的话主要是大模型接口调用费。日常测试和少量并发使用一个月几十块人民币。生产成本取决于用户量按调用次数计费每轮回答大约消耗 1000~1500 个 token。3.2 知识库预处理从一堆杂文到干净的切片这一步是整个项目里最脏最累但最关键的。我做了几件事清洗。网上扒来的文章自带一堆广告和无关内容我写了一个清洗脚本规则包括去掉所有链接、去掉图片引用、去掉“关注公众号”等营销段落、把全角符号转半角、统一数字格式。规范化。把 HTML 转成 Markdown然后按标题结构重组。我的做法是把常见标题词“一、”“二、”“1.”“1”“第一”全部统一成 Markdown 的##或###格式方便后续按标题切片。切片。我最终的切片逻辑是import re from typing import List def split_markdown_by_heading(text: str, max_chunk_size: int 500, overlap: int 50) - List[str]: 按 Markdown 标题层级切块超过最大长度时按段落继续切带重叠。 # 按标题分割 sections re.split(r(?m)^(#{2,3})\s, text) chunks [] for i in range(1, len(sections), 2): level len(sections[i]) content sections[i 1].strip() if not content: continue # 如果内容太长按段落再切 if len(content) max_chunk_size: paragraphs re.split(r\n\s*\n, content) current for para in paragraphs: if len(current) len(para) max_chunk_size and current: chunks.append(current.strip()) current current[-overlap:] \n\n para else: current \n\n para if current: chunks.append(current.strip()) else: chunks.append(content) return chunks这个脚本是核心但它解决的问题深度有限。真正要命的不是切而是切出来的块要“接得住上下文”。比如一篇讲“卫生间防水”的文章标题是“施工步骤”下面的内容可能包含“涂刷第一遍防水涂料后要等 12 小时”这个“12 小时”如果没有前文“第一遍”单独检索出来模型不知道说的是什么。所以我切完片之后在每块开头加了它所属的一级标题作为前缀比如“【卫生间防水·施工步骤】”。实测下来这一个小改动让回答准确性提高了不少因为大模型拿到切片时一眼就知道这段在讲什么不会误读。3.3 向量化与检索建立“语义索引”切片完成后需要把每段文字转成向量。这个过程要特别注意向量化模型和检索时用的模型必须一致。我有一次换了向量化接口但忘了更新检索端的模型结果检索出来的内容驴唇不对马嘴折腾了半天才排查出来。入库时每一条记录包含这几个字段id唯一标识content切片文本source_type来源类型规范/经验/产品说明source_name来源名称title所属一级标题vector向量化结果查询时做两步先向量检索出 top 20 相关切片再用关键词做一次 BM25 检索这个用开源检索库就可以最后把两路结果做加权融合取最终 top 5 作为大模型的参考上下文。为什么要做混合检索因为向量检索擅长找“意思相近”的内容但个别装修术语还是要精确匹配才靠谱。比如用户问“踢脚线”的时候向量检索可能召回一些关于“地脚线”“墙角保护”的内容而 BM25 能稳稳地把包含“踢脚线”字眼的文章捞出来。两路并行走互补效果很明显。3.4 对话接口把知识库和大模型串起来这是核心逻辑代码我用 FastAPI 写了一个接口from fastapi import FastAPI, HTTPException from pydantic import BaseModel import openai app FastAPI() class ChatRequest(BaseModel): session_id: str message: str class ChatResponse(BaseModel): answer: str sources: list # 伪代码逻辑实际使用时需替换为你的 API 配置 def build_messages(session_id: str, user_message: str) - list: query parse_query(user_message) # 查询解析 chunks hybrid_search(query[query]) # 混合检索 history get_history(session_id) # 获取多轮上下文 system_prompt load_system_prompt() # 加载系统提示词 context_text \n\n.join( f[来源:{c[source_type]}|{c[source_name]}]\n{c[content]} for c in chunks ) messages [{role: system, content: system_prompt \n\n参考资料如下\n context_text}] for h in history: messages.append({role: h[role], content: h[content]}) messages.append({role: user, content: user_message}) return messages def generate_answer(messages: list) - str: resp openai.ChatCompletion.create( modelyour-model-id, messagesmessages, temperature0.3, top_p0.9, ) return resp.choices[0].message.content app.post(/api/chat, response_modelChatResponse) async def chat(req: ChatRequest): try: messages build_messages(req.session_id, req.message) answer generate_answer(messages) save_history(req.session_id, req.message, answer) return ChatResponse(answeranswer, sourcesextract_sources(messages)) except Exception as e: raise HTTPException(status_code500, detailstr(e))这段代码里面有两个细节值得展开。第一个是 temperature 参数。我最终设的是 0.3。这个参数控制生成的随机性越高回答越有创造性越低越保守。装修咨询是典型的需要“确定性”的场景温度太高模型容易发挥给出一些花里胡哨但不实用的建议。0.3 是我测试下来既保留一定表达自然度、又不会跑偏的甜点值。第二个是 sources 的返回。用户问完问题之后界面下方会显示这次回答引用了哪些资料标着“来源施工规范”“来源装修公司工艺标准”。这个设计一开始只是为了内部调试方便上线后意外发现用户对它的信任度明显提升——看到答案有出处用户更愿意按建议去执行。这也说明AI 助手不是越像真人越好让人感觉到后面有专业资料库在支撑反而更可信。3.5 前端界面不炫技但要把关键信息说清楚前端我没怎么做花活一个居中的对话窗口左侧是聊天记录右侧是“常见问题快捷入口”。这个快捷入口是上线后根据用户高频问题总结出来的比如“卫生间防水做多高”“瓷砖通铺注意事项”“全屋定制柜子按投影面积还是展开面积算”一键点进去就能问降低用户输入门槛。消息气泡里答案下面是折叠的参考来源列表点开能看到具体的引用标题和原文片段。输入框旁边加了一个免责声明小字“建筑做法受地区、房屋结构、材料品牌影响建议结合线下专业意见使用。”这个声明不只是合规需要也能有效降低系统被当“医嘱”用导致的误导风险。部署我用了最简单的方案后端 FastAPI Uvicorn前端静态文件直接由后端托管单机部署用反向代理加一层 HTTPS。没上 Docker也没搞 K8s对于一个个人项目来说越简单越容易维护。4. 常见问题与排查技巧实录4.1 检索结果不相关是大模型还是知识库的锅这是调试中出现频率最高的问题。一开始我老觉得是大模型回答得不好后来证明 80% 的根因在检索环节。典型现象问“瓷砖要不要做美缝”回答时引用的资料却是“瓷砖选购注意事项”。排查思路是去向量数据库里看检索出来的 top 5 切片到底是什么内容如果切片本身就不对那问题出在向量化和检索不在生成。这类问题通常有三个原因切片太碎或太杂知识内容被切得七零八落。解决方法是调整切片策略按语义块切而不是纯按字数切。向量化模型不适合中文长文本。有些开源模型对中文长句理解弱换个模型测试一圈往往能找到明显更好的。用户问题本身有歧义。如果“开放”和“封闭”这种词同时出现在备选切片里检索结果容易跑偏。这时需要优化查询解析层的改写逻辑让改写后的 query 更聚焦。排查这类问题有一个笨但有效的方法把检索到的切片都打印出来人工判断是不是应该被召回。坚持做几天你会发现系统哪儿有毛病心里清清楚楚。4.2 模型“一本正经地胡说八道”怎么摁住大模型隔三差五还是会编出来一些看似合理、实际上没处查证的内容。比如有一次用户问“墙面返潮能不能贴壁纸”系统回答里居然有“可以使用防潮壁纸市场常见品牌包括……”——知识库里根本没提过任何品牌。这种幻觉问题我控制手段有这么几层按优先级排强约束提示词在系统提示词里明确写“禁止编造参考材料中不存在的信息”这属于底线能用但不够。回答要求标注来源当模型被要求“引用资料时标明出处不引用时直接承认不知道”它会有意识地减少自由发挥。结构化输出约束让模型输出 JSON 格式的答案结构包含answer、confidence置信度、source三个字段。模型发现要输出source但知识库里确实没有对应资料时它宁可降低confidence也不太会硬编。后置校验这是最后一道防线。对模型输出的答案做一次“事实性验证”把答案里的关键数字和实体抽出来再回知识库里查一遍有没有对应内容。我刚开始做这个功能目前只对数字类信息做校验效果还不错。4.3 用户问到“系统外问题”是答还是不答装修咨询系统免不了遇到边界问题比如“推荐一款油烟机”“你们能帮忙找施工队吗”这类涉及产品推荐、服务对接的问题。一开始我让系统直接回答结果知识库里没有品牌库回答的推荐完全是凭空捏造我自己看了都觉得不靠谱。后来我在意图识别层加了一个兜底分类器把问题分成“装修知识类”“产品咨询类”“服务需求类”三大类。装修知识类正常走 RAG 流程产品咨询类回复“系统不提供具体品牌推荐建议到线下门店实测”服务需求类回复“系统暂不提供施工队推荐这里整理了一份找施工方的 5 个考察要点”。这个设计既守住了边界又没让用户带着问题白跑一趟。4.4 对话时间长了就“犯糊涂”记忆该存多少多轮对话还有一个典型问题聊了十几轮之后模型开始前后矛盾。比如用户最开始说“预算 10 万”聊到后面问“全屋中央空调值得装吗”模型给的回答完全没考虑预算限制。我排查后发现问题还不是出在记忆条数上而是出在记忆的“注意力权重”上。对话历史越长初始条件预算、面积、楼层被淹没在后面的闲聊里模型自动忽略了。我的解决方案是做一个关键信息提取器每轮对话结束后把用户的房屋条件和关键约束提取出来单独存成一个“用户画像”字段下一轮拼接时放在对话历史之前并且用特殊标记强调。比如用户已知条件 - 房屋面积89平米 - 户型两室一厅 - 装修预算10万元 - 所在地区南方沿海城市湿度较高 请注意以上条件对回答所有问题均有效回答后续问题时须自动带入这些条件。这样改完之后哪怕聊了二十轮系统依然记得用户一开始说的预算和房屋情况。这个细节说实话比很多商业的 AI 客服做得都好但实现成本很低值得做。4.5 效果评估怎么知道系统在变好很多人做 AI 应用做完就完了从来不量化效果。我做了一套简单的评估流程现在分享给你。评估集我从真实用户咨询里整理了 100 个高频问题覆盖空间厨房、卫生间、卧室等、项目水电、防水、木工等、场景新房装修、旧房改造、局部翻新。每个问题都从知识库里找到标准答案并标记了难度直接问答 / 需要多条件推理 / 需要结合地区季节等上下文。打分维度针对每个回答我人工打三个分相关性有没有答到点子上、准确性关键参数和工艺是否符合行业规范、可执行性用户看完能不能照着做。每项 1~5 分。回归测试每次修改知识库或提示词后用同一套评估集跑一遍对比分数变化。这个方法能帮你发现“修好一个问题打崩另一个问题”的回归情况。我至今还留着最初几版系统的测试结果相关性从 3.1 分一路涨到 4.5 分准确性从 3.5 涨到 4.3 分。每次看到数字往上走就知道这个项目是在真正向前推进的。5. 部署上线后的运行经验与内容运营系统上线后我并没有“撒手不管”知识库运营反而成了日常最重要的工作。持续追踪真实提问。我每周会导出用户提问记录把答不上来的问题、用户追问超过两轮的问题批量整理入库补充资料。第一周知识库只有 300 多篇文档三个月后涨到了 800 多篇其中至少 200 多篇是来自真实问题的驱动补充。按季节调整知识库重点。夏天回南天地区用户问除湿防潮相关问题明显增多冬天北方用户问暖气改地暖的增多。我会在季节转换前主动搜集相关优质资料入库让助手“应季”变得更能帮上忙。回答质量抽检。每周抽 30 条真实问答一条一条看发现问题就回到知识库和提示词层面去修。我把这个环节当成 AI 应用运营的“人工反馈闭环”这比任何自动化评估工具都管用。我个人在实际搭建过程中的体会是这个项目真正难的不是代码而是知识库的组织和对用户问题的理解。代码那套东西大模型和向量数据库的文档都写得明明白白你照着做就行但知识库怎么切、提示词怎么约束、多轮对话怎么管理这些全靠一遍一遍测试摸索出来的手感。如果你也想动手做一个别追求一步到位的完美版先搭个简单原型跑起来拿真实用户问题去打磨两到三周就能看到明显的效果。最后再分享一个小技巧做这类垂直领域 AI 助手别一开始就往里面塞一堆“通用知识”比如“装修风格分类大全”这种资料看起来全面但用户问得最多的问题其实就集中在几十个具体场景里。先把你手上最优质的、针对高频问题的资料放进去跑起来再慢慢扩。知识库宁精勿滥这是我做这个项目最深刻的教训也是给准备入坑的同学最诚恳的建议。