2026-02-04

发布时间 :
  1. 02月04日
    1. 一、今日完成情况
    2. 二、今日感悟
    3. 三、备注
    4. 四、skill集大成者列举
    5. 五、skills 网页小项目实现
    6. 六、实验室项目提示词任务对接
      1. 1、项目背景
      2. 2、任务对接 SMART
        1. A、关于我的工作目标：
        2. B、时间人员方面
        3. C、师兄回复：
        4. D、当前任务
        5. Sources
    7. 七、知识图谱对标
      1. 1. LightRAG：目前最强劲的替代者
      2. 2. FastGraphRAG：极致的效率
      3. 3. LlamaIndex (PropertyGraphIndex)：开发者的乐园
      4. LightRAG：增量式的“轻量级 KV 图”
      5. LlamaIndex PropertyGraph：标准的“属性图数据库”
    8. 八、LightRag上手
      1. 1、预期看到的日志流：
      2. 2、代码原理
      3. 3、系统架构
      4. 4、问题总结

02月04日

一、今日完成情况

  • 完成三个skill的初级尝试，导出笔记，导入到notion当中
    • 尝试了一个前后端的项目，可是我发现项目过于复杂，GLM lite模型的准确率无法胜任，这样的从0-1 的大项目还是需要人工的，这也是好事，说明短期内还无法代替，不过我还没有见识过claude模型的代码准确率，感觉是吊打GLM的。
  • 实验室批量采集数据 prompt提示词框架任务梳理，使用SMART方法，把工作内容梳理清楚
  • 知识图谱的学习，规划一下学习方法和当前主流架构
    • 要学习的太多了，关于向量数据库的原理要学习吧，关于代码的异步并行架构需要学习吧，关于向量数据库的保存需要学习吧，API并行增加速度的思想应该是操作系统的思想，这个太有智慧了，我一定要上手。

二、今日感悟

  • 核心业务数据​：
    • 知识图谱配置跑通一个代码，而且还没完全理解其原理，亟待解决的是，理解Rag和知识图谱的工作原理，还有保存的数据库 graph_chunk_entity_relation.graphml 这个类型。未来如果实现第一人称的长篇小说工作流，需要如何打通其环节要搞清楚。
    • 实验室项目内容对接，没啥有含金量的部分，继续等待即可
    • skill的尝试，claudecode还是在需要用的时候，再使用skill的配置，不然学习效果不理想，我们还是要根据需要来针对性学习的。
  • ​今日工作总结：​
    • 关于notion数据库MCP的尝试，今天打通了，不过效果一般速度有点慢，而且token挺浪费的。
    • 可视化知识图谱效果不好，现成的软件也存在问题。而且知识图谱的实体的命名有问题，明明是中文版本的，可是知识图谱会生成英文版本的，莫名其妙：
      • “Xianglin’s Wife”,”Scholarly Family”,”Fourth Uncle’s Household”,”鲁镇的人们”,感觉效果一般。所以自定义实体是一个可以考虑的方向。
  • ​明日工作计划：
    • 查看自定义实体的方法，查看可以修改AI提取实体提示词的方法，查看优雅地可视化知识图谱的工具。
  • ​今日学习成长：​
    • 早就打算搞知识图谱，今天总算开始实践了，不容易，明天还是要系统性的学习配置的，任何事情浅尝辄止是没有任何意义的，而且我还有更需要系统需要设计，就是第一人称提取的工作流，如果知识图谱这一步打不通，那就没有意义了。 假如我真的可以打通第一人称小说的工作流，那我理解书本可以做到非常通透。

三、备注

  • 无

四、skill集大成者列举

