RAG - Tag - 傲来说的博客https://aolaishuo.cc/tags/rag/RAG - Tag - 傲来说的博客Hugo -- gohugo.iozh-cnWed, 27 May 2026 00:00:00 +0800我用纯 Python 手搓了一个 RAG 知识库：不用 LangChain，也能让文档开口说话https://aolaishuo.cc/posts/%E6%88%91%E7%94%A8%E7%BA%AFpython%E6%89%8B%E6%90%93%E4%BA%86%E4%B8%80%E4%B8%AArag%E7%9F%A5%E8%AF%86%E5%BA%93/Wed, 27 May 2026 00:00:00 +0800傲来说https://aolaishuo.cc/posts/%E6%88%91%E7%94%A8%E7%BA%AFpython%E6%89%8B%E6%90%93%E4%BA%86%E4%B8%80%E4%B8%AArag%E7%9F%A5%E8%AF%86%E5%BA%93/我用纯 Python 手搓了一个 RAG 知识库：不用 LangChain，也能让文档开口说话

全文约 3000 字，阅读需要 6 分钟

起因

最近工作里有个很具体的痛点：文档太多，而且太杂。

合同扫描件、行业报告、内部资料、会议截图、Word、Markdown、PDF，格式五花八门。真正要用的时候，最麻烦的不是“有没有这份资料”，而是“我到底在哪份资料里见过这句话”。

我想要的东西其实很简单：

把这些文档丢进一个系统里，以后直接用自然语言提问，它能从资料里找依据、给答案、贴出处。

市面上当然有很多方案。但试了一圈，总觉得不完全合适：

  • 有的太重，依赖链很长，调一个小功能要理解一堆抽象；
  • 有的太贵，OCR、Embedding、LLM 全走 API，文档量一大成本就上来了；
  • 有的隐私边界不够清楚，公司资料直接传第三方服务器，这事很难放心。

于是我干脆自己写了一个。

项目名叫 RagLite：轻量、透明、尽量把重计算放在自己手里。

它能干什么？

一句话：把你的文档变成一个可对话的知识库。

比如扔进去 35 张截图，或者一本 459 页的扫描版 PDF，等它完成 OCR、分块、向量化和入库之后，就可以直接问：

“将军崖岩画是什么？”

它会先从知识库里检索相关片段，再调用大模型生成回答，并把来源一起贴出来。这样你既能快速得到结论，也能回到原文核对。

目前支持这些文件：

  • Markdown / 纯文本
  • Word（.docx）
  • PDF，包括纯图片扫描件
  • 图片截图（PNG / JPG）

我最看重的是两点：

第一，原始文件不必交给第三方平台。OCR 和向量化默认都可以在本机完成。

第二，代码路径足够短。出了问题，你能直接打开对应文件看懂它在做什么。

为什么不用 LangChain？

不是 LangChain 不好。

它解决的是“快速搭建复杂 LLM 应用”的问题，生态、集成、抽象都很完整。但我的需求没有那么复杂：文档解析、OCR、分块、Embedding、检索、生成，链路清楚，能跑稳就行。

很多时候，框架的抽象层会在前期让你觉得省事，到了调试阶段又把问题藏起来。链条、Agent、Tool、Memory，每个概念都包了一层。检索结果不对时，你可能要一路穿过好几层封装，才能找到真正影响结果的那个参数。

RagLite 的思路更朴素：

每个模块自包含，能少一层就少一层。

项目结构大概是这样：

config.py          # 配置，一个 dataclass
ingest/
  ocr.py           # OCR，调用本地 Ollama
  chunker.py       # 文档分块
  embed.py         # 向量化，支持多种模式
  pipeline.py      # 入库流水线
serve/
  store.py         # ChromaDB 存储
  retriever.py     # 混合检索
  api.py           # FastAPI 接口
  mcp_server.py    # MCP 协议

没有太多魔法。哪一步出问题，就看哪一个文件。

]]>RAG 选型不踩坑：15 个项目的真实数据告诉你谁在裸泳https://aolaishuo.cc/posts/2026-05-26-rag%E9%80%89%E5%9E%8B%E4%B8%8D%E8%B8%A9%E5%9D%9115%E4%B8%AA%E9%A1%B9%E7%9B%AE%E7%9C%9F%E5%AE%9E%E6%95%B0%E6%8D%AE/Tue, 26 May 2026 00:00:00 +0000傲来说https://aolaishuo.cc/posts/2026-05-26-rag%E9%80%89%E5%9E%8B%E4%B8%8D%E8%B8%A9%E5%9D%9115%E4%B8%AA%E9%A1%B9%E7%9B%AE%E7%9C%9F%E5%AE%9E%E6%95%B0%E6%8D%AE/RAG 选型不踩坑：15 个项目的真实数据告诉你谁在裸泳

数据采集日期：2026 年 5 月 26 日。所有量化数据来自 GitHub REST API 实时采集，社区评价来自 GitHub Issues、Reddit、HackerNews、知乎等 8+ 独立信源的交叉验证。

一、为什么 RAG 赛道值得重新审视

2023 年，RAG（检索增强生成）还是 LLM 应用的"标配架构"，几乎每个 AI 项目的技术选型讨论都从"用 LangChain 还是 LlamaIndex"开始。到了 2026 年，局面已经截然不同——框架之间开始分化，“去框架化"的声音越来越响，LlamaIndex 创始人 Jerry Liu 公开承认"框架时代正在结束”。

这不是说 RAG 本身不重要了。恰恰相反，几乎所有企业级 AI 落地场景都绕不开它——客服知识库、合同审查、技术文档检索、合规问答，每个场景背后都需要"让 LLM 基于你的私有数据回答问题"的能力。真正变化的是选择变得困难了：GitHub 上叫得出名字的 RAG 相关项目就有几十个，每个都宣称自己是"最佳实践"。选错一个框架的代价不只是技术债——团队时间、项目窗口期、甚至是领导层对 AI 战略的信任，都是沉没成本。

我们做了一件事：用数据说话。采集了 15 个主流 RAG 相关项目的实时 GitHub 数据，加上对 LangChain、LlamaIndex、Dify、RAGFlow、Haystack、LightRAG 六个核心项目在 Reddit、HN、知乎、GitHub Issues 等多源的社区口碑交叉验证，形成这份面向技术决策者的全景扫描报告。

二、15 个项目，六个赛道：一张全景图

先看全貌。这 15 个项目并非都在做同一件事，它们可以归入六个差异明显的赛道：

赛道 项目 头部 Stars 核心定位
RAG 框架 LangChain、LlamaIndex、Haystack、LangChain4J LangChain 122.7K 提供构建 RAG 管道的抽象层与集成生态
端到端平台 Dify、RAGFlow Dify 129.4K 从数据摄入到应用交付的一站式方案
Agent 框架 AutoGen、CrewAI、Semantic Kernel AutoGen 55.6K 多 Agent 协作与工作流编排
向量数据库 Qdrant、Milvus、Chroma、Weaviate Qdrant 29.9K 向量检索的基础设施层
RAG 系统 R2R 7.8K 专注 RAG 的完整解决方案
工具库 Instructor 6.2K 结构化输出的辅助工具

一个反直觉的发现：Stars 最高的不是 RAG 框架，而是端到端平台 Dify（129.4K Stars），比排名第二的 LangChain（122.7K）还多出近 7000 颗星。这背后反映的趋势是越来越多的团队不想自己拼积木了——从数据解析、向量化、检索、到 Prompt 编排和前端交付，他们想要一个完整的、可视化的解决方案。

]]>