基于NLP的软件产品需求特性抽取技术咨询：Stanford Open IE应用问题

Hey there! Let me share some targeted thoughts and solutions based on your work building an information extraction app for software product feature extraction—where features are defined as user-visible aspects of a product.

1. Why POS Tagging Makes Sense (But Can Be Enhanced) #

Starting with parts-of-speech tagging is a solid foundation, since it helps identify core word types (nouns, verbs, adjectives) that form your Actor-Action-Object (AAO) triples. That said, pairing POS tagging with dependency parsing can add more context: it maps how words relate to each other (e.g., which noun is the subject of a verb, which phrase modifies an object) — this helps reduce ambiguity when building AAO triples, especially in complex sentences.

2. Common Pitfalls with Stanford Open IE (And How to Fix Them) #

You mentioned issues with Stanford Open IE's AAO outputs. From my experience, these usually fall into a few categories, with straightforward fixes:

• Misidentified Actors: The tool might pick up modifiers or secondary subjects instead of the core product/system. Fix this by adding a rule set that prioritizes actors like "system", "product", "app", or your target product's name. For example, filter out triples where the actor isn't in a predefined list of product-related entities.
• Vague or Irrelevant Actions: Open IE might extract verbs that don't relate to user-visible features (e.g., "runs" instead of "supports"). Create a domain-specific verb list focused on user-facing actions: "supports", "provides", "allows", "offers", "enables", etc. Only keep triples with verbs from this list.
• Incomplete/Inaccurate Objects: The tool might truncate important details (e.g., extracting "credit card" instead of "Visa credit card"). Solve this by integrating a software feature term dictionary (build one with terms like "payment method", "one-click refund", "user dashboard") — use this to expand or correct extracted objects to match full, meaningful feature phrases.
• Missing Actors in Implicit Sentences: Sentences like "Supports contactless payments" lack a clear actor. Add a fallback rule to assign the target product as the actor for these cases.

3. Post-Processing for Cleaner Triples #

Even with fixes, Stanford Open IE might output noisy triples. Add a post-processing step to:

• Merge duplicate or highly similar triples (e.g., (System, supports, credit card) and (System, supports, payment via credit card))
• Correct obvious errors (e.g., swapping actor and object if the triple doesn't make sense for your feature definition)
• Filter out triples that don't align with "user-visible" — for example, exclude any triple about internal system processes (e.g., (System, uses, database))

Quick Example Workflow #

Let’s walk through how this would work with a sample sentence:

"This project management tool allows team members to assign tasks and provides a real-time progress dashboard."

1. POS + Dependency Parsing: Identifies "tool" as the core subject, "allows" and "provides" as key verbs, "assign tasks" and "real-time progress dashboard" as objects.
2. Stanford Open IE Extraction: Might output (tool, allows, assign tasks) and (tool, provides, real-time progress dashboard).
3. Post-Processing: Confirms these align with user-visible features, keeps them, and discards any irrelevant triples the tool might generate.

内容的提问来源于stack exchange，提问作者Tayyab