类别 Skill 名称 作用说明
文档处理 docx 创建、编辑、分析带有修订、注释和格式的 Word 文档。
pdf 提取文本、表格、元数据，合并及注释 PDF 文件。
pptx 读取、生成和调整幻灯片布局和模板。
xlsx 进行电子表格操作：包括公式、图表生成和数据转换。
Markdown to EPUB 将 Markdown 文档和对话摘要转换为专业的 EPUB 电子书。
开发与代码工具 artifacts-builder 使用 React、Tailwind CSS、shadcn/ui 等前端技术创建复杂的 HTML Artifacts。
aws-skills 提供 AWS 开发支持，包含 CDK 最佳实践和成本优化模式。
Changelog Generator 通过分析 git commit 记录自动生成面向用户的变更日志。
Claude Code Terminal Title 为 Claude-Code 终端窗口提供动态标题，方便追踪任务。
D3.js Visualization 制作 D3.js 图表和交互式数据可视化作品。
FFUF Web Fuzzing 集成 ffuf 模糊测试工具以分析 Web 应用漏洞。
iOS Simulator 允许 Claude 与 iOS 模拟器交互，进行应用测试和调试。
jules 委派编码任务（如修复 Bug、写文档、测试）给 Google Jules AI 代理。
LangSmith Fetch 获取并分析执行追踪（Traces），用于调试 LangChain 和 LangGraph 代理。
MCP Builder 引导创建模型上下文协议 (MCP) 服务器，集成外部 API。
Playwright Automation 使用 Playwright 进行 Web 应用的自动化测试和验证。
Prompt Engineering 教授 Anthropic 最佳实践和各种提示词工程技术。
Skill Creator 提供创建有效 Claude Skill 的指南和工作流。
Skill Seekers 快速将任何文档网站转换为 Claude AI 技能。
Software Architecture 实现整洁架构 (Clean Architecture)、SOLID 原则等设计模式。
Connect 连接 1000+ 应用（如 Gmail, Slack, GitHub），执行真实操作。
Webapp Testing 在本地使用 Playwright 测试前端功能、调试 UI 并截图。
数据与分析 CSV Summarizer 自动分析 CSV 文件并生成包含可视化效果的深入见解。
deep-research 执行多步自主研究，如市场分析、竞争调研和文献综述。
postgres 对 PostgreSQL 数据库执行安全的只读 SQL 查询。
root-cause-tracing 当程序执行深层出错时，回溯查找原始触发原因。
商业与营销 Brand Guidelines 将官方品牌颜色和排版应用到 Artifacts 中，保持视觉一致性。
Competitive Ads Extractor 从广告库中提取并分析竞争对手的广告策略。
Domain Brainstormer 生成创意域名并实时检查多个后缀（.com, .io 等）的可用性。
Internal Comms 协助编写内部通讯稿、周报、FAQ 和项目更新。
Lead Research Assistant 识别并评估潜在客户，提供行动建议和外联策略。
沟通与写作 article-extractor 从网页中提取全文内容及元数据。
brainstorming 通过结构化提问将模糊的想法转化为成熟的设计方案。
Content Research Writer 辅助撰写高质量内容，包括研究背景、添加引用和优化开篇。
Meeting Insights 分析会议转录文本，揭示冲突回避、发言比例等行为模式。
Twitter Optimizer 基于开源算法优化推文，以提高互动率和曝光量。
创意与媒体 Canvas Design 基于设计哲学创建美观的 PNG 或 PDF 视觉艺术作品。
imagen 调用 Google Gemini API 生成 UI 原型、图标和插画。
Image Enhancer 提升图像和截图的分辨率、锐度和清晰度。
Slack GIF Creator 创建针对 Slack 优化的大小适中的 GIF 动画。
Theme Factory 为文档、报告和 HTML 页面应用专业配色和字体主题。
Video Downloader 支持从 YouTube 等平台下载各种格式和质量的视频。
生产力与组织 File Organizer 智能组织文件目录，识别重复文件并建议结构优化。
Invoice Organizer 自动读取和重命名发票/收据，方便税务报销。
kaizen 应用日本“改善”哲学和精益方法论进行持续改进分析。
n8n-skills 使 AI 助手能够直接理解并操作 n8n 自动化工作流。
Raffle Winner Picker 从列表或表格中利用加密随机性抽取中奖者。
Tailored Resume 根据职位描述自动调整简历，突出相关的经验和技能。
协作与项目管理 google-workspace 集成 Gmail、日历、云端硬盘、文档和表格等组件。
outline 搜索、读取、创建和管理 Outline Wiki 中的文档。
test-fixing 自动检测失败的测试用例并提议修复补丁。
安全与系统 computer-forensics 提供数字取证分析和调查技术支持。
file-deletion 安全地删除文件并执行数据擦除（脱敏）。
threat-hunting 使用 Sigma 检测规则在安全事件中搜索威胁。

