- 博客(15)
- 收藏
- 关注
RSS订阅原创 企业级知识库核心逻辑与实战要点
以 WisdomLink2 后端（FastAPI + SQLAlchemy + LangGraph + Milvus/Qdrant/FAISS）为蓝本。 定位：讲清楚一个生产级知识库系统真正的核心逻辑是什么、企业场景里每一步会死在哪里、以及对应的解法。 所有机制均在本项目中真实落地，括号内标注对应模块，可对照源码验证。
2026-09-22 13:00:36
121
原创 打造可信的企业知识库：RAG 工程实践实录
本文分享企业知识库构建中RAG工程的实战经验，聚焦“可信问答”核心目标。通过四条红线（可溯源、秒回、容错、可切换）指导架构设计，实现文档解析、清洗、切片与原子化索引重建。采用三路召回（向量、关键词、图谱）+ RRF融合+重排模型的检索链路，保障精准与鲁棒。高频问题直返标准答案，避免大模型调用。系统支持本地/云端一键切换，组件故障不阻塞服务。强调“小片段命中、大片段上下文”的父子切片策略，确保答案可验证、可追溯，真正打造可信赖的企业智能问答系统。
2026-09-21 10:19:51
231
原创 知识库RAG系统踩坑实录
本文分享了从RAG Demo到可用企业知识库系统过程中踩过的七大核心坑：未初始化变量导致静默降级、errors="replace"引发数据污染、检索命中≠实际引用、幽灵进程伪装配置错误、流式接口收尾逻辑失效、中文环境编码陷阱，以及修复引入新缺陷。每个问题背后都是生产环境特有的“非理想路径”——教程避而不谈的沉默失败、隐性依赖与协议差异。作者强调：真正的系统可用性不在于功能跑通，而在于对失败路径的显式处理、上下文日志、fail-fast设计与全链路一致性验证。
2026-09-15 22:01:52
111
原创 从零构建LLM-Wiki知识库系统
本文介绍了一种创新的LLM Wiki知识库系统，通过三层架构（原始资料层、Wiki层、Schema层）实现知识的复利增长。系统支持从文档或主题生成结构化词条，采用三层降级问答机制（Wiki词条→RAG文档→参数化兜底），并包含自动维护功能（健康检查、知识图谱、交叉引用）。相比传统RAG系统，LLM Wiki能够积累知识、利用LLM内置知识、构建知识网络，实现零成本本地运行。技术栈采用全异步FastAPI架构，支持多种LLM服务，解决了知识无积累、通用知识浪费等痛点。
2026-07-11 22:58:21
776
原创 LLM Wiki 知识库详解：从有损压缩到复利增长的知识革命
本文系统分析了三种知识库范式：参数化知识库（直接问LLM）、传统RAG知识库和LLM维护的持久化Wiki。文章指出，LLM本质是互联网的有损压缩，而持久化Wiki通过三层架构（原始资料层、Wiki层和Schema层）实现了知识的复利增长，解决了人工维护Wiki的高成本问题。三种范式各具特点：参数化知识库简单但模糊，传统RAG精确但无积累，持久化Wiki能自动维护交叉引用并积累知识。选择方案时应考虑精确性、私有性和长期价值需求。持久化Wiki代表了知识管理的新范式，实现了Vannevar Bush设想的自动维
2026-07-11 22:42:21
243
原创 RAG与SAG-检索增强与搜索增强深度对比分析
本文对比了RAG（检索增强生成）和SAG（搜索增强生成）两大AI生成范式的本质差异。RAG通过向量检索本地知识库生成回答，具有响应快、数据私密可控的优势，但受限于知识库的时效性和覆盖范围；SAG通过调用搜索引擎获取互联网最新信息，具有实时性强、覆盖广的特点，但存在隐私风险和高延迟问题。文章从架构设计、数据来源、实时性、隐私安全等维度进行了详细对比，指出两者并非替代关系，而是互补技术，建议根据业务场景（如内部知识查询用RAG，最新资讯获取用SAG）进行混合架构设计。作者还分享了KB-MVP项目的实践经验，强调
2026-07-09 11:28:59
532
原创 不再被 FunASR 官方服务折磨：基于 FastAPI 构建生产级中文语音识别服务
文章摘要 该项目基于FastAPI重构了FunASR的中文语音识别服务，解决了官方runtime服务在稳定性、内网部署和错误处理等方面的问题。核心设计包括：1) 采用BaseASRModel抽象基类+ModelManager注册表模式，实现模型可扩展管理；2) 封装Paraformer-zh模型及其VAD、标点恢复子模型，提供端到端语音识别能力；3) 通过FastAPI提供稳定RESTful接口。该方案保留了FunASR优秀的模型能力，同时构建了更适合生产环境的服务层，已在GitHub和Gitee开源。
2026-07-09 09:36:17
220
原创 RAG技术栈复用实战-从知识库问答到多业务场景扩展
RAG技术栈复用实战：从知识库到多业务场景扩展 本文探讨如何将RAG知识库系统的技术栈复用于智能客服、内容推荐等业务场景。核心观点是：约70%的RAG组件可直接复用，差异化适配主要集中在数据颗粒度、意图解析和排序策略三个维度。 文章拆解了RAG的七大核心模块（内容分块器、向量化器、向量存储、意图识别器、检索编排、重排序器和LLM生成器），评估了各模块在不同场景下的复用度。以智能客服系统为例，展示了如何通过调整QA对分块方式、新增意图分类模块和置信度兜底机制，复用知识库问答系统的基础设施。 这种技术栈复用方法
2026-07-08 10:08:54
325
原创 从零构建轻量级RAG知识库问答系统
本文介绍了一个轻量级RAG知识库问答系统KB-MVP的设计与实现。该系统针对现有方案部署复杂、模型绑定、答案不可溯源等问题，采用零外部中间件设计（使用numpy+JSON存储），支持多供应商模型灵活切换（适配通义千问、DeepSeek、GLM、Ollama等），并实现答案溯源功能。系统基于Python+FastAPI构建，采用抽象基类+工厂模式实现模型适配层，通过.env配置即可切换不同供应商。核心特点包括：单进程运行、本地化优先、引用溯源高亮和万级向量瞬时检索，验证想法仅需python -m app.ma
2026-07-07 14:21:37
621
原创 自定义Gateway网关
官网在下图提供了 Spring Cloud Gateway 工作原理的高级概述：客户端向 Spring Cloud Gateway 发出请求。如果网关处理程序映射确定请求与路由匹配，则会将其发送到网关 Web 处理程序。该处理程序通过特定于请求的过滤器链运行请求。过滤器被虚线分开的原因是过滤器可以在发送代理请求之前和之后运行逻辑。执行所有“预”过滤器逻辑。然后发出代理请求。发出代理请求后，将运行“post”过滤器逻辑。实际上，官网的描述并不是特别清晰。请求进入Gateway Client。
2024-10-17 15:49:55
1698
原创 自定义类加载器解决jar包多版本冲突问题
在项目中，版本冲突问题很常见。就以国密安全方案为例。java国密依赖的jar包：bcprov-jdk15on。常见1.5*版本跟1.6*版本之间冲突。当项目需要跟多个三方对接。三方提供的安全方案所依赖的包两种版本都有时，就需要解决版本冲突。使都两种国密安全方案能正常使用。使用自定义类加载器解决版本冲突问题。
2024-10-09 16:38:32
2135
1
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人