Repository navigation
feat(AI) : 初版RAG方案 #39
Description
遵循敏捷开发原则，先开个mvp的初版RAG项目，提供好基础的代码框架，后续大家就可以进行进一步的分工提升。
技术选型
语言：Python
后端框架: FastAPI - 因为有专门的FastAPI转MCP的方案，方便后续拓展出MCP功能
RAG框架：LlamaIndex - 比Langchain更专注于RAG，所以更适合我们项目
向量数据库：Pinecone - Serverless 向量数据库，有免费套餐，适合 MVP 阶段
Rerank: Cohere - 免费
Embedding: Gemini Embedding - 目前没有设备，只能先用免费的线上模型
LLM: Gemini 2.5-flash-lite - 免费且快。
开发步骤
- 数据索引：开发一个 把 docs下所有文章分块并向量化存进 Pinecone 的 Python 脚本。分块策略先用全文处理，因为目前文章不多，且mvp先简单出发， 以搭框架为主。后面再采用更好的分块策略。
- 查询API：开发一个用于查询的接口，方便提供服务，接收用户提问，连接pinecone检索，传递LLM回答。
初步后续规划
- 优化效果，优化分块策略等
- 开发一个无 LLM 纯查询的 API 作为搜索 API 替换掉目前主站效果不好的搜索功能。
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
longsizhuo commentedon Jul 18, 2026
@Crokily 帮你做了一次现状核对（2026-07，逐文件确认过），这个方案立项 10 个月后生态已经变了不少，供你决定三个 issue 的去留：
已经存在的（当时规划的能力，如今以别的形态实现了）
involutionhell-agent-tools的检索用 Orama，schema 含embeddings: vector[512]+ 中文分词 tokenizer（src/search.mjs），索引从站点构建的 dump 加载app/api/chat/route.ts+lib/ai/）真正还缺的（RAG 的最后一公里）
现在的 chat 助手只做当前页上下文注入（读当页 MDX 塞进 system prompt），没有跨全库检索——用户在 A 页问 B 页的内容，助手看不见。
建议（供你定夺）
/api/chat，实现全库 RAG」——复用现有索引，零新基建、零新费用，工作量比原方案小一个量级如果你确认这个方向，我们可以把新 issue 的技术要点一起写清楚。三个 issue 的关闭/保留由你决定 🙌