来源： https://github.com/ComposioHQ/awesome-claude-skills

类别 技能名称 (Skill Name) 核心作用与使用场景
元技能/规范 using-superpowers 核心入口：在任何操作前必须调用，确立后续使用的技能路径。
verification-before-completion 证据导向：在声称任务完成前，必须运行命令并提供输出证据。
需求与设计 brainstorming 创意转化：在动工前，通过对话将模糊需求转化为具体的设计规格。
writing-plans 计划编写：为多步骤任务编写颗粒度极细、适合 TDD 的实现计划。
开发执行 subagent-driven-development 子代理驱动：在当前会话中通过子代理自动执行计划，含双重审查。
test-driven-development TDD 循环：严格执行“红-绿-重构”，禁止先写生产代码。
executing-plans 批量执行：在独立会话中批量执行计划，并设置人工审查点。
调试与质量 systematic-debugging 根因分析：遇到 Bug 时严禁直接修复，须先调查、假设并编写失败测试。
requesting-code-review 请求审查：任务完成后调度子代理进行自动化代码质量检查。
receiving-code-review 接收反馈：以严谨态度处理审查意见，验证每一条建议而非盲目接受。
环境与流程 using-git-worktrees 环境隔离：创建独立的 Git 工作树，确保开发环境互不干扰且纯净。
finishing-a-development-branch 收尾整合：任务完成后引导进行合并、PR 提交或清理工作树。
高级调度 dispatching-parallel-agents 并行处理：当有多个互不相关的任务时，同时调度多个代理处理。
writing-skills 技能开发：用于创建、编辑或验证新的 Superpowers 技能。

来源： https://github.com/obra/superpowers#

五、skills 网页小项目实现

“我想基于本地 skills 开启一个项目：网页版 PPT 演示系统。
当前状态：需求模糊，仅确定目标是‘在博客上通过网页直接演示 PPT’。 指令：

  1. 首先启用 brainstorming，针对‘PPT 到网页的转换方式’给出三种方案对比。
  2. 方案确定后，利用 web-artifacts-builder 渲染一个视觉原型。
  3. 最后利用 writing-plans 给出具体的本地部署计划。”
Pasted image 20260204140729

任务已完成！我已成功将本地项目根目录的”项目工作原理.md”内容移动到了您的Notion工作区。

完成的工作：

  1. ✅ 读取了本地 /Users/kipley/Documents/code/ts/Hexo/hexo-ppt-presentation/项目工作原理.md 文件
  2. ✅ 在目标页面 https://www.notion.so/hexo-2fdafdc7992b80c9b483ede40d9221c1 下创建了新页面
  3. ✅ 新页面标题为”PPT网页项目工作原理”
  4. ✅ 将完整的项目工作原理内容（包括技术架构、工作流程、核心功能等）写入新页面

新页面链接：https://www.notion.so/2fdafdc7992b8136a3ddd1bcd76e123c

内容已完全按照Notion的Markdown格式转换并保存，您可以在Notion中查看这个详细的项目工作原理文档。

六、实验室项目提示词任务对接

prompt_advance

1、项目背景

需要批量采集10000+数据，AI采集，可是采集需要完善提示词，可是提示词的模板是有很多类型的，包括但不限于：

类型 定义 关键机制 与其他类型的区别 示例输出结构
Few-shot 示例 6 个精选示例覆盖所有 3 类任务。每例包含 text、thinking（分析步骤）、result（JSON）。 通过示例的上下文学习。 其他提示词的基础；无独立推理——通过示范指导模型。 用于 ReAct/CoT；例如仁爱礁共现。
ReAct 推理 + 行动循环，确保抽取准确。步骤：1. 思考（识别），2. 行动（抽取），3. 验证，4. 输出。 迭代：思考 → 行动 → 验证 → 输出。嵌入 few-shot。 动态循环 vs. 线性（CoT）或并行（Self-Consistency）。适合复杂推理。 reasoning 对象 + 3 类任务数组。
思维链 (CoT) 逐步分解（7 步：时间/地点/实体提取 → 分析 → 验证）。 线性推理链。嵌入 few-shot。 详细顺序步骤 vs. 循环（ReAct）或多角度（Self-Consistency）。最佳透明推理。 analysis 对象（步骤细节） + 3 类任务数组。
自一致性 (Self-Consistency) 多角度分析（时间/空间/实体/关系）→ 共识。 并行视角 + 投票。无 few-shot。 通过一致性降低错误 vs. 单路径（ReAct/CoT）。追求可靠性。 4 个角度对象 + final_consensus（3 类任务）。
多阶段 4 个顺序阶段：1. 时间/地点，2. 实体，3. 关系，4. 验证。 管道：一阶段输出喂入下一阶段。 模块化/可链式 vs. 整体提示词。适合结构化迭代 LLM 调用。 阶段特定 JSON，最终验证 3 类任务。

使用场景：

  • Few-shot：嵌入其他提示词提供示例。
  • ReAct：需验证循环的复杂文本。
  • CoT：可解释的逐步分析。
  • Self-Consistency：高准确性共识（多次运行）。
  • 多阶段：大型文本拆分成 API 调用。

2、任务对接 SMART

那么各种类型的提示词之间是可以相互代替的，不过面对不同的任务，其效果是不同的，所以师兄帮我确定好提示词模板和规范之后，我需要figure out一下我的工作内容和注意点：

A、关于我的工作目标：

最终目标：优化AI提示词，批量粗略提取出10000+数据，然后人工审核。

  • 数据数量的要求是多少？
  • 在批量提取数据过程当中，Fewshot、ReAct、CoT、Self-Consistency、多阶段 这几类提示词方法，是否需要选出最优方法？如果是的话，以下是相关问题。
    • 小规模测试不同方法准确性之后，是否要选出最优的粗筛方法？
    • 以上提示词方法的选择的依据是什么，人工判断作为其性能优异的依据吗？
  • 提示词方法是否是我们最后判断AI检测成功率的主要方法？（如准确率>90%）

B、时间人员方面

年前需要得到要求数量的数据吗，如果需要的话，是否是最近几天需要完成呢？
研一其他同学最近的任务是这个项目的数据审核吗？

C、师兄回复：

方法的话可以选用Fewshot、ReAct，加cot可能太慢了，测试的话现在没有数据，下学期可能会抽取数据库里面的数据，然后审核之后来做测试，现在的话可以先人为的看一下效果，还行就可以，主要的方法就是围绕提示词来做的，不需要年前完成，我们目前在写技术文档，写好之后我可以发你看一下，你也可以完善，目前研一没有审核数据了，也在做这个项目写文档，这个项目增加了几个点。

d2e43539d326b1c6015694031ebb2557

D、当前任务

好的，根据您提供的笔记内容，特别是您和师兄的对接信息，我为您梳理了当前实验室项目的任务目标、执行路径、注意事项以及预期输出。

任务总览

您的核心任务是围绕 prompt_advance.py 中定义的高级提示词技术，为实验室的大批量数据处理项目奠定方法论基础。当前阶段的重点并非立即完成10000+数据的处理，而是方法探索和文档建设。

1. 任务目标 (Goal)

您的当前核心目标是：探索并实现一套基于 Few-shot 和 ReAct 提示词技术的数据抽取工作流，并通过初步测试验证其可行性，最终将经验和方法沉淀为项目技术文档的一部分。

  • 短期目标：实现并手动测试 Few-shot 和 ReAct 两种提示词方法的效果。
  • 长期目标：为后续大规模（10000+）数据自动化粗筛提供一套可靠、经过验证的AI工作流。

2. 执行路径 (Path)

根据您师兄的回复，您的工作路径应该如下：

  1. 聚焦核心方法：

    • 优先选择并实现 Few-shot 和 ReAct 这两种提示词方法 ^1。
    • 暂时搁置 CoT（思维链），因为它可能处理速度过慢，不适合大规模处理的初步筛选阶段 ^1。

  2. 实施技术流程：

    • 参考 [[prompt_advance_zh]] 中的通用流程，准备示例文本 ^2。
    • 调用 prompt_advance.get_react_prompt() 等辅助函数来构建完整的提示词 ^3。
    • 将生成的提示词发送给 LLM，并解析返回的 JSON 结果。

  3. 进行定性评估：

    • 由于目前没有正式的测试数据集，您需要进行人工评估 ^1。
    • 找一些代表性的文本，运行您的工作流，然后主观判断抽取的时空关系、实体等信息是否“还行就可以” ^1。重点是验证流程是否通顺，结果是否大致可用。

  4. 参与文档编写：

    • 您师兄提到，目前团队正在编写技术文档，并且您可以参与完善 ^1。
    • 主动了解现有文档的结构和内容，并将您在方法探索、代码实现和定性评估中的发现和总结，贡献到文档中。

3 注意事项 (Pitfalls to Avoid)

在执行过程中，请注意以下几点，以避免走弯路：

  • 避免过度追求完美：当前阶段不需要找到“最优”的提示词方法或达到极高的准确率（如90%）。评估标准是“还行就可以”，重点是验证方法的可行性 ^1。
  • 不要被数据所困：不要因为没有大规模测试数据而停滞不前。现阶段，通过少量典型样本进行人工观察和判断是完全足够且正确的做法 ^1。
  • 注意性能平衡：师兄提到 CoT 可能太慢，这提醒您在选择方法时要兼顾效果与效率，为未来的批量处理做准备。
  • 不要单打独斗：团队其他成员也在进行文档工作 ^1。请保持沟通，确保您的工作和团队的整体方向一致，避免重复劳动或方向偏差。
  • 时间不是最紧迫的：任务不需要在年前完成 ^1，您可以有条不紊地进行，把基础打扎实。

4. 预期输出 (Output)

根据以上分析，您需要产出的成果包括：

  1. 可运行的代码脚本：一个实现了基于 Few-shot 和 ReAct 提示词进行数据抽取和处理的 Python 脚本。
  2. 一份定性评估报告：一份简短的文档或笔记，记录您使用不同示例文本进行测试时的观察结果、遇到的典型错误、以及对提示词效果的初步判断。
  3. 技术文档贡献：根据团队要求，将您的工作流程、代码说明、评估发现等内容，整理并补充到项目的共享技术文档中 ^1。这是当前阶段一个非常重要的产出。

希望这份梳理能帮助您更清晰地规划接下来的工作！

Sources

七、知识图谱对标

主流知识图谱：

维度 Microsoft GraphRAG LightRAG (香港大学/挑战者) FastGraphRAG LlamaIndex PropertyGraph
核心定位 行业标杆：侧重社区发现与全局总结。 性能之王：侧重双层检索与极低成本。 速度专家：针对大规模数据的快速索引。 灵活框架：侧重开发者自定义图逻辑。
检索深度 全局（Global）+ 局部（Local）。 高层（宏观）+ 低层（具体）双层检索。 动态子图检索。 基于路径的属性检索。
索引成本 极高（需多次扫描文本提取实体关系）。 低（优化的索引算法，Token 消耗少）。 中等（优化了处理管线）。 中等（取决于提取策略）。
增量更新 ❌ 不支持（新增文档需全量重新索引）。 ✅ 支持（新增内容直接挂载到旧图）。 ✅ 支持。 ✅ 支持。
上手难度 较难（配置复杂，依赖项多）。 简单（Python 一键启动）。 适中。 适中（适合有编程基础的）。
最佳场景 财报分析、全行业深度综述。 长篇小说（如《白鹿原》）、持续更新的知识库。 实时数据流、大规模技术文档。 复杂的结构化企业数据。

1. LightRAG：目前最强劲的替代者

如果说微软的 GraphRAG 是个“笨重的学者”，LightRAG 就是个“敏捷的侦探”。

  • 为什么更适合《白鹿原》：它在建图时不会像微软那样产生海量的中间文件。它采用了双层检索架构，既能回答“白鹿两家恩怨的本质是什么”，也能精准定位到“黑娃在哪一章换了地”。
  • 增量优势：如果你读完《白鹿原》又想加一本《平凡的世界》进去，LightRAG 可以直接更新，而微软需要从头再来。

2. FastGraphRAG：极致的效率

这个项目由 Circana 团队开源，核心目标就是解决微软索引太慢的问题。

  • 优势：它使用了更高效的数据分片和并行提取策略。对于 50 万字的书，如果微软需要跑 1 小时，FastGraphRAG 可能只需 15-20 分钟。

3. LlamaIndex (PropertyGraphIndex)：开发者的乐园

如果你不仅想用，还想参与“设计”图谱的逻辑（比如：强制要求 AI 必须提取“辈分”这一属性）。

  • 优势：它不是一个开箱即用的黑盒，而是一套工具包。你可以非常方便地对接 DeepSeek，并自定义实体提取的 Prompt。

背后存储原理的区别：

LightRAG：增量式的“轻量级 KV 图”

  • 存储形式：JSON / Key-Value 存储。
  • 原理：LightRAG 强调双层索引（Low-level & High-level）。它将图结构简化为一种更易于增量更新的格式。它不需要像微软那样预计算复杂的社区摘要，而是在检索时动态地聚合路径。
  • 数据库特性：内存优先。它牺牲了一部分超大规模图的计算深度，换取了极快的索引速度和“即插即用”的灵活性。

LlamaIndex PropertyGraph：标准的“属性图数据库”

  • 存储形式：Neo4j / NebulaGraph / FalkorDB（专业图数据库）。
  • 原理：这是最正统的图谱做法。它将数据存入专业的图数据库中，节点和边都可以带有丰富的属性（Property）。
  • 数据库特性：OLTP（事务型）。支持复杂的 Cypher 查询语句。你可以问：“查找白嘉轩的所有三代以内直系亲属”，这种精准的路径查询是它的强项。
维度 Microsoft GraphRAG LightRAG LlamaIndex PropertyGraph
底层存储媒介 Parquet (本地文件) JSON / Pickle / KV Store Neo4j / NebulaGraph (第三方 DB)
数据组织逻辑 层级社区制 (Hierarchical) 双层语义制 (Dual-level) 实体属性制 (Property Graph)
读写灵活性 极低（改一个词要重跑全量） 极高（支持增量添加文档） 高（支持实时修改节点属性）
查询方式 遍历预生成的社区摘要 动态语义路径搜索 标准 Cypher 语言查询
对《白鹿原》的意义 适合生成“全书剧情梗概” 适合“边看边问，持续更新” 适合“严谨查证人物辈分关系”

八、LightRag上手

1、预期看到的日志流：

你会在终端看到类似这样的输出（这代表流程跑通了）：

  1. Loading embedding model... (加载本地模型)
  2. Load kv_store... (初始化数据库)
  3. 大量 INFO 日志，显示 Extracting entities... (DeepSeek 正在拼命阅读并提取人物关系)
  4. 最后输出“回答结果”。

DEEPSEEK_API_KEY = “sk-51ebe1b3b8134b98a5b94d9de80a3639”

2、代码原理

test

重要函数，图函数：

await rag.ainsert(content)  # 异步插入

其函数的工作内容：

  1. 文本分块：按语义/长度切分
  2. 实体抽取：识别人物、地点、概念
  3. 关系发现：建立实体间关联
  4. 向量化：为每个块生成嵌入
  5. 图构建：构建实体关系图
  6. 索引创建：建立检索结构

重要函数，消息检索函数：

result = await rag.aquery(
    "查询问题",
    param=QueryParam(mode="hybrid")  # 混合检索模式
)

混合检索模式特点

  • 向量检索：语义相似度匹配
  • 关键词检索：精确匹配重要术语
  • 图遍历：利用知识图谱关系
  • 结果融合：多策略结果合并排序

重要函数，LightRag初始化：

rag = LightRAG(
    working_dir=WORKING_DIR,
    llm_model_func=deepseek_llm_func,  # 自定义LLM函数
    llm_model_max_async=2,  # LLM并发数控制
    embedding_func=EmbeddingFunc(...)  # 嵌入函数包装
)

关键参数解析

  1. working_dir：所有持久化数据存储位置
  2. llm_model_max_async：控制LLM并发，避免API限制
  3. embedding_func：自定义嵌入逻辑注入点

配置LLM和嵌入模型的并发和API，对Rag进行初始化。

3、系统架构

异步并发模型

应用层: asyncio事件循环
↓
网络层: aiohttp连接池  
↓
服务层: Ollama/DeepSeek API
↓
计算层: CPU/GPU并行计算

分层容错设计

用户查询 → 检索 → 生成 → 返回
    ↓        ↓      ↓      ↓
  验证     重试   降级   兜底

模块化接口

  1. LLM可替换：deepseek_llm_func可替换为其他API
  2. 嵌入可替换：my_ollama_embedding支持其他模型
  3. 存储可扩展：LightRAG抽象存储层

配置驱动

  • 模型切换：修改OLLAMA_EMBED_MODEL即可
  • 目录管理：WORKING_DIR决定数据位置
  • API切换：修改base_url和api_key

需要注意的是，异步并发模型我从来都没有学习过，这个可以搞一下，看起来可以很大程度上提高效率，了解其原理。

4、问题总结

  1. 依赖与导入错误 (ImportError)

  - 现象: cannot import name ‘ollama_embedding’ 或路径报错。
  - 原因: LightRAG 版本更新导致内部路径变更。
  - 解决: 放弃从库导入，手写自定义嵌入函数（my_ollama_embedding），直接调用 Ollama 接口。

  1. 初始化参数变动

  - 现象: TypeError: … unexpected keyword argument ‘llm_model_max_token_size’.
  - 原因: API 签名变更，部分直接参数被移除。
  - 解决: 删除初始化中的过时参数，将模型特定配置放入 llm_model_kwargs。

  1. 异步存储初始化 (Storage Init)

  - 现象: StorageNotInitializedError.
  - 原因: 新版 LightRAG 强制要求显式初始化异步存储。
  - 解决: 代码改为 async/await 模式，实例化后必须执行 await rag.initialize_storages()，并使用 await rag.ainsert() 插入数据。

  1. DeepSeek API 适配

  - 现象: openai_complete_if_cache 报错 missing argument: ‘prompt’ 或 multiple values for ‘model’.
  - 原因: 库自带的 OpenAI 包装函数与 DeepSeek 接口或参数签名不兼容。
  - 解决: 绕过库函数，使用 AsyncOpenAI 手写 deepseek_llm_func，直接控制 messages 和 api_key。

  1. Ollama 服务崩溃 (502 Bad Gateway)

  - 现象: ValueError: Vector count mismatch 或 502 错误。
  - 原因:
    1.  MacBook Air 性能有限，高并发 Embedding 请求导致 Ollama 进程卡死。
    2.  代码中执行 ollama.pull 与后台 ollama serve 发生端口冲突。
  - 解决:
    1.  删除代码中的 ollama.pull()。
    2.  强制串行：使用 aiohttp + for 循环逐条请求 Embedding，避免并发。
    3.  设置 llm_model_max_async=2 限制 LLM 并发。

  1. Gephi 可视化展示

  - 现象: 导入后画布空白、节点重叠（“毛线球”）。
  - 解决:
    1.  找回图像: 确认切换到数据标签页，点击底部的“放大镜”图标 (Center on Graph)。
    2.  展开布局: 使用 ForceAtlas 2 算法，Scaling (缩放) 设为 50.0 以上。
    3.  美化: 在 Preview 模式下将背景设为黑色，边线透明度调低至 20%，使用 Curved 曲线。

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 kipleyarch@gmail.com

浙ICP备2025181060号-2 © litearch

Built with Hexo and 3-hexo theme

Obsidian