装修这件事最磨人的往往不是搬砖而是问问题。我去年给房子做翻新第一反应是上网搜“瓷砖通铺要不要做对缝”结果答案分成两派一派坚持要对缝才好看另一派说这是智商税两边分析得头头是道再搜“90平米三房预算25万够不够”有人说25万能装出样板间效果也有人说连柜子都做不起。问题本身不难难的是从一堆互相矛盾的信息里找到真正适合自己家的那一条路。装修咨询天然就是AI助手该干的活多源信息高度分散、决策链条长、每个人的表达方式又千差万别恰好是大语言模型擅长的场景。所以我把这个想法落地成了一个家居装修AI智能咨询助手目标很直接——让装修咨询从“大海捞针”变成“一问即答”。这篇文章会完整记录我从产品定位、知识库搭建、对话引擎实现到最后线上实测踩坑的全过程希望能给正在做同类工具、或者想用大模型改造生活服务信息检索的朋友一些可参考的思路。1. 装修咨询为什么是“大海捞针”——先聊聊用户真正在问什么1.1 用户的痛点是“找不到”不是“没有”很多人以为装修咨询难是因为网上的信息少。实际恰恰相反装修相关信息多到爆炸施工工艺有五花八门的规范讲解材料有各种测评和参数表预算有无数人的装修账单分享设计审美更是各说各话。问题的核心从来不是“没有答案”而是“答案太散、太杂、太容易矛盾”。传统搜索给用户的是链接列表用户需要自己点开一个个帖子自行判断哪条适用、哪条过时、哪条是软文。一次完整咨询走下来用户至少要在十几个页面之间来回跳脑子里的信息还经常互相打架。论坛和社媒上的经验帖也靠不住很多分享带有强烈的主观倾向甚至隐藏着商家的推广痕迹。更麻烦的是装修行业本身更新快两年前的地面材料主流方案今年可能已经换了玩法。1.2 三类高频咨询问题形态完全不同我用一个模拟项目做了三个月的需求收集从真实用户对话里提炼出三类高频问题它们的形态差异很大知识查询类“防水层刷多高才合格”“瓷砖留缝一般留多少”“乳胶漆和墙布哪个耐用”。这类问题有相对标准的技术答案关键在于找到权威来源并准确表述。决策计算类“我家套内85平全屋定制大概多少钱”“瓷砖通铺比普通铺法贵多少”。这类问题需要结合用户的具体情况面积、城市、材料档次做结构化计算而不是简单背诵一段知识。避坑经验类“装修公司增项一般藏在哪”“断桥铝门窗怎么辨别好坏”。这类问题其实是“经验众筹”答案没有绝对对错更多是概率性建议需要告诉用户哪些情况更容易发生、怎么预防。这三类问题的检索策略和生成策略完全不同。如果用一个统一方案去处理就会出现“该给权威来源的地方在讲个人经验该给计算逻辑的地方在背参数”的拧巴情况。1.3 为什么AI助手能解决而搜索引擎不能核心差别在于搜索引擎负责“找到”AI助手负责“回答”。用户装修时真正需要的不是一堆链接而是一个结合了他自己房型、预算、城市、偏好的综合判断。普通搜索页面不具备这种“把多源信息按照当前场景重组”的能力。大模型的价值恰恰在这它可以扮演一个整合者把散落在规范文档、行业百科、社区经验、行情数据里的信息片段按照用户的个性化条件重新组合成一段连贯、有逻辑、可操作的答复。而且基于对话的形式用户不用费劲组织关键词直接说“我家厨房不大想做开放式要注意啥”这种口语化描述系统也能理解。当然大模型也带来了新问题它太能编了。如何让它的输出不偏离知识库事实是我后面几章反复折腾的核心。2. 这位“助手”的定位和总体架构——先划边界再做方案2.1 能力边界能答什么不能答什么动手写代码之前我先给助手划了一条清晰的能力边界。这点特别重要很多同类型项目死就死在“什么都能答一点但什么都答不深”。我定义的能力范围包括四块装修知识问答施工工艺、材料特性、验收标准、装修流程等规范性内容。预算与方案估算根据面积、户型、城市和档次给出半包/全包、硬装/软装的粗略价格区间。材料与品牌选型对比乳胶漆和墙布、木地板和瓷砖、集成吊顶和石膏板等常见选择题。避坑经验解释解释装修中常见的增项、材料猫腻、合同陷阱并提供预防性建议。不能做的也有四条硬限制不提供实时报价所有价格均为知识库收录时点的行情区间实际以当地施工方报价为准。不做结构安全判断比如“这面墙能不能砸”必须现场勘测助手只能给一般性规范说明。不承诺任何施工质量不承担售后责任。不接受用户上传图纸做深度设计这类需求引导到线下设计师。边界定清楚之后后续所有的知识库建设和模型提示词都围绕这个范围展开超出范围的请求统一走“明确告知无法回答 给出替代路径”的兜底逻辑。2.2 整体流程设计整个系统的处理链路我整理成了六个环节每一步都能单独监督和调优用户输入接收自然语言问题支持口语化表达和连续追问。意图识别与槽位抽取判断问题属于知识查询、决策计算、避坑经验还是边界外请求同时抽取城市、面积、户型、预算等结构化字段。混合检索向量库检索语义相似的文档片段结构化数据库按槽位条件执行查询两条线并行。结果重排把向量检索结果按权威等级、时效性、与当前问题的相关度重新排序去掉明显不匹配项。答案生成把检索片段和对话历史一起交给大模型按照设定好的输出结构生成答案。输出校验检查答案中的关键数据是否能在检索片段里找到依据找不到的必须删除或标注为“经验性参考”。这个流程看起来朴素但每一步都有讲究。混合检索解决了单一向量检索在数字条件匹配上的天然劣势重排环节解决了知识库里“权威文档排在犄角旮旯”的问题输出校验是最后一道防幻觉关卡。2.3 技术选型的几个考虑推理层我选用通用大模型API作为基础原因是不需要单独训练模型把精力集中在数据工程和提示词优化上。检索层用了一套开源向量数据库配合传统关系型数据库存结构化行情表。整套系统可以跑在一台常规服务器上知识库全量大概几十万条文档片段这个规模对向量检索来说毫无压力。在选型上我坚持了两条原则第一能用成熟组件解决的绝不自研第二每个环节都要留人工干预口子。知识库的增删改、重排权重的调整、提示词的迭代全部通过后台配置完成不需要重新部署服务。这套设计在后来的纠错过程中帮了大忙好几次线上问题都是改一条配置就解决了。3. 知识库建设与清洗——答案质量的第一道关口3.1 数据来源分成四类处理方式完全不同知识库是整套系统的地基地基没打好模型再强也白搭。我把数据来源分成四类每一类的处理策略都不一样数据类别典型内容可靠等级处理方式权威规范类施工验收规范、材料国家标准摘要高直接作为事实依据优先引用行业百科类材料参数、工艺流程、术语解释较高清洗后入库标注来源行情数据类不同城市、不同档次的预算区间中单独建结构化表按城市和档次索引社区经验类装修日记、避坑分享、案例复盘低作为观点样本仅用于生成“经验性建议”不当作事实分类的好处在于生成答案时系统知道哪些内容可以当成铁律哪些内容只能说成“多数人经验”。我自己见过太多AI咨询工具把某篇个人装修日记里的主观观点当成标准答案输出这就是数据没分级导致的。权威规范类数据是知识库的骨架子。我整理了和家装直接相关的施工、验收、材料等公开标准条文剔除了大量设计院和施工单位才需要看的工业级内容只保留家装场景真正会涉及的部分。行业百科类数据则通过半自动方式抓取整理人工抽检比例大约在30%。3.2 清洗流程六步走到位很多教程喜欢直接教你怎么切分向量但实际工程里清洗比切分重要十倍。清洗环节我用了六步去广告和软文识别带有明显推广性质的内容直接丢弃这类内容对答案质量杀伤力最大。去重复同一内容经常在多个来源出现用语义相似度做一次去重知识库体积能缩小40%以上。合并碎片把同一主题的零散问答合并成结构完整的知识块避免检索时只找到半句话。拆分观点与事实社区经验里的“我觉得”“我踩过坑”标记为观点规范文档里的“必须”“不应”标记为事实。打标签每块数据都标注来源类型、适用地域、更新时间、可靠等级。人工抽检随机抽10%看一遍实际内容质量同时重点人工复核存在争议的施工工艺部分。第六步最花时间但也最值。我在做人工复核时就发现过好几处行业百科把老版本规范当新规在写如果没有这层过滤AI助手会把过时工艺当成现行标准输出给用户。3.3 文档切分与向量化别按固定长度硬切做过RAG应用的朋友都知道文档切分是门手艺活。我第一版图省事按固定的500字符切分结果检索经常命中半个表格、半句话答案前言不搭后语。后来改成了语义段落切分先按原文的章节层级拆成一级块再把一级块按照自然段和表格边界细切同时把所属章节的标题作为前缀信息拼进每个块里。比如一段说“瓷砖留缝”的内容切出来的每个块都会带上“瓷砖铺贴施工要点”这个上下文前缀检索匹配度明显提升。长文档还有另一个坑一个块太长时向量化会把核心信息稀释掉。我处理的办法是给超过800字符的块额外生成一个“摘要块”摘要块负责被检索命中生成时则引用原始长块。相当于给每个大知识点配了一个“检索替身”效果稳定很多。3.4 结构化数据能和SQL对接就绝不塞进向量库刚开始我犯过一个错误把所有行情数据都转成文本塞进向量库。比如“某城市半包均价800到1000元每平米”看起来没问题但用户一问“120平米半包多少钱”向量检索只能勉强匹配到这句话却算不出120乘以均价的结果。后来我把行情类数据全部抽出来建了独立的关系表字段包括城市、装修类型、档次、价格区间、数据时点。用户间涉及计算类问题时系统先走结构化查询拿到区间值再交给大模型组织语言。这个改动让预算类问题的准确率从不到60%直接拉升到85%以上。这也是一条经验凡是能精确计算和精确匹配的就不要靠向量相似度去蒙。向量检索擅长语义相关性但在数字、地域、档次的精确匹配上非常脆弱。4. 对话引擎实现——从“检索到”到“答得好”4.1 意图识别与对话状态对话引擎的第一道工序是判断用户想干什么。我保留了四个意图主类知识查询、决策计算、避坑经验、边界外请求。分类用大模型做但给模型配了一个精细的判定逻辑列表例如“出现面积、价格、预算时优先走计算类”“出现区域行情、本地价格时还需要抽取城市字段”。意图分类不是终点难点在于后续的状态管理。用户经常这样说话“我家套内面积大概82平”“在东部某个三线城市”“想做原木风”……然后过两句突然问“那地板和木纹砖选哪个”。其中“82平”“三线城市”“原木风”这些信息分布在前面几轮对话里系统必须把它们都记下来才能回答最后这个选型问题。我是用槽位表来管理对话状态的。系统维护一张结构化的字段表包含城市、面积、户型、装修类型、风格偏好、预算范围、材料类型等槽位每轮对话都尝试抽取并更新这些字段而不是把所有历史对话一股脑都丢给模型。这样既能节省上下文空间又能保证关键信息不丢失。4.2 槽位管理多轮追问如何不丢信息槽位管理真正发挥作用的地方是追问策略。决策计算类问题最典型用户问“全屋定制要多少钱”单独给一个全国均价毫无意义必须知道他在哪、多大面积、什么板材级别。我的追问策略分两步先看已有槽位缺什么才问什么并且一次只问最关键的缺失项。比如用户只说了“90平米”那系统会优先问“你在哪个城市”城市拿到后再问“柜体板材用颗粒板还是多层板”。这样一步步补齐大约三轮之内就能给出相对可靠的估算。槽位更新还有一个细节当用户在新对话里推翻先前信息时系统要能覆盖旧值。比如开始说“预算30万”后面说“算了降到20万”如果槽位不更新后面所有答案都会基于错误预算。我加了一个槽位冲突检测逻辑每次抽取新值时都跟旧值比对变化幅度过大时主动向用户确认“您刚才提到预算20万后面预算相关回答会按这个更新”避免理解偏差。4.3 答案生成强制引用、先结论后理由提示词设计上我踩了很多版本迭代出来的经验。先说结论装修咨询的答案不能像论文一样先铺垫背景用户要的是立刻知道该怎么办。我生成的答案结构固定为四段直接答案用一两句话回应核心问题给出明确倾向和数字参考。决策维度说明这个结论依赖哪些条件预算、风格、使用场景条件变了结论可能变。理由与依据展开解释为什么引用知识库段落作为支撑。补充提醒给出实际操作中的注意事项。强制引用是绝对底线。我在提示词里明确要求涉及具体参数、价格区间、工艺要求的内容必须标注来源标签标签对应检索片段的ID如果检索片段里没有依据就写“根据当前知识库暂无法提供准确数据建议咨询当地专业施工方”。输出后还会跑一遍校验脚本把答案里出现的每个标签ID跟实际检索结果比对存在对不上的就做降级处理。反例我也见了不少模型答得极其流畅、数据看着也像样实际上参数全是从训练记忆里“脑补”出的根本不是知识库内容。没有强制引用机制这类幻觉很难被第一时间发现。4.4 兜底逻辑不知道就是不知道装修领域最容易出事的就是边界问题。用户问“承重墙上一米宽的横梁能不能敲掉一部分走管道”这类问题关乎结构安全任何AI都不该给出“可以”或“不可以”的绝对判断。我的兜底逻辑分三层第一层系统判定为知识库覆盖范围内的问题正常回答第二层范围边缘问题如涉及结构改动、水电改造等高风险操作先给一般性规范说明再明确提示“必须由持证工程师现场评估”第三层完全超出范围的请求直接给出“暂时无法回答”并提供替代查询路径比如建议用户补充哪些信息可以获取近似答案。试过的人都知道让大模型承认自己不会特别难。必须用提示词反复约束同时在输出校验时识别猜测性表述比如“我觉得”“应该可以”“可能没问题”这类措辞会被打回重写。前期宁可答得保守也不能给出一个看起来信心满满但其实没有依据的风险建议。5. 实测效果与踩坑复盘——真实线上跑过的三个大坑5.1 测试与评估方式系统上线前我拉了三个星期的真实用户模拟对话记录一共120多个问题覆盖前面提到的四个意图分类。每个问题都预置了“标准答案要点”和“评价维度”评价维度包括答案可操作性、数据准确性、引用正确性、是否答非所问。评估方式分两层机器先用规则粗筛比如关键数字是否在检索片段中对应、是否带来源标签、是否出现“绝对化”措辞人工再对抽检样本做细评。所有有争议的问题会进周会讨论把结论回流到知识库或提示词里。首轮内测的总体准确率只有68%离我预期的90%差距很大。但拆开看每个分类后发现问题非常集中也让我定了接下来三个大坑的修补方向。5.2 坑一知识库里的“权威打架”第一个大坑是知识库内部自相矛盾。我在清洗阶段虽然做了去重但没处理“不同来源对同一工艺参数说法不一致”的情况。比如某个施工规范说防水层刷高300毫米合格另一份行业指南提到应该刷到500毫米以上才稳妥。两者其实并不完全冲突一个是底线一个是推荐做法但模型分不清回答时可能随机抽取一个标准输出造成用户两次问同样的问题得到不同答案。解决思路是给每条数据加了一个“要求等级”字段分“强制要求”“推荐做法”“经验参考”三档。生成答案时优先以强制要求为准再补充推荐做法并在表述上明确区分“验收底线是XX但为了长期使用建议做到XX”。改完之后这类矛盾导致的错误回答占比下降了一半以上。5.3 坑二多轮上下文截断导致关键信息丢失第二个坑出在对话轮次的上下文管理上。前期我用“最近三轮对话 最新问题”的模式去生成答案长对话里面积、城市等槽位信息一旦被挤出上下文窗口回答就突然“失忆”。有一次用户连续问了五个问题期间提到了“出租房简装”到第五个问题系统已经完全忘了这个前提给出的材料建议是按自住精装推荐的前后矛盾。后来我把槽位表升级为回答生成的硬性输入不管上下文怎么滚动槽位字段始终单独传给模型优先级高于对话历史。同时在每轮回答开头附带一句当前槽位确认灵巧地提醒用户“当前记录出租房简装、三线城市、面积90平”如果不对可以随时纠正。这个改动既解决了信息丢失也让用户对回答的信任度明显上升。5.4 坑三模型回答过于绝对第三个坑是生成内容的“绝对化”表达。用户问“乳胶漆和墙布哪个好”模型给了一句“乳胶漆更好”从对比逻辑上没错但忽略了用户实际情况如果是出租房乳胶漆确实更实惠但若是自住且预算充足墙布的质感和寿命可能更合适。算法的“最优解”因条件而异模型却天然倾向给出一个斩钉截铁的结论。我修改了提示词要求所有对比类问题都必须先给出决策维度再给初步倾向而且明确注明“以下为一般情况下的倾向最终要结合您的预算和偏好”。同时新增了一个“对比输出”模板让模型按“适用场景、价格区间、寿命、维护难度、颜值效果”五个维度做结构化解说。这个改版后测试集的“可操作性”评分从65分涨到了82分。5.5 人工抽检与持续迭代线上稳定运行后我保留了每天5%对话记录的人工抽检流程。抽检不只看答案本身对不对还要看有没有“无效提问被强行回答”“明显猜测被掩过去”等情况。每周把抽检问题汇总分类按优先级排进知识库修正清单。这套流程保证了系统是活着的知识库每个月都会补充新内容比如新型环保材料参数提示词每个版本迭代都记录效果差异数据清洗的规则也在不断细化。这里想特别强调AI助手上线不是终点它更像一个需要持续照顾的“信息花园”不浇水不修剪几个月后杂草就会盖过庄稼。写在最后这个项目做完最大的感受是大模型能力再强也只是个“读资料、写答案”的好手真正决定咨询质量的是知识库的深度和流程设计的严谨度。我自己目前还在做一些小的扩展比如用图片输入做简单的材料识别拍一张地板照片判断大致品类以及把预算估算细化到具体的空间分区厨卫单独算。如果你也在做类似方向建议从你自己的装修需求出发选一个窄到具体的场景比如只做“旧房翻新咨询”切入会比一开始就想覆盖全部装修问题要稳得多。