diff --git a/README_prompts.md b/README_prompts.md
index b1e0d14..3425af6 100644
--- a/README_prompts.md
+++ b/README_prompts.md
@@ -13,3 +13,23 @@ graphRAG在商品搜索中如何使用？我想将他用于，对商品的模糊
 
 
 2. 我希望参考analyze_image_style加上一个动态的图片分析，调用两轮大模型，第一轮的目的是让大模型根据对话历史分析要提取哪些信息，加载背景（时尚购物），加载对话历史，调用语言大模型，要求根据对话意图了解需要从图片中了解哪些信息，注意，图片中的具体内容、具体的产品、颜色、分隔、主要特性等等时尚领域的描述都要加上，根据对话上下文在这些通用的提取内容上加上特别要关注的内容，第二轮则是根据这些提取的需求调用多模态大模型。可以配置化，对于图片内容的分析调用analyze_image_style还是动态的分析，暂时使用analyze_image_style。
+
+
+
+
+
+
+
+
+
+
+
+系统提示词，要指导，根据搜索结果判断可以直接引用搜索结果呈现给用户还是需要修改query重新规划搜索。搜索也应该是一整套方案，可以发起多个query。
+搜索工具层面，对于搜索结果要调用LLM判断，分析top20条结果，为每条结果打标签，分三种层级：完美匹配、部分匹配、不相关，最后给出top20的一个总体的判断。
+彻底替代 extract_products_from_response，引入结果仓库（Result Registry），用于存储SearchResult，为可呈现的“引用包/搜索结果块”。
+引用应该是嵌套在文本中，比如：我为你挑选了xxx（引用的搜索结果块 页面上将呈现query和结果列表），考虑到xxx，也挑选了（引用的搜索结果块2），接下来你可以：xxx
+
+以上纯属示例，表示搜索结果块是可以在输出文本中被引用的。并且，提示词也要通用，不要为我的个例所影响，要考虑如何做到通用，适合各种电商品类。
+
+请深度思考如何让 最终 AI 消息 可以引用某次搜索的结果，而不是重新复述，并且废除extract_products_from_response这种方法。要规划一套健全的商品搜索结果的管理、和引用的方法。
+
diff --git a/app.py b/app.py
index 2b9e2e7..6a5560c 100644
--- a/app.py
+++ b/app.py
@@ -33,10 +33,8 @@ st.set_page_config(
 st.markdown(
     """
     <style>
-    /* Hide default Streamlit elements */
-    #MainMenu {visibility: hidden;}
-    footer {visibility: hidden;}
-    header {visibility: hidden;}
+    /* Show default Streamlit elements (sidebar toggle, etc.) */
+    /* #MainMenu, footer, header no longer hidden */
     
     /* Body and root container */
     .main .block-container {
@@ -505,7 +503,7 @@ def display_message(message: dict):
 
             # Create exactly 3 columns with equal width
             cols = st.columns(3)
-            for j, product in enumerate(products[:3]):  # Ensure max 3
+            for j, product in enumerate(products[:9]):  # Ensure max 3
                 with cols[j]:
                     display_product_card(product)
         else:
diff --git a/app/tools/search_tools.py b/app/tools/search_tools.py
index c0a081f..f2b77e1 100644
--- a/app/tools/search_tools.py
+++ b/app/tools/search_tools.py
@@ -166,15 +166,12 @@ def search_products(query: str, limit: int = 5) -> str:
             specs = product.get("specifications", [])
             if specs:
                 color_spec = next(
-                    (s for s in specs if s.get("name") == "color"),
+                    (s for s in specs if s.get("name").lower() == "color"),
                     None,
                 )
                 if color_spec:
                     output += f"   Color: {color_spec.get('value', 'N/A')}\n"
 
-            if product.get("relevance_score") is not None:
-                output += f"   Relevance: {product['relevance_score']:.2f}\n"
-
             output += "\n"
 
         return output.strip()
diff --git a/docs/openclaw.md b/docs/openclaw.md
new file mode 100644
index 0000000..e0124cd
--- /dev/null
+++ b/docs/openclaw.md
@@ -0,0 +1,196 @@
+# OpenClaw 源码技术方案解读
+
+> 面向源码阅读者的技术剖析：从 CLI 入口、Gateway 控制面、渠道插件、路由与会话、Agent 执行到媒体与安全。
+
+## 1. 总体架构（控制面 + 执行面）
+
+OpenClaw 把系统拆成两层：
+
+- **Gateway 控制面**：统一承载 WebSocket/HTTP、方法分发、客户端连接、鉴权、配置热重载、渠道生命周期。
+- **Agent/Channel 执行面**：负责模型调用、会话持久化、消息路由、跨渠道发送、媒体处理、插件扩展。
+
+这种设计把“系统连接与治理”与“具体业务执行”分离，便于在不改动主干的前提下持续增加新渠道和新能力。
+
+## 2. CLI 启动链：轻入口 + 按需加载命令
+
+`src/index.ts` 作为统一入口，先做运行时守护（环境变量归一化、运行时版本检查、全局异常处理），再交给 Commander 程序对象解析命令。核心思路是：**先把运行环境稳定，再执行命令逻辑**。
+
+CLI 命令注册使用“延迟加载”策略：`registerCoreCliCommands` 会先挂占位命令，在真正执行时动态 `import` 对应模块并二次解析参数。这显著降低了冷启动成本，也能避免一次性加载全部命令依赖。
+
+## 3. Gateway 服务器：集中式编排器
+
+`startGatewayServer` 是系统级编排入口，启动前会串行处理：
+
+1. 读取并迁移历史配置；
+2. 校验配置合法性并补齐启动鉴权；
+3. 自动启用满足条件的插件；
+4. 组装基础能力 + 渠道插件能力形成完整方法集；
+5. 构建运行时状态（鉴权、限流、心跳、节点、插件、通道、发现服务等）；
+6. 挂载 WS 处理器并对外广播统一事件。
+
+这让 Gateway 成为“单一控制平面”：无论来自 CLI、WebChat、桌面端还是移动端，最终都走同一套 RPC/Event 协议。
+
+## 4. 方法协议：基础方法 + 插件方法拼接
+
+`server-methods-list.ts` 维护内置方法集合（如 `agent`、`send`、`channels.status`、`node.invoke`、`chat.send`），再合并渠道插件额外暴露的方法，形成完整 capability 列表。
+
+这相当于“内核 API + 扩展 API”模型：内核保持稳定，插件在边界内扩展。
+
+## 5. 渠道插件体系：注册表驱动
+
+渠道并不是硬编码在主流程中，而是通过插件注册表统一管理。`listChannelPlugins` 从活动插件注册表读取渠道定义并排序输出；Gateway 在启动时基于这些定义动态创建日志上下文、运行时环境与方法集合。
+
+这意味着新增渠道的关键不是修改核心 switch-case，而是实现符合接口的插件并注册，整体可维护性更好。
+
+## 6. 渠道生命周期管理：可观测 + 自恢复
+
+`createChannelManager` 负责渠道账户的启动/停止/状态维护，具备：
+
+- 多账户粒度运行时快照；
+- 启动前配置完整性检查；
+- 崩溃后指数退避重启；
+- 手动停用后禁止自动拉起；
+- 统一暴露运行状态给上层 health/status。
+
+这套机制让各渠道实现从“业务代码”中抽离，收敛到统一的运维语义。
+
+## 7. 路由与会话键：多维绑定解析
+
+`resolve-route.ts` 把输入上下文（channel/account/peer/guild/team/roles）映射到目标 agent 与 sessionKey。其本质是一套优先级匹配规则：
+
+- peer 精确匹配；
+- parent peer 继承；
+- guild + roles；
+- guild/team/account/channel；
+- 默认 agent 回退。
+
+并且它带有按 `channel+account` 的评估缓存，避免在高频消息场景重复解析绑定规则。
+
+## 8. Agent 执行：Gateway 方法到模型调用
+
+Gateway 侧 `agent` 方法会完成请求校验、幂等处理、附件规范化、会话键解析与重置语义，然后调用 `agentCommand` 执行一次 Agent turn。
+
+`agentCommand` 再根据模型/Provider/思考等级/会话状态选择执行路径：
+
+- CLI Provider 走 `runCliAgent`；
+- 内嵌执行走 `runEmbeddedPiAgent`；
+- 并支持模型回退、会话更新、事件发射、结果投递。
+
+因此 OpenClaw 的 Agent 调用并不是“直接请求模型”，而是带有会话与路由语义的受控执行流水线。
+
+## 9. Outbound 抽象：优先插件动作，回退核心发送
+
+`outbound-send-service.ts` 体现了一个关键策略：
+
+1. 先尝试调用渠道插件动作（send/poll）；
+2. 插件未处理时回退到核心 `sendMessage/sendPoll`；
+3. 在发送链路中支持中断信号、镜像写回会话、网关上下文。
+
+这保证了不同渠道可做差异化实现，同时保留统一兜底路径。
+
+## 10. 媒体管线：安全优先
+
+`media/store.ts` 中可见明显的“安全默认”策略：
+
+- 限制协议仅 HTTP/HTTPS；
+- 使用 SSRF 防护与主机名解析钉扎；
+- 限制文件大小（默认 5MB）；
+- 临时目录权限收紧（700/600）；
+- 文件名净化与过期清理；
+- 安全读取本地文件并映射错误类型。
+
+这使媒体能力在可用性与安全性间取得平衡。
+
+## 11. 配置系统：JSON5 + 兼容迁移 + 环境变量注入
+
+`config/io.ts` 不是简单读写配置文件，而是完整的配置编排层：
+
+- 支持 JSON5；
+- include/merge patch/env 引用替换；
+- 默认值补全、路径归一化、版本迁移；
+- 写入审计与备份轮转；
+- 与插件 schema 联合校验。
+
+这套机制让 OpenClaw 能在长期迭代中保持配置向后兼容。
+
+## 12. 具体案例：从用户一句话到系统动作链
+
+下面用两个典型请求，说明 OpenClaw 在真实场景里会触发什么动作。
+
+### 案例 A："帮我在 GitHub 搜索 xx 相关项目，筛选能迁移到 xx 的方案，仔细阅读并讲技术方案和关键代码"
+
+这个需求不是一次普通问答，而是一条“检索 -> 过滤 -> 深读 -> 结构化输出”的多阶段流水线。典型动作链如下：
+
+1. **消息入站**
+   用户消息通过 Telegram/Discord/WebChat 等渠道进入 Gateway；渠道插件先归一化消息、账户信息、线程信息，再转为统一 `agent` 请求。
+2. **会话与目标 agent 解析**
+   路由层用 channel/account/peer/thread 上下文解析 `agentId + sessionKey`，把任务绑定到既有会话（避免每轮丢上下文）。
+3. **请求校验与幂等**
+   Gateway `agent` handler 校验参数、附件、渠道合法性和幂等键，然后把任务交给 `agentCommand`。
+4. **任务规划（Agent 内部）**
+   Agent 将原句拆成可执行子任务，例如：
+   - 关键词扩展（xx 的同义词、上下游术语）；
+   - 候选项目召回（stars/更新时间/语言/许可证）；
+   - 迁移可行性筛选维度（架构耦合度、依赖复杂度、部署形态、数据模型兼容性）；
+   - 深读清单（README、docs、核心目录、关键 entrypoint）。
+5. **候选项目检索**
+   Agent 通过浏览器或 HTTP 工具抓取 GitHub 搜索页/项目页，得到候选仓库列表与基础元信息。
+6. **第一轮筛选（可迁移性粗筛）**
+   基于显性信号先过滤：
+   - 是否活跃维护；
+   - 是否与目标技术栈接近；
+   - 是否有可运行示例与清晰模块边界；
+   - 许可证是否满足使用场景。
+7. **第二轮深读（代码级）**
+   对入围项目进行“关键代码阅读”：
+   - 定位入口文件与启动链；
+   - 识别核心模块边界与数据流；
+   - 抽取关键实现片段（例如路由层、调度层、插件层、存储抽象层）；
+   - 记录迁移风险（强绑定云服务、隐式全局状态、非标准构建流程）。
+8. **输出构建**
+   Agent 生成结构化结论：
+   - 项目对比表（适配度/迁移成本/风险）；
+   - 每个项目的技术方案摘要；
+   - 关键代码位置与原因说明（为什么这段代码关键）；
+   - 推荐优先级与迁移路径建议（PoC -> 灰度 -> 全量）。
+9. **结果发送与会话沉淀**
+   结果经 outbound 发送到原渠道（插件优先、核心兜底），并写入会话 transcript。后续用户说“把第 2 个项目展开到模块级改造方案”时，可直接沿用当前上下文继续执行。
+
+#### 这个案例在系统内触发的关键机制
+
+- **Gateway 控制面**：统一承接请求、鉴权、方法分发。
+- **路由层**：保证请求进入正确 agent/session。
+- **Agent 执行层**：负责任务分解与工具编排。
+- **Outbound 层**：统一回传，不同渠道差异由插件吸收。
+- **会话存储层**：沉淀中间结论与最终报告，支撑多轮深挖。
+
+### 案例 B："在 Twitter 上搜集 xx 相关信息，写一篇调查报告"
+
+一个典型执行链如下：
+
+1. **请求入站与鉴权**
+   用户请求到达 Gateway 后，先经过鉴权与方法白名单控制。
+2. **任务分解**
+   Agent 将任务拆成“检索关键词集合、时间窗口、可信账号优先级、去重规则、证据归档格式”。
+3. **数据采集**
+   通过浏览器/HTTP 等工具抓取公开推文、线程、外链文章与引用关系，必要时抓页面快照做证据留存。
+4. **清洗与聚类**
+   依据主题、立场、时间线、传播强度进行聚类，过滤明显噪声与重复转发。
+5. **报告生成**
+   输出“事实层（发生了什么）+ 观点层（各方怎么说）+ 风险层（哪些结论证据不足）+ 建议层（下一步怎么验证）”。
+6. **多渠道投递**
+   按当前会话策略发送到用户指定渠道；如果是群聊线程，还会带上 thread 信息以保持上下文连续。
+
+### 两个案例背后的共性机制
+
+- **同一控制面**：不管是 GitHub 调研还是 Twitter 调研，都是同一条 Gateway RPC/Event 主干。
+- **同一路由语义**：都通过 sessionKey/agentId 保证上下文连续，而不是每次“无状态回答”。
+- **同一执行模式**：都属于“规划 -> 工具调用 -> 归纳输出”的 agentic 工作流。
+- **同一发送抽象**：都走 outbound 统一接口，渠道差异由插件吸收。
+- **同一安全基线**：媒体下载、外链抓取、文件读写都受限于安全策略（协议、大小、路径、SSRF）。
+
+## 13. 一句话总结
+
+OpenClaw 的核心技术方案可以概括为：
+
+**“以 Gateway 为统一控制面，以插件与路由为扩展骨架，以 Agent 会话语义为执行核心，并在媒体/配置层默认内建安全与可运维能力。”**
diff --git a/offline/product_understanding/graphRAG-服装领域提取字段.md b/offline/product_understanding/graphRAG-服装领域提取字段.md
new file mode 100644
index 0000000..fa498d9
--- /dev/null
+++ b/offline/product_understanding/graphRAG-服装领域提取字段.md
@@ -0,0 +1,93 @@
+# 一、基础层（商品基础标识信息）
+
+用于唯一标识商品及其基础分类信息，是所有结构化与检索能力的基础。
+
+| English Field | 中文字段名 | 字段说明                                 |
+| ------------- | ----- | ------------------------------------ |
+| id            | 商品ID  | 商品的唯一标识符，用于系统索引、关联与去重                |
+| title         | 商品标题  | 商品原始标题文本，用于全文检索与语义理解                 |
+| title_cn      | 中文标题  | 商品中文标题，用于中文搜索与展示                     |
+| category_path | 类目路径  | 商品所属标准类目层级，如“女装>连衣裙>碎花裙”，用于基础筛选与结构组织 |
+
+---
+
+# 二、风格层（风格表达与审美定位）
+
+用于表达商品整体审美倾向与风格标签，是构建风格社区与模糊风格搜索的核心层。
+
+| English Field   | 中文字段名 | 字段说明                                 |
+| --------------- | ----- | ------------------------------------ |
+| style_primary   | 主风格   | 商品最核心的风格类型，如清新、法式、极简、甜美等，用于风格聚合与概览生成 |
+| style_secondary | 次风格   | 商品的补充风格标签，用于细分风格组合与多维交叉              |
+| tags            | 标签    | 运营或营销类标签，包含趋势词或活动词，不作为核心结构依据         |
+
+---
+
+# 三、结构层（服装版型与剪裁结构）
+
+用于描述服装的物理结构与轮廓形态，是影响穿着效果与身材适配的核心维度。
+
+| English Field | 中文字段名   | 字段说明                                  |
+| ------------- | ------- | ------------------------------------- |
+| silhouette    | 版型 / 廓形 | 服装整体轮廓结构，如A字、H型、伞裙、直筒、修身等，决定整体线条与风格表达 |
+| length        | 长度      | 服装长度分类，如短款、中长款、长款、拖地等，影响视觉比例与适用场景     |
+| neckline      | 领型      | 领口形态，如圆领、V领、方领、一字肩等，影响风格与脸型修饰效果       |
+| sleeve_type   | 袖型      | 袖子结构类型，如无袖、短袖、泡泡袖、灯笼袖等，影响风格表达与季节属性    |
+
+---
+
+# 四、材质层（面料成分与质感特征）
+
+用于描述服装的材质构成与触感视觉质感，是风格表达与穿着体验的重要来源。
+
+| English Field  | 中文字段名 | 字段说明                         |
+| -------------- | ----- | ---------------------------- |
+| material       | 材质    | 面料成分，如棉、麻、雪纺、聚酯等，体现服装基本材料属性  |
+| fabric_texture | 面料质感  | 面料触感或视觉质感特征，如轻薄、垂坠、挺括、柔软、透气等 |
+
+---
+
+# 五、视觉层（颜色与图案表现）
+
+用于描述商品的视觉呈现特征，是风格判断与模糊审美搜索的重要依据。
+
+| English Field | 中文字段名 | 字段说明                            |
+| ------------- | ----- | ------------------------------- |
+| main_color    | 主色系   | 商品主要颜色类别，如白色、浅蓝、粉色等，用于基础视觉筛选    |
+| color_tone    | 色调风格  | 颜色整体倾向，如低饱和、莫兰迪、马卡龙、亮色系、深色系等    |
+| pattern       | 图案    | 图案类型，如纯色、碎花、条纹、格纹、波点等，影响风格与视觉层级 |
+
+---
+
+# 六、功能层（穿着功能与修饰效果）
+
+用于表达服装的功能属性与身材修饰能力，是推荐解释与个性化匹配的重要依据。
+
+| English Field          | 中文字段名 | 字段说明                        |
+| ---------------------- | ----- | --------------------------- |
+| features               | 功能特性  | 功能性描述，如透气、抗皱、有弹力、防走光等       |
+| body_flattering_points | 修饰效果  | 对身材的修饰优势，如遮胯、显腰线、拉长比例、显腿长等  |
+| suitable_body_type     | 适合体型  | 适合的体型类型，如梨形、苹果型、小个子、高个子、微胖等 |
+
+---
+
+# 七、场景层（使用环境与人群定位）
+
+用于描述商品适用的使用情境与目标人群，是场景化推荐与风格细分的重要维度。
+
+| English Field   | 中文字段名 | 字段说明                  |
+| --------------- | ----- | --------------------- |
+| usage_scene     | 使用场景  | 适用场景，如通勤、约会、度假、校园、日常等 |
+| season          | 适用季节  | 适合穿着的季节，如春、夏、秋、冬      |
+| target_audience | 目标人群  | 主要面向人群，如女性、学生、通勤人群等   |
+
+---
+
+# 八、补充层（扩展与营销信息）
+
+用于承载未归类属性与营销性表达，不作为核心结构依据。
+
+| English Field  | 中文字段名 | 字段说明                  |
+| -------------- | ----- | --------------------- |
+| key_attributes | 关键属性  | 未归类的补充结构特征，用于承载长尾属性信息 |
+| selling_points | 卖点描述  | 商品营销性文案，用于增强展示与转化表达   |
diff --git a/offline/product_understanding/graphRAG.md b/offline/product_understanding/graphRAG.md
new file mode 100644
index 0000000..2b7f249
--- /dev/null
+++ b/offline/product_understanding/graphRAG.md
@@ -0,0 +1,158 @@
+
+## 需求
+graphRAG在商品搜索中如何使用？我想将他用于，对商品的模糊查询。
+离线输出处理端：
+我们的商品没有格式化的类别标签等字段，可以用大模型进行提取 风格 类别 标签 材质 功能特性 等，但是问题是：他们表达形式各异，如果要做成一个体系、做归一化，成本较高。
+在线端：用户的搜索可能是模糊搜索，比如，给我找找清新风格的裙子，那么通过关键词搜索是比较差的，基于graphrag的思想如果能够得到“清新”分隔的商品集合的一个概览，就很好，直到当前店铺的“清新”风格有哪些可供选择，有哪些重要的考虑点，再进一步匹配看有哪些适合我的。
+请帮我广泛的搜索有哪些相关的技术资料或者开源项目
+
+
+## GraphRAG 能解决什么（对齐你的痛点）
+
+你描述的关键不是“找到某条商品信息”，而是两类更难的需求：
+
+1. **概览型/全局型问题（Global query）**
+   “清新风格在这个店铺里大概有哪些类型？有哪些重要考虑点？有哪些代表款？”
+   这类问题用纯向量检索/关键词检索很容易“只给一堆相似商品”，但缺少“总结 + 结构化概览”。GraphRAG 的强项就是把语料（这里是商品文本/卖点/详情）组织成**图 + 社区（community）+ 社区摘要**，用摘要回答概览型问题。([arXiv][1])
+
+2. **弱结构/弱标签的数据组织**
+   你们没现成的类目/风格/材质等字段，且表达形式各异；要强行做完整归一化成本高。
+   GraphRAG 的一个现实落点是：**不追求先把全量字段“统一成完美本体”**，而是先用 LLM 做抽取→把“相近概念/表述”通过 embedding 聚合成图上的节点群/社区→对社区做摘要，形成“可解释的风格集合概览”。([microsoft.github.io][2])
+
+---
+
+## 2) 一套“低归一化成本”的 GraphRAG 商品搜索架构（建议落地路径）
+
+### 离线：从商品文本构建“风格/要素图谱 + 社区摘要”
+
+**输入**：商品标题、卖点、详情、评价要点、图文描述（可选）、店铺活动文案等。
+**目标**：让“清新”这种概念能对应到一组社区摘要（概览），再能落到代表商品（实例）。
+
+**步骤建议：**
+
+1. **抽取候选要素（不强求统一）**
+   用 LLM 从每个商品里抽取：风格、版型、场景、材质、颜色倾向、功能特性等（先允许多样表达）。
+   如果你担心一致性，可以先用“属性-值对”的范式抽取（attribute-value），后面再聚类。相关研究专门讨论了“抽取 + 归一化”的提示模板和基准数据集（WDC-PAVE）。([arXiv][3])
+
+2. **轻量归一化：embedding 聚类 / 同义聚合（比手工本体便宜很多）**
+   把候选要素值（如“清新/清爽/小清新/森系清新/干净感”）做向量化→聚类→形成“概念簇节点”。
+   你不需要一次性定标准名，可以先给每个簇一个“LLM 生成的簇摘要+别名列表”，逐步迭代。
+
+3. **建图（Product ↔ 概念簇 ↔ 属性类型）**
+
+* 商品节点（SKU/SPU）
+* 概念簇节点（如“清新感-风格簇”“棉麻-材质簇”）
+* 属性类型节点（风格/材质/场景…）
+  边：商品—(has_style)—风格簇；商品—(has_material)—材质簇…
+
+4. **社区发现 + 社区摘要（GraphRAG 核心）**
+   在图上做 community detection，把高度相关的概念簇 + 商品群组织起来，并为每个社区预生成摘要（“这个社区代表的清新风格通常有哪些元素、适合什么人群/场景、避坑点、代表商品类型…”）。这就是你想要的“清新商品集合概览”。([arXiv][1])
+
+> 这套流程，Microsoft GraphRAG 的 indexing pipeline 就是面向“从非结构化文本抽结构化信息并形成可检索结构”的。([microsoft.github.io][2])
+
+---
+
+### 在线：模糊查询“清新风格的裙子”怎么答得又准又像导购
+
+可以把在线请求拆成“两段式”：
+
+1. **先做全局概览（global）**
+   识别用户意图：想看“清新”在店里有哪些主要分支（比如：棉麻清新、法式清新、学院清新、通勤清新…）
+   → 在图上找到与“清新”最相关的社区（支持动态选择社区/层级的思路也有官方文章介绍）
+   → 返回：概览摘要 + 关键考虑点（材质、场景、版型、透/不透、打理成本…）+ 每个分支 3–5 个代表商品。([微软][4])
+
+2. **再做个性化检索（local）**
+   根据用户补充条件（预算/身高/场景/偏好）
+   → 在对应社区内做“局部检索”：hybrid（BM25+向量）+ 结构化过滤（材质簇/场景簇）
+   → 输出更精准的候选列表，并解释“为什么这些更像你要的清新”。
+
+---
+
+## 3) 你要的：相关技术资料 & 开源项目（按用途分组）
+
+### A. GraphRAG 体系与实现（核心必看）
+
+* **microsoft/graphrag（官方开源）**：GraphRAG 的模块化实现与 pipeline 思路（indexing + querying）。([GitHub][5])
+* **Microsoft Research Blog 系列（原理 + 全局搜索/社区选择等）**：理解“global query 为何需要社区摘要、动态社区选择”等。([microsoft.github.io][6])
+* **论文：From Local to Global: A Graph RAG Approach…（GraphRAG 经典论文）**：两阶段建图 + 社区摘要的原型描述，非常贴你“先概览再细搜”的需求。([arXiv][1])
+* **GraphRAG Survey（综述）**：想系统盘点组件（query processor / retriever / organizer / generator）可以看这个。([arXiv][7])
+
+### B. 工程化工具链：用现成框架快速搭原型
+
+* **LlamaIndex GraphRAG（PropertyGraph cookbook）**：有一套可跑的 GraphRAG pipeline 示例，适合你快速 PoC。([developers.llamaindex.ai][8])
+* **LangChain Graph RAG retriever**：把“向量相似检索 + 结构化遍历”组合成 retriever 的集成入口。([docs.langchain.com][9])
+* **Neo4j GraphRAG Python 包（+ GitHub）**：偏“图数据库落地”的路线，提供 KG 构建管道、向量检索器、Cypher 检索器等。([neo4j.ac.cn][10])
+* **一个资源汇总仓库 Graph-RAG/GraphRAG**：把 GraphRAG 相关论文/工具做了分类整理，找资料很省时间。([GitHub][11])
+
+### C. “商品要素抽取/归一化”相关（你离线端的关键难题）
+
+* **Using LLMs for the Extraction and Normalization of Product Attribute Values（+ WDC-PAVE）**：专门研究“从商品文本抽取属性值并做归一化”，非常对症。([arXiv][3])
+* **Explicit Attribute Extraction in e-Commerce Search（ECNLP@LREC-COLING 2024）**：更偏“从搜索 query 抽属性值”，对在线端 query understanding 很有帮助。([ACL Anthology][12])
+
+### D. 线上检索底座（GraphRAG 之外，你一定会搭配的“混合检索/排序”）
+
+因为你最终仍要落到“给一组商品候选”，强烈建议 GraphRAG 的“概览/组织”层下面，接一个成熟的 hybrid 检索引擎：
+
+* **Vespa（开源，电商 sample apps + hybrid tutorial）**：电商搜索/排序是它的强项，有示例应用与 LTR 思路。([GitHub][13])
+* **Weaviate Hybrid Search（BM25 + vector）**：混合检索文档齐全，也有 OpenAI cookbook 示例。([Weaviate 文档][14])
+* **Hybrid Search 评测工具（GitHub）**：如果你要比较不同 embedding / 融合策略，这类基准框架能省很多时间。([GitHub][15])
+
+---
+
+## 4) 一个“最小可行 PoC”建议（能最快验证价值）
+
+如果你只想先证明“清新概览”这件事能跑通：
+
+1. 选一个类目（裙子）+ 1–3 万商品文本
+2. LLM 抽取：风格/材质/场景/版型（先不做强归一化）
+3. embedding 聚类：把风格值聚成 50–200 个簇
+4. 建图 + 社区摘要（直接用 microsoft/graphrag 或 LlamaIndex cookbook 跑通）([GitHub][5])
+5. 在线输入：“清新风格的裙子”
+   输出：
+
+* 清新在店铺内的 3–6 个分支（社区摘要）
+* 每个分支的 3–5 个代表商品
+* 2–4 条“挑选考虑点/避坑点”（来自社区摘要）
+
+只要这一步用户觉得“像导购一样把清新讲清楚了”，再去补“更精细的过滤/排序/个性化”。
+
+
+## 服装领域字段选择
+
+
+基础层：
+- id
+- title
+- category_path
+
+风格层：
+- style_primary
+- style_secondary
+
+结构层：
+- silhouette
+- length
+- neckline
+- sleeve_type
+
+材质层：
+- material
+- fabric_texture  （棉麻感 / 轻薄 / 垂坠）
+
+视觉层：
+- main_color
+- color_tone
+- pattern
+
+功能层：
+- features
+- body_flattering_points
+
+场景层：
+- usage_scene
+- season
+- target_audience
+
+补充层：
+- selling_points
+- key_attributes
--
libgit2 0.21.2