RAG 实践 & AI 当下发展

type

status

date

slug

summary

背景

公司的 1024 节日开展了一个自建 RAG 应用的比赛，虽然在比赛之前，我已经接触并参与了一些相关项目，但相比于比赛的形式，这种有标准化输入输出还能评判优劣的场景，对自己的实际能力考察确实会更加全面

赛事经历

赛事介绍：

模仿客服的角色定位，结合众多产品的私有知识库，回答赛方评委提供的一些问题，问题类型包含（文本、图片和视频）

应用结果通过公网可访问 API 来输出，问题即 request，答案即 response

团队作业，4-5 人一组（不同方向：前端、大数据、IT 等等）

期间自己还参与了其他的一些 toy 项目，比如： AI 女友聊天机器人

这里先聊聊团队作业，从离开大学之后，再次和不同频道、不同专业的人协作比赛，人和人的沟通成本确实比自己闷头做要高很多，~~但好处是大家都有自己的分工，自己只需要做好自己的事情，然后和队友同步进度，最后再合并到一起，这样确实可以完成一个相对完整的东西~~

技术思考

比赛的整体方案思路比较朴实无华：

对图片做 OCR 提取文本信息，对视频做字幕提取文本信息，对所有文本信息做结构化处理

对知识库做清洗、切片、整理，内嵌到 LLM 中

对问题做前置工作：意图识别、意图发散、问题转义和记忆上下文变量

LLM 处理问题，对得到的结果进行过滤、精炼、总结

格式化最终返回结果

期间尝试了字节的 COZE，其应用完善程度超乎我的想象，就是有些节点（记忆上下文、知识库查询）效果还差点

期间也做了两套方案：

COZE 的工作流编排方案

使用 LangChain 的直接 prompt 调用方案

最后因为知识库查询的准确度问题，还是使用了方案 2

后续

团队老大最后在赛事总结的时候，提到一个概念：我们要当设计者，而不是执行者

结合我自身也将近两年的工作经历来看，这确实是一个方向上的转变，从执行者到设计者的转变

管理层的绩效目标，是定向锚定目标去拿结果，至于过程中谁做的、谁付出最多，那是团队内部的事情

社会性群体，天然就会形成类似 1-3-5-1 的比例群体，十个人的团队，锚定📌自己的定位，很重要

承上启下

技术之外的事情到此结束，回到技术本身

行业内对这个业务场景的标准作业流是怎样的，我找到了这样一张图

问答系统架构分析

上图展示了一个复杂的问答系统的工作流程，分为 查询翻译、路由、查询构建、索引、检索和生成六大模块。以下是按流程顺序的详细分析和补充说明：

1. 查询翻译（Query Translation）

查询分解（Query Decomposition）: 将复杂问题分解为子问题或分步问题，例如：

多轮查询（Multi-query）
回溯查询（Step-back）
检索-生成融合（RAG-Fusion）

伪文档生成（Pseudo-documents）: 使用 HyDE 技术生成假设性文档，以帮助回答潜在的复杂问题。

补充分析：

通过问题分解与伪文档生成，可以提升系统处理复杂问题的能力，适用于需要多轮推理或具备丰富背景知识的对话场景。

2. 路由（Routing）

逻辑路由（Logical Routing）: 基于查询逻辑选择适合的数据库类型（关系型数据库、图数据库或向量数据库）。

语义路由（Semantic Routing）: 将查询转换为语义向量，通过语义匹配选择最合适的提示或数据库。

路由模块提升了系统的效率和准确性。逻辑路由解决了数据库选择的问题，而语义路由进一步优化了查询意图与匹配效果。

3. 查询构建（Query Construction）

关系型数据库（Relational DBs）:

通过 Text-to-SQL 技术将自然语言转换为 SQL 查询。
支持关系型数据库操作，并可结合 PGVector 进行嵌入查询。

图数据库（Graph DBs）: 使用 Text-to-Cypher 技术将自然语言转换为 Cypher 查询语言，以访问图数据库。

向量数据库（Vector DBs）: 采用自查询检索器（Self-query Retriever），自动生成元数据过滤条件，支持向量数据库。

该模块支持多模态查询（SQL、Cypher、向量化），适用于结构化和非结构化数据存储，实现多源信息的融合。

4. 索引（Indexing）

分块优化（Chunk Optimization）: 使用语义分割器（Semantic Splitter）按字符、段落或语义片段拆分文档，提高嵌入效率。

多表示索引（Multi-representation Indexing）: 将文档转化为紧凑的表示单元（如摘要），以便快速检索。

专用嵌入（Specialized Embeddings）: 通过微调技术（如 ColBERT）优化嵌入表示的任务特化能力。

分层索引（Hierarchical Indexing）: 采用 RAPTOR 技术实现文档的分层抽象与组织。

索引模块通过分块、分层和优化技术，提升系统性能，特别适合大规模语料库的高效检索需求。

5. 检索（Retrieval）

排序与精炼（Ranking & Refinement）: 使用 Re-Rank、RankGPT 或 RAG-Fusion，对检索到的文档进行相关性排序、过滤和压缩。

主动检索（Active Retrieval）: 如果初始检索结果不理想，可采用 CRAG 技术从其他数据源重新检索。

检索模块支持动态调整，确保系统对实时数据和复杂查询的适应性，是开放域问答系统的核心能力。

6. 生成（Generation）

主动生成检索（Active Retrieval for Generation）: 根据生成质量，动态调整问题的重写或重新检索。

Self-RAG 与 RRR: 将生成模型（如 GPT）与检索模块（如 RAG）结合，优化答案质量。

生成模块结合检索结果与生成能力，提供高质量且解释性强的答案，适用于需要推理或生成复杂内容的场景。

总结

图中的技术（如 RAG-Fusion、ColBERT、HyDE）处于前沿水平，是多源异构数据融合与生成增强的典型架构

可以看出，RAG 技术在问答系统中已经非常成熟，在实际应用中，RAG 可与其他技术结合使用，以达到更好的效果

AI 当下发展

我目前日常使用的 AI 应用：

Cursor IDE

豆包（拍照识图、百度百科

体验过程中明显能感觉到：

国内应用在服务体验上，更能体现一个产品的优势

国外应用则是在专业角度上，内容更加全面和权威

再来看这位行业投资人的看法：

其中不乏有些"暴论"，但整体的一个思考逻辑，还是挺能反映问题的

AI 应用会先落实在 b 端，然后反哺 c 端

国内因为体制的原因，真正的 AI 助手落地十分困难

至于我们的态度? —— 当下的风口还没停下来，需要关注亦或者等待一个机会的